Software
Now the self-destruction mechanism most probably was rendered useless, I decided it was time to see what the software really did. Seemingly, the PASSWORD.exe program on the stick uncompressed itself into a temp directory to 2 files: SinglePWD.exe and USB20.dll. I fired up a disassembler/debugger (W32Dasm) and took a look at the code of the dropped executable. Just as I thought, the .exe was the main program displaying the user interface and such and the USB20.dll was used to talk to the sticks hardware. What I hadn't guessed, however, was that the routines in USB20.dll would be high-level: instead of SendToStick() and ReceiveFromStick() I found routines like GetWriteProtectState, RefreshFileBrowser and VerifyPassWord. You may have figured out that last one, VerifyPassWord, caught my interest. There only was one call to that subroutine in the complete program, and the surrounding code seems to handle the cases of a wrong password and a hardware error (like when the stick is removed).
After some goofing around, getting used to the debugger, etc, I decided to look
at the value the VerifyPassWord-routine returns. It seemed to use EAX to indicate
it's status, so I decided to set a breakpoint after the routine, ran the program
and entered a password. The debugger stopped the program and I modified EAX to
be 1 instead of the 0 the routine returned. I continued the program, hoping to
get to an error message of some kind that would help me find some way in. Instead,
no error message came but all of a sudden I had access to the sticks data!
Seemingly the program itself decides if the password is correct or not and unlocks
the key depending on that decision. I just overrided the answer, so it gave me
full access, without even getting anything like the real password.
