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.

« Prev 4 Next »

© 2006-2022 Sprite_tm - Contact