Hacking the stick
I decided to inspect the flash first. According to Ritech, the data on it was
encrypted; it wouldn't be
the first time
a manufacturer of USB-sticks claims stuff the stick doesn't actually do, though.
I desoldered the flash-chip using a heat-gun. (Please note that Ritech claims
opening the device and pulling out the flash-chip isn't possible without
irreparably damaging said flash-chip.) I then inserted it into my nand-reader,
a device consisting mainly of a pcb, some resistors and a connector to the
parallel port of my PC.
The file I dumped off the chip seemed to confirm Ritechs claim of using
encryption to store the data: apart from the first few K at the start of the
flash which seemed to contain the firmware for the xSIL USB-to-nand-chip and some
wear-levelling tables, the data was complete gobbledygook, with no discernable pattern.
Having dumped the flash, I decided to solder the chip back in and try another way
to get to my data.
I decided to take a look at the connections between the main PCB and the fingerprint-PCB. This one consisted of two pin headers, both of which had 7 pins. The first one seemed to be used solely to control the LEDs; the other one, however, seemed to connect the fingerprint-handling-IC to the main PCB. I connected my oscilloscope to these pins, and surely enough, two of the pins revealed some kind of communication when a finger was put on the sensor. The communication seemed to be an asynchronous serial one, and the width of the pulses indicated it had to be at 9600 baud. I decided to listen in on the communication and connected an old GSM data-cable to the pin that seemed to be sending data from the fingerprint-IC to the main PCB. It turned out the communication was question-response-based, and went something like this:
- Main PCB: "Ok, please inform me when a finger is detected."
- Fingerprint-IC: "I'll do."
- Fingerprint-IC: "I have detected a fingerprint!"
- Main PCB: "Do you know it?"
- Fingerprint-IC: "Nope, unknown to me."
- Main PCB: "Bummer. Give a shout when you detect another one."
- Fingerprint-IC: "Will do."
- Fingerprint-IC: "I have detected another fingerprint!"
- Main PCB: "Ok, do you know it?"
- Fingerprint-IC: "Yes, it's the 2nd fingerprint I have been learnt"
- Main PCB: "Ok. One more and I'll unlock."
While the real communication is more binary and has checksums and response-IDs, this is basically how the communication between these components work. Some people may already have spotted the weakness in the scheme: what if it's not the fingerprint-IC which is sending the 'I have found a recognized fingerprint!'-response?
Eager to see if such a hack is possible, I cut the pin the responses from the fingerprint-IC were sent on and spliced the datacable in between. Now my PC acted as a man-in-the-middle: it could listen in to the things the fingerprint-IC sent and could decide if it would just pass through the message, block it, or send something completely different. Then, I recorded some of the responses the chip sent when presented a correct fingerprint. Finally, I created a little program (60 lines of C) which detects and blocks the message sent when a fingerprint is not recognised and sends one of the recorded messages instead.
After writing the program, I wired up the stick, inserted it to the USB-port and
pressed my nose against the fingerprint-sensor: I was quite sure it didn't know
that 'fingerprint' yet. My program gave the message that it had altered the
message from the fingerprint-IC, and lo and behold: the green LED blinked
indicating the stick thought it had received a recognized fingerprint. Repeating
the procedure gave the stick the second 'fingerprint' it wanted, and the
contents of the stick were available to my computer.
