With an unused RFID card (MIFARE Classic 1K) that I had found in my old wallet, I've decided to clone it onto a blank card.
After executing nfc-mfclassic w X u <Original Card file name> <Blank Card file name>, I did a mfoc -O on the newly cloned blank card and the result was that everything was identically cloned as the original card. However I noticed that when comparing the dump of the newly cloned card to the dump of the clean blank card, I observed that the value of sector 0 was not cloned during the process of cloning using the nfc-mfclassic w X u command. I understand that the manufacturer block on blank cards, the manufacturer block can be clone but why in this example it's not doing that?
Below is the hex dump of the clean blank card before it was cloned.
00000000 de a0 ca 73 c7 08 04 00 01 23 8e aa 37 1d 58 1d |...s.....#..7.X.|
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000030 ff ff ff ff ff ff ff 07 80 69 ff ff ff ff ff ff |.........i......|
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000070 ff ff ff ff ff ff ff 07 80 69 ff ff ff ff ff ff |.........i......|
00000080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000b0 ff ff ff ff ff ff ff 07 80 69 ff ff ff ff ff ff |.........i......|
000000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000000f0 ff ff ff ff ff ff ff 07 80 69 ff ff ff ff ff ff |.........i......|
00000100 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000120 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000130 ff ff ff ff ff ff ff 07 80 69 ff ff ff ff ff ff |.........i......|
00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000150 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000170 ff ff ff ff ff ff ff 07 80 69 ff ff ff ff ff ff |.........i......|
00000180 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000190 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001b0 ff ff ff ff ff ff ff 07 80 69 ff ff ff ff ff ff |.........i......|
000001c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000001f0 ff ff ff ff ff ff ff 07 80 69 ff ff ff ff ff ff |.........i......|
00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000230 ff ff ff ff ff ff ff 07 80 69 ff ff ff ff ff ff |.........i......|
00000240 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000250 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000260 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000270 ff ff ff ff ff ff ff 07 80 69 ff ff ff ff ff ff |.........i......|
00000280 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000290 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000002a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000002b0 ff ff ff ff ff ff ff 07 80 69 ff ff ff ff ff ff |.........i......|
000002c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000002d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000002e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000002f0 ff ff ff ff ff ff ff 07 80 69 ff ff ff ff ff ff |.........i......|
00000300 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000310 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000320 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000330 ff ff ff ff ff ff ff 07 80 69 ff ff ff ff ff ff |.........i......|
00000340 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000350 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000360 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000370 ff ff ff ff ff ff ff 07 80 69 ff ff ff ff ff ff |.........i......|
00000380 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000390 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000003a0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000003b0 ff ff ff ff ff ff ff 07 80 69 ff ff ff ff ff ff |.........i......|
000003c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000003d0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000003e0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
000003f0 ff ff ff ff ff ff ff 07 80 69 ff ff ff ff ff ff |.........i......|
00000400
The first block of sector 0 of MIFARE Classic cards is the manufacturer block. This block is read-only on regular card hardware and, thus, cannot be cloned since you cannot write it to another card.
However, there exists special hardware (dedicated card emulators, like Proxmark, and special MIFARE Classic tags from other manufacturers, so-called Chinese clone cards) which allow writing to the manufacturer block. You could use such dedicated hardware to store a clone of a genuine card incuding the first block.
Related
I have a MIFARE Classic 1k, I used a reader to read everything on the card and would like to encode any data I write to it in NDEF so it can be read by a phone. I can only manually write the bytes atm and don't really know where to go from here. (I removed the data i wrote and replaced it with zeroes because it was sensitive)
Tried using different software but it seems like im the only one who wants such a weird thing done, here is the dump of the card. I do know the 16 sectors are separated by the KeyA ACs and KeyB (...FFFFF078069FFF...) Each sector being four blocks long ending in the keys, and all sector zero is used for is manufacturer info and UID.
Block 0: 77 57 DF D7 28 08 04 00 62 63 64 65 66 67 68 69
Block 1: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Block 2: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Block 3: FF FF FF FF FF FF FF 07 80 69 FF FF FF FF FF FF
Block 4: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Block 5: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Block 6: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Block 7: FF FF FF FF FF FF FF 07 80 69 FF FF FF FF FF FF
Block 8: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Block 9: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Block 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Block 11: FF FF FF FF FF FF FF 07 80 69 FF FF FF FF FF FF
And so on until block 63...
I'm a big fan of the default formatting of the hd command. For example:
$ head -c128 /bin/bash |hd
00000000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|
00000010 03 00 3e 00 01 00 00 00 30 f6 02 00 00 00 00 00 |..>.....0.......|
00000020 40 00 00 00 00 00 00 00 48 ce 11 00 00 00 00 00 |#.......H.......|
00000030 00 00 00 00 40 00 38 00 0b 00 40 00 1d 00 1c 00 |....#.8...#.....|
00000040 06 00 00 00 04 00 00 00 40 00 00 00 00 00 00 00 |........#.......|
00000050 40 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 |#.......#.......|
00000060 68 02 00 00 00 00 00 00 68 02 00 00 00 00 00 00 |h.......h.......|
00000070 08 00 00 00 00 00 00 00 03 00 00 00 04 00 00 00 |................|
00000080
I'm looking for a hexdump command that does the same thing but is double-wide. Output should look something like:
$ head -c128 /bin/bash |2hd
00000000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 03 00 3e 00 01 00 00 00 30 f6 02 00 00 00 00 00 |.ELF............| |..>.....0.......|
00000020 40 00 00 00 00 00 00 00 48 ce 11 00 00 00 00 00 00 00 00 00 40 00 38 00 0b 00 40 00 1d 00 1c 00 |#.......H.......| |....#.8...#.....|
00000040 06 00 00 00 04 00 00 00 40 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 |........#.......| |#.......#.......|
00000060 68 02 00 00 00 00 00 00 68 02 00 00 00 00 00 00 08 00 00 00 00 00 00 00 03 00 00 00 04 00 00 00 |h.......h.......| |................|
00000080
So far, I've got this. It does not line up properly.
2hd() {
local poe='" " 8/1 "%02x "' # pieces of eight, heh
hexdump -e '"%07.7_Ax\n"' \
-e '"%07.7_ax" '"$poe $poe $poe $poe"' " |" 32/1 "%_p" "|\n"' "$#"
}
$ head -c128 /bin/bash |2hd
0000000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 03 00 3e 00 01 00 00 00 30 f6 02 00 00 00 00 00 |#.......H...........#.8...#.....|
0000040 06 00 00 00 04 00 00 00 40 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00 |h.......h.......................|
0000080 a8 02 00 00 00 00 00 00 a8 02 00 00 00 00 00 00 a8 02 00 00 00 00 00 00 1c 00 00 00 00 00 00 00 |................................|
00000c0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 98 cd 02 00 00 00 00 00 98 cd 02 00 00 00 00 00 |................................|
0000100
(I haven't decided whether or not I want the right-side display to be in one part or two.)
I'm hoping to do this entirely within a single reference to hexdump. It'd help to know what the hexdump command to get the 16-col hd output would look like too. (The docs I can find are not helpful at this.)
I think you may just need to split the second -e:
2hd() {
local poe='" " 8/1 "%02x "'
hexdump -e '"%07.7_Ax\n"' \
-e '"%07.7_ax" '"$poe $poe $poe $poe" \
-e ' " |" 32/1 "%_p" "|\n"' "$#"
}
Multiple -e each work on the same input. In your original, the %_p applies to the input after the %x because it is in the same -e.
busybox hexdump source defines -C as:
bb_dump_add(dumper, "\"%08.8_Ax\n\""); // final address line after dump
//------------------- "address " 8 * "xx " " " 8 * "xx "
bb_dump_add(dumper, "\"%08.8_ax \"8/1 \"%02x \"\" \"8/1 \"%02x \"");
//------------------- " |ASCII...........|\n"
bb_dump_add(dumper, "\" |\"16/1 \"%_p\"\"|\n\"");
so that means you can implement hd as:
hexdump -e "\"%08.8_Ax\n\"" -e "\"%08.8_ax \"8/1 \"%02x \"\" \"8/1 \"%02x \"" \
-e "\" |\"16/1 \"%_p\"\"|\n\""
I assembled an assembly file in GCC under Windows like so:
as main.s -o main.o
And now I have the following object file:
4C 01 03 00 00 00 00 00 90 00 00 00 08 00 00 00
00 00 05 01 2E 74 65 78 74 00 00 00 00 00 00 00
00 00 00 00 04 00 00 00 8C 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 20 00 30 60 2E 64 61 74
61 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40 00 30 C0 2E 62 73 73 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 80 00 30 C0 C3 90 90 90
2E 66 69 6C 65 00 00 00 00 00 00 00 FE FF 00 00
67 01 66 61 6B 65 00 00 00 00 00 00 00 00 00 00
00 00 00 00 2E 74 65 78 74 00 00 00 00 00 00 00
01 00 00 00 03 01 01 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 2E 64 61 74 61 00 00 00
00 00 00 00 02 00 00 00 03 01 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 2E 62 73 73
00 00 00 00 00 00 00 00 03 00 00 00 03 01 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
04 00 00 00
I'd like to look inside this file to try and understand how object files are put together. Where can I find a format specification for whatever format this file is?
I'm loading a DIBSection from a file with the following:
HBITMAP bmpIn = (HBITMAP) LoadImage(NULL, _T("c:\\Temp\\Temp.bmp"), IMAGE_BITMAP, 0, 0, LR_CREATEDIBSECTION | LR_LOADFROMFILE);
Empirically I've discovered the following differences between the loaded bitmap and the bitmaps that I've used in the past, but I can't find any documentation stating that there should be a difference.
The lines are ordered in memory top down rather than bottom up. I've verified that the .bmp file itself is ordered bottom up.
The row padding is to a multiple of 2 bytes rather than 4.
I've also discovered a documented difference when you use CreateDIBSection to create a DIBSection from scratch.
The DIBSECTION.dsHandle and BITMAP.bmBits values returned by GetObject will be NULL.
Where's the documentation for the first two differences, and am I missing anything? This is with Windows 7 but I can't imagine it would be different for other versions of Windows.
Edit: Some additional details. Here's a hex dump of temp.bmp; it's a 7x7 image with a white stripe down the right side and blue values incrementing along the left (0x10,0x20,etc.). You can see that the bottom line (00,00,70) is first and that there's 3 bytes of padding.
00: 42 4d de 00 00 00 00 00 00 00 36 00 00 00 28 00
10: 00 00 07 00 00 00 07 00 00 00 01 00 18 00 00 00
20: 00 00 a8 00 00 00 00 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 00 00 70 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 ff ff ff 00 00 00 60 00
50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
60: ff ff ff 00 00 00 50 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 ff ff ff 00 00 00 40 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: ff ff ff 00 00 00 30 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 ff ff ff 00 00 00 20 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: ff ff ff 00 00 00 10 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 ff ff ff 00 00 00
Here's a sample program to read the .bmp file and write out the contents. I've removed error checking for brevity.
int _tmain(int argc, _TCHAR* argv[])
{
HBITMAP bmpIn = (HBITMAP) LoadImage(NULL, argv[1], IMAGE_BITMAP, 0, 0, LR_CREATEDIBSECTION | LR_LOADFROMFILE);
FILE * out = _tfopen(argv[2], _T("wb"));
DIBSECTION obj = {0};
GetObject(bmpIn, sizeof(obj), &obj);
cout << "dsBm.bmHeight = " << obj.dsBm.bmHeight << endl;
cout << "dsBmih.biHeight = " << obj.dsBmih.biHeight << endl;
cout << "sizeof(DIBSECTION) = " << sizeof(DIBSECTION) << endl;
fwrite(&obj, sizeof(DIBSECTION), 1, out);
int stride = (((obj.dsBmih.biWidth * obj.dsBmih.biBitCount) + 15) / 16) * 2;
int bytecount = abs(obj.dsBmih.biHeight) * stride;
vector<BYTE> bits(bytecount);
GetBitmapBits(bmpIn, bytecount, &bits[0]);
fwrite(&bits[0], 1, bytecount, out);
fclose(out);
return 0;
}
And here's the output from the above program along with a hex dump of the file produced:
dsBm.bmHeight = 7
dsBmih.biHeight = 7
sizeof(DIBSECTION) = 84
00: 00 00 00 00 07 00 00 00 07 00 00 00 18 00 00 00
10: 01 00 18 00 00 00 11 00 28 00 00 00 07 00 00 00
20: 07 00 00 00 01 00 18 00 00 00 00 00 a8 00 00 00
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
50: 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00
60: 00 00 00 00 00 00 ff ff ff 00 20 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 ff ff ff 00
80: 30 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 ff ff ff 00 40 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 ff ff ff 00 50 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ff ff
c0: ff 00 60 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 ff ff ff 00 70 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 ff ff ff 00
Call GetDIBits instead of GetBitmapBits. The docs for GetBitmapBits (here) indicate that this is returning data for a device-dependent bitmap, whereas you have a device-independent bitmap. They also indicate that this call shouldn't be used and is just there for 16-bit compatibility. So, using GetDIBits should do the trick.
Windows API function GetRawInputDeviceInfo has a parameter uiCommand. One of the options is RIDI_PREPARSEDDATA. It says "pData points to the previously parsed data".
I don't get what previously parsed data they are referring to. Is it the data that was last sent with WM_INPUT? Or is it data that was returned by any of the functions? Or something else? Also in what format is that data?
Preparsed data is report descriptor data associated with a top-level collection. User-mode applications or kernel-mode drivers use preparsed data to extract information about specific HID controls without having to obtain and interpret a device's entire report descriptor.
MSDN Link
"Also in what format is that data?"
Today I looked into GetRawInputDeviceInfo(), including the RIDI_PREPARSEDDATA data. Here's the output of the program when I test my XBOX controller. Everything except for displayable characters are in hex, and the hex for the displayable characters are given in parentheses after the displayable character.
getting device info...
Preparing 5 device lists...
Getting 5 devices...
index: type| location
0: HID| 0x01FB035F
1: Keyboard| 0x0001003F
2: Keyboard| 0x000B003D
3: Mouse| 0x0001003B
4: Mouse| 0x000B0039
Which would you like more info about?__
Pointer: 0x01FB035F
Type: HID
Name: \\?\HID#VID_0E6F&PID_0401&IG_00#7&2c93b906&0&0000#{4d1e55b2-f16f-11cf-88cb-001111000030}
Vendor ID: 0x00000e6f
Product ID: 0x00000401
Version Number: 0x00000000
Usage Page: 0x0001
Usage: 0x0005
DATA: (940 bytes)
H(0x48) i(0x69) d(0x64) P(0x50)
(0x20) K(0x4b) D(0x44) R(0x52)
05 00 01 00
00 00 00 00
00 00 07 00
07 00 0f 00
07 00 00 00
07 00 00 00
07 00 00 00
07 00 00 00
d8 02 04 00
01 00 00 00
10 00 01 00
03 00 10 00
02 00 00 00
05 00 01 00
01 00 00 00
08 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
1(0x31) 00 1(0x31) 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
ff ff ff ff
00 00 00 00
ff ff ff ff
00 00 00 00
00 00 00 00
01 00 00 00
10 00 01 00
01 00 10 00
02 00 00 00
03 00 01 00
01 00 00 00
08 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
0(0x30) 00 0(0x30) 00
00 00 00 00
00 00 00 00
01 00 01 00
00 00 00 00
00 00 00 00
ff ff ff ff
00 00 00 00
ff ff ff ff
00 00 00 00
00 00 00 00
01 00 00 00
10 00 01 00
07 00 10 00
02 00 00 00
09 00 02 00
01 00 00 00
08 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
4(0x34) 00 4(0x34) 00
00 00 00 00
00 00 00 00
02 00 02 00
00 00 00 00
00 00 00 00
ff ff ff ff
00 00 00 00
ff ff ff ff
00 00 00 00
00 00 00 00
01 00 00 00
10 00 01 00
05 00 10 00
02 00 00 00
07 00 02 00
01 00 00 00
08 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
3(0x33) 00 3(0x33) 00
00 00 00 00
00 00 00 00
03 00 03 00
00 00 00 00
00 00 00 00
ff ff ff ff
00 00 00 00
ff ff ff ff
00 00 00 00
00 00 00 00
01 00 00 00
10 00 01 00
09 00 10 00
02 00 00 00
0b 00 03 00
01 00 00 00
08 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
2(0x32) 00 2(0x32) 00
00 00 00 00
00 00 00 00
04 00 04 00
00 00 00 00
00 00 00 00
ff ff ff ff
00 00 00 00
ff ff ff ff
00 00 00 00
00 00 00 00
09 00 00 00
01 00 0a 00
0b 00 0a 00
02 00 00 00
0d 00 00 00
01 00 05 00
1c 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
01 00 0a 00
00 00 00 00
00 00 00 00
05 00 0e 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
01 00 00 02
04 00 01 00
0c 00 04 00
B(0x42) 00 00 00
0d 00 00 00
01 00 05 00
08 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
9(0x39) 00 9(0x39) 00
00 00 00 00
00 00 00 00
0f 00 0f 00
01 00 00 00
01 00 00 00
08 00 00 00
00 00 00 00
;(0x3b) 10 00 00
0e 00 00 00
00 00 00 00
05 00 01 00
00 00 03 00
00 00 03 00
01 00 00 00
00 00 01 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 01 00
00 00 00 00
01 00 00 00
00 00 00 00
00 00 01 00
00 00 00 00
02 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
end of data.Press any key to continue . . .
Notice the HidP KDR at the beginning. Other than that it looks like gibberish. The program formatted it nicely into four-octet words, but it looks like it will not display properly here without extra effort from me. Yes, it is meant to display on a command line, and no, I do not want to get rid of the result of system("pause").