I'm currently writing an ssh honeypot in Java as a personal project. I'm having trouble understanding the algorithm negotiation. To be precise, the structure of the received data from the client. Here is what I receive, with my personal annotations:
00 00 07 AC == packet length
08 == padding length
14 == SSH_MSG_KEXINIT
6C 31 89 77 EB 54 E1 8B D4 B1 35 08 FD 52 65 6E == cookie
00 00 00 D4 == string length
kex algorithms in byte form
00 00 01 67 == string length
server host key algorithms in byte form
00 00 00 E9 == string length
encryption_algorithms_client_to_server in byte form
00 00 00 E9 == string length
encryption_algorithms_server_to_client in byte form
00 00 01 92 == string length
mac_algorithms_client_to_server in byte form
00 00 01 92 == string length
mac_algorithms_server_to_client in byte form
00 00 00 1A == string length
compression_algorithms_client_to_server in byte form
00 00 00 1A == string length
compression_algorithms_server_to_client in byte form
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
Information about the negotiation can be found here:
rfc4253
There are two things I don't fully understand:
The padding: How is it calculated? According to rfc4253, there should be a random padding (8 bytes in this case). I don't see it anywhere. Moreover, the size of the packet length + padding length + payload + padding should be a multiple of 8, which isn't the case here. (?)
The packet length: If I just sum up everything after the packet length, I get 0x797. Adding the 8 byte padding (wherever it is), I get 0x79F. Am I correct in thinking that the languages for client->server and server->client, although not defined, still take 4 byte each? That gets me to 0x7A7. If I now add the boolean and the reserved 4 bytes (see packet structure), I finally get 0x7AC. Is that correct? That would mean the trailing zeros have the following structure:
00 00 00 00 == length of string for language_client_to_server
00 00 00 00 == length of string for language_server_to_client
00 == boolean first_kex_packet_follows
00 00 00 00 == reserved
rest: garbage?
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 followed this tutorial to the letter, but I'll to explain in detail what steps I took exactly. I have an ECP5-evaluation 85k board.
I soldered bridges on R34/R35 (RX/TX) and R21 (connects LED D1 to RXD)
I used my windows installation to run the latest version of FT_PROG. In FT_PROG I went to FT_EEPROM -> Hardware Specific -> Port B -> Hardware and set it to RS232 and hit program. It completed succesfully according to the software.
Then I forwarded the USB port to my virtual box linux machine. It recognizes the board and I can succesfully run verilog files on it.
I ran ./raw_serial.sh to upload raw_serial.v to my board which is supposed to repeatedly print A to the serial monitor.
I then opened minicom on /dev/ttyUSB1 and it recognizes the device, baudrate is set correctly.
I then tried to use cu as follows: sudo chmod 666 /dev/ttyUSB1 && sudo cu -l /dev/ttyUSB2 -s 115200. It opens a terminal and says it is connected.
Led D1 is lighting up and both terminal programs indicate that the connection is succesful (I tried one of them at a time of course). Nothing is printed to the screen. When I use minicom and reupload raw_serial.v some <?> signs are printed to the screen but that's it. I tried turning echo on and off but nothing seems to work.
The following worked for me and it will probably work for others too. I'm assuming you're using openocd.
Do not use FT_PROG in windows, it doesn't seem to actually flash the FTDI chip. However, it lets you read back the hex dump that was supposed to be flashed to the chip. The hex dump for the unchanged EEPROM as it comes out of the box is as follows:
00000000 01 08 03 04 10 60 00 07 C0 FA 08 00 11 11 9A 10 .....`..Àú....š.
00000010 AA 3C E6 12 00 00 00 00 56 00 00 00 00 00 00 00 ª<æ.....V.......
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000050 00 00 00 00 00 00 02 03 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 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
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 10 03 4C 00 61 00 ............L.a.
000000A0 74 00 74 00 69 00 63 00 65 00 3C 03 4C 00 61 00 t.t.i.c.e.<.L.a.
000000B0 74 00 74 00 69 00 63 00 65 00 20 00 45 00 43 00 t.t.i.c.e. .E.C.
000000C0 50 00 35 00 20 00 45 00 76 00 61 00 6C 00 75 00 P.5. .E.v.a.l.u.
000000D0 61 00 74 00 69 00 6F 00 6E 00 20 00 42 00 6F 00 a.t.i.o.n. .B.o.
000000E0 61 00 72 00 64 00 12 03 46 00 54 00 32 00 55 00 a.r.d...F.T.2.U.
000000F0 59 00 54 00 4A 00 56 00 00 00 00 00 00 00 FC 27 Y.T.J.V.......ü'
I just post this here for future reference, we're not going to use the stock eeprom.
We need to flash the eeprom to RS232-HS mode. To do so, we must first change the hex dump of the eeprom accordingly. To put channel B in RS232-HS mode we need to change the last column of the last row from ' to |. Create a hex file called eeprom_RS232.bin with the following contents:
00000000 01 08 03 04 10 60 00 07 C0 FA 08 00 11 11 9A 10 .....`..Àú....š.
00000010 AA 3C E6 12 00 00 00 00 56 00 00 00 00 00 00 00 ª<æ.....V.......
00000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000050 00 00 00 00 00 00 02 03 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 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
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 10 03 4C 00 61 00 ............L.a.
000000A0 74 00 74 00 69 00 63 00 65 00 3C 03 4C 00 61 00 t.t.i.c.e.<.L.a.
000000B0 74 00 74 00 69 00 63 00 65 00 20 00 45 00 43 00 t.t.i.c.e. .E.C.
000000C0 50 00 35 00 20 00 45 00 76 00 61 00 6C 00 75 00 P.5. .E.v.a.l.u.
000000D0 61 00 74 00 69 00 6F 00 6E 00 20 00 42 00 6F 00 a.t.i.o.n. .B.o.
000000E0 61 00 72 00 64 00 12 03 46 00 54 00 32 00 55 00 a.r.d...F.T.2.U.
000000F0 59 00 54 00 4A 00 56 00 00 00 00 00 00 00 FC 27 Y.T.J.V.......ü|
Now, we need to flash this eeprom to our ECP5 using Anton's method. To do this, first create a file ftdi_RS232.conf with the following contents:
vendor_id=0x403
product_id=0x6010
filename="eeprom_RS232.bin"
flash_raw=true
With the following command we can flash to our ECP5: ftdi_eeprom --flash-eeprom ftdi_RS232.conf. Should we ever want to revert back to the stock eeprom, we can easily repeat this method with the hex dump given in step 1.
Now it's time to flash the verilog file. However, the device description of the ECP5 has changed from Lattice ECP5 Evaluation Board to Dual RS232-HS. We need to tell openocd to look for that specific device. Start by creating a file ecp5.cfg with the following contents:
# this supports ECP5 Evaluation Board
interface ftdi
ftdi_device_desc "Dual RS232-HS"
ftdi_vid_pid 0x0403 0x6010
# channel 1 does not have any functionality
ftdi_channel 0
# just TCK TDI TDO TMS, no reset
ftdi_layout_init 0xfff8 0xfffb
reset_config none
# default speed
adapter_khz 5000
# ECP5 device - LFE5UM5G-85F
jtag newtap ecp5 tap -irlen 8 -expected-id 0x81113043
Then, create your svf file as you usually do and flash it with the following command:
sudo --preserve-env=PATH env openocd -f ./ecp5.cfg -c "transport select jtag; init; svf raw_serial.svf; exit"
Finally, we can open a terminal to read the serial output of the ECP5. Personally, I like to use minicom: sudo chmod 666 /dev/ttyUSB0 && minicom -D /dev/ttyUSB0.
One more problem with the raw_serial.v example was that it doesn't use a baudrate of 115200 as the readme suggests but 19200. The clock that is connected to the FTDI chip runs at 12 MHz. If you want a baudrate of 115200 you need to send a bit every 12,000,000 / 115,200 ~= 104 ticks. This means you need to change line 14 to if (counter == 104) begin.
I'm interested in operating system concepts, so I downloaded the Hello world OS. I'd like to know how to compile and link the code and make a bootable image. I'm using an old version of Cygwin on Windows (Cygwin-b20) from 1999.
My code for main.c is:
#include "bloader.h"
int main();
unsigned int oldEBP;
struct boot_dir *viewableDirectory;
int totalMem;
char * passedParams;
void _start(int memSize, char *parms, struct boot_dir *loadedfiles)
{
asm("mov %%ebp, %0":"=m"(oldEBP));
viewableDirectory = loadedfiles; /*make file mem locations global*/
totalMem = memSize; /*make mem of system global*/
passedParams = parms; /*make paramaters passed to system global*/
main();
asm("hlt"); /* this halts the machine, solving the problem of triple-faults on
some machines, but also making it impossible to return to DOS */
}
int main()
{
char *vidmem = (char *) 0xb8000;
/* "Hello " */
vidmem[0] = 'H';
vidmem[1] = 0x7;
vidmem[2] = 'e';
vidmem[3] = 0x7;
vidmem[4] = 'l';
vidmem[5] = 0x7;
vidmem[6] = 'l';
vidmem[7] = 0x7;
vidmem[8] = 'o';
vidmem[9] = 0x7;
vidmem[10] = ' ';
vidmem[11] = 0x7;
/* "World " */
vidmem[12] = 'W';
vidmem[13] = 0x7;
vidmem[14] = 'o';
vidmem[15] = 0x7;
vidmem[16] = 'r';
vidmem[17] = 0x7;
vidmem[18] = 'l';
vidmem[19] = 0x7;
vidmem[20] = 'd';
vidmem[21] = 0x7;
vidmem[22] = ' ';
vidmem[23] = 0x7;
/* "OS" */
vidmem[24] = 'O';
vidmem[25] = 0x7;
vidmem[26] = 'S';
vidmem[27] = 0x7;
return 0;
}
I'm interested in instructions to:
Create ISO file after compile and run it with VMware (or other virtual machines)
Run this code after compiling in real machine when system boots and how to add it to bootloader (for example GRUB) entry
Make an empty file and give it the extension .vmdk
open it up in your favorite hex editor
and place your compiled boot loader code
its exactly the same as a hard drive
also the last 2 bytes in the sector must be 55 and AA
your bootloader code starts from 00
it will look something like this
Sector Offset Hex Values Ascii
x00000000 x000 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
x010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
x020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
x030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
x040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
x050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
x060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
x070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
x080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
x090 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
x0A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
x0B0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
x0C0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
x0D0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
x0E0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
x0F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
-------------
x1F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA
here is a guide to make run a boot loader
http://www.codeproject.com/Articles/36907/How-to-develop-your-own-Boot-Loader#_Toc231383191
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").