A little Game/Quiz: Do you see my values? (Interpreting Hex-Values) - bluetooth

Okay I need some Help... I got a bluetooth-le-weight-scale. I can connect my Raspberry Pi to this scale and get some data. But its not easy for me to read my values in this hex-salad.
After every measurement I get two lines of Information, which should contain my values
(I simulated all measurements ... Person 5 is just me pushing my hands on the scale .. Person 2 + 3 is me wearing socks on the scale, so no need to give me some medical advices if you find some unrealistic values :D )
Scale: starts with 5.0kg(officaly, but i can see a 4.9 as starting point), Max 180kg (this could be just a safety note. its a glass-scale), d = 100g
what I noted from the Display:
# | Person | m kg| Fat % | TbW % | Mus % | Bone kg | kcal | BMI
1 | 5 |13,3 | 5 | 72,7 | 60,1 | 0,8 | 1056 | 13,3
2 | 3 |73,6 | 26,3 | 51,1 | 34,2 | 3,5 | 2428 | 24,3
3 | 2 |76,8 | 18,5 | 61,1 | 41,9 | 3,4 | 2741 | 24,8
4 | 5 |15,0 | 5 | 70,3 | 58,4 | 0,9 | 1092 | 15,0
5 | 6 | 5,1 | 5 | 73 | 66,5 | 0,5 | 881 | 5,1
What I received via Bluetooth:
# | handle | Byte 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18
-----------------------------------------------------------------------------
1 | 0x001b | value: 1d 32 05 00 fe 0f 13 11 11 01 12 00 ff 05 09 00 00 00 00
1 | 0x001e | value: 6f 0f 13 11 11 05 20 04 32 f0 d7 f2 59 f2 08 f0 00 00 00
-----------------------------------------------------------------------------
2 | 0x001b | value: 1d c0 1c 00 fe 45 06 00 00 7a 13 00 ff 03 09 00 00 00 00
2 | 0x001e | value: 6f 45 06 00 00 03 7c 09 07 f1 ff f1 56 f1 23 f0 00 00 00
-----------------------------------------------------------------------------
3 | 0x001b | value: 1d 00 1e 00 fe 37 01 00 00 d7 12 00 ff 02 09 00 00 00 00
3 | 0x001e | value: 6f 37 01 00 00 02 b5 0a b9 f0 63 f2 a3 f1 22 f0 00 00 00
-----------------------------------------------------------------------------
4 | 0x001b | value: 1d dc 05 00 fe 80 14 11 11 83 18 00 ff 05 09 00 00 00 00
4 | 0x001e | value: 6f 80 14 11 11 05 44 04 32 f0 bf f2 48 f2 09 f0 00 00 00
-----------------------------------------------------------------------------
5 | 0x001b | value: 1d fe 01 00 fe 5c 15 11 11 ac 16 00 ff 06 09 00 00 00 00
5 | 0x001e | value: 6f 5c 15 11 11 06 71 03 32 f0 da f2 99 f2 05 f0 00 00 00
Note:
Each time before receiving the values, I have to send my scale a Unix-timestamp.. most of the times, I had just send 1111111111 or 0000000000 or something like that.. but I did not note what I send.. sorry..
there is always another incoming line where I spotted the user values, that are stored in the scale. So I think these are unimportant but maybe I'm wrong
P2, male, Height: 176cm, Age: 34
P3, female, Height: 174cm, Age: 23
P5, male, Height: 100cm, Age: 10
so maybe someone could tell me, like where I can find the Information that represents my weight. I just have spotted the person numbers
thanks for helping & greetings from germany


ok ok.. I solved it...
0x1b:
weight: byte: 1 & 2
timestamp: byte 5-8
person: byte 13
0x1e:
timestamp: byte 1-4
person: 5
kcal: 6 & 7
fat: 8 & 9
tbw: 10 & 11
muscle: 12 & 13
bone: 14 & 15


To add some more details:
values decode as unsigned integers, little endian. For some obscure reason the 2 byte (short) integers have a most significant nibble as 0xf.
Transmission starts off with indication 0x25 which contains the programmed properties of the person detected (i.e. weight is within +/- 2 kg of last measurement).
0x25:
person: byte 2
gender: byte 4 (1=male, 2=female)
age: byte 5
size: byte 6
activity: byte 8 (0=normal, 3=high)

Related

is a jpeg with a bogus huffman table recoverable?

I have a JPEG that is un-openable in any program:
Opening in Ubuntu Image Viewer yields:
Passing the photo through convert yields similar results:
$ convert corrupt.jpg out.jpg
convert.im6: Bogus Huffman table definition `corrupt.jpg' # error/jpeg.c/JPEGErrorHandler/316.
convert.im6: no images defined `out.jpg' # error/convert.c/ConvertImageCommand/3044.
Running the photo through exiftool yields:
ExifTool Version Number : 9.46
File Name : corrupt.jpg
Directory : .
File Size : 47 kB
File Modification Date/Time : 2015:04:11 01:31:14-07:00
File Access Date/Time : 2018:05:04 10:26:04-07:00
File Inode Change Date/Time : 2018:05:04 10:26:03-07:00
File Permissions : r--------
File Type : JPEG
MIME Type : image/jpeg
Comment : Y�.�.�..2..Q.Q.
Image Width : 640
Image Height : 480
Encoding Process : Baseline DCT, Huffman coding
Bits Per Sample : 8
Color Components : 3
Y Cb Cr Sub Sampling : YCbCr4:2:2 (2 1)
Image Size : 640x480
Un-corrupted photos containing similar image contents average 45-48k, so I reckon the photo data itself is inside this JPEG somewhere.
I hosted the photo on S3. You can download it w/ wget:
wget https://s3.amazonaws.com/jordanarseno.com/corrupt.jpg
I opened the file with hexedit and found the following:
the photo contents outside of the first few hundred bytes is randomly distributed enough to suggest it contains an image. i.e. I'm not seeing consecutive streams of 0's of F's.
it does in-fact start with the FF D8 file signature, as JPEGs ought to.
the next two bytes are not FF E0 or FF E1 like the list of file signatures says should correspond to JPEGs or JFIFs. Instead it isFF FE. Which, is in the table, but is listed as:
Byte-order mark for text file encoded in little-endian 16-bit Unicode
Transfer Format
not long after the FF FE, I see bytes whose ascii representation is: &'()*456789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz. Seems rather strange for a JPEG. What is this?
likewise, the ASCII string &'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz appears about 100 bytes later.
FF D9 (the JPEG terminator string) is in the file, but characters do appear after this terminator:
FF D9 5C 72 78 E0 7C 94 CD B2 9C FF 00 C4 BF 53 C0 E7 FE 41 D3 9C FF 00 E3 95 7C F1 B6 92 5F 7A 2B EB 54 AF BF E6 30 FD A0 7F CC 3B 53 E9 FF 00 40 F9 FF 00 F8 8A 4D F7 08 30
Switching over to Windows and using JPEGsnoop yields:
JPEGsnoop 1.8.0 by Calvin Hass
http://www.impulseadventure.com/photo/
-------------------------------------
Filename: [C:\corrupt.jpg]
Filesize: [47760] Bytes
Start Offset: 0x00000000
*** Marker: SOI (xFFD8) ***
OFFSET: 0x00000000
*** Marker: COM (Comment) (xFFFE) ***
OFFSET: 0x00000002
Comment length = 36
Comment=Y.Ò................à.....2..Q.Q...
*** Marker: DQT (xFFDB) ***
Define a Quantization Table.
OFFSET: 0x00000028
Table length = 132
----
Precision=8 bits
Destination ID=0 (Luminance)
DQT, Row #0: 3 2 2 3 4 7 9 10
DQT, Row #1: 2 2 2 3 4 10 10 9
DQT, Row #2: 2 2 3 4 7 10 12 10
DQT, Row #3: 2 3 4 5 9 15 14 11
DQT, Row #4: 3 4 6 10 12 19 18 13
DQT, Row #5: 4 6 9 11 14 18 19 16
DQT, Row #6: 8 11 13 15 18 21 21 17
DQT, Row #7: 12 16 16 17 19 17 18 17
Approx quality factor = 91.45 (scaling=17.09 variance=0.95)
----
Precision=8 bits
Destination ID=1 (Chrominance)
DQT, Row #0: 3 3 4 8 17 17 17 17
DQT, Row #1: 3 4 4 11 17 17 17 17
DQT, Row #2: 4 4 10 17 17 17 17 17
DQT, Row #3: 8 11 17 17 17 17 17 17
DQT, Row #4: 17 17 17 17 17 17 17 17
DQT, Row #5: 17 17 17 17 17 17 17 17
DQT, Row #6: 17 17 17 17 17 17 17 17
DQT, Row #7: 17 17 17 17 17 17 17 17
Approx quality factor = 91.44 (scaling=17.11 variance=0.19)
*** Marker: COM (Comment) (xFFFE) ***
OFFSET: 0x000000AE
Comment length = 5
Comment=...
*** Marker: SOF0 (Baseline DCT) (xFFC0) ***
OFFSET: 0x000000B5
Frame header length = 17
Precision = 8
Number of Lines = 480
Samples per Line = 640
Image Size = 640 x 480
Raw Image Orientation = Landscape
Number of Img components = 3
Component[1]: ID=0x01, Samp Fac=0x21 (Subsamp 1 x 1), Quant Tbl Sel=0x00 (Lum: Y)
Component[2]: ID=0x02, Samp Fac=0x11 (Subsamp 2 x 1), Quant Tbl Sel=0x01 (Chrom: Cb)
Component[3]: ID=0x03, Samp Fac=0x11 (Subsamp 2 x 1), Quant Tbl Sel=0x01 (Chrom: Cr)
*** Marker: DHT (Define Huffman Table) (xFFC4) ***
OFFSET: 0x000000C8
Huffman table length = 418
----
Destination ID = 0
Class = 0 (DC / Lossless Table)
Codes of length 01 bits (000 total):
Codes of length 02 bits (001 total): 00
Codes of length 03 bits (005 total): 01 02 03 04 05
Codes of length 04 bits (001 total): 06
Codes of length 05 bits (001 total): 07
Codes of length 06 bits (001 total): 08
Codes of length 07 bits (001 total): 09
Codes of length 08 bits (001 total): 0A
Codes of length 09 bits (001 total): 0B
Codes of length 10 bits (000 total):
Codes of length 11 bits (000 total):
Codes of length 12 bits (000 total):
Codes of length 13 bits (000 total):
Codes of length 14 bits (000 total):
Codes of length 15 bits (000 total):
Codes of length 16 bits (000 total):
Total number of codes: 012
----
Destination ID = 1
Class = 0 (DC / Lossless Table)
Codes of length 01 bits (000 total):
Codes of length 02 bits (003 total): 13 0E 0F
Codes of length 03 bits (001 total): 10
Codes of length 04 bits (001 total): 11
Codes of length 05 bits (001 total): 12
Codes of length 06 bits (001 total): 12
Codes of length 07 bits (012 total): 12 0B 0D 13 15 13 11 15 10 11 12 11
Codes of length 08 bits (016 total): 01 03 03 03 04 04 04 08 04 04 08 11 0B 0A 0B 11
Codes of length 09 bits (013 total): 11 11 11 11 11 11 11 11 11 11 11 11 11
Codes of length 10 bits (011 total): 11 11 11 11 11 11 11 11 11 11 11
Codes of length 11 bits (012 total): 11 11 11 11 11 11 11 11 11 11 11 01
Codes of length 12 bits (015 total): 01 01 01 01 00 00 00 00 00 00 01 02 03 04 05
Codes of length 13 bits (012 total): 06 07 08 09 0A 0B 10 00 02 01 03 03
Codes of length 14 bits (009 total): 02 04 03 05 05 04 04 00 00
Codes of length 15 bits (010 total): 01 7D 01 02 03 00 04 11 05 12
Codes of length 16 bits (014 total): 21 31 41 06 13 51 61 07 22 71 14 32 81 91
Total number of codes: 131
----
Destination ID = 1
Class = 10 (AC Table)
ERROR: Invalid DHT Class (10). Aborting DHT Load.
ERROR: Expected marker 0xFF, got 0x73 # offset 0x0000026C. Consider using [Tools->Img Search Fwd/Rev].
*** Searching Compression Signatures ***
Signature: 01FF5BA518B453CC8F224A4C85505196
Signature (Rotated): 01D13AFD01FF0B6EC46EA4081D25BB4D
File Offset: 0 bytes
Chroma subsampling: 2x1
EXIF Make/Model: NONE
EXIF Makernotes: NONE
EXIF Software: NONE
Searching Compression Signatures: (3347 built-in, 0 user(*) )
EXIF.Make / Software EXIF.Model Quality Subsamp Match?
------------------------- ----------------------------------- ---------------- --------------
CAM:[NIKON ] [NIKON D40 ] [FINE ] Yes
Based on the analysis of compression characteristics and EXIF metadata:
ASSESSMENT: Class 1 - Image is processed/edited
This may be a new software editor for the database.
If this file is processed, and editor doesn't appear in list above,
PLEASE ADD TO DATABASE with [Tools->Add Camera to DB]
*** Additional Info ***
NOTE: Data exists after EOF, range: 0x00000000-0x0000BA90 (47760 bytes)
As a last note, the EXIF.Model identified by JPEGSnoop is incorrect. This photo would have been taken with a VC0706 UART Model: LCF - 23T 0V528
In summary: Is this JPEG recoverable?

The approach used to get this back was more luck than judgement. I think I can explain, though be aware it involves a hex editor...
The Wikipedia page for the syntax of a JPEG file explains that it is made up of a series of segments each started by a two byte marker - 0xFF and another byte to indicate the type of segment.
The hope was that it was just the Huffman table segment of the file that was wrong - as suggested by the error message. Without needing to understand what a Huffman table is, it was enough to see that the same section on Wikipedia explains it is a 0xFF 0xC4 marker for a Huffman table segment.
Further down the page, it mentions:
The JPEG standard provides general-purpose Huffman tables; encoders
may also choose to generate Huffman tables...
Opening up a few other JPEG files found what looks like a standard set of 4 consecutive Huffman table segments - each starting with that 0xFF 0xC4 marker. The sample corrupt.jpg however just had one Huffman table - from position 0x00c8 to 0x02bc below.
(Both contain that &'()*56789:CDEFGHIJSTUVWXYZcdefghijstuvwxyz sequence you mentioned in their Huffman tables. In the corrupt file it appears twice in that single Huffman table, in the 'more conventional' JPEGs it appears in the second and fourth Huffman tables.)
From there, the fixed image is a copy and paste of the standard 4 Huffman tables, in place of that range of bytes in corrupt.jpg - now from 0x00c8 to 0x0278 in the fixed file.
Because the JPEG format is based around scanning for segments between those 0xff markers, you can just swap out the Huffman segments - there are no other pointers in the file to worry about. As you said, the rest of the file looked like a plausible JPEG.
Summary of the steps taken:
Hex search the corrupt.jpg for FF C4 and note the offset
Hex search for the next FF. If it's another FF C4 (so a second Huffman table) keep going
Delete the content from the first FF C4 (included) up to but not including the next FF
Instead replace it with the 'standard 4 Huffman tables'. These are the bytes in the last sample below, or can be copied from 0x00c8 to 0x0278 in the fixed file
Corrupt Huffman table:
0000-00d0: xx xx xx xx xx xx xx xx-ff c4 01 a2-00 00 01 05 !....... ........
0000-00e0: 01 01 01 01-01 01 00 00-00 00 00 00-00 00 01 02 ........ ........
0000-00f0: 03 04 05 06-07 08 09 0a-0b 01 00 03-01 01 01 01 ........ ........
0000-0100: 0c 10 0d 0b-0c 0f 0c 09-0a 0e 13 0e-0f 10 11 12 ........ ........
0000-0110: 12 12 0b 0d-13 15 13 11-15 10 11 12-11 01 03 03 ........ ........
0000-0120: 03 04 04 04-08 04 04 08-11 0b 0a 0b-11 11 11 11 ........ ........
0000-0130: 11 11 11 11-11 11 11 11-11 11 11 11-11 11 11 11 ........ ........
0000-0140: 11 11 11 11-11 11 11 11-11 11 11 11-11 11 11 11 ........ ........
0000-0150: 01 01 01 01-01 00 00 00-00 00 00 01-02 03 04 05 ........ ........
0000-0160: 06 07 08 09-0a 0b 10 00-02 01 03 03-02 04 03 05 ........ ........
0000-0170: 05 04 04 00-00 01 7d 01-02 03 00 04-11 05 12 21 ......}. .......!
0000-0180: 31 41 06 13-51 61 07 22-71 14 32 81-91 a1 08 23 1A..Qa." q.2....#
0000-0190: 42 b1 c1 15-52 d1 f0 24-33 62 72 82-09 0a 16 17 B...R..$ 3br.....
0000-01a0: 18 19 1a 25-26 27 28 29-2a 34 35 36-37 38 39 3a ...%&'() *456789:
0000-01b0: 43 44 45 46-47 48 49 4a-53 54 55 56-57 58 59 5a CDEFGHIJ STUVWXYZ
0000-01c0: 63 64 65 66-67 68 69 6a-73 74 75 76-77 78 79 7a cdefghij stuvwxyz
0000-01d0: 83 84 85 86-87 88 89 8a-92 93 94 95-96 97 98 99 ........ ........
0000-01e0: 9a a2 a3 a4-a5 a6 a7 a8-a9 aa b2 b3-b4 b5 b6 b7 ........ ........
0000-01f0: b8 b9 ba c2-c3 c4 c5 c6-c7 c8 c9 ca-d2 d3 d4 d5 ........ ........
0000-0200: d6 d7 d8 d9-da e1 e2 e3-e4 e5 e6 e7-e8 e9 ea f1 ........ ........
0000-0210: f2 f3 f4 f5-f6 f7 f8 f9-fa 11 00 02-01 02 04 04 ........ ........
0000-0220: 03 04 07 05-04 04 00 01-02 77 00 01-02 03 11 04 ........ .w......
0000-0230: 05 21 31 06-12 41 51 07-61 71 13 22-32 81 08 14 .!1..AQ. aq."2...
0000-0240: 42 91 a1 b1-c1 09 23 33-52 f0 15 62-72 d1 0a 16 B.....#3 R..br...
0000-0250: 24 34 e1 25-f1 17 18 19-1a 26 27 28-29 2a 35 36 $4.%.... .&'()*56
0000-0260: 37 38 39 3a-43 44 45 46-47 48 49 4a-53 54 55 56 789:CDEF GHIJSTUV
0000-0270: 57 58 59 5a-63 64 65 66-67 68 69 6a-73 74 75 76 WXYZcdef ghijstuv
0000-0280: 77 78 79 7a-82 83 84 85-86 87 88 89-8a 92 93 94 wxyz.... ........
0000-0290: 95 96 97 98-99 9a a2 a3-a4 a5 a6 a7-a8 a9 aa b2 ........ ........
0000-02a0: b3 b4 b5 b6-b7 b8 b9 ba-c2 c3 c4 c5-c6 c7 c8 c9 ........ ........
0000-02b0: ca d2 d3 d4-d5 d6 d7 d8-d9 da e2 e3-e4 e5 e6 e7 ........ ........
0000-02c0: e8 e9 ea f2-f3 f4 f5 f6-f7 f8 f9 fa-xx xx xx xx ........ ........
Then the next two bytes are ff dd for the start of the next segment:
0000-02c0: xx xx xx xx-xx xx xx xx-xx xx xx xx-ff dd 00 04 ........ ........
This was replaced with the standard 4 general-purpose Huffman tables instead - look for the ff c4 markers:
0000-00d0: xx xx xx xx xx xx xx xx-ff c4 00 1f-00 00 01 05 !....... ........
0000-00e0: 01 01 01 01-01 01 00 00-00 00 00 00-00 00 01 02 ........ ........
0000-00f0: 03 04 05 06-07 08 09 0a-0b ff c4 00-b5 10 00 02 ........ ........
0000-0100: 01 03 03 02-04 03 05 05-04 04 00 00-01 7d 01 02 ........ .....}..
0000-0110: 03 00 04 11-05 12 21 31-41 06 13 51-61 07 22 71 ......!1 A..Qa."q
0000-0120: 14 32 81 91-a1 08 23 42-b1 c1 15 52-d1 f0 24 33 .2....#B ...R..$3
0000-0130: 62 72 82 09-0a 16 17 18-19 1a 25 26-27 28 29 2a br...... ..%&'()*
0000-0140: 34 35 36 37-38 39 3a 43-44 45 46 47-48 49 4a 53 456789:C DEFGHIJS
0000-0150: 54 55 56 57-58 59 5a 63-64 65 66 67-68 69 6a 73 TUVWXYZc defghijs
0000-0160: 74 75 76 77-78 79 7a 83-84 85 86 87-88 89 8a 92 tuvwxyz. ........
0000-0170: 93 94 95 96-97 98 99 9a-a2 a3 a4 a5-a6 a7 a8 a9 ........ ........
0000-0180: aa b2 b3 b4-b5 b6 b7 b8-b9 ba c2 c3-c4 c5 c6 c7 ........ ........
0000-0190: c8 c9 ca d2-d3 d4 d5 d6-d7 d8 d9 da-e1 e2 e3 e4 ........ ........
0000-01a0: e5 e6 e7 e8-e9 ea f1 f2-f3 f4 f5 f6-f7 f8 f9 fa ........ ........
0000-01b0: ff c4 00 1f-01 00 03 01-01 01 01 01-01 01 01 01 ........ ........
0000-01c0: 00 00 00 00-00 00 01 02-03 04 05 06-07 08 09 0a ........ ........
0000-01d0: 0b ff c4 00-b5 11 00 02-01 02 04 04-03 04 07 05 ........ ........
0000-01e0: 04 04 00 01-02 77 00 01-02 03 11 04-05 21 31 06 .....w.. .....!1.
0000-01f0: 12 41 51 07-61 71 13 22-32 81 08 14-42 91 a1 b1 .AQ.aq." 2...B...
0000-0200: c1 09 23 33-52 f0 15 62-72 d1 0a 16-24 34 e1 25 ..#3R..b r...$4.%
0000-0210: f1 17 18 19-1a 26 27 28-29 2a 35 36-37 38 39 3a .....&'( )*56789:
0000-0220: 43 44 45 46-47 48 49 4a-53 54 55 56-57 58 59 5a CDEFGHIJ STUVWXYZ
0000-0230: 63 64 65 66-67 68 69 6a-73 74 75 76-77 78 79 7a cdefghij stuvwxyz
0000-0240: 82 83 84 85-86 87 88 89-8a 92 93 94-95 96 97 98 ........ ........
0000-0250: 99 9a a2 a3-a4 a5 a6 a7-a8 a9 aa b2-b3 b4 b5 b6 ........ ........
0000-0260: b7 b8 b9 ba-c2 c3 c4 c5-c6 c7 c8 c9-ca d2 d3 d4 ........ ........
0000-0270: d5 d6 d7 d8-d9 da e2 e3-e4 e5 e6 e7-e8 e9 ea f2 ........ ........
0000-0280: f3 f4 f5 f6-f7 f8 f9 fa-xx xx xx xx xx xx xx xx ........ .....(..

EMV: Second Generate AC Results in 6985 SW_Error Access condition not satisfied

I'm doing some EMV testing, and hoping someone can shed some light on what I'm seeing. I'm running the Mastercard M-TIP tests that apply to our solution, and I'm seeing some unexpected results. When running the M-TIP 50 tests (1, 2, 3) with the M-TIP 50 test card, I'm getting errors on the 2nd GENERATE_AC command. Our solution is technically defined as offline with online capability, but we're currently testing in an entirely offline environment.
I've spent a good amount of time reading the EMV books and scouring Google, but I still don't understand why it's returning 6985. The best guess I can come up with at this point is it has something to do with CDA (which should also be happening during this process?)
I've included the 1st and 2nd GEN_AC requests and responses to show what's happening. If someone could provide insight into what's happening or what's going wrong, I would greatly appreciate it.
1st Generate AC (ARQC)
Request : 80 AE 90 00 2F 00 00 00 00 20 00 00 00 00 00 00 00 00 80 00 80 00 08 26 17 01 03 00 B0 32 0F C0 22 00 00 00 00 00 00 00 00 00 00 44 03 02 16 11 12 60 00 80
Class :80
Ins :AE
P1 :90
P2 :00
Lc :2F
Data :00 00 00 00 20 00 00 00 00 00 00 00 00 80 00 80 00 08 26 17 01 03 00 B0 32 0F C0 22 00 00 00 00 00 00 00 00 00 00 44 03 02 16 11 12 60 00 80
Tag 9F 02: Transaction Amount : 00 00 00 00 20 00
Amount value: 20.00
Tag 9F 03: Cashback Amount : 00 00 00 00 00 00
Amount value: 0.00
Tag 95 : Terminal Verification Results (TVR) : 00 80 00 80 00
Byte 1 bit 8 = 0 Offline data authentication was performed
bit 7 = 0 SDA passed or not performed
bit 6 = 0 No ICC data missing
bit 5 = 0 Card does not appear on terminal exception file
bit 4 = 0 DDA passed or not performed
bit 3 = 0 CDA passed or not performed
bit 2 = 0 SDA not selected
bit 1 = 0 RFU
Byte 2 bit 8 = 1 ICC and terminal have different application versions
bit 7 = 0 No Expired application
bit 6 = 0 Application effective
bit 5 = 0 Requested service allowed for card product
bit 4 = 0 No New card
bit 3 = 0 RFU
bit 2 = 0 RFU
bit 1 = 0 RFU
Byte 3 bit 8 = 0 Cardholder verification was successful or not performed
bit 7 = 0 Recognised CVM
bit 6 = 0 PIN Try Limit not exceeded
bit 5 = 0 No PIN entry required (PIN pad may or may not be present or may or may not be working)
bit 4 = 0 No PIN entry required (PIN pad may or may not be present)
bit 3 = 0 No Online PIN entered
bit 2 = 0 RFU
bit 1 = 0 RFU
Byte 4 bit 8 = 1 Transaction exceeds floor limit
bit 7 = 0 Lower consecutive offline limit not exceeded
bit 6 = 0 Upper consecutive offline limit not exceeded
bit 5 = 0 Transaction not selected randomly for online processing
bit 4 = 0 Merchant did not force transaction online
bit 3 = 0 RFU
bit 2 = 0 RFU
bit 1 = 0 RFU
Byte 5 bit 8 = 0 No Default TDOL used
bit 7 = 0 Issuer authentication passed or not performed
bit 6 = 0 Script processing passed before final GENERATE AC or no script received
bit 5 = 0 Script processing passed after final GENERATE AC or no script received
bit 4 = 0 RFU
bit 3 = 0 RFU
bit 2 = 0 RFU
bit 1 = 0 RFU
Tag 5F 2A: Transaction Currency Code : 08 26
Code (num) = 08 26
Code (an) = GBP
Currency = Pound Sterling
Tag 9A : Transaction Date : 17 01 03
Year : 2017
Month: January
Day : 03
Tag 9C : Transaction Type : 00
Purchase (of goods or services)
Tag 9F 37: Unpredictable Number : B0 32 0F C0
Tag 9F 35: Terminal Type : 22
Terminal Type: 22
Attended
Merchant
Offline with online capability
Tag 9F 45: Data Authentication Code : 00 00
Tag 9F 4C: ICC Dynamic Number : 00 00 00 00 00 00 00 00
Tag 9F 34: Cardholder Verification Method (CVM) Results : 44 03 02
Byte 1 bit 8 = 0 (default value)
bit 7 = 1 (Apply succeeding CVM field if this CVM is unsuccessful)
bit 6-1= 000100 (Enciphered PIN verification performed by ICC)
Byte 2 = '03' (If terminal supports the CVM type)
Byte 3 = '02' (Successful)
Tag 9F 21: Transaction Time : 16 11 12
Time = 16:11:12
Hours (HH) = 16
Minutes (MM) = 11
Seconds (SS) = 12
Tag 9F 40: Additional Terminal Capabilities : 60 00 80
Byte 1 bit 8 = 0 Cash NOT supported
bit 7 = 1 Goods supported
bit 6 = 1 Services supported
bit 5 = 0 CashBack NOT supported
bit 4 = 0 Inquiry NOT supported
bit 3 = 0 Transfer NOT supported
bit 2 = 0 Payment NOT supported
bit 1 = 0 Administrative NOT supported
Byte 2 bit 8 = 0 CashBack Deposit NOT supported
bit 7 = 0 RFU
bit 6 = 0 RFU
bit 5 = 0 RFU
bit 4 = 0 RFU
bit 3 = 0 RFU
bit 2 = 0 RFU
bit 1 = 0 RFU
Byte 3 bit 8 = 1 Numeric keys supported
bit 7 = 0 Alphabetic and special characters keys NOT supported
bit 6 = 0 Command keys NOT supported
bit 5 = 0 Function keys NOT supported
bit 4 = 0 RFU
bit 3 = 0 RFU
bit 2 = 0 RFU
bit 1 = 0 RFU
Byte 4 bit 8 = 0 Print, attendant NOT supported
bit 7 = 0 Print, cardholder NOT supported
bit 6 = 0 Display, attendant NOT supported
bit 5 = 0 Display, cardholder NOT supported
bit 4 = 0 RFU
bit 3 = 0 RFU
bit 2 = 0 Code table 10 NOT supported
bit 1 = 0 Code table 9 NOT supported
Byte 5 bit 8 = 0 Code table 8 NOT supported
bit 7 = 0 Code table 7 NOT supported
bit 6 = 0 Code table 6 NOT supported
bit 5 = 0 Code table 5 NOT supported
bit 4 = 0 Code table 4 NOT supported
bit 3 = 0 Code table 3 NOT supported
bit 2 = 0 Code table 2 NOT supported
bit 1 = 0 Code table 1 NOT supported
masterKeyAC: 9E 15 20 43 13 F7 31 8A CB 79 B9 0B D9 86 AD 29
uniqueKeyAC: 80 32 AD CE E0 B9 40 BA FB E3 5B 5B 15 9E 8F EA
MCHIP SKD Session Key Derivation
ATC: 00 08
UN: B0 32 0F C0
Cryptogram Version No.: 10
ICC Master Key AC: 9E 15 20 43 13 F7 31 8A CB 79 B9 0B D9 86 AD 29
Derived Card Unique Key: 80 32 AD CE E0 B9 40 BA FB E3 5B 5B 15 9E 8F EA
Derived Session Key: A1 00 11 56 78 15 15 85 2B 53 76 A9 18 14 AA F2
AC calculation: 00 00 00 00 20 00 00 00 00 00 00 00 00 80 00 80 00 08 26 17 01 03 00 B0 32 0F C0 79 00 00 08 A7 40 0F 04 00 00 80
Amount Authorised : 00 00 00 00 20 00
Amount Other : 00 00 00 00 00 00
Terminal Verification Results : 00 80 00 80 00
Transaction Currency Code : 08 26
Transaction Date : 17 01 03
Transaction Type : 00
Unpredictable Number : B0 32 0F C0
Application Interchange Profile : 79 00
Application Transaction Counter : 00 08
Card Verification Results : A7 40 0F 04 00 00
AC Session Key : A1 00 11 56 78 15 15 85 2B 53 76 A9 18 14 AA F2
CDA Signature Generation
Input data: E0 B8 C8 03 72 22 60 00 80 30 00 00 00 00 00 20 00 00 00 00 00 00 00 00 80 00 80 00 08 26 17 01 03 00 B0 32 0F C0 22 00 00 00 00 00 00 00 00 00 00 44 03 02 16 11 12 60 00 80 9F 27 01 80 9F 36 02 00 08 9F 10 12 02 10 A7 40 0F 04 00 00 00 00 00 00 00 00 00 00 00 FF
ICC dynamic number: 98 43 55 5A 0A C1 C2 4A
ICC private key: 1A C2 53 A6 2F FC 28 F2 CA 67 EE 9B 2C BE 16 C2 38 FB E3 C8 8B 28 4A 81 18 44 4B 6A BD 6F 68 FD F4 70 23 62 20 D1 4A 1A 11 6F E4 A8 5C 33 FE 1E 35 CD 9A 3F 48 44 13 64 A3 E9 50 58 ED 26 35 82 D3 6E FA 8E A4 EF EE A2 42 21 C5 4C 02 FB 5D C3 AE 17 97 8B D6 CE 6B 68 A2 4B 3B 13 C8 61 3A 2E 1E 0A 53 1B A1 71 AF 7E 1E FF 44 4B FF 72 50 03 89 F6 64 2F 0F 62 E4 9A 43 0C 6D F7 0C 07 EE 0D
ICC public modulus: A0 8D F5 E5 1F E8 F5 B0 BE 6F 97 A3 0C 74 88 8D 55 E7 56 B3 42 F1 BF 06 91 99 C4 80 70 9C 75 F3 BA A0 D4 4C C4 E7 BC 9C 68 9F 5B F2 29 37 F4 B5 42 D1 9D 7B B1 98 74 5B D7 77 E2 15 8E E5 41 12 8A 15 8E 73 6A 88 4B 82 C5 21 61 6E F0 6F 8D 26 7C 07 B1 EF 79 8A B5 77 AA A3 C6 DD 89 37 C9 B2 34 4C EC AD 5A B8 D5 29 BC AC A7 F9 EC EA DE 85 99 0F 1E 04 FE AE 9F A0 33 DF 69 12 68 F9 F2 D5
Terminal unpredictable number: B0 32 0F C0
Signature: 89 A6 C6 A0 AD 68 43 14 03 EE 4E 92 4B A8 CE B0 ED D9 F2 23 9A AB C9 90 D6 67 FD D5 B4 FF FC 98 99 AB 66 A7 10 0D 5B EB EE 36 7C 36 79 2D A2 A2 92 11 A2 0C 00 71 86 4B BE 20 BA 44 57 73 E5 0C 2D FB 17 AA DE 5C 85 8B 19 66 B8 F3 40 E0 00 EB BF 10 8B 1C AE 91 BD D0 DC 0C D3 D5 40 85 42 72 B0 E2 2F 30 D5 B5 EA 61 29 C9 9F 4F 39 F3 EE BC 66 06 F7 60 11 4D D6 DB 57 CF 57 F6 C1 EF 8C 35
Signed Dynamic Authentication Data
Evaluated: 6A 05 01 26 08 98 43 55 5A 0A C1 C2 4A 80 EC 19 0A DB E4 1C 90 B0 AA 00 A2 EC B5 50 A9 54 A9 92 00 1E CA 05 21 B1 DD 13 98 ED BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB 8E 73 0F 77 06 61 76 D4 6A 68 EF 7A 9C 45 23 0C 9A 62 43 C6 BC
RecoveredDataHeader '6A'h
DynamicApplicationData_for_signature '05 01 26 08 98 43 55 5A 0A C1 C2 4A 80 EC 19 0A DB E4 1C 90 B0 AA 00 A2 EC B5 50 A9 54 A9 92 00 1E CA 05 21 B1 DD 13 98 ED BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB'h structure
SignedDataFormat '05'h
HashAlgorithmIndicator '01'h
ICCDynamicDataLength 38
ICCDynamicData '08 98 43 55 5A 0A C1 C2 4A 80 EC 19 0A DB E4 1C 90 B0 AA 00 A2 EC B5 50 A9 54 A9 92 00 1E CA 05 21 B1 DD 13 98 ED'h
PadPattern 'BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB BB'h
HashResult '8E 73 0F 77 06 61 76 D4 6A 68 EF 7A 9C 45 23 0C 9A 62 43 C6'h
RecoveredDataTrailer 'BC'h
Expected: 6A 05 01 .. .. .. .. BC
RecoveredDataHeader '6A'h
DynamicApplicationData_for_signature 05 01 .. .. .. structure
SignedDataFormat '05'h
HashAlgorithmIndicator '01'h
ICCDynamicDataLength Length(ICCDynamicData)
ICCDynamicData .. concatenation
QS{0-}
''h
PadPattern .. concatenation
QS {..}
''h
HashResult .. concatenation
QS{1-}
''h
RecoveredDataTrailer 'BC'h
Previous Transaction History
Response: 61 A5
SW1 SW2: 61 A5 (SW_OK Response bytes available(Le))
Get Response
Request : 00 C0 00 00 A5
Class :00
Ins :C0
P1 :00
P2 :00
Le :A5
Response: C0 77 81 A2 9F 27 01 80 9F 36 02 00 08 9F 4B 81 80 89 A6 C6 A0 AD 68 43 14 03 EE 4E 92 4B A8 CE B0 ED D9 F2 23 9A AB C9 90 D6 67 FD D5 B4 FF FC 98 99 AB 66 A7 10 0D 5B EB EE 36 7C 36 79 2D A2 A2 92 11 A2 0C 00 71 86 4B BE 20 BA 44 57 73 E5 0C 2D FB 17 AA DE 5C 85 8B 19 66 B8 F3 40 E0 00 EB BF 10 8B 1C AE 91 BD D0 DC 0C D3 D5 40 85 42 72 B0 E2 2F 30 D5 B5 EA 61 29 C9 9F 4F 39 F3 EE BC 66 06 F7 60 11 4D D6 DB 57 CF 57 F6 C1 EF 8C 35 9F 10 12 02 10 A7 40 0F 04 00 00 00 00 00 00 00 00 00 00 00 FF 90 00
Ack Byte : C0
Data : 77 81 A2 9F 27 01 80 9F 36 02 00 08 9F 4B 81 80 89 A6 C6 A0 AD 68 43 14 03 EE 4E 92 4B A8 CE B0 ED D9 F2 23 9A AB C9 90 D6 67 FD D5 B4 FF FC 98 99 AB 66 A7 10 0D 5B EB EE 36 7C 36 79 2D A2 A2 92 11 A2 0C 00 71 86 4B BE 20 BA 44 57 73 E5 0C 2D FB 17 AA DE 5C 85 8B 19 66 B8 F3 40 E0 00 EB BF 10 8B 1C AE 91 BD D0 DC 0C D3 D5 40 85 42 72 B0 E2 2F 30 D5 B5 EA 61 29 C9 9F 4F 39 F3 EE BC 66 06 F7 60 11 4D D6 DB 57 CF 57 F6 C1 EF 8C 35 9F 10 12 02 10 A7 40 0F 04 00 00 00 00 00 00 00 00 00 00 00 FF
Tag 77 : Response Message Template Format 2
Tag 9F 27: Cryptogram Information Data (CID) : 80
Byte 1 bit 8-7 = 10 ARQC
bit 6-5 = 00 Payment System specific cryptogram
bit 4 = 0 No advice required
bit 3-1 = 000 No information given
Tag 9F 36: Application Transaction Counter (ATC) : 00 08
Decimal value = 8
Tag 9F 4B: Signed Dynamic Application Data : 89 A6 C6 A0 AD 68 43 14 03 EE 4E 92 4B A8 CE B0 ED D9 F2 23 9A AB C9 90 D6 67 FD D5 B4 FF FC 98 99 AB 66 A7 10 0D 5B EB EE 36 7C 36 79 2D A2 A2 92 11 A2 0C 00 71 86 4B BE 20 BA 44 57 73 E5 0C 2D FB 17 AA DE 5C 85 8B 19 66 B8 F3 40 E0 00 EB BF 10 8B 1C AE 91 BD D0 DC 0C D3 D5 40 85 42 72 B0 E2 2F 30 D5 B5 EA 61 29 C9 9F 4F 39 F3 EE BC 66 06 F7 60 11 4D D6 DB 57 CF 57 F6 C1 EF 8C 35
Tag 9F 10: Issuer Application Data [M/Chip 4] : 02 10 A7 40 0F 04 00 00 00 00 00 00 00 00 00 00 00 FF
Key Derivation Index = 02
Cryptogram Version Number = 10
Card Verification Results (CVR) = A7 40 0F 04 00 00
Byte 1 bit 8-7 = 10 AC Returned in Second Generate AC: Not requested
bit 6-5 = 10 AC Returned in First Generate AC: ARQC
bit 4 = 0 RFU
bit 3 = 1 Offline PIN Verification Performed
bit 2 = 1 Offline Encrypted PIN Verification Performed
bit 1 = 1 Offline PIN Verification Successful
Byte 2 bit 8 = 0 DDA not returned
bit 7 = 1 M/Chip Select 4: Combined DDA/AC Generation Returned in First Generate AC, M/Chip Lite 4: Value not allowed
bit 6 = 0 Combined DDA/AC Generation Not Returned in Second Generate AC
bit 5 = 0 Issuer Authentication not performed
bit 4 = 0 CIAC-Default not skipped on CAT3 or not required
bit 3 = 0 RFU
bit 2 = 0 RFU
bit 1 = 0 RFU
Byte 3 bit 8-5 = 0000 Right nibble of Script Counter : '0'
bit 4-1 = 1111 Right nibble of PIN Try Counter: 'F'
Byte 4 bit 8 = 0 RFU
bit 7 = 0 Unable To Go Online Not Indicated
bit 6 = 0 Offline PIN Verification Performed
bit 5 = 0 No Failure OF Offline PIN Verification
bit 4 = 0 PTL Not Exceeded
bit 3 = 1 International Transaction
bit 2 = 0 International Transaction
bit 1 = 0 Terminal Does Not Erroneously Consider Offline PIN OK
Byte 5 bit 8 = 0 Lower Consecutive Offline Limit Not Exceeded
bit 7 = 0 Upper Consecutive Offline Limit Not Exceeded
bit 6 = 0 Lower Cumulative Offline Limit Not Exceeded
bit 5 = 0 Upper Cumulative Offline Limit Not Exceeded
bit 4 = 0 Go Online On Next Transaction Was Not Set (in this transaction or in a previous one)
bit 3 = 0 No Issuer Authentication Failed (in this transaction or in a previous one)
bit 2 = 0 No Script Received (in a previous transaction)
bit 1 = 0 No Script Failed (in a previous transaction)
Byte 6 bit 8 = 0 RFU
bit 7 = 0 RFU
bit 6 = 0 RFU
bit 5 = 0 RFU
bit 4 = 0 RFU
bit 3 = 0 RFU
bit 2 = 0 No Match found in Additional Check Table
bit 1 = 0 Match Found in Additional Check Table
DAC = 00 00
Counters = 00 00 00 00 00 00 00 FF
SW1 SW2 : 90 00 (SW_OK)
2nd Generate AC (TC)
Request : 80 AE 50 00 23 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 59 33 00 80 00 80 00 B0 32 0F C0 98 43 55 5A 0A C1 C2 4A
Class :80
Ins :AE
P1 :50
P2 :00
Lc :23
Data :00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 59 33 00 80 00 80 00 B0 32 0F C0 98 43 55 5A 0A C1 C2 4A
Tag 91 : Issuer Authentication Data [M/Chip] : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Tag 8A : Authorization Response Code : 59 33
Response Code = 59 33
Meaning = Unable to go online, Requesting for offline approval
Tag 95 : Terminal Verification Results (TVR) : 00 80 00 80 00
Byte 1 bit 8 = 0 Offline data authentication was performed
bit 7 = 0 SDA passed or not performed
bit 6 = 0 No ICC data missing
bit 5 = 0 Card does not appear on terminal exception file
bit 4 = 0 DDA passed or not performed
bit 3 = 0 CDA passed or not performed
bit 2 = 0 SDA not selected
bit 1 = 0 RFU
Byte 2 bit 8 = 1 ICC and terminal have different application versions
bit 7 = 0 No Expired application
bit 6 = 0 Application effective
bit 5 = 0 Requested service allowed for card product
bit 4 = 0 No New card
bit 3 = 0 RFU
bit 2 = 0 RFU
bit 1 = 0 RFU
Byte 3 bit 8 = 0 Cardholder verification was successful or not performed
bit 7 = 0 Recognised CVM
bit 6 = 0 PIN Try Limit not exceeded
bit 5 = 0 No PIN entry required (PIN pad may or may not be present or may or may not be working)
bit 4 = 0 No PIN entry required (PIN pad may or may not be present)
bit 3 = 0 No Online PIN entered
bit 2 = 0 RFU
bit 1 = 0 RFU
Byte 4 bit 8 = 1 Transaction exceeds floor limit
bit 7 = 0 Lower consecutive offline limit not exceeded
bit 6 = 0 Upper consecutive offline limit not exceeded
bit 5 = 0 Transaction not selected randomly for online processing
bit 4 = 0 Merchant did not force transaction online
bit 3 = 0 RFU
bit 2 = 0 RFU
bit 1 = 0 RFU
Byte 5 bit 8 = 0 No Default TDOL used
bit 7 = 0 Issuer authentication passed or not performed
bit 6 = 0 Script processing passed before final GENERATE AC or no script received
bit 5 = 0 Script processing passed after final GENERATE AC or no script received
bit 4 = 0 RFU
bit 3 = 0 RFU
bit 2 = 0 RFU
bit 1 = 0 RFU
Tag 9F 37: Unpredictable Number : B0 32 0F C0
Tag 9F 4C: ICC Dynamic Number : 98 43 55 5A 0A C1 C2 4A
Previous Transaction History
Response: 69 85
SW1 SW2: 69 85 (SW_Error Accesscondition not satisfied)
Test Completed

It seems like you did a lot of "Offline approval" without clear counters.
There are several possible reasons in your case for 6985:
1) AC Session Key Counter Limit Exceeded
Because response code in Second Generate AC is "Unable to go online, Requesting for offline approval" card goes Offline, therefore CTR accumulates and is not reset (it reset only then Online in Generate AC 2).
Try to personalize increased limits or do full Online.
2) Overflow during the amount conversion, if transaction International
(transaction currency != CRM currency Code).
Required full Online
3) Overflow during add the cumulative amount, if transaction Domestic (transaction currency == CRM currency Code).
Required full Onlinе
also, check why "Country code" is absent in Cdol1

I got some help from my test tool's support system. Their response helped explain this scenario:
Response 1:
"The transaction amount in your test cases M-TIP 50 test1, test2, and test 3 are all above the floor limit, so the transactions are supposed to go online. However, due to your test environment is offline, the transactions can not be processed online. I can see the issuer authentication data in the 2nd generate AC are all 0s (They are not returned by the issuer, but the default value set by the terminal). The card validate the authentication data to see if the data is returned by the issuer. In your case, the validation is failed and the card returns "69 85"."
Response 2:
"The MTIP50 test cases are a little special. The issuer authentication data for MTIP50 test cases is 16 bytes which is different than the normal value (10 bytes). Thus BTT has extra checks on the issuer authentication data of MTIP50. Since the issuer authentication data are all zeros in your case, the simulated card thinks they are not valid."
Resolution:
Turns out this was an issue with the testing tool I was using. They recently released a new version of their software and this no longer happens.

How to get Coordinates of Touchscreen Rawdata using Linux

We have a 3m microtouch display. It's connected to my Debian system via USB and recognized as human interface (hid). I am trying to access and push realtime information... if its getting touched I want to know where (x,y) and pipe it through netcat to another host.
Unfortunately I am only able to get raw data using:
cat /dev/input/event2 | hexdump
or
evtest
You get hexcode that seem nowhere documented...
Does anybody have a clue how to get that information? There must be a way to extract it from the hexcode. Unfortunately I have no idea how to interpret the hexcode. I couldn't find any source where its documented...
Is there a way the Kernel could provide me those desired information in realtime?
As a workaround, is there, maybe, a solution where the X-Server could tell me? The touchscreen behaves like a mouse in X. I actually already tried to get x,y-position of the mouse via xlib. But it was too slow and wouldn't tell me if somebody is touching or not...
evtest sample output:
Event: time 1425319271.595631, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value 51
Event: time 1425319271.595631, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 10304
Event: time 1425319271.595631, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 30629
Event: time 1425319271.595631, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 893
Event: time 1425319271.595631, type 3 (EV_ABS), code 49 (ABS_MT_TOUCH_MINOR), value 414
Event: time 1425319271.595631, type 1 (EV_KEY), code 330 (BTN_TOUCH), value 1
Event: time 1425319271.595631, type 3 (EV_ABS), code 0 (ABS_X), value 10304
Event: time 1425319271.595631, type 3 (EV_ABS), code 1 (ABS_Y), value 30629
Event: time 1425319271.595631, -------------- SYN_REPORT ------------
Event: time 1425319271.601632, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 10306
Event: time 1425319271.601632, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 30625
Event: time 1425319271.601632, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 962
Event: time 1425319271.601632, type 3 (EV_ABS), code 49 (ABS_MT_TOUCH_MINOR), value 421
Event: time 1425319271.601632, type 3 (EV_ABS), code 47 (ABS_MT_SLOT), value 1
Event: time 1425319271.601632, type 3 (EV_ABS), code 57 (ABS_MT_TRACKING_ID), value 52
Event: time 1425319271.601632, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 15416
Event: time 1425319271.601632, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 24159
Event: time 1425319271.601632, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 649
Event: time 1425319271.601632, type 3 (EV_ABS), code 49 (ABS_MT_TOUCH_MINOR), value 354
Event: time 1425319271.601632, type 3 (EV_ABS), code 0 (ABS_X), value 10306
Event: time 1425319271.601632, type 3 (EV_ABS), code 1 (ABS_Y), value 30625
Event: time 1425319271.601632, -------------- SYN_REPORT ------------
Event: time 1425319271.606626, type 3 (EV_ABS), code 47 (ABS_MT_SLOT), value 0
Event: time 1425319271.606626, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 10318
Event: time 1425319271.606626, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 30609
Event: time 1425319271.606626, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 1014
Event: time 1425319271.606626, type 3 (EV_ABS), code 49 (ABS_MT_TOUCH_MINOR), value 426
Event: time 1425319271.606626, type 3 (EV_ABS), code 47 (ABS_MT_SLOT), value 1
Event: time 1425319271.606626, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 24161
Event: time 1425319271.606626, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 681
Event: time 1425319271.606626, type 3 (EV_ABS), code 49 (ABS_MT_TOUCH_MINOR), value 376
Event: time 1425319271.606626, type 3 (EV_ABS), code 0 (ABS_X), value 10318
Event: time 1425319271.606626, type 3 (EV_ABS), code 1 (ABS_Y), value 30609
Event: time 1425319271.606626, -------------- SYN_REPORT ------------
Event: time 1425319271.611629, type 3 (EV_ABS), code 47 (ABS_MT_SLOT), value 0
Event: time 1425319271.611629, type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 10320
Event: time 1425319271.611629, type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 30605
Event: time 1425319271.611629, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 1053
Event: time 1425319271.611629, type 3 (EV_ABS), code 49 (ABS_MT_TOUCH_MINOR), value 430
Event: time 1425319271.611629, type 3 (EV_ABS), code 47 (ABS_MT_SLOT), value 1
Event: time 1425319271.611629, type 3 (EV_ABS), code 48 (ABS_MT_TOUCH_MAJOR), value 705
Event: time 1425319271.611629, type 3 (EV_ABS), code 49 (ABS_MT_TOUCH_MINOR), value 392
Event: time 1425319271.611629, type 3 (EV_ABS), code 0 (ABS_X), value 10320
Event: time 1425319271.611629, type 3 (EV_ABS), code 1 (ABS_Y), value 30605

Console-based solution
You can obtain parsed coordinates using evtest tool.
If you only need single-touch coordinates: look for ABS_X and ABS_Y fields:
type 3 (EV_ABS), code 0 (ABS_X), value 10306
type 3 (EV_ABS), code 1 (ABS_Y), value 30625
If you need multi-touch coordinates:
ABS_MT_SLOT represents number of finger
ABS_MT_POSITION_X and ABS_MT_POSITION_Y -- coordinates
Finger #0:
type 3 (EV_ABS), code 47 (ABS_MT_SLOT), value 0
type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 10318
type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 30609
Finger #1:
type 3 (EV_ABS), code 47 (ABS_MT_SLOT), value 1
type 3 (EV_ABS), code 53 (ABS_MT_POSITION_X), value 20301
type 3 (EV_ABS), code 54 (ABS_MT_POSITION_Y), value 24161
For example, if you need to send single-touch coordinates via network, you can use script like this:
#!/bin/sh
# ---- Global variables ----
input=/dev/input/event0
code_prefix="ABS"
code="${code_prefix}_[XY]"
val_regex=".*(${code_prefix}_\(.\)), value \([-]\?[0-9]\+\)"
val_subst="\1=\2"
# ---- Functions ----
send_axis() {
# 1. Convert axis value ($1) from device specific units
# 2. Send this axis value via UDP packet
echo $1
}
process_line() {
while read line; do
axis=$(echo $line | grep "^Event:" | grep $code | \
sed "s/$val_regex/$val_subst/")
if [ -n "$axis" ]; then
send_axis $axis
fi
done
}
# ---- Entry point ----
if [ $(id -u) -ne 0 ]; then
echo "This script must be run from root" >&2
exit 1
fi
evtest $input | process_line
Program-based solution
You can write C application that will read your event file. Obtained binary data can be easily interpreted, see section 5 in kernel documentation.
You can wait for next data portion using select() syscall.
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <fcntl.h>
#include <linux/input.h>
/* Change it to your dev file for the touch screen */
#define EVENT_DEVICE "/dev/input/event2"
#define EVENT_TYPE EV_ABS
#define EVENT_CODE_X ABS_X
#define EVENT_CODE_Y ABS_Y
/* TODO: Close fd on SIGINT (Ctrl-C), if it's open */
static int fd = -1;
int main(int argc, char *argv[])
{
struct input_event ev;
char name[256] = "Unknown";
fd_set readfds;
/* /dev/input/event* files are only readable by root:input */
if ((getuid()) != 0) {
fprintf(stderr, "You are not root! This may not work...\n");
return EXIT_SUCCESS;
}
/* Open device for non-blocking read */
fd = open(EVENT_DEVICE, O_RDONLY | O_NONBLOCK);
if (fd == -1) {
fprintf(stderr, "%s is not a vaild device\n", EVENT_DEVICE);
return EXIT_FAILURE;
}
/* Print device name */
ioctl(fd, EVIOCGNAME(sizeof(name)), name);
printf("Reading from:\n");
printf(" - device file: %s\n", EVENT_DEVICE);
printf(" - device name: %s\n", name);
/* Prepare for select(): zero and set the fd into fd_set */
FD_ZERO(&readfds);
FD_SET(fd, &readfds);
/* Press Ctrl-C to stop the program */
for (;;) {
const size_t ev_size = sizeof(struct input_event);
ssize_t size;
int ret;
/* struct timeval timeout = { 30, 0 }; */
/*
* select(): no-timeout version, just stop on errors or
* interrupts.
*/
ret = select(fd + 1, &readfds, NULL, NULL, NULL);
/*
* select(): timeout-enabled version, stop if no event has
* occurred until timeout; might be useful e.g. for background
* tasks.
*/
/* ret = select(fd + 1, &readfds, NULL, NULL, &timeout); */
if (ret == -1) {
perror("Error: select() failed");
goto err;
} else if (ret == 0) {
fprintf(stderr, "Error: select() timeout\n");
continue;
}
size = read(fd, &ev, ev_size);
if (size < ev_size) {
fprintf(stderr, "Error: Wrong size when reading\n");
goto err;
}
if (ev.type == EVENT_TYPE && (ev.code == EVENT_CODE_X
|| ev.code == EVENT_CODE_Y)) {
/* TODO: convert value to pixels */
printf("%s = %d\n", ev.code == EVENT_CODE_X ? "X" : "Y",
ev.value);
}
}
return EXIT_SUCCESS;
err:
close(fd);
return EXIT_FAILURE;
}
Coordinates units
First of all you need to know next things:
where is coordinates origin point (i.e. [x=0;y=0])
which units your device is using for representing coordinates
This information usually can be found in driver code for your device.
This is the driver for your device.
So it seems like you need to divide your axis value from evtest by 65535 and multiply it by width or height of device (in pixels). For example, if you get X=30000, and width of your LCD panel is 1080 pixels, you need to do:
X = round((30000 / 65535) * 1080) = 494 pixels

You get hexcode that seem nowhere documented...
This is documented by the device itself, which is how the hid-multitouch driver can interpret the USB data it receives.
You can find the information using the following commands:
$ lsusb # determine the bus & device numbers
...
Bus 001 Device 067: ID 1aad:000f KeeTouch
...
$ sudo usbhid-dump -a 1:67 -e d
001:067:002:DESCRIPTOR 1615651625.434241
05 0D 09 04 A1 01 85 03 09 22 09 00 15 00 26 FF
00 75 08 95 09 81 02 A1 00 05 0D 09 51 15 00 26
FF 00 75 08 95 01 81 02 05 0D 09 42 15 00 25 01
75 01 95 01 81 02 09 32 81 02 09 47 81 02 95 05
81 03 05 01 09 30 26 FF 7F 55 00 65 00 35 00 46
00 00 75 10 95 01 81 02 09 31 35 00 46 00 00 81
02 05 0D 09 48 15 00 26 FF 7F 75 10 95 01 81 02
09 49 15 00 26 FF 7F 75 10 95 01 81 02 C0 A1 00
05 0D 09 51 15 00 26 FF 00 75 08 95 01 81 02 05
0D 09 42 15 00 25 01 75 01 95 01 81 02 09 32 81
02 09 47 81 02 95 05 81 03 05 01 09 30 26 FF 7F
55 00 65 00 35 00 46 00 00 75 10 95 01 81 02 09
31 35 00 46 00 00 81 02 05 0D 09 48 15 00 26 FF
7F 75 10 95 01 81 02 09 49 15 00 26 FF 7F 75 10
95 01 81 02 C0 A1 00 05 0D 09 51 15 00 26 FF 00
75 08 95 01 81 02 05 0D 09 42 15 00 25 01 75 01
95 01 81 02 09 32 81 02 09 47 81 02 95 05 81 03
05 01 09 30 26 FF 7F 55 00 65 00 35 00 46 00 00
75 10 95 01 81 02 09 31 35 00 46 00 00 81 02 05
0D 09 48 15 00 26 FF 7F 75 10 95 01 81 02 09 49
15 00 26 FF 7F 75 10 95 01 81 02 C0 A1 00 05 0D
09 51 15 00 26 FF 00 75 08 95 01 81 02 05 0D 09
42 15 00 25 01 75 01 95 01 81 02 09 32 81 02 09
47 81 02 95 05 81 03 05 01 09 30 26 FF 7F 55 00
65 00 35 00 46 00 00 75 10 95 01 81 02 09 31 35
00 46 00 00 81 02 05 0D 09 48 15 00 26 FF 7F 75
10 95 01 81 02 09 49 15 00 26 FF 7F 75 10 95 01
81 02 C0 A1 00 05 0D 09 51 15 00 26 FF 00 75 08
95 01 81 02 05 0D 09 42 15 00 25 01 75 01 95 01
81 02 09 32 81 02 09 47 81 02 95 05 81 03 05 01
09 30 26 FF 7F 55 00 65 00 35 00 46 00 00 75 10
95 01 81 02 09 31 35 00 46 00 00 81 02 05 0D 09
48 15 00 26 FF 7F 75 10 95 01 81 02 09 49 15 00
26 FF 7F 75 10 95 01 81 02 C0 A1 00 05 0D 09 54
15 00 25 1F 75 08 95 01 81 02 C0 09 55 85 FD 15
00 26 FF 00 75 08 95 01 B1 02 C0 05 0D 09 0E A1
01 85 FC 09 52 09 53 15 00 26 FF 00 75 08 95 02
B1 02 C0
001:067:001:DESCRIPTOR 1615651625.436655
05 01 09 02 A1 01 85 02 09 01 A1 00 06 00 FF 09
00 15 00 26 FF 00 75 08 95 09 81 02 05 01 09 30
09 31 15 00 26 FF 7F 75 10 95 02 81 02 05 09 19
01 29 08 15 00 25 01 95 08 75 01 81 02 C0 C0
001:067:000:DESCRIPTOR 1615651625.437001
06 00 FF 09 00 A1 01 09 00 85 01 A1 00 09 00 15
00 26 FF 00 35 00 46 FF 00 75 08 95 3F 81 02 C0
09 02 85 FE A1 00 09 06 15 00 26 FF 00 35 00 46
FF 00 75 08 95 3F B1 02 C0 C0
I use the lsusb command to determine the bus and device numbers and pass that to the usbhid-dump command. You can use the dump command without those numbers, but then you get a list of all your devices. Probably not what you want in most cases.
The codes in there are interpreted by the hid_parser() command in the kernel. Only some devices may not be properly recognized and that's when you need this information.
How to interpret that data is defined by the USB consortium. At this time, it is version 1.11 and it can be found on this page for the hid type of devices.
This mainly includes Keyboards, Mice, Touchscreens, Touchpads, Joysticks, although some other types of devices support this too (your Power button, various buttons on your monitor, etc.)

How do you decode an Ethernet Frame without things like Wireshark?

For example: How would one decode the following ethernet frame?
00 26 b9 e8 7e f1 00 12 f2 21 da 00 08 00 45 00 05 dc e3 cd 20 10 35 06 25 eb 0a 0a 0a 02 c0 a8 01 03 c3 9e 0f 40 00 00 10 00 00 00 14 00 70 10 00 5c 59 99 00 00 02 04 05 b4 01 03 03 06 00 00 01 98 64 34 e8 90 84 98 20 12 18 19 04 85 80 00
I know that the first 6 bytes are the MAC destination address : 00 26 b9 e8 7e f1 The next 6 bytes are the source MAC address : 00 12 f2 21 da 00 The next 2 bytes show the ethernet type : 08 00 The next 4 bytes are : 45 00... Ipv4... "5" the number of bytes in the header.. and "00" means there are no differentiated services.
What I don't know is what anything after that is or how to read it.
Anyone help?

Rearranging a bit your packet, we have:
00 26 b9 e8 7e f1 00 12 f2 21 da 00 08 00 45 00
05 dc e3 cd 20 10 35 06 25 eb 0a 0a 0a 02 c0 a8
01 03 c3 9e 0f 40 00 00 10 00 00 00 14 00 70 10
00 5c 59 99 00 00 02 04 05 b4 01 03 03 06 00 00
01 98 64 34 e8 90 84 98 20 12 18 19 04 85 80 00
If you know that the first 6 octets form the destination mac address, that means that it is an Ethernet layer 2 packet.
According to IEEE 802.3, $3.1.1:
First 6 octets are the destination mac address (00 26 b9 e8 7e f1)
Next 6 octets are the source mac address (00 12 f2 21 da 00)
Next 4 octets are, optionally the 802.1Q tag (present, 08 00 45 00)
Next 2 octets are either:
Maximum payload size - aka MTU (if <= 1500, which is the case, 05 dc is 1500)
Ethernet 2 frame (if >= 1536)
Next is the payload ranging from 46 octets (if the 802.1Q tag is absent) or 42 octets (if the 802.1Q tag is present) to up to 1500 octets (starts at e3 cd 20 10 ..., ends either at 20 12 18 19 or at 03 06 00 00, depends on the 7th item)
Last 4 octets form the CRC32 code (either 01 98 64 34 or 04 85 80 00, depending on the 7th item)
There is also 12 octets used for padding (random - not so random - bytes), that may or may not be inserted in this packet. (if inserted, the padding is e8 90 84 98 20 12 18 19 04 85 80 00)

hexdump and xxd produce different outputs on red hat and ubuntu/mint

Firstly , I am mentioning whatever happened on my linux mint/ubuntu system ...
udit#udit-Dabba ~/ah $ xxd -r -p input.txt output.txt
udit#udit-Dabba ~/ah $ cat input.txt
60 00 00 00 00 14 06 20 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 02 00 15 00 15 7A 32 B1 08
00 00 00 00 50 02 FF FF 7E 95 00 00 00 00 02 29
udit#udit-Dabba ~/ah $ cat output.txt
` z2P��~�)
udit#udit-Dabba ~/ah $ hexdump -C output.txt
00000000 60 00 00 00 00 14 06 20 00 00 00 00 00 00 00 00 |`...... ........|
00000010 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 02 00 15 00 15 7a 32 b1 08 |............z2..|
00000030 00 00 00 00 50 02 ff ff 7e 95 00 00 00 00 02 29 |....P...~......)|
00000040
udit#udit-Dabba ~/ah $ od -x output.txt
0000000 0060 0000 1400 2006 0000 0000 0000 0000
0000020 0000 0000 0000 0100 0000 0000 0000 0000
0000040 0000 0000 0000 0200 1500 1500 327a 08b1
0000060 0000 0000 0250 ffff 957e 0000 0000 2902
0000100
Now when I tried same thing on red hat , some strange behaviour is occuring.
[root#cc]$ xxd -r -p input.txt output.txt
[root#cc]$ cat input.txt
60 00 00 00 00 14 06 20 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 02 00 15 00 15 7A 32 B1 08
00 00 00 00 50 02 FF FF 7E 95 00 00 00 00 02 29
[root#cc]$ cat output.txt
` P~)[root#cc]$ hexdump -C output.txt
00000000 60 00 00 00 00 14 06 20 00 00 00 00 00 00 00 00 |`...... ........|
00000010 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 50 02 ff ff 7e 95 00 00 00 00 02 29 |....P...~......)|
00000030
[root#cc]$ od -x output.txt
0000000 0060 0000 1400 2006 0000 0000 0000 0000
0000020 0000 0000 0000 0100 0000 0000 0000 0000
0000040 0000 0000 0250 ffff 957e 0000 0000 2902
0000060
I am not able to find out why this discrepency occcuring between outputs of red hat and linux mint/ubuntu.
If possible tell me some awk/shell to perform the same in place of xxd -r -p
Pleae help me !!
EDIT:
On linux mint/ubuntu system ..
udit#udit-Dabba ~/ah $ hexdump -C input.txt
00000000 36 30 20 30 30 20 30 30 20 30 30 20 30 30 20 31 |60 00 00 00 00 1|
00000010 34 20 30 36 20 32 30 20 30 30 20 30 30 20 30 30 |4 06 20 00 00 00|
00000020 20 30 30 20 30 30 20 30 30 20 30 30 20 30 30 20 | 00 00 00 00 00 |
00000030 0a 30 30 20 30 30 20 30 30 20 30 30 20 30 30 20 |.00 00 00 00 00 |
00000040 30 30 20 30 30 20 30 31 20 30 30 20 30 30 20 30 |00 00 01 00 00 0|
00000050 30 20 30 30 20 30 30 20 30 30 20 30 30 20 30 30 |0 00 00 00 00 00|
00000060 20 0a 30 30 20 30 30 20 30 30 20 30 30 20 30 30 | .00 00 00 00 00|
00000070 20 30 30 20 30 30 20 30 32 20 30 30 20 31 35 20 | 00 00 02 00 15 |
00000080 30 30 20 31 35 20 37 41 20 33 32 20 42 31 20 30 |00 15 7A 32 B1 0|
00000090 38 20 0a 30 30 20 30 30 20 30 30 20 30 30 20 35 |8 .00 00 00 00 5|
000000a0 30 20 30 32 20 46 46 20 46 46 20 37 45 20 39 35 |0 02 FF FF 7E 95|
000000b0 20 30 30 20 30 30 20 30 30 20 30 30 20 30 32 20 | 00 00 00 00 02 |
000000c0 32 39 20 0a 0a 0a 0a 0a |29 .....|
000000c8
On red hat machine ..
[root#cc]$ hexdump -C input.txt
00000000 36 30 20 30 30 20 30 30 20 30 30 20 30 30 20 31 |60 00 00 00 00 1|
00000010 34 20 30 36 20 32 30 20 30 30 20 30 30 20 30 30 |4 06 20 00 00 00|
00000020 20 30 30 20 30 30 20 30 30 20 30 30 20 30 30 0a | 00 00 00 00 00.|
00000030 30 30 20 30 30 20 30 30 20 30 30 20 30 30 20 30 |00 00 00 00 00 0|
00000040 30 20 30 30 20 30 31 20 30 30 20 30 30 20 30 30 |0 00 01 00 00 00|
00000050 20 30 30 20 30 30 20 30 30 20 30 30 20 30 30 20 | 00 00 00 00 00 |
00000060 0a 30 30 20 30 30 20 30 30 20 30 30 20 30 30 20 |.00 00 00 00 00 |
00000070 30 30 20 30 30 20 30 32 20 30 30 20 31 35 20 30 |00 00 02 00 15 0|
00000080 30 20 31 35 20 37 41 20 33 32 20 42 31 20 30 38 |0 15 7A 32 B1 08|
00000090 20 0a 30 30 20 30 30 20 30 30 20 30 30 20 35 30 | .00 00 00 00 50|
000000a0 20 30 32 20 46 46 20 46 46 20 37 45 20 39 35 20 | 02 FF FF 7E 95 |
000000b0 30 30 20 30 30 20 30 30 20 30 30 20 30 32 20 32 |00 00 00 00 02 2|
000000c0 39 20 20 0a |9 .|
000000c4

I have no idea whats happening, but the third line is being eaten on red hat.
This is what you asked for. Reverse hexdump with awk+bash.
echo 'ibase=16' | cat - hdump | tr ' ' \; | bc | awk '{printf("%c",$0)}'
replace hdump with input.txt
echo 'ibase=16' | cat - input.txt | tr ' ' \; | bc | awk '{printf("%c",$0)}' > output.txt
codes were found here:
http://www.unix.com/shell-programming-scripting/132294-reverse-hexdump-without-xxd.html#post302404631

A late answer, but hopefully may help to somebody else reading this:
xxd had buggy handling of spaces in "-r -p" mode. As it scanned the characters, if it hit 2 consecutive non-hex characters, it would throw away everything until the next newline or end of file. If the second of the 2 consecutive characters was itself the newline character (i.e., the line ended with a space followed by a newline), the net effect would be to discard the entire next line.
I am pretty certain this is what caused Udit's problem. (I think the hexdump he later added of input.txt did not actually reflect the original state of that file.)
It looks like xxd is primarily maintained as part of the vim distribution. I looked at the xxd source included with vim 7.3, and it has the buggy handling problem fixed. Unfortunately nobody bothers to update the version #, so it still reports the same xxd 1.10 version string.
Try creating this test file (with 1 blank space at the end of the first line and none on the second; should be a 22 byte file on Linux/Unix; if you run "xxd -p" on it, it should report 3230200a34652034662035340a34322034312034340a):
20
4e 4f 54
42 41 44
If you run "xxd -r -p" on this, with a version of xxd exhibiting the buggy handling, you should see it print BAD. With a newer (fixed) version of xxd, it'll print NOTBAD.
If you run into this buggy handling and updating to a newer version of xxd is not an option, you can avoid this problem with some sed preprocessing, e.g.,
$ sed -e 's/ *//g' -e '/^$/d' input.txt | xxd -r -p > output.txt

I'd say that you have some invisible character in the input.txt file that makes the third line look invalid somehow.
And maybe the invalid character is encoding-dependent, and that's why it works in one machine and not in other.
It would be helpful to see the result of hexdump -C input.txt to check that.

$ cat foo
60 00 00 00 00 14 06 20 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 02 00 15 00 15 7A 32 B1 08
00 00 00 00 50 02 FF FF 7E 95 00 00 00 00 02 29
$ cat foo | xxd -r -p | hexdump -C
00000000 60 00 00 00 00 14 06 20 00 00 00 00 00 00 00 00 |`...... ........|
00000010 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 02 00 15 00 15 7a 32 b1 08 |............z2..|
00000030 00 00 00 00 50 02 ff ff 7e 95 00 00 00 00 02 29 |....P...~......)|
00000040

Resources