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.