3

Some forensic tools like Lantern 2.0 allow the use of a passcode bypass file to get around the passcode lock on iOS 4.2 and later. This means that if someone has your device they can get around the normal restriction to not sync until the device is unlocked.

I'm wondering which file or files iTunes creates and stores to convince a locked iOS device to sync over USB. Even better would be an analysis of the specific keychain items are needed to bypass the passcode lock for iOS.

Improve this question
5
  • 1
    holy crap, $700 bucks! I don't quite understand the question, mike, but maybe this helps.
    – cregox
    Commented May 1, 2011 at 0:33
  • $700 to be able to bill thousands for a single case to the government or a big time law firm is chump change. Also weeds out the one star reviews and means you can afford good support staff. The framework you linked to is awesome for accessing things once the device is unlocked but doesn't appear to jimmy the passcode lock using certificates from a host computer.
    – bmike ♦
    Commented May 2, 2011 at 22:36
  • please forgive my ignorance once again, but who's jimmy?
    – cregox
    Commented May 2, 2011 at 22:41
  • 1
    It's a colloquial verb - my apologies for using slang. merriam-webster.com/dictionary/jimmy
    – bmike ♦
    Commented May 2, 2011 at 23:06
  • that's cool. :) now... what exactly you wanted to accomplish here? :P
    – cregox
    Commented May 2, 2011 at 23:09

3 Answers 3

Reset to default
3

The complete description of the feature on the Lantern site is "Pass code bypass with certificate file from syncing computer" so I don't think "until the device is unlocked" is the accurate way to phrase it. It seems that Lantern re-uses the pre-existing credentials set up between the computer and the phone.

edit: And in re-reading your question it seems you may be aware of this. A quick perusal of the iOS developer documentation doesn't yield anything to me but you can likely determine this for yourself if you have a mac you sync your phone to.

from a terminal window run the command sudo fs_usage -wf filesys | grep -i itunes and you should be able to see what files iTunes consults when you connect your passcode-locked phone.

Improve this answer
5
  • I'm looking for the location of those credentials on my mac and a basic understanding of the trust chain that iTunes uses to convince iOS to talk when it's in a locked state. :-) I'll edit my question to make this more obvious. Thanks!
    – bmike ♦
    Commented Apr 27, 2011 at 21:05
  • I've spent over 30 minutes in fs_usage - the buffer overruns mean i'm missing most of the iTunes file accesses, and I'd guess the call is in a security framework and obfuscated or handled by usbmuxd or a helper. I'd rather not recompile fs_usage with a bigger buffer - but it's a bit of a needle in a haystack problem. I'm fairly certain the file isn't accessed in an observable manner at sync time... I've even tried running iTunes with DYLD_IMAGE_SUFFIX=_debug so it calls IO in debug mode which slows things down to lessen fs_usage's buffer overruns to no benefit.
    – bmike ♦
    Commented Apr 27, 2011 at 23:04
  • It's looking more like the keychain files are the source but I can't be sure at this point....
    – bmike ♦
    Commented Apr 28, 2011 at 17:34
  • @bmike could you confirm your suspect?
    – cregox
    Commented May 2, 2011 at 23:09
  • I'll post an answer with the suspicions I have so far...
    – bmike ♦
    Commented May 2, 2011 at 23:39
2

After several hours of looking and using fs_usage to trace files, I have come to the conclusion that the certificates are indeed stored in the keychain. (which in hindsight is a DUH moment).

Here are the files iTunes reads on launch and during a sync on my mac.

18:38:16.776  stat64                                 /Library/Keychains/System.keychain                                                      0.000010   iTunes              
18:38:16.776  open              F=5        (R_____)  /Users/me/Library/Keychains/login.keychain                                            0.000007   iTunes              
18:38:16.801  open              F=5        (R_____)  /Library/Keychains/System.keychain                                                      0.000016   iTunes              
18:38:26.013  open              F=48       (R_____)  /System/Library/Keychains/SystemRootCertificates.keychain                               0.000024   iTunes

I have been unable to uncover which specific keys or chain of keys are needed. They keychain in my home folder appears to not be needed since other user accounts on my mac see content of my locked iPhone even before iTunes launches. Whetherusbmuxd or another low level daemon is reading a system level certificate or the API to access iOS data relies on a common library for access in bypassing the passcode lock on iOS 4 is unclear.

It is clear that the iOS passcode won't protect from someone that can access the files on your hard drive (and has the detailed knowledge that isn't yet clear which certificate or file has the keys stored)

FileVault won't protect you since the certificate appears to be stored outside the user folder.

Improve this answer
1

I believe you're talking about the escrow keybag, stored at %ALLUSERSPROFILE%\Apple\Lockdown - this is the cert bag required for iTunes to connect and sync with previously paired iOS devicees without the user re-entering credentials. If you sync your iPhone to your Mac, and then copy the contents of the above folder to another Mac, you can access the device on the 2nd Mac without reentering creds.

If you're interested in a real deep dive of the technical details behind this, take a look at this presentation - http://conference.hackinthebox.org/hitbsecconf2011ams/materials/D2T2%20-%20Jean-Baptiste%20Be%CC%81drune%20&%20Jean%20Sigwald%20-%20iPhone%20Data%20Protection%20in%20Depth.pdf

Improve this answer
1
  • I will investigate that - looks very promising!
    – bmike ♦
    Commented Jul 18, 2011 at 1:56

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .