Informix - Nothing happening when creating a db_space - informix

So Im trying to create a new db_space for my informix database.
I already created a file ( /matiasInformixDBSpaces/dbspace_proyectoUTU ) and gave necessary permissions to the informix user and group.
Now, logged in as root user I am attempting to create a new db_space. The first one was 500 MB and this one I intended to be 1 GB. the problem I am facing is that when I run the command below, it says "Verifying physical disk space, please wait..." and it just stays there forever.
No errors or warnings are thrown. The first time I did it it was super fast. I dont know what is going on now.
onspaces -c -d proyectoUTUinformix -p /matiasInformixDBSpaces/dbspace_proyectoUTU -o 5000 -s 1000240
Can someone help me to figure out what is going wrong?

Steps towards diagnosis
I’m curious about why you have a non-zero offset. If the name refers to a raw device and the volume manager uses the start, then it makes sense. Otherwise, it is rare to use a non-zero offset. However, that has a negligible effect on speed; it just wastes a little space.
Please identify your platform, and the version of Informix you are using.
Have you looked at the size of the file from another terminal window?
$ a6 timecmd -m -- onspaces -c -d auxilliary -p /opt/informix/dev/$IXS.auxilliary.c0 -o 0 -s 1000240
2018-04-16 22:27:07.348 [PID 71071] onspaces -c -d auxilliary -p /opt/informix/dev/osiris_19.auxilliary.c0 -o 0 -s 1000240
Verifying physical disk space, please wait ...
Space successfully added.
** WARNING ** A level 0 archive of Root DBSpace will need to be done.
2018-04-16 22:27:07.969 [PID 71071; status 0x0000] - 0.620s
$
I ran the command above on my own Mac (running macOS 10.13.4, with Informix 12.10.FC6 — I need to upgrade!) having created the empty file and set the permissions. This Mac has solid-state disk (SSD). The a6 command runs programs 'as informix'; the timecmd echoes more timing information than the simple time command — start time, command executed, PID, and then finish time, exit status and duration. I use it more for long-running commands, where knowing that it started a couple of hours ago is helpful.
Clearly, 0.620s is quick — essentially immediate. It shouldn't take very long on your system — a few seconds at most — to write a file that's 1,024,245,760 bytes long, which is the size of the file I ended up with.
So, you need to look hard at the disk you're using. If it's a memory stick, or a remote mounted file system connected via a modem line, then it could take a long time. But a mainstream SSD or spinning disk shouldn't take very long at all.
Given what's happened, interrupt the command. Review what's in your online log file — onstat -m for me showed:
05:27:07 Space 'auxilliary' added.
05:30:18 Space 'auxilliary' dropped.
I run my servers in UTC time zone; I'm in US/Pacific, currently UTC-7. Hence 22:27 locally corresponds to 05:27 in UTC.
Obviously, the 'dropped' message corresponded to my onspaces -d auxilliary command, run about three minutes after the add command. If you can't find a 'space added' message in your online log file, then the operation failed. If you find a 'space added' message, your terminal froze. (You didn't type control-S in it, did you? Try a control-Q to restart it.) You'll need to do the archive mentioned, of course (there's one required after the drop, too) if the space was added.
Try using:
time dd if=/dev/zero of=/matiasInformixDBSpaces/dbspace_proyectoUTU bs=1024 count=1000240
and see how long that takes. I ran:
$ a6 timecmd -m -- dd if=/dev/zero of=/opt/informix/dev/$IXS.auxilliary.c0 bs=1024 count=1000240
2018-04-16 22:43:05.006 [PID 71161] a6 dd 'if=/dev/zero' 'of=/opt/informix/dev/osiris_19.auxilliary.c0' 'bs=1024' 'count=1000240'
1000240+0 records in
1000240+0 records out
1024245760 bytes transferred in 6.740104 secs (151962902 bytes/sec)
2018-04-16 22:43:11.765 [PID 71161; status 0x0000] - 6.758s
$
That's much longer than the onspaces command, which means that onspaces did not write to every block in the disk file. When I analyzed the content of the file, I got:
$ a6 timecmd -m -- odx $opt/$IXS.auxilliary.c0
2018-04-16 23:10:26.836 [PID 71321] odx /opt/informix/dev/osiris_19.auxilliary.c0
0x0000: 00 00 00 00 04 00 50 35 00 00 00 18 18 00 E4 0F ......P5........
0x0010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
* (253)
0x0FF0: 00 00 00 00 00 00 00 00 00 00 00 00 42 35 16 00 ............B5..
0x1000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
* (255)
0x2000: 02 00 00 00 04 00 50 35 01 00 08 08 20 00 D8 0F ......P5.... ...
0x2010: 00 00 00 00 00 00 00 00 35 00 00 00 97 D0 03 00 ........5.......
0x2020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
* (252)
0x2FF0: 00 00 00 00 00 00 00 00 18 00 08 00 40 35 16 00 ............#5..
0x3000: 03 00 00 00 04 00 55 35 00 00 04 08 18 00 E4 0F ......U5........
0x3010: 00 00 00 00 00 00 00 00 03 00 00 00 00 00 00 00 ................
0x3020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
* (252)
0x3FF0: 00 00 00 00 00 00 00 00 00 00 00 00 44 35 16 00 ............D5..
0x4000: 04 00 00 00 04 00 51 35 05 00 02 08 D4 00 14 0F ......Q5........
0x4010: 00 00 00 00 00 00 00 00 01 00 40 00 01 28 00 00 ..........#..(..
0x4020: 88 00 00 00 00 00 00 00 01 00 00 10 12 8F D5 5A ...............Z
0x4030: 01 00 00 00 32 00 00 00 32 00 00 00 32 00 00 00 ....2...2...2...
0x4040: 02 00 00 00 00 00 00 00 FF FF FF FF 01 00 40 00 ..............#.
0x4050: 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x4060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0x4070: 00 00 00 00 01 00 00 00 00 00 00 00 01 00 00 00 ................
0x4080: 01 00 00 00 00 00 00 00 01 00 00 00 0C 00 00 00 ................
0x4090: 18 00 6D 00 00 00 00 00 00 00 00 00 00 00 00 00 ..m.............
0x40A0: 61 75 78 69 6C 6C 69 61 72 79 00 69 6E 66 6F 72 auxilliary.infor
0x40B0: 6D 69 78 00 54 42 4C 53 70 61 63 65 00 00 00 00 mix.TBLSpace....
0x40C0: 00 00 00 00 00 04 00 00 00 03 00 00 00 32 00 00 .............2..
0x40D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
* (240)
0x4FE0: 00 00 00 00 00 00 00 00 C0 00 14 00 C0 00 00 00 ................
0x4FF0: C0 00 00 00 A0 00 20 00 18 00 88 00 47 35 16 00 ...... .....G5..
0x5000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
* (64014079)
0x3D0CC000:
2018-04-16 23:10:30.808 [PID 71321; status 0x0000] - 3.971s
$
As you can see, some control information was written into the first 0x5000 bytes, but thereafter, the file was all null bytes. I'm not quite sure what it means by 'verifying physical disk space' given that the sub-second timing for onspaces means that it did not actually write to the space.
Resolution
If you follow the discussion in the comments below, you will see that the cause of the hold up was that the system was in the state CKPT REQ (checkpoint required). This could be seen from onstat output, for example. To get past that, either new logs needed to be added or the logical logs needed to be backed up.
Caution: By setting the backup device to /dev/null, you can let the server run without getting blocked, which might be OK while setting up the system, but won't be a good idea in production.
Check out the Backup and Restore Guide to learn about ON-BAR and ON-Tape, the two possible backup systems.
A lot depends on the context where you'll be running the server. If there's already a system for running backups that uses the BSA interface, using ON-BAR to integrate with that may be most appropriate. If you don't have such a corporate backup system, then ON-Tape may be simpler.
Before you go into production, please ensure you have a proper backup strategy, and you have practiced both backups and restores of the system.
You need to be confident that your backups work. You need to be confident that you know how to use them.
Do make sure your disks are not hard-wired directly to device names. You can use symlinks, or use the names of files. You need to be able to relocate the data, and hard-wired device names can make that difficult.

Related

FailureAction for service after boot

Sometimes, after server reboot, my service fails directly on the first startup. I have defined that the service should be restarted after a minute if it has failed.
However, it does not attempt to restart. Did I miss something?
The binary value of the FailureAction is
80 51 01 00
01 00 00 00
01 00 00 00
03 00 00 00
14 00 00 00
01 00 00 00 60 EA 00 00
01 00 00 00 E0 93 04 00
01 00 00 00 C0 27 09 00

Unresolved symbol in stacktrace when using GCC 4.8.2's Asan

I give a try to bug hunting with the help of this tuto : https://fuzzing-project.org/tutorial2.html
When I'm using address-sanitizer, I don't have any symbol resolution on the stack trace.
I try the manipulation describe here : Meaningful stack traces for address sanitizer in GCC but it doesn't work for me. My OS is Ubuntu 14.04
Here are the steps I take :
I use a test program in C which is a classic off-by-one-error
int main() {
int a[2] = {1, 0};
int b=a[2];
}
I install llvm 3.5 with apt-get
I export The following variables
export AFL_USE_ASAN=1
export ASAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer-3.5
export ASAN_OPTIONS=symbolize=1
I compile with gcc 4.8.2 with the following command
gcc -o test -fsanitize=address -g3 -ggdb test.c
There are the warnings I've got in the bug report when I launch the test program. It seems that AddressSanitizer can't connect to llvm-symbolizer-3.5
==13382== ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff92d6b0e8 at pc 0x400845 bp 0x7fff92d6b0a0 sp 0x7fff92d6b098
READ of size 4 at 0x7fff92d6b0e8 thread T0
==13382== WARNING: Can't read from symbolizer at fd 3
==13382== WARNING: Can't read from symbolizer at fd 3
==13382== WARNING: Can't read from symbolizer at fd 3
==13382== WARNING: Can't read from symbolizer at fd 3
==13382== WARNING: Can't read from symbolizer at fd 3
==13382== WARNING: Can't read from symbolizer at fd 3
==13382== WARNING: Failed to use and restart external symbolizer
0x400844 (/media/data/test+0x400844)
0x7fe5e7d4aec4 (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4)
0x400688 (/media/data/test+0x400688)
Address 0x7fff92d6b0e8 is located at offset 40 in frame <main> of T0's stack:
This frame has 1 object(s):
[32, 40) 'a'
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
(longjmp and C++ exceptions *are* supported)
Shadow bytes around the buggy address:
0x1000725a55c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000725a55d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000725a55e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000725a55f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000725a5600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x1000725a5610: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00[f4]f4 f4
0x1000725a5620: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
0x1000725a5630: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000725a5640: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000725a5650: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x1000725a5660: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Heap righ redzone: fb
Freed Heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
ASan internal: fe
==13382== ABORTING
And I don't get any symbol on the stacktrace.
If I perform a sudo I don't have any warnings but I don't have any symbol resolution either.
==13392== ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff911555e8 at pc 0x400845 bp 0x7fff911555a0 sp 0x7fff91155598
READ of size 4 at 0x7fff911555e8 thread T0
0x400844 (/media/data/test+0x400844)
0x7f4721057ec4 (/lib/x86_64-linux-gnu/libc-2.19.so+0x21ec4)
0x400688 (/media/data/test+0x400688)
Address 0x7fff911555e8 is located at offset 40 in frame of T0's stack:
This frame has 1 object(s):
[32, 40) 'a'
HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext
(longjmp and C++ exceptions are supported)
Shadow bytes around the buggy address:
0x100072222a60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100072222a70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100072222a80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100072222a90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100072222aa0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x100072222ab0: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00[f4]f4 f4
0x100072222ac0: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
0x100072222ad0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100072222ae0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100072222af0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x100072222b00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Heap righ redzone: fb
Freed Heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
ASan internal: fe
==13392== ABORTING
I also try the python script "asan_symbolize.py" describes in the google page project but without any results.
https://code.google.com/p/address-sanitizer/wiki/CallStack
I updated to gcc 4.9.
Now it's working.
Here's the step I take in Ubuntu to update.
sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt-get update
sudo apt-get install gcc-4.9 g++-4.9
sudo update-alternatives --install /usr/bin/gcc gcc /usr/bin/gcc-4.9 60 --slave /usr/bin/g++ g++ /usr/bin/g++-4.9
More details here : https://askubuntu.com/questions/466651/how-do-i-use-the-latest-gcc-4-9-on-ubuntu-14-04
export ASAN_SYMBOLIZER_PATH=/usr/bin/llvm-symbolizer-3.5
...
READ of size 4 at 0x7fff911555e8 thread T0
0x400844 (/media/data/test+0x400844)
0x7f4721057ec4 (/lib/x86_64-linux-gnu/libc-2.19.so+0x21ec4)
0x400688 (/media/data/test+0x400688)
Under Clang, you need to pipe your output through asan_symbolize to get the symbols. I discuss Clang because you are clearly using LLVM gear (llvm-symbolizer-3.5 above). So you should do something like:
./test 2>&1 | asan_symbolize
I have asan_symbolize in both /usr/bin and /usr/local/bin:
$ find /usr/ -name asan*
/usr/bin/asan_symbolize
/usr/lib/llvm-3.4/lib/clang/3.4/include/sanitizer/asan_interface.h
/usr/local/bin/asan_symbolize.py
/usr/local/lib/clang/3.5.0/include/sanitizer/asan_interface.h
I have two copies because one was installed with Clang via apt-get (/usr/bin/asan_symbolize), and I build Clang from sources on occasion (/usr/local/bin/asan_symbolize.py).
If you have no copies, then I believe you can fetch it from address-sanitizer on Google Code.
Once you start using asan_symbolize, you might encounter a situation where asan_symbolize cannot find the symbols due to a path change (for example, a program or library was copied from its build location to a destination directory). For that, see Specify Symbol Path to asan_symbolize? on the Asan mailing list.
In kcc's answer, he meant to do something like:
./test 2>&1 | sed "s/<old path>/<new path>/g" | asan_symbolize
(I think I had to do it when testing Postgres).
I recently started using GCC's sanitizers, but I have never used asan_symbolize with GCC. I'm not sure how well its going to work for you. Naively, I would expect its going to work as expected.
I compile with gcc 4.8.2 with the following command...
I'm not sure how well mixing/matching will work for you. Perhaps you should stick to GCC; or you should install Clang and use it.
Python has a crash course in Clang and its sanitizers at Dynamic Analysis with Clang. It discusses topics like getting stack traces. (I wrote the page for the the Python project to help them add Clang and its sanitizers to its release engineering process).

Identify this image format

This is going to be a big shot in the dark.
A client has an application that is incredibly outdated. It's running at one of their client's offices. The app contains a lot (hundreds of thousands) of images viewable from a proprietary interface.
So, those images are in some odd "proprietary" format. The whole goal of this is to be able to pull and convert all of the images so the data stored within the app can be transferred to their updated system. Now, quotation marks were placed around proprietary because we know that it isn't proprietary, rather, it's in some other format that we can't identify. The application does make use of an old version of ImageGear (GEAR32SD.DLL is bundled with the app).
This is a hex dump of an image file containing only one white pixel:
50 50 03 00 01 00 00 00 01 00 00 00 52 00 00 00 01 00 00 00 96 00 96 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 53 00 00 00 01 00 00 00 00 01 00 01 f0 00 00 00 e5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1c 35
This is a hex dump of an image file containing only one black pixel:
50 50 03 00 01 00 00 00 01 00 00 00 52 00 00 00 02 00 00 00 96 00 96 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 54 00 00 00 01 00 00 00 00 01 00 01 f0 00 00 00 e5 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 35 40 35
The leading 50 50 03 is present in every file.
If this looks even remotely familiar, please pipe up. At this point we haven't got a lot left to try. We just want our images.
Find the image viewer your client uses and reverse engineer that program. RE'ing the images is just guessing/fuzzing, versus RE'ing a parser where you actually have a chance at success.

How to solve “Error 13 while loading file” when using Qemu?

I write the following bytes into a file named disk.img
FA 8D 36 1B 7C E8 01 00 F4 AC 3C 00 74 0C B4 0E
BB 07 00 B9 01 00 CD 10 EB EF C3 4D 61 79 20 74
68 65 20 66 6F 72 63 65 20 62 65 20 77 69 74 68
20 79 6F 75 21 0D 0A 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
..enough zero to make the size of file 512bytes.
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 AA
The above bytes are proper instructions and magic number that should work when loading into the boot sector. But after I executed "qemu-X86_64 disk.img", error happens.
Error -13 while loading disk.img
Does anyone know how to solve the problem or what is the reason that might lead to this error?
Thank you!
I don't know if you can fill a image with just anything and expect it to work just because you have 55 AA in the correct place. Since you seem to be writing a bootloader make sure your code thinks it is executing at the correct place. It should be in offset 0x7C0 (if i remember this correctly, double check thaat). You set it using [org 0x7c0] in the top of your assembly file.
Also I'm not sure you can have only a 512 byte file. Try to make a harddriver bigger than that something like dd if=/dev/zero of=disk.img bs=512 count=2000 and then just copy your bootloader to the first part of the disk using dd again.
Also you should use the -hda or -fda tag so it should be qemu -hda disk.img

What is RIDI_PREPARSEDDATA in GetRawInputDeviceInfo?

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").

Resources