Hacking the silver stick
While the silver stick is the one advertised as having AES-encryption, it seems only the white stick really has it. The absense of encryption on it is why I tried hacking the silver stick first.
As far as I could see, the silver stick works in combination with two programs. The first one is the autorun-program on the emulated CDROM, which just unlocks the protected partition on the stick. The second one is the software that gets installed on the PC and runs the other features. Both programs use the same UI and fingerprint-data but otherwise work independently: when you have identified yourself to unlock the protected partition, you'll have to identify yourself again to get to your bookmarks, web-passwords etcetera. I first decided to dig around in the autorun-program.
As soon as the stick is inserted, it just shows an emulated CDROM-drive with
the autorun-app on it. It does the same on non-Windows-machines; the stick
is probably completely non-usable on anything but Windows.
The autorun-app is a self-extracting file that creates a new directory in
the temp-folder of the user Windows runs as, so it doesn't need administrator
priveledges. It then drops a few .dlls and a second executable in that folder
and runs the executable.
I decided to load up the executable in a debugger. After some browsing
of the disassembly and the subroutines in the dlls, my eye was struck by one
certain function in an helper-DLL that was named
'HM120SDK4_SS500A_HMFV.bMediaChange2Flash'. The function struck my eye because
the program swaps the emulated CDROM for the protected partition as soon as
the right fingerprint was given: this routine could be responsible for that.
I decided to try something bold: I changed the call to a function in the same
DLL (CheckSensorStatus) to run MediaChange2Flash. I ran the executable and
tried to get my finger scanned. The program gave me a 'No device found'-error,
but at the same time I saw Windows promptly finding the 'protected'
partition.
While the previous hack worked well to get to the protected partition, it didn't completely prove the stick is insecure; the stored bookmarks, web-passwords, the virtual drive and everything else that was provided by the software installed on the PC itself, still needed a fingerprint to be used. I decided to focus on that next.
After a lot of tracing (the way the functions in the dlls called eachother
wasn't always too clear) I found out that the decision if a fingerprint is
accepted, was made in one routine in a certain dll: bHMFVVerify in HMFVLib.
Looking around a bit and tracing the routine when given a correct and a false
fingerprint, revealed a couple of conditional jumps which condition changed
the outcome of the routine. The first ones seemed to check if the fingerprint
itself was a normal fingerprint (no smudges or bad pictures) but the third one
seemed to come after routine that checked the fingerprint itself against
what was in its database. The result of this code got stored, too, so I
decided hack up some code after it to always indicate
a valid fingerprint. It worked nicely: everything just barely looking like
a fingerprint now got accepted. Total changes needed: one byte in one
single .dll-file.
That's all that's needed to get access to all the secret data on the
stick: every fingerprint was, from now on, recognized as 'valid'. If I would
put the modified dll on the Internet, everyone with just a tad of Google skills
could find it and 'hack' this stick.
One last note: This stick does contain the feature to protect the data on it with a password in combination with a fingerprint. While I haven't tried to hack the password-prompt in-depth, with the experience I had with the rest of the code, I think it's safe to say that it wouldn't take much to disable that too.
Anyway, one down, one to go.