Analysis of usb hid device interface protocol using ollydbg

Analysis of usb hid device interface protocol using ollydbg
Author: tase tase@163.com
Keywords: ollydbg, USB, hid, bus hound,

Analysis tools: ollydbg, bus hound
Analysis object: a USB interface Flight Simulator

Objective: To analyze the software that uses the usb hid device, "buckle" the data protocol of the HID device from its main program, and then implement the usb hid device based on these protocols, this allows you to copy the original hid data collection device.

I was lucky enough to get an original flight simulation software and interface device. This simulator collects data from the remote control device to the PC through a USB interface, and then simulates the real flight through the software, because the original equipment is expensive, I plan to DIY a set of interfaces, so I started to analyze it!

This simulator software consists of two parts: a simulation software and a USB data collection device. before getting the device, I guess it may be a hid (Human Body device) device, many USB data collection devices are designed using the hid protocol, so that they can be installed without a driver in windows, in addition, you can access these hardware interfaces in the user mode through the built-in Windows interfaces.

After testing, the HID device uses the bushound5 bus observer to capture data from USB devices on the bus. The HID device is very simple, it took me two hours to figure out the meaning of most of the data, so I quickly implemented the device on the Single Chip Microcomputer Development Board according to the protocol I understood and inserted it into my device, the simulator software quickly recognized my interface, but when the data of each channel is displayed, It is 0. That is to say, its system detects an interface device, however, this data set for backup sampling is incorrect.

So I went back to the bus data analysis and found the two missing bits. I didn't understand the two bits. I guess they are the check bit. After observation, the two bits are only related to a few bytes, but it takes me four days to get these two bits. These days I learned many features that most people do not know about excel, I learned how to use Vbscript to write macros. I even used MATLAB. I used the statistical method to find the 2bit pattern, but eventually I failed.

I thought of ollydbg's protocol for analyzing the USB interface in the main program. I didn't think of it. One night, I solved my problem.
There are two ways to access the HID device in Windows: kernel mode, that is, access using the driver method. This method is very complicated. I know the principle, but I have not written such a driver. Second, the customer State means that applications can access the HID device by calling the hid function provided by windows. If we intercept the calls of these functions, it is not far from our goal.

Generally, the main program recognizes USB hid peripherals by calling the hidd_gethidguid function to obtain the class ID of the HID device and calling the setupdigetclassdevs function to query all installed hid devices, obtain a handle pointing to the HID device set. Call the setupdienumdeviceinterface function to query the interface information of each device in the HID device set. Call the setupdigetdeviceinterfacedetail function to obtain detailed information about each interface, this includes the device name (the first four bytes). createfile uses this device name to open the device and calls the setupdidestroydeviceinfolist function to release the device information set. Step 2: Open the device and obtain the property value and device Capability Description of the device, call the createrfile function to open the device. Call the hidd_getattributes function to obtain the relevant properties of the USB device. It contains the vendor ID, product ID, and version number of the device. You can determine whether the device is the target device based on the information, but we are not concerned about this. We are concerned about readfile operations after the device is opened. We know that, all devices in Windows read and write as files.

Start the ollydbg to load the simulator software. The break point "hidd_getattributes" and "createfile" can be used to obtain the key information of the hid, such as the manufacturer ID, product ID, and version? Before debugging, unplug all unnecessary USB devices on the machine. In this way, the enumerated devices will be less and the number of breakpoints will be much less.

Because Bus Hound is used earlier, it is easy to know the VID and PID of the device we want to care about. In this way, after the breakpoint is in HidD_GetAttributes, it is easy to know which device is of interest to us, the device string path in the stack. When the CreateFile function breakpoint occurs, are you sure you want to open the device that we care about?

After opening the HID device we are concerned about, we need to care about ReadFile and WriteFile. The next breakpoint is ReadFile. Unfortunately, there are too many such breakpoints! Think of a problem, although HID is a low-speed device, but the refresh time is also 10 ms/frame, so the average WINDOWS timer can only be accurate to 50 ms, to read the standby data of HID Without Frame loss, a high-precision timer-multimedia timer will be used.

When a multimedia timer is used, the following functions are certainly used: timeGetDevCaps, timeBeginPeriod, and timeSetEvent. the breakpoint is placed on this function. After some efforts, the key ReadFile is found, after reading the HID device data, what should I do? According to common sense, it is time to analyze and verify it. Indeed, my analysis is correct. Here is the key assembly code obtained at that time, because this article was written in a few months later, therefore, some content can only be recalled.

After reading the code, you can fully understand the protocol.

004417B2. 8B0D D8CD9500 mov ecx, dword ptr ds: [95CDD8] // retrieves the high byte of the CH1-CH4
004417B8. A3 00CE9500 mov dword ptr ds: [95CE00], EAX
004417BD. 33D2 xor edx, EDX
004417BF. 8BC1 mov eax, ECX
004417C1. 8A15 D7CD9500 mov dl, byte ptr ds: [95CDD7] // retrieve bytes Channel Data
004417C7. 25 FF000000 and eax, 0FF
004417cc. 8bf2 mov ESI, EDX // note that the low 8-bit data of the period will be stored and used as the check bit in the future.
004417ce. 8bd0 mov edX, eax
004417d0. 83e2 03 and EDX, 3 // mask the high byte with 0x3, and retrieve the high two bits of the bytes.
004417d3. 33db xor ebx, EBX
004417d5. c1e2 08 SHL edX, 8 // shift the height of the secondary node to the left of the secondary node.
004417d8. 8a1d d6cd9500 mov BL, byte ptr ds: [95cdd6] // retrieve CH2 Channel Data
004417de. 8d9432 dc03000> Lea edX, dword ptr ds: [edX + ESI + 3dc] // calculate the final data of the shard, and the data of the two-digit + shard + constant 3dc
004417e5. 8915 e0cd9500 mov dword ptr ds: [95cde0], EDX // save shard data
004417eb. 8bd0 mov edX, eax
004417ed. 83e2 0C and EDX, 0C // obtain the high 2-bit mask of CH2
004417f0. c1e2 06 SHL edX, 6 // calculate the two-digit height of CH2
004417f3. 8d941a dc03000> Lea edX, dword ptr ds: [edX + EBX + 3dc] // calculate the complete CH2 data
004417fa. 33db xor ebx, EBX
004417fc. 8915 e4cd9500 mov dword ptr ds: [95cde4], EDX // save CH2 data
00441802. 8bd0 mov edX, eax
00441804. 83e2 30 and EDX, 30 // take the top CH3 mask
00441807. 8add mov BL, ch // obtain low 8-bit CH3 data
00441809. c1e2 04 SHL edX, 4 // high 2 displacement position
0044180c. 25 c0000000 and eax, 0c0 // obtain the high level mask of the methane
00441811. 8d8c1a dc03000> Lea ECx, dword ptr ds: [edX + EBX + 3dc] // calculate the complete CH3 data
00441818. 33d2 XOR edX, EDX
0044181a. 8a15 d5cd9500 mov DL, byte PTR DS
00441820. 890d e8cd9500 mov dword ptr ds: [95cde8], ECx // save CH3 data
00441826. 8d8482 dc03000> Lea eax, dword ptr ds: [edX + eax * 4 + 3dc] // calculate the methane d Data
0044182d. A3 eccd9500 mov dword ptr ds: [95 cdec], eax // Save the data of Methane
00441832. A1 dccd9500 mov eax, dword ptr ds: [95 cddc] // retrieve the high data and flag data of the CH5-CH8
00441837. A8 40 test Al, 40 // The 6bit of the flag indicates the parity frame.
00441839. 74 41 je short reflex.0044187c // if the value is 0, the CH5 and ch6 are valid, and goto to 0044187c.
0044183b. 25 ff000000 and eax, 0ff // otherwise it is an odd number of frames
00441840. 33d2 XOR edX, EDX
00441842. 8a15 dbcd9500 mov DL, byte ptr ds: [95 cddb] // obtain the low 8-bit data of CH5
00441848. 8bc8 mov ECx, eax
0044184a. 83e1 0C and ECx, 0c
0044184d. c1e1 06 SHL ECx, 6
00441850. 8d8c11 dc03000> Lea ECx, dword ptr ds: [ECx + EDX + 3dc] // calculate the complete data of CH5.
00441857. 8bd0 mov edX, eax
00441859. 83e2 03 and EDX, 3 // take the height of ch6 2 bits
0044185c. 890d f8cd9500 mov dword ptr ds: [95cdf8], ECx // save CH5
00441862. c1e2 08 SHL edX, 8
00441865. 33c9 XOR ECx, ECx
00441867. 8a0d dacd9500 mov Cl, byte ptr ds: [95 cdda] // obtain the low 8-bit ch6
0044186d. 8d940a dc03000> Lea edX, dword ptr ds: [edX + ECx + 3dc] // calculate ch6 data
00441874. 8915 FCCD9500 mov dword ptr ds: [95 CDFC], EDX // save CH6 data
0044187A. EB 4A jmp short REFLEX.004418C6
0044187C> 25 FF000000 and eax, 0FF
00441881. 33D2 xor edx, EDX
00441883. 8A15 DBCD9500 mov dl, byte ptr ds: [95 CDDB]
00441889. 8BC8 mov ecx, EAX
0044188B. 83E1 0C and ecx, 0C
0044188E. C1E1 06 shl ecx, 6
00441891. 8D8C11 DC03000> lea ecx, dword ptr ds: [ECX + EDX + 3DC]
00441898. 8BD0 mov edx, EAX
0044189A. 890D F0CD9500 mov dword ptr ds: [95CDF0], ECX
004418A0. 83E2 03 and edx, 3
004418A3. 33C9 xor ecx, ECX
004418A5. 8A0D DACD9500 mov cl, byte ptr ds: [95 CDDA]
004418AB. C1E2 08 shl edx, 8
004418AE. 8D940A DC03000> lea edx, dword ptr ds: [EDX + ECX + 3DC]
004418B5. 8BC8 mov ecx, EAX
004418b7. c1e9 07 SHR ECx, 7 // note that the highest bit of the flag is retrieved here for judgment.
004418ba. 8915 f4cd9500 mov dword ptr ds: [95cdf4], EDX // the above section calculates the data of the 7-8 channel and saves
004418c0. 890d 04ce9500 mov dword ptr ds: [95ce04], ECx
004418c6> 8bd0 mov edX, eax // partial flag of Public 2bit check bit
004418c8. 83f6 07 xor esi, 7 // values and 0x7 XOR =>
004418cb. 83e2 0f and EDX, 0f // The flag bit is 4 bits => B
004418ce. 03d6 add edX, ESI // low 4 bits and a + B ==> C
004418d0. d1e2 SHL edX, 1 // C <1 => d
004418d2. 33d0 XOR edX, eax // d xor flag ==> E
004418d4. f6c2 30 test DL, 30 // E & 0x30 ==> F is successful if it is 0!
004418d7. 74 3A je short reflex.00441913
004418d9. A1 c4cd9500 mov eax, dword ptr ds: [95cdc4]
004418de. 85c0 test eax, eax
004418e0. 75 40 jnz short reflex.00441922
004418e2. A1 08ce9500 mov eax, dword ptr ds: [95ce08]
004418e7. c705 c4cd9500> mov dword ptr ds: [95cdc4], 1
004418f1. 50 push eax
004418f2. EB 1D JMP short reflex.00441911
004418f4> 8b0d 08ce9500 mov ECx, dword ptr ds: [95ce08]
004418fa. c705 c4cd9500> mov dword ptr ds: [95cdc4], 1
00441904. 8935 b8cd9500 mov dword ptr ds: [95cdb8], ESI
0044824a. 8935 bccd9500 mov dword ptr ds: [95 cdbc], ESI
00441910. 51 push ECx
00441911> ffd5 call EBP
00441913> A1 c4cd9500 mov eax, dword ptr ds: [95cdc4]
00441918. 33f6 xor esi, ESI
0044191a. 3bc6 CMP eax, ESI
0044191c. ^ 0f84 61 feffff je reflex.00441783
00441922> 5f pop EDI
00441923. 5E pop ESI
00441924. 5D pop EBP
00441925. 33c0 XOR eax, eax
00441927. 5B pop EBX
00441928. 59 pop ECx
00441929. C2 0400 retn 4

2bit = (ppacket-> bytech1 ^ 0x07) + (ch_hid_report [7] & 0x0f) <1) & 0x30)> 4;

At that time, I was so excited to use a line of C language to complete 2bit verification data that had plagued me for four days! I immediately wrote this algorithm into the firmware of the microcontroller and inserted it into my DIY hid simulator device. OK, the system has been able to correctly collect data from my device.
USB protocol cracking successful!

This is the first time I have used ollydbg to solve practical problems. If you are ignorant, please criticize them.

Summary: Sometimes, when we solve a problem, we often fail to get progress on the front. We should start from the side and the back. The so-called pig and spam have different ways of killing each other!