Do you like my hacking? If so, please consider leaving something in the
Fediverse (Mastodon etc): @Sprite_tm@social. spritesmods.com
So, is it safe? The answer to the question would be (as usual): It depends.
If you're just a generic Joe Blow who wants to make sure your private pictures don't get viewed by your collegues or kids, you're golden. The fact that the there's no way a software-only attack can get the pincode means that some hardware-experience is needed to start hacking the device, and that will deter casual onlookers enough to make the device completely safe for curious neighbours or collegues, even if they are smart enough to, for example, install a keylogger on your PC.
If you're a business-person with actual info to hide, info that could financially benefit other parties... you can still use this, but make sure to pick a strong pincode. More than 11 digits should do, depending on how badly others want the data.
If you're, say, the president of a nuclear country and want to use this to carry around the launch codes of your nukes, I wouldn't recommend this device. While the thing is safe for a casual hacker like me, someone with money or the resources to de-cap chips can probably get to the data fairly easy: the PIC which contains the keys to the HD is not a secure device and when decapped under a microscope in a laboratory can probably be made to give up that key fairly easily.
Aside from the bruteforcing probability, the evil-maid-attack still is a factor too. If someone has the engineering skills to create a microcontroller to catch the PIN or the HD-key and is willing to break in twice to solder it in, put back the HD, wait a while and then steal the HD, the enclosure won't really stop him from doing that. Ofcourse you can wonder how common such a scenario is in real life, but it may be a good thing to keep in mind.
« Prev 8
39 commentsTo read PIC's EEPROM you could reflash the bootloader (so you'll be able to dump the rest of the code and the EEPROM). If you need the bootloader's code, you need to "sacrifice" a second device, overwriting all *but* the bootloader with NOPs and a bootloader dumper. They most probably didn't split the password beetween the bootloader, the code memory and the EEPROM...
Thank you for this enjoyable article! I had a lot of fun reading it.
The \'Y\'-cable is not for voltage, but for increased current. However, the extra \'power\' lead itself can only supply an extra 100mA, as there is no \'intelligence\' on this conenctor to tell the PC that this is also a high power device and therefore requires more than the default standard (100mA).
Sprite_tm, right, I did catch that, and certainly you have demonstrated the need for anti tamper to be a part of the design. I was just wondering, and since you mention earlier in the article varying times for the same event, how reliable such an approach would be, especially if you factor in varying password lengths or increased numbers of user passwords and what effect they have on the timing of incorrect and correct entries to the eeprom write.
Captain Scarlet: I explain that in the article: when the pincode is correct, the bytes get writen slightly earlier than when the pincode is incorrect; that\'s how I differentiate between the two.
Sprite_tm, I enjoyed reading your breakdown of this device, the monitoring of the eeprom especially was impressive. However, one must assume the Manufacturer of this device also write to eeprom in the case of a correct entry, just to reset the number of brute force attacks back to zero. So if this happens before any transfer of data to the other chip, and you are resetting as soon as you see an eeprom write. How would you be able to differentiate between a valid and invalid entry?
Johnny Blue: I disagree. The anti-brute-force-protection was completely disabled by my methods, and at least for pincodes of less dan, say, eight digits, bruteforcing is perfectly possible. Yes, as long as you use >11 digits as a pincode, the device is safe, but I doubt many people use pincodes that long.
Seems this device is good. I loved the article, but in the end you failed. \"Evil Maid\" attack that one is good but funny, could this not be used with every device, a computer, or phone! Now for the electron microscope, we all know who has this equipment and its not the \"hackers\" its the government. I would think that this device should get some respect? I loved the other hacks that you have done and really surprised how easy the other devices were to crack.
TokyoDrift: The PIC probably uses a polynominal random number generator (aka the rand()-function in c) primed by something like interrupts and keypresses. That\'s fairly random, and if it takes e.g. the key sequence you enter as entropy too, there\'s no way you can enter 2 different pincodes and have the same outcome, timing-wise. ICSP I tried, no go; resetting the PIC on reset too but it seems like it writes some other data (perhaps the initio-key) first and I couldn\'t get it not to overwrite that.
@ultra: the user password and the 16bit key is stored in the PICs internal EEPROM, you can\'t read that if the lock bits are set and they probably are ... the serial EEPROM, as figured out and said by Sprite_tm, only contains the Initio firmware ... the HDD key is stored on the hard drive encrypted with the 16bit key, so the initio chip doesn\'t know any of those two the only plain passwords are stored in the PICs internal, with normal tools unreadable storage ... so obviously the only chance to unlock the harddrive is to either make the pic change the user key without changing the 16bit key (i.e. resetting the harddrive) or get information about the password from the PIC to make bruteforcing easier (i.e. timing attack)
Really cool article, wonder if it\'d be possible to dump the contents of that EEPROM, maybe the password is stored on there? The PIC must be getting it from somewhere to compare, no?
yeah...sorry for that, my fault...but still, there is no real coincidence and on a µc (as there\'s none at all) o there are not much ways to generate a random number for doing random operations to render the timing attack useless, i guess...probably they use either the noise on an open IO pin or the time a button was pressed or something like that...both effects can be terminated by making sure every IO pin is pulled up/down permanently and using a second mikrocontroller for entering the code...did you try that?...I don\'t know how much you tested but I think the timing attack is, next to killing the lock fuses using a electron microscope and stuff, the only acceptable solution...I\'m sure you already tried reading the µc through ICSP, right? would be really dumb if they forgot to set the lock fuses...oh and you tried lowering the voltage when the pic tries writing the new key to it\'s eeprom, did you also try resetting the pic after it wrote the 6 password bytes? like, right before it starts writing the new initio key?...I\'d really like to see this thing hacked...oh and btw, I really like your articles :)
Some quick responses to the comments here: hey-chrisb: Tried that; it was protected. Serial eeprom only has the program code for the Initio-chip, nothing usefull there. akira2051: Nope, because you\'re limited to the rate the PIC accepts keypresses at. HiHiHi: Working on it :) TokyoDrift: That\'s basically the timing-attack I describe on page 5.
I got another idea you should think of: 8MHz is not much you can basically measure the time it needs in CPU clocks so if the firmware is like for(i=0;i<number_of_digits;i++){ if(entered_digit[i] != real_digit[i]){ return; } } you could bruteforce it digit by digit like - put 0 to the first digit - measure the time - put 1 to the first digit - measure the time - if 0 was slower the first digit is 0, if I was slower it\'s one, if they were the same go on with 2 - and so on - after you got the first digit, move on with the second one that would, at 16 digits, be 160 tries in the worst case, and this can be done within minutes TD
Please post more often, I miss the fine articles you post on this site.. or else! :-)
Wonderful article.
Why not use the AVR to emulate the signals from the keypad? Could you? That would drastically increase your brute-force rate, no?
Cheers for the reply. Interesting to know that the electronics side has a lot of \"margin\".
This is a very nice read. Thanks a lot, you are a clever guy.
Also what about the pic? Did connect a programmer to the header is see if it was protected?
What\'s on the serial eeprom? Did you dump it? Maybe the pin is just on there...
If the key sent by the INIC from the PIC doesn\'t change, why bother with the pass code at all? Why not just replay the \"unlock\" signal to the INIC directly?
would it be possible to slurp the code of the PIC and reprogram it without some of it\'s \"safety\" features ?
Wouldn\'t it be possible to extract the encrypted hd-key, then crack it with the random key (from eeprom) and some bruteforce for the digits? Seems like this wouldn\'t take too long, especially for shorter codes.
Ray: because it was the first one I managed to grab :) 250 or 400 would\'ve worked just as well. Much lower (10 ohm-ish) and the voltage over it would be too low to accurately measure, too high (10k-ish) and the PIC wouldn\'t be able to draw any power anymore.
Can I ask why you chose a 330 Ohm resistor to place in the power supply line to the PIC? I mean, why 330, and not 250 or 400?
Wow, hiya Reddit :) lucygucy: Unfortunately, the pic only talks to the Inic when you\'ve entered the correct password, so no way to capture the correct key. Secondly: the key sent to the Inic doesn\'t change when a pincode is changed, so that\'s no help.
but if i was. I would totally hit that.
Could you not insert a microcontroller between between the INIC and the PIC? If you control all communication, in theory, you could avoid the INIC being aware of a changed passcode, then proceed with the failed write approach.
Thanks for publishing this work. Your explanation of timing attacks was well-done. I arrived via http://www.reddit.com/r/programming/comments/d63kf/hacking_a_passcode_encrypted_usb_hard_drive/ -Tyler
awesome work! very clever :)
Johnny: That\'s basically the evil-maid-attack I describe. Woeka: That\'s the idea, but the rate at which you can do that is limited by the debouncing times in the PIC: It just won\'t accept pincodes that quickly.
You could attach a logger to the SPI line and wait for the owner to enter the proper pin. It would require an extra visit, but might save all the brute-forcing time.
Maybe you can make the AVR do the pushing in the numbers for you by tying the keypad to the AVR? That would make it probably a lot faster.
cde: Before the SPI data gets send, the correct pincode has to be entered into the PIC, so unless you know the correct pw, there\'s nothing to record anyway. The EEPROM is internal to the PIC, so there\'s no way to disable writes by just tying a pin low or high.
is the only spi data sent during a reset and correct password? Simple micro to record any spi data, and boom. Additionally, since the eeprom is used to store the number of tries, couldn\'t it be set to write disabled if there is a pin for that, or just copying and rewritting its info every 30 or so tries.
Basically, yeah. If the PIC was unlocked, it would make things quite a bit easier :P
great great post! thanks! just to make sure, the pic saves the password onto the internal flash? and the pic is locked to prevent from reading the firmware and the data? right?