Hacking the iUSB
Because the iUSB uses a password to protect the contents on it, there was a much higher probability that the security it offered is strong enough to keep a casual hacker like me outside. The specs of the HD-enclosure said it used a proprietary encryption scheme developed by the company itself. In cryptography, using proprietary encryption schemes is a big no-no, though, because while it is easy to develop an encryption scheme you can't crack yourself, there always are people who can. The chance of a public encryption scheme like AES being cracked is a lot smaller.
I decided to take it from the start: load the app in a debugger, run, and see what happens. I entered a wrong password and up came a message box telling me 'Access denied'. I traced the code back to the location where the decision to accept or deny the password was taken and changed it to always accept the password. Unfortunately, it seemed the password was either checked a second time' or taken as a key for another routine: while the program now accepted my password, it didn't unlock the encrypted partition; instead, it gave an error.
My first thought was to take a better look at the routine that checks the password: it seemed to do its job quite quickly, so perhaps a brute-force method could be implemented using the algorithm it used. That way, the password could be found in a relatively short time. The disadvantage it had was that I'd have to analyse the code, write a bruteforcer and then wait a long time, perhaps weeks, before the password was found. I decided to try something else first.
The iUSB-software has some more things you can do without entering the password, though. You can re-initialize the disk with a new password, but that option erases all data too, so using that wasn't feasible: the data was erased in a way that even data-recovery-software couldn't retrieve it. The other option was changing the password, but the program asked for the old password too. I expected the check on the old password to be the same as on the login-screen, but decided to try and break the verification for this screen anyway.
So I restarted the debugger, entered a wrong old password, got a message box. I traced the code back to the location the decision to show the message-box was taken, and modified it to never see a password as false. Re-run, enter a bogus old password and 'test' as the new password: the program told me the password is changed successfully. While that's a nice thing, the real question was if the disk was now accessable: if the program used the password as a key to decrypt something, the fakery I did would show itself. So i started the program a third time and entered the new password, 'test'. Fully expecting to see an error, I clicked OK. The window closed... and the private partition showed itself, completely intact. The iUSB-disk was cracked too.
I later found out that the disk was even more vulnerable than I thought. A friend, who wanted to use the disk under Linux, found out that the enclosure, on powerup, checks the disks partition table to see which partition should be protected. That can be abused: if you backup the partition table, then overwrite it with an empty one and then plug the disk out and in again, it doesn't see the partition to be protected and just allows access to the complete disk. If the backup of the partition table is then written back without unplugging the HD, the OS will be able to access both partitions without being stopped by the enclosure: the 'secure' data will be readable.