Reverse Engineering a Samsung Scanner Button, page 5
Pages: 1 2 3 4 5 6 7 8
Step 6: Analyse the data, part1
Now we can open the capture file in an editor and have a look at everything that happened when we pressed the 'scan' button and dumped the USB traffic on that bus to our capture file. This data is going to lead us to a solution. What we will see are the 'URBs' or 'USB Request Blocks' in the form that usbmon represents them. You should see something like this in the capture file:
ffff88007a52b9c0 3115373453 S Ci:1:003:0 s c1 9a 0000 0100 0008 8 <
ffff88007a52b9c0 3115373605 C Ci:1:003:0 0 8 = 1b9a0000 00000000
ffff880023078d80 3116831450 S Ci:1:003:0 s c1 23 0100 0100 0008 8 <
ffff880023078d80 3116831696 C Ci:1:003:0 0 8 = 4e4f5453 50505254
Let's put this in a table for better analysis:
ffff88007a52b9c0 | 3115373453 | S Ci:1:003:0 s | c1 9a 0000 0100 0008 8 < |
ffff88007a52b9c0 | 3115373605 | C Ci:1:003:0 0 | 8 = 1b9a0000 00000000 |
ffff880023078d80 | 3116831450 | S Ci:1:003:0 s | c1 23 0100 0100 0008 8 < |
ffff880023078d80 | 3116831696 | C Ci:1:003:0 0 | 8 = 4e4f5453 50505254 |
So in our first URB (top line), starting from the left, in black followed by green we see:
1. | Memory address or Tag | ffff88007a52b9c0 |
2. | Timestamp | 3115373453 |
In red we see:
3. | Event type | S |
4. | Transfer type | Ci |
5. | Bus | 1 |
6. | Device | 003 |
7. | Endpoint | 0 |
8. | URB Status | s |
And in blue we see:
9. | Request Type | c1 |
10. | Command or bRequest | 9a |
11. | wValue | 0000 |
12. | wIndex | 0100 |
13. | wLength in hex | 0008 |
14. | wLength integer | 8 |
What I have just shown you is sort of jumping to the end... those URBs show us the control call that queries the hardware address of the 'scan' button. We will discuss how I zeroed in on this target and then I will show you what changed that gave me the answer that I was looking for.
Let's think about this for a moment... you have this giant data dump of the messages that were going from the host to the device and the responses coming back to the host.
How can we know what we are actually looking for if we do not understand the control protocol and what a proper message looks like?
It may not be obvious at first, but we should look for a huge bulk data transfer (which would be our actual scan data of the page in the scanner) and then work our way backwards to see if we can spot the control message. Remember that this will not exactly be obvious, since in this case there are no control endpoints on this unit, so we can't just look for that endpoint being accessed to find the control message.
However, since we can identify the bulk data transfer, then the control button query, control message and device response from the bulk data endpoint will be very close by, just above the bulk data series of packets of the scan itself.