Law Enforcement Forensics Tools Against Smart Phones

Turns out the password can be easily bypassed:

XRY works by first jailbreaking the handset. According to Micro Systemation, no ‘backdoors’ created by Apple used, but instead it makes use of security flaws in the operating system the same way that regular jailbreakers do.

Once the iPhone has been jailbroken, the tool then goes on to ‘brute-force’ the passcode, trying every possible four digit combination until the correct password has been found. Given the limited number of possible combinations for a four-digit passcode—10,000, ranging from 0000 to 9999—this doesn’t take long.

Once the handset has been jailbroken and the passcode guessed, all the data on the handset, including call logs, messages, contacts, GPS data and even keystrokes, can be accessed and examined.

One of the morals is to use an eight-digit passcode.

EDITED TO ADD (4/13): This has been debunked. The 1Password blog has a fairly lengthy post discussing the details of the XRY tool.

Posted on April 3, 2012 at 2:01 PM26 Comments

Comments

Genuinely Confused April 3, 2012 2:23 PM

“One of the morals is to use an eight-digit passcode.”

If they’ve got control of the phone’s operating system, then the only reason I can see for ‘guessing’ the password is either that (a) they don’t really have full control of the OS, or (b) the PIN is used to encrypt the phone’s datastore. If it’s the (b), then I don’t see how a 26.5-bit PIN-space is going to help much.

Humberto Massa April 3, 2012 2:29 PM

Anyway this is not the whole thing, and you can use an alphanumeric password with (semi?) unlimited length, etc. But the real point here is: your phone is now one of your computers, and if someone has physical access to your computer, you have to assume all data acessible from that device is compromised.

llewelly April 3, 2012 2:31 PM

Aside from the issues raised in the previous comments, if a four digit PIN is cracked in a second, an eight digit PIN is cracked in about 2 hours 47 minutes.

That’s an important difference if the attacker only has the device for as long as it takes you to visit the restroom, but if they’ve long term possession, it doesn’t matter much.

That’s one of the key deficiencies of PINs; making them twice as long is only helpful for certain attack scenarios, because branching factor is so poor.

RH April 3, 2012 2:33 PM

Usually “jailbreak” refers to getting root privileges, which would be sufficient to upload the (assuming hashed) PINs to a computer with enough horsepower to slaughter such a simple password in seconds.

Brian April 3, 2012 2:39 PM

I think the point is that you need the PIN to be able to jailbreak the device (the jailbreaks that I know of are currently based on exploiting application bugs).

theOtherGeoff April 3, 2012 2:39 PM

If it only tries those options, then everyone who disables simple pass codes (and uses at least one one numeric character) will be safe(r).

That said someone will eventually upgrade this to complex pass codes, but once you get to 6 or more digits out of 100 characters, you’re seeing a a much different attack senario (“Dear Judge, we’d like to hold the prisoner until we crack his phone… which we estimate will be less than 50 years from now”)

Ryan Lackey April 3, 2012 2:52 PM

How do you jailbreak the locked phone (in the case of a phone being stolen while locked, which is the most likely case). If I can get the phone while it is unlocked, game over already.

Pre-iPhone 4S or iPad 2, you could do a device-present online attack against the passcode without fear of a tamper response. (image the contents of the device, then test passcodes; restore in the event the tamper response is tripped). As far as I know, this only works on jailbroken devices after the iPad 2 (new iPad or iPhone 4S), so a 4 digit passcode might even be sufficient. For good measure, go with a longer passcode.

I don’t know if the Apple protection chip inside the device is FIPS 140-2 level 2 or higher. I would assume the best way to subvert the device, absent an Apple backdoor or some implementation error, would be a hardware key extraction attack on that chip. This is relatively expensive (destroys the phone, and probably takes an hour of a technician’s time with a good lab), so it’s beyond the reach of anyone but a private company, motivated grad student, or national police or intelligence group.

David April 3, 2012 2:59 PM

With iOS, why not just switch to the strong password option as opposed to the four digit default? Security trumps simplicity. I just thought I would add this as many don’t realize you can actually change the four digit easy-to-crack ‘password’ to a strong password using General>Settings>Password Unlock> Tick ‘Simple Passcode to ‘OFF’>Change Passcode>Enter Your New Passcode. You’ll no longer be presented with a number pad, but a place to type in a strong up-to-30 character passcode.

NoMail April 3, 2012 3:13 PM

This works well because the passcode has to be cracked ON the device itself, wich allows only aprox. 7 guesses per second (A4). So an alphanumeric passcode with sufficient lenght/randomness raises the bar at a considered secure level.

David April 3, 2012 4:26 PM

Thomas, Read Elcomsoft’s FAQ. There’s a lot of “ifs” and “buts” in there. They also admit they are out of luck with iPad 2 and the New iPad. Their method also depends a lot on iTunes installed on your computer. Lesson here: don’t use iTunes at all, with iCloud there’s no need to have iTunes anyway.

t-e-c-h----- April 3, 2012 5:34 PM

As 3d printer technology matures, it’s time we start making open source phones with open source firmware and demand the telcomms support them, or launch a boycott of the telcomms until they support the open phones.

The problem, time and time again, is with proprietary hardware, software, or both.

In a few years, unless TPTB steps in, we’ll all be trading designs for hardware with 3d printers to make devices and all those sweatshops in China will be forced to close down.

Patrick Henry April 3, 2012 6:31 PM

You can’t break my four digit passcode because my iPhone will erase itself after 10 failed passcode attempts.

You can’t jailbreak my phone because it is an iPhone 4S running iOS 5.1.

Suck it, XRY.

Matt April 3, 2012 6:31 PM

How about turning on the iOS feature that erases all data after 10 wrong attempts? Seems to me that this would do a decent job of securing your data?

By default your phone backs up to iTunes every timeout syncs so you should loose much data if any.

unknown April 3, 2012 11:56 PM

You can’t jailbreak my phone because it is an iPhone 4S running iOS 5.1.

For a minute I thought you were serious.

Melpomene April 4, 2012 4:51 AM

It is hard to use a 8 character decryption key on android since you are forced to use the same password for decrypting your phone and for unlocking your screen to make a phonecall. Thus a 8 char password will make normal usage of the phone cumbersome.
I don’t see why this is enforced though, since the PIN for the screen unlock could reboot after X failed attempts and promt for the longer disk encryption password and avoid bruteforce attempts on the shorter screen PIN that way.

Peter A. April 4, 2012 7:41 AM

@tech: the problem with open-source phones are patents. All mobile phone standards are ‘secured’ in this way. You need to buy licenses to several essential algorithms and stuff.

A 3d printer? all it could do is the case. It won’t produce the electronic parts you need, the circuit board, nor it would put it all together. Even if someone created and published open-source schematics, you still have to buy parts and pay someone to assemble all the stuff – unless you’re really skilled in soldering SMD parts 🙂

So it is quite possible to launch a relatively small company which produces and sells cheap low-end mobile phones, but no ‘free’ stuff, sorry. You’ll get sued in no time.

As for high-end smartphones, it is a significant engineering effort to build one. No one is going to do this for free. So someone has to pay for HW development – and it could be easily a 7-digit figure. The OS/apps could potentially be free, but the underlying firmware would be quite tied to the hardware and most likely not free, not only because of patents, but because someone who have paid for HW development would want to sell it to make profit.

JimFive April 4, 2012 9:54 AM

@melpomene

In order to use your phonebook or speed dial you would need to decrypt the phone anyway, so unless you know the phone number everyone you call it would be more annoying to go through the phone pin and then then decrypt pin in order to make a call.

JimFive

anonymous coward April 4, 2012 12:28 PM

You can’t break my four digit passcode because I don’t have Apple-fanboy gadgets.

You can’t jailbreak my iPhone because I don’t buy that shit.

Melpomene April 5, 2012 8:15 AM

@JimFive Yes, one would decrypt the phone on startup and have a simple lockscreen that takes a PIN to unlock, failed attempts results in reboot of the phone and forces the user to type in the password again. Thus protecting against bruteforce attempts on the short PIN code. The phone would remain decrypted when turned on, so you would be able to access the phonebook.
I am thus not refering to keeping the phone locked for simple usage, but rather have different passwords for decrypting the harddrive and for unlocking the screen since they have different risk accosiated with them.

TRX April 6, 2012 6:45 PM

Old Unix systems had a time delay between each password attempt. The delay got longer with each attempt. The sysadmin could set the number of attempts allowed before the account was locked.

If nothing else, it prevented the “10,000 attempts in 4 seconds” brute force attacks…

TRX April 6, 2012 6:47 PM

call logs, messages, contacts, GPS data
and even keystrokes

A relevant question might be, “is it really necessary to store all this data in the first place?”

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.