Hacking the white stick
As I mentioned before: the white stick provides a protected amount of storage-space by encrypting a part of its unprotected space with AES-256 encryption, according to the manufacturers description. I took it for granted that the encryption really is AES-256: it's a cypher that's easy to implement and hard to crack, so it would be a safe and sane choice to use that. Because of that knowledge, I decided to pick the key as my vector of attack instead of the encryption method.
The white key has the same autorun-mechanism as the silver key: autorun via
an emulated CDROM-drive, unpack into a temp directory, run the real application
from there. The difference is that the extracted app packs the rest of the
features, like saving bookmarks securely, too, so there's no need to install
something first. A second advantage: once you have passed the initial
fingerprint check, you can access everything.
Again, I loaded the dropped app in the debugger. The encryption routines were quite visible after browsing the .dlls associated with the program: there is a library called 'truedisk.dll' containing the various operations possible on the encrypted disk. Because the command to mount the disk was in there too, I could set a breakpoint on it and as soon as I entered my (correct) fingerprint, it'd give me the key the disk was encrypted with.
Knowing the correct key, I decided to try and find it somewhere on the stick. I looked in the encrypted file, in memory dumps, in program traces, but it couldn't be found anywhere. Too bad. I decided I needed a change of strategy.
Instead of looking for it, I decided to go the same route as I did at the first stick. I looked at the dll-functions the program called, and sure enough, I found a few spots that seemed to call a function that checks if the scanned fingerprint is the right one. Hacking these did seem to do what I wanted at first. It didn't do exactly what I wanted, though: while whe hack looked like it got accepted by the user interface, it ended up with the wrong key being passed to the decryption routine in truedisk.dll.
After some hours of tracing, cursing, thinking and hacking, I finally found out what I was doing wrong. It looks like the encryption key for the disk is somehow coupled to every finger the stick knows as being correct. As soon as you delete a finger from that database, though, its entry seems to be overwritten with garbage instead of being nicely deleted. So, when I hacked the routines, they did return that they've found a correct finger but they didn't give the right key to the decryption routines. I went a bit deeper and hacked a certain routine, called DiscernFinger, to always return the indication that the scanned finger was recognized. Unfortunately , the first finger in the database got deleted while I was experimenting, so the software scanned the fingers in the database, the routine indicated the first one was correct, and the program would go right ahead and unlock the disk with the associated key... which was garbage. The solution was easy: first, let a few calls to the routine pass by, to accomodate for the deleted fingerprints, and only then fake a correct answer.
Long story short: It took me quite some time, but the white stick is just as vulnerable to simple code modification as the silver one. Creating a file with which everyone could unlock this stick is a tad more difficult than it was for the silver stick, but still doable.