Checkm8, Checkra1n and the new "golden age" for iOS Forensics

By -

My dear friend and fantastic professional partner Francesco Picasso always complains about me never posting on Reality Net's "Blog".

In fact, to be honest, we have never been very good at selling our "brand": in the world of digital forensics we are known by our personal accounts (@mattiaep and @dfirfpi) and not because of our blog.

Yes, we are also known as "The DFIR Mafia", but that is another funny story ðŸ˜Š

Indeed, Francesco is right: my last post on our blog is way back on June 3, 2015 and was titled "iOS 8.3: the end of iOS Forensics?". 

 After the “first golden age” of iOS Forensics (iPhone 4 "bootrom" exploit dated 2010), most of the forensics techniques were based on Apple's bugs or "left open" doors.

Over the years we have explored and tried all the possible ways to extract data from an iOS device.
  • We have relied on, and we still heavily rely on, iTunes backups. It's definitely a great way to get a huge amount of information!
  • We explored the galaxy of the “AFC protocol” that allowed us to see the "Media", analyzing every single database or plist file we had in front of our eyes
  • We intervened between Apple and the developers to understand which kind of “sysdiagnose” information was useful to Apple for “troubleshooting” an “App” and how these data could be of interest for a forensic analysis.
Thanks to the work of a huge number of smart people we had the opportunity to
  • Identify and parse iOS backups stored on computers
  • Attack the backup password protection 
  • Use pairing certificates to gain access to the phone
We had the option to download data from iCloud, also in this case with some excellent tools that allow the extraction of "tokens" from computers.

 When the “passcode” was available we got several times in the "jailbreak" underground to obtain a "full file system" acquisition studying all the possible methods of minimizing risks on the phone.

We have used "jailbreaks" and we still use them a lot for research, being always careful to  remember: "Hey dude, disable the automatic update of the operating system or you'll lose the jailbreak. Apple has already solved the problem in the latest version of iOS".

We have had, and still have, the problem of locked devices.

And also here over the years, we have tried them all.

We relied on hardware devices that were sometimes a bit weird but still worked.

We used "unlock" services with great success and we saw an amazing black-box device (or maybe another color, I don't remember ðŸ˜‰) that with some "Hex Magic" is able to attack the code and, even when this is not possible or unsuccessful, to pull out some information.

From September 27th 2019, the day of axi0mX's publication of this post, something changed in my head and I thought: 

 “A"bootrom" exploit for all devices from iPhone 4s to iPhone X. 
Ten years after the last bootrom exploit: this is a game-changer for iOS Forensics!"



I'm going to be very honest: my skills in terms of "extreme reversing" and "encryption" are limited. 

Every time I find something "encrypted" I knock on Francesco's door who, after puffing and complaining for a couple of days, brings out some solution.

/ * Reality Net marketing space * /

If you are interested read these posts:
/ * End Reality Net marketing space * /

I love the analysis part! 
I'm passionate about understanding what happens on the "bytes" when I interact with a device, whichever that is. 

After the post on Twitter I waited patiently and finally on November 10th 2019 this post was published on Reddit.



I want to publicly thank again all the genius and talents behind the checkra1n project.

My infinite respect for your competences and reversing and hacking skills. 
I will be honoured to shake your hand if we'll meet somewhere in the world.

And here I actually thought: “yes, we are facing “the new golden age" for iOS Forensics!"

I took my 64 GB iPhone X with iOS 13, looked at in its Face-ID and said: "My friend: now I create an encrypted backup and then I try to jailbreak you with checkra1n If something goes wrong it was nice to work with you, we'll see you soon in your new life. "

I downloaded checkra1n on my Mac and connected my iPhone X.

Not knowing exactly where I was going to, I thought: let's start in the situation in which the iPhone is unlocked and paired with a PC. Execute checkra1n and see what happens.

I followed the instructions and after a few seconds I saw on my iPhone screen what I had seen tweeting in the previous days by checkra1n developers.

I anxiously waited the end of the process, I inserted my passcode and I tried to connect, via iproxy, to the phone as "root".

At the request of the password I had a jolt and I entered the magic word "alpine".

I got access.

At that point I thought: I'm root, I inserted the passcode, I have access to the "full file system" acquisition.

I started one of the tool in my arsenal, Elcomsoft iOS Forensic Toolkit, I followed the "Full File System" procedure and saw the TAR file appearing on my computer!

After several hours the file was about 48 GB.



So I started thinking about what this jailbreak can open in terms of possibilities and risks.

I went back to read the FAQ on the checkra1n website and in particular


The answer is simple: no ðŸ˜Š

And I perfectly understand (and agree) why this should be so.

Then, at that point, I made the trivial reasoning: we are in front of a "bootrom" exploit, I can try redoing the same procedure starting from the condition of a turned off phone (aka, "Before First Unlock").

I turned off the phone and restarted it, connecting "Before First Unlock" to the Mac. I re-ran the entire procedure and tried again to connect. And I had access.

The result was a 21 GB file.



I then started processing both files with:
The result is definitely interesting and opens up the space for various evaluations and considerations, which have an impact on both the Digital Forensics of iOS devices, but also on the risks from the user's perspective.

From a forensic point of view:
  • The study of the exploit can lead to the development of stable solutions that make it possible to perform a "full file system" acquisition, both in the condition of "Before First Unlock" (aka, without knowing the passcode) and in the condition of "After First Unlock ”(aka, I know the passcode)
  • The availability of a solution to be able to access a device as "root" in a stable manner and in "real time" simplify testing activities on the behaviour of the operating system and third-party applications
  • The option to obtain a “full file system” acquisition allows a better comparison of the results produced by the the various available tools
  • It also allows the development of open source scripts with the great advantage of subjecting them to tests also based on real used devices
  • In general, a more step-by-step access that will allow to give more concrete and effective answers on questions like "why a certain information is found in a given place", thus also helping tool developers to improve their solutions
  • Access to the keychain "before" and "after" first unlock allows to study how third party applications use it, thus identifying potential vulnerabilities or access channels to third party systems (aka "token")
  • Many other things that do not come (yet) to my mind!
From the user's point of view, there are certainly new risks.

An exploit that is not "patchable" makes all devices vulnerable and therefore, at least, the risks related to "I lost my iPhone” or “Someone stole my phone" is to be considered "medium / high", even in the case of a passcode protected device.

The first tests I did on my device show that a lot of file (as expected) are available BFU. 
Some examples:
  • The well-known com.apple.wifi.plist file, which contains the list of Wi-Fi networks my phone was connected to, including "last joined" and "last auto joined" timestamps
  • The com.apple.MobileBluetooth.plist file, which contains the list of “paired” Bluetooth devices
  • The file "locationd/consolidated.db", which can contain user geolocation information
  • The "Accounts3.sqlite" file, which contains the list of user accounts
  • The * .log files of the WhatsApp application, containing the metadata (times, recipients, type of communication, etc.) of WhatsApp communications. In my phone, this data goes back about 8 days
A first article, to which I gave my small contribution, was written on the Elcomsoft blog (https://blog.elcomsoft.com/2019/11/ios-device-acquisition-with-checkra1n-jailbreak/).

In the upcoming weeks I would like to find the time to be able to make a more in depth comparison between information available "Before First Unlock" and "After First Unlock".

I do not want to promise Francesco that this is the first of a long series of posts ... but it certainly gave a new life and boost to my passion for "iOS Forensics"

Thank you all and now Forza Genoa!

Comments

Post a Comment

Popular posts from this blog

A first look at Android 14 forensics

By -
Android 14 was released to the public by the Open Handset Alliance on October 4, 2023, and is now available on various smartphones, including the Google Pixel. This blog post aims to explore a list of the majr oartifacts you can find on this version of the Android OS.  For testing and review, I set up a Google Pixel 7A and used it for about a month, with a SIM card and various native and third-party apps installed. The blog post is organized by sections: Device information and general settings User accounts Information on Cellular, Wi-Fi, and Bluetooth connections Native Android applications Google applications Analysis of the use of native and third-party applications Other relevant information As always, I'll try to update this blog post as I test and research. Device information and general settings build.prop TXT format Stored in the root directory of the system partition  Among other things, it contains the device manufacturer, the device model, the operating system version, a
Keep reading

Huawei backup decryptor

By -
When doing Mobile Forensics the first and usually the hardest step is to get access to user's data . It depends on the case type, but the so called physical  acquisition is the analyst object of desire. The reason is simple: iOS and Android native backups, respectively adb  and iTunes , contain a subset of user data, because they respect the various apps configurations where they can specify " you can't include me in backups ". Which leads to inconsistent situations like, for example, having WhatsApp data in iTunes backups and not having it in Android adb backups. Not considering WhatsApp, the majority of apps in iOS and Android do not allow their data to be included in backups . In the scenario where  device is unlocked or the lock  code is known (the only scenario considered in this post), the analyst could use the device itself to make the analysis of the installed applications. Anyone who did that at least once knows how uncomfortable is this approach. Al
Keep reading

WhatsApp Xtract

By -
I don’t want to bore you explaining what is WhatsApp . If you have this serious gap, you can fill it here .  Forensically speaking, WhatsApp was a very cool app until the last June. After that, someone had decided to add the extension “crypt” to such excellent source of information which was msgstore.db . This database stores information about contacts and also entire conversations. But simply opening it with SQLite Browser , you can have some troubles in extracting a single chat session with a desired contact, or in reordering the messages. My last python script wants to overcome these problems, avoiding to deal with complex SQL queries. Now, you need only to decrypt that file! Go to the repo.
Keep reading