Freezing Android To Crack The Encryption


Build a better lock and someone will make a tool to open it without the key. Or in this case they’ve made a tool to discover the key using a trip to through the deep freeze. The Forensic Recovery of Scrambled Telephones — or FROST — uses cold temperatures and a custom recovery image to crack Android encryption keys.

Cold boot hacks go way back. They leverage use of low temperatures to slow down the RAM in a device. In this case, the target phone must already be powered on. Booting a phone that uses the encryption offered by Android 4.0 and newer requires the owner’s pass code to decrypt the user partition. But it then remains usable until the next power cycle. By freezing the phone, then very quickly disconnecting and reconnecting the battery, researchers were able to flash their own recovery image without having the encryption key cleared from RAM. As you can see above, that recovery package can snoop for the key in several different ways.

[Thanks Rob]

40 thoughts on “Freezing Android To Crack The Encryption

  1. “On the downside, scrambled telephones are a a nightmare for IT forensics and law enforcement, because once the power of a scrambled device is cut any chance other than bruteforce is lost to recover data.”

    That was a disturbing sentence from the article.

          1. In Australia at least, the police aren’t going to be sending your mobile to an IT lab without good reason for suspecting you in a crime, and anyone willing to fork out the money to get information off your phone will have other ways of getting enough information anyway.

            If your phone is being sent to a forensic IT lab, invasion of privacy should probably be one of your last concerns.

          2. I could tell you a story about playing shadow run on irc, a freinds chat logs, his nosy sister and my interview with the police. In short be paranoid protect your privacy.

    1. Right, because an iPhone is so much more secure! It’s not like there are methods to bypass the lock screen or anything… Oh wait!

      Also, there is no encryption on iPhones… So by default, Android is by FAR, more secure than any iOS device.

  2. Here’s what I don’t get: they’re pulling the battery to force it to reboot into recovery. However, most Android phones have a PMIC that monitors the power button for a long press, and affects a cold reset. The time between the reset and the DRAM init code is minimal, far less than replugging the battery, when reset is asserted, so the freezing should be unnecessary.

    The real point of this exercise is to realize one of the reasons vendors lock bootloaders, and why SoCs with security fuses usually have a way to disable JTAG access.

  3. This is the take-away:

    If you can’t risk anyone else obtaining a file, phone number, etc., then don’t leave it on a cell phone. To paraphrase Smokey the Bear, “Only you can prevent unsecure data.”

  4. So it seems the trend towards non-user-serviceable batteries aids security in this regard. Interesting.

    On the other side, if you wanted to have some fun with this, use a thermally activated power switch, forcing a hard reset of the handset (or detonating a small explosive charge) any time the handset reaches temperatures useful for this hack. Just don’t answer your phone outdoors in Alaska…

  5. thx for sharing it… now whoever first designs a lipo battery that works just like a regular battery but has a very unfortunate ;-) tendency to explode and send shrapnels when rapidly cooled… will make some serious $$$

    1. Destructive-by-design instead of defective-by-design? :D

      Seriously though, there’s an obvious way around this on ARM chips: Don’t store the key (directly) in RAM so even if the firmware has horrible data security, you can still prevent trivial reading of the key. For example, store a 32-bit XOR key in a register and then reserve it for reading/writing all encryption keys. Maybe have another one just for related data structures. This is trivial, machine cycles-wise, but would make a key search practically useless. If a (native, not Java) user program can access that key, well it’s already operating from a point of advantage to possible exploits like key-snarfing, anyways. It would at least then have to be an inside job. A larger key (say, 256 bits) would be more secure but not as practical.

  6. In the introduction:
    >However, we show that cold boot attacks are more generic and allow to retrieve sensitive information, such as contact lists, visited web sites, and photos, directly from RAM, even though the bootloader is locked.

    But then later
    >For this command to work, the bootloader must be unlocked.

    So where exactly do they show this working on locked devices?

  7. The more personal the device the larger the risk…..
    Use it for it’s function not as an attached limb.
    But hey who really leaves incriminating information on a phone, except for the call logs and messages which should be vague if you really are into that sort of thing.
    most days a phone call for me goes like this.

    me:”on my way”

    and if it’s a friend

    friend:”On my way”

    mostly just keeps the bill minimal lol

    Don’t store pictures you dont want others to see or data you wont want others to have…
    Be paranoid.

    P.S my mom uses her cell like it’s a walkie talkie as soon as she hears the information she wants from you expect that to be the end of the call if she called you.

    1. Me:”yo”
      friend:”On my way”

      and the guys listening to your phone calls are like “yup, he’s prolly buying drugs” :-D

      Be very paranoid ;-)

  8. Out of curiosity: doesn’t the cold slow the RAM access of the recovery image ?
    Using frozen ram to probe it with an external device sounds doable to me.

    But preventing it from dataloss and at the same time still be able to use the same RAM chip almost sounds like magic.

  9. Freeze it – why didn’t I think of that?

    On a long-ago project hacking the Dakota/CVS single-use cameras, it was discovered that a timely powercycle + shorting of solder jumpers could be used to put the cam into bootloader mode and so dump a firmware image + misc. RAM contents (possibly keys). A small percentage of the bytes came back corrupted due to the momentary loss of power. My hacky solution was a short C program to take multiple dumps and recover a clean copy of the memory contents by majority vote (search for ‘filedata finagler’ in ). Putting the cam on ice instead could have saved some work :-)

Leave a Reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.