SANS FOR585 Q&A: Smartphone Forensics – Questions answered

 

 

Learning doesn’t stop when you leave the SANS classroom. Instructors Domenica “Lee” Crognale, Heather Mahalik and Terrance Maguire answer some of the most common questions from FOR585 Smartphone Forensics course students in these short videos:

1) Using Hashcat to Crack an Encrypted iTunes Backup: Acquiring a locked iOS can be difficult so an iTunes backup may be the best evidence to examine. The iTunes backup files might be encrypted so this mini webcast outlines how to use HashCat to crack the encrypted iTunes backup files.

Capture1

 

 

 

 

 

 

 

2) An Overview of Third Party App Examination: There are millions of applications (Apps) that can be used on a smartphone. This mini webcast outlines an approach to examining these applications.

Capture2

 

 

 

 

 

 

 

3) Why Every Examiner Needs a Test Device?: In a perfect world, we would always be examining rooted Androids and jailbroken iOS devices, but unfortunately, full access to the file system is becoming a thing of the past. This mini webcast highlights the importance of populating test devices with user data so you can better speak to the artifacts that you ARE able to access on your next examination.

Capture3

 

 

 

 

 

 

 

 

4)What if Nothing Supports Android Pie (v9)? The latest versions of Android are not commonly supported for acquisition by our tools. What can you do? Use ADB and interact with the live device. This mini webcast will teach you how to use ADB to extract information from Android devices and will discuss the traces some tools leave behind and why that trace is required if you want to obtain data.

 

Capture4

 

 

 

 

 

 

 

5) iOS Malware – Where to Begin: It’s notably more difficult to pinpoint malware on your non-jailbroken iOS device without access to the application packages. This mini webcast outlines some of the best practices in analyzing the files you can access to provide indications of suspicious activity and the applications and services that are likely responsible.

 

Capture5

 

 

 

 

 

 

 

 

6) Two Major Plists: This mini webcast will discuss how to determine if iMessage is disabled on an iPhone and how to determine if an iCloud restore occurred. Simple questions like this can make a difference in your investigation. We will discuss the file locations, which acquisition methods provide access to the files of interest and most importantly, how to parse the data.

 

 

Capture6

 

 

 

 

 

 

 

About SANS FOR585: Smartphone Forensics Course

This in-depth smartphone forensic course provides examiners and investigators with advanced skills to detect, decode, decrypt, and correctly interpret evidence recovered from mobile devices. The course features 27 hands-on labs, a forensic challenge, and a bonus take-home case that allow students to analyze different datasets from smart devices and leverage the best forensic tools, methods, and custom scripts to learn how smartphone data hide and can be easily misinterpreted by forensic tools. Each lab is designed to teach you a lesson that can be applied to other smartphones. You will gain experience with the different data formats on multiple platforms and learn how the data are stored and encoded on each type of smart device. The labs will open your eyes to what you are missing by relying 100% on your forensic tools. More information: http://sans.org/FOR585 | Next course runs: sans.org/u/Mht

More Resources:

mobile posterFOR585 Mobile Forensics Poster: Use this poster as a cheat-sheet to help you remember how to handle smartphones, where to obtain actionable intelligence, and how to recover and analyze data on the latest smartphones and tablets. This poster was created by FOR585 Advanced Smartphone Forensics course authors & Certified Instructors Heather Mahalik, Cindy Murphy and Domenica “Lee” Crognale with support from the SANS DFIR Faculty. Download it here

Heather Mahalik’s blog: https://smarterforensics.com/blog/

 

How to build an Android application testing toolbox

 

Mobile devices hold a trove a data that could be crucial to criminal cases, and they also can play a key role in accident reconstructions, IP theft investigations and more. It’s not just investigators who care about examining a mobile device – so do those interested in application research and data, and enterprises who rely on smartphones and tablets to perform work tasks, engage with customers and deliver new services.

Capture3 Effectively accessing and testing smartphones requires an optimal application toolbox, and the chops to use it. Listen to this webinar that details how to build your Android application testing toolbox to ensure you’re set up to successfully access and examine the information you need from Android mobile phones.

SANS instructor Domenica Crognale, who is one of the course co-authors of SANS FOR585: Advanced Smart Phone Forensics, and who teaches the course as well, details why testing of mobile phone applications is critical – especially given the fact that Android apps change weekly and even daily. It is becoming more common for application developers to restrict very important user artifacts from being accessed from these Android devices. This most often includes the SQLite databases, which likely contain the information that examiners are after. It’s not just commercially available applications you have to consider. Often, custom-built apps aren’t parsed by commercial tools, so you’ll need to know how to access and parse any data stored on the device.

During the webinar, Domenica talks about the importance of rooting Android devices as well as ways to access and parse the data. She explains how to do this using utilities that exist on the SIFT workstation or that can be downloaded for free from the SANS website.

This webcast explores topics such as:

  • Choosing the best test device
    During a forensics acquisition, many tools will apply a soft root onto the phone that is then removed once the data is obtained. But a full physical acquisition is not always necessary for application testing. Ideally, we want a test phone that is always rooted, whether or not the device loses power, because the root basically unlocks access to the core of the device’s operating system so you can access, add, remove or tweak anything inside the phone.
  • Rooting your Android
    During the webinar, Domenica walks through a demo of a root, how to locate the root and share information on free and publicly-available root tools.
  • Utilizing File Browsers for quick file/folder access
    Sometimes a file browser is all you really need to get to the data you’re after. Domenica shares her favorite third-party applications for accessing the file system.
  • Examining application directories of interest
    Once you have access to the files you need, utilize tools available on the SIFT workstation to view the contents of SQLite databases.

Listen to the recording, “Building your Android application testing toolbox” webcast now.  And check out our FOR585: Advanced Smartphone Forensics, a week-long course that teaches you how to find key evidence on a smartphone, how to recover deleted mobile device data that forensic tools miss, advanced acquisition terminology and free techniques to gain access to data on smartphones, how to handle locked or encrypted devices, applications, and containers, and much more

650x125_CDI-2018_No-EBDomenica will be teaching FOR585: Advanced Smartphone Forensics at SANS Cyber Defense Initiative  Dec 11-18.  Register to attend live here: sans.org/u/JGl  or to  try it from home via Simulcast register here: sans.org/u/JGq

For additional course runs log in here

1500x500_OLT-Nov15-Dec5

Top 11 Reasons Why You Should NOT Miss the SANS DFIR Summit and Training this Year

The SANS DFIR Summit and Training 2018 is turning 11! The 2018 event marks 11 years since SANS started what is today the digital forensics and incident response event of the year, attended by forensicators time after time. Join us and enjoy the latest in-depth presentations from influential DFIR experts and the opportunity to take an array of hands-on SANS DFIR courses. You can also earn CPE credits and get the opportunity to win coveted DFIR course coins!

summit video pic

To commemorate the 11th annual DFIR Summit and Training 2018, here are 11 reasons why you should NOT miss the Summit this year:

1.     Save money! There are two ways to save on your DFIR Summit & Training registration (offers cannot be combined):

·       Register for a DFIR course by May 7 and get 50% off a Summit seat (discount automatically applied at registration), or

·       Pay by April 19 and save $400 on any 4-day or 6-day course, or up to $200 off of the Summit. Enter code “EarlyBird18” when registering.

2.     Check out our jam-packed DFIR Summit agenda!

·       The two-day Summit will kick off with a keynote presentation by Kim Zetter, an award-winning journalist who has provided the industry with the most in-depth and important investigative reporting on information security topics. Her research on such topical issues as Stuxnet and election security has brought critical technical issues to the public in a way that clearly shows why we must continue to push the security industry forward.

·       The Summit agenda will also include a presentation about the Shadow Brokers, the group that allegedly leaked National Security Agency cyber tools, leading to some of the most significant cybersecurity incidents of 2017. Jake Williams and Matt Suiche, who were among those targeted by the Shadow Brokers, will cover the history of the group and the implications of its actions.

·       All DFIR Summit speakers are industry experts who practice digital forensics, incident response, and threat hunting in their daily jobs. The Summit Advisory Board handpicked these professionals to provide you with highly technical presentations that will give you a brand-new perspective of how the industry is evolving to fight against even the toughest of adversaries. But don’t take our word for it, have a sneak peek, check out some of the past DFIR Summit talks.

kaplan

Immerse yourself in six days of the best in SANS DFIR training. Here are the courses you can choose from:

·       FOR500 – Advanced Windows Forensics

·       FOR585 – Advanced Smartphone Forensics

·       FOR610 – Reverse-Engineering Malware

·       FOR508 – Digital Forensics, Incident Response & Threat Hunting

·       FOR572 – Advanced Network Forensics: Threat Hunting, Analysis, and Incident Response

·       FOR578 – Cyber Threat Intelligence

·       FOR526 – Memory Forensics In-Depth

·       FOR518 – Mac and iOS Forensic Analysis and Incident Response

·       MGT517 – Managing Security Operations: Detection, Response, and Intelligence

3.    All courses will be taught by SANS’s best DFIR instructors. Stay tuned for more information on the courses we’re offering at the conference in a future article post.

4.     Rub elbows and network with DFIR pros at evening events, including networking gatherings and receptions. On the first night of the Summit, we’re going to gather at one of Austin’s newest entertainment venues, SPiN, a ping pong restaurant and bar featuring 14 ping pong tables, lounges, great food, and drinks. Give your overloaded brain a break after class and join us at our SANS Community Night, Monday, June 9 at Speakeasy. We will have plenty of snacks and drinks to give you the opportunity to network with fellow students.

5.     Staying to take a DFIR course after the two-day Summit? Attend SANS@Night talks guaranteed to enrich your DFIR training experience with us. Want to know about threat detection on the cheap and other topics? As for cheap (and in this case, that doesn’t mean weak), there are actions you can take now to make threat detection more effective without breaking the bank. Attend this SANS@Night talk on Sunday evening to learn some baselines you should be measuring against and how to gain visibility into high-value actionable events that occur on your systems and networks.

6.     Celebrate this year’s Ken Johnson Scholarship Recipient, who will be announced at the Summit. This scholarship was created by the SANS Institute and KPMG LLP in honor of Ken Johnson, who passed away in 2016. Early in Ken’s digital forensics career, he submitted to a Call for Presentations and was accepted to present his findings at the 2012 SANS DFIR Summit. His networking at the Summit led to his job with KPMG.

7.     Prove you’ve mastered the DFIR arts by playing in the DFIR NetWars – Coin Slayer Tournament. Created by popular demand, this tournament will give you the chance to leave Austin with a motherlode of DFIR coinage! To win the new course coins, you must answer all questions correctly from all four levels of one or more of the six DFIR Domains: Windows Forensics & Incident Response, Smartphone Analysis, Mac Forensics, Memory Forensics, Advanced Network Forensics, and Malware Analysis. Take your pick or win them all!

 

8.     Enjoy updated DFIR NetWars levels with new challenges. See them first at the Summit! But not to worry, you will have the opportunity to train before the tournament. You’ll have access to a lot of updated posters that can serve as cheat sheets to help you conquer the new challenges, as well as the famous SIFT WorkStation that will arm you with the most powerful DFIR open-source tools available. You could also choose to do an hour of crash training on how to use some of our Summit sponsors’ tools prior to the tournament. That should help give you an edge, right? That new DFIR NetWars coin is as good as won!

9. The Forensic 4:cast Awards winners will be announced at the Summit. Help us text2985celebrate the achievements of digital forensic investigators around the world deemed worthy of the award by their peers. There is still time to cast your vote. (You may only submit one set of votes; any additional voting will be discounted). Voting will close at the end of the day on May 25, 2018.

10.  Come see the latest in tools offered by DFIR solution providers. Summit sponsors and exhibitors will showcase everything from managed services covering advanced threat detection, proactive threat hunting, and accredited incident response to tools that deliver rapid threat detection at scale, and reports that provide insights for identifying potential threats before they cause damage.

11.  Last but not least, who doesn’t want to go to Austin?!? When you think Austin, you think BBQ, right? This city isn’t just BBQ, Austin has amazing food everywhere and there’s no place like it when it comes to having a great time. The nightlife and music include the famous 6th Street – which, by the way, is just walking distance from the Summit venue. There are many other landmarks such as Red River, the Warehouse District, Downtown, and the Market District. You will find entertainment of all kinds no matter what you’re up for. Nothing wrong with some well-deserved play after days full of DFIR training, lectures, and networking!

As you can see, this is an event you do not want to miss! The SANS DFIR Summit and Training 2018 will be held at the Hilton Austin. The event features two days of in-depth digital forensics and incident response talks, nine SANS DFIR courses, two nights of DFIR NetWars, evening events, and SANS@Night talks.

The Summit will be held on June 7-8, and the training courses run from June 9-14.

We hope to see you there!

TIME IS NOT ON OUR SIDE WHEN IT COMES TO MESSAGES IN IOS 11

BLOG ORIGINALLY POSTED SEPTEMBER 30, 2017 HEATHER MAHALIK

apQ3w85_460s_v1

This is going to be a series of blog posts due to the limited amount of free time I have to allocate to the proper research and writing of an all-inclusive blog post on iOS 11. More work is needed to make sure nothing drastic is missing or different and to dive deeper into the artifacts that others have reported to me as currently being unsupported by tools.

From what I have seen thus far, I am relieved that iOS 11 artifacts look very similar to iOS 10. This is good news for forensicators who see iOS devices and have adapted to the challenges that iOS 10 brought. Prior to writing this, I was referred to a blog post on iOS 11,that was an interesting read (thanks Mike). I suggest you also check it out as it pinpoints what is new in iOS 11 in regards to features: https://arstechnica.com/gadgets/2017/09/ios-11-thoroughly-reviewed/5/

Understanding what the OS is capable of doing helps us determine what we need to look for from a forensic standpoint. From what I have seen so far, the major artifact paths have not changed for iOS 11. Key artifacts for normal phone usage appear to be in the same locations:
– Contacts- /private/var/mobile/Library/AddressBook/AddressBook.sqlitedb
– Calls-/private/var/mobile/Library/CallHistoryDB/CallHistory.storedata
– SMS – /private/var/mobile/Library/sms.db
– Maps – /private/var/mobile/Applications/com.apple.Maps/Library/Maps/History.mapsdata – Still missing? Refer to my blog post from Dec.

When I test an update to a smartphone OS, I normally start with basic user activity (create a new contact, place some calls, send messages, ask for directions, etc.) and then I dump my phone and see what the tools can do. For this test, I created both encrypted and unencrypted iTunes backups, used PA Methods 1 and 2 and did a logical extraction with Oxygen Detective. What I found is that not all tools parsed the data in the same manner, which is to be expected. (I also plan to test more methods and tools as time allows and for my FOR585 course updates.)
To get this post done in a timely manner, I found one item that has always been parsed and jumped out as “missing” or not completely supported.

4403afcf498768ffc5653803d484788dd1da5d11a5a2238441046b64b1889d5c

iMessages and SMS in iOS 11 were the first items that jumped out as “something is off…” and I was right. I sent test messages and could not locate them in the tools as easily as I have done in the past. I normally sort by date, because I know when I send something. Up until this release of iOS, we could rely on our tools to parse the sms.db and parse it well. The tools consistently parsed the message, to/from, timestamps, attachments and even deleted messages from this database. Things have changed with iOS11 and it doesn’t seem that our tools have caught up yet, at least not to the same level they were parsing older iOS versions.

One of the most frustrating things I find is that the tools need access to different dumps in order to parse the data (as correctly as it could for this version). For example, Oxygen didn’t provide access to the sms.db for manual parsing, nor did it parse it for examination when the tools was provided and iTunes backup. This had nothing to do with encryption, because the passcode was known and was provided. UFED isn’t the same as PA Method 1 and 2 (you have heard this from me before), but it’s confusing because most don’t know the difference. This is what it looked like when I imported the iOS 11 backup into Oxygen. Believe me, there are more than 3 SMS/iMessages on my iPhone.

Oxygen_iTunes-vs-O2-extraction2

However, I when I dumped my iPhone logically using Oxygen Detective, it parsed the SMS and provided access to the sms.db. When I say “parsed” the sms.db, I am not referring to timestamp issues at all, those will be addressed in a bit. Here is what my device looked like when I dumped it and parsed it in Oxygen.

Oxygen_iTunes-vs-O2-extraction

Spot the differences in the messages? Yep, you now see 48,853 more! Crazy… all because the data was extracted a different way. I also tested adding in the PA, Method 1 image and those message numbers were different, but the sms.db was available and parsed. You really have to dump these devices in different ways to get the data!

Bottom line – add the sms.db to something you need to manually examine for iOS 11 to ensure your tool is grabbing everything and parsing it. The rest of this blog is going to focus on just that – parsing the sms.db in regards to changes found in iOS 11.

Let’s take a look at what is the same (comparing iOS 11 to iOS 10):
• SMS and iMessages are still stored in the sms.db
• Multiple tables in this database are required for parsing/joining the messages correctly
What is different (comparing iOS 11 to iOS 10):
• Additional tables appear to be used?
• The timestamp is different for iOS 11 – SOMETIMES!

Here is what I found (so far). The tools are hit or miss. Some tools are parsing the data, but storing the messages in a different location, others are parsing the message content, but not the timestamp… you catch my drift… What I recommend? Go straight to the database and take a look to make sure the tool(s) you rely on are not missing or misinterpreting the messages (wait… didn’t I just say that – YES, I did.)
The timestamp fields for the sms.db are all over the place now. What I am seeing is that the length of the Mac Absolute value varies between two formats and both of these formats can be stored in the same column. This is why the tools are struggling to parse these dates. Additionally, the tables in the sms.db differ in how they are storing the timestamp. So, if your tool is parsing it correctly, excellent – but still take a look at the tables.
Here are some examples of what this mess looks like. The column below is from the chat table in the sms.db. Notice how it has the traditional Mac Absolute value (number of seconds since 01/01/2001), while others are a 18 digit Mac Absolute values and some are 0 (sent messages).

strange_datetime3

Additionally, I was seeing some that were 19 digits that were not appended with 00s at the end. The “conv start date” on the left column is from the messages table in sms.db and this timestamp has not changed. As expected, your tools handle this one nicely. The table on the right column is from the chat_message_join table, and this caused a little havoc as well due to the variety of timestamps in the column. Converting this wasn’t fun! Thanks Lee for your help here. You, my friend, ROCK!

strange_datetime

When I first ran my SQL query, I noticed this one pesky date that wasn’t converting. This is because it was the timestamp highlighted above and I needed to beef up my query to handle this. If you see a date that looks like the one below, something is up and you aren’t asking for the data to be rendered correctly. The query below will handle this for you.

strange_datetime2

Don’t believe me that this causes issues yet, take a look at how it looked in one tool.

Oxygen_SMSiOS11-1

The dates and times are not parsed correctly. I found that the dates and times appear to be consistent when the tools are parsing the 9 digit Mac Absolute timestamps from specific tables. Otherwise, expect to have to do this yourself. Here is where it was correct, but this wasn’t the case for all of my messages sent using iOS 11.

PA_iMessage

If you need a sanity check, I always like to use the Epoch Converter that I got for free from BlackBag to make sure I am not losing my mind when dealing with these timestamps. Below, you can see it was parsing it correctly (Cocoa/Webkit Date). Also, I love that it gives you both localtime and UTC.

unixepochconverter

This leads me to the good news -below is the query that will handle this for you. This query is a beast and “should” parse all sms and iMessages from the sms.db REGARDLESS of the iOS version, but only columns that I deemed interesting. (Note that I state should, because this has only been run across a few databases and you should report any issues back to me so they can be fixed.) Take this query and copy and paste it into your tool of choice. Here, I used the DB Browser for SQLite because it’s free. I limited some columns to the ones I care about the most, so you should make sure this query isn’t missing any columns that may be relevant to your investigation.

SELECT
message.rowid,
chat_message_join.chat_id,
message.handle_id,
message.text,
message.service,
message.account,
chat.account_login,
chat.chat_identifier AS “Other Party”,
datetime(message.date/1000000000 + 978307200,’unixepoch’,’localtime’) AS “conv start date”,
case when LENGTH(chat_message_join.message_date)=18 then
datetime(chat_message_join.message_date/1000000000+978307200,’unixepoch’,’localtime’)
when LENGTH(chat_message_join.message_date)=9 then
datetime(chat_message_join.message_date +978307200,’unixepoch’,’localtime’)
else ‘N/A’
END AS “conversation start date”,
datetime(message.date_read + 978307200,’unixepoch’,’localtime’) AS “date read”,
message.is_read AS “1=Incoming, 0=Outgoing”,
case when LENGTH(chat.last_read_message_timestamp)=18 then
datetime(chat.last_read_message_timestamp/1000000000+978307200,’unixepoch’,’localtime’)
when LENGTH(chat.last_read_message_timestamp)=9 then
datetime(chat.last_read_message_timestamp +978307200,’unixepoch’,’localtime’)
else ‘N/A’
END AS “last date read”,
attachment.filename,
attachment.created_date,
attachment.mime_type,
attachment.total_bytes
FROM
message
left join chat_message_join on chat_message_join.message_id=message.ROWID
left join chat on chat.ROWID=chat_message_join.chat_id
left join attachment on attachment.ROWID=chat_message_join.chat_id
order by message.date_read desc

Here is a snippet of what this beauty looks like. (Note: this screenshot was taken prior to me joining attachments – aka MMS).

parsed_db

I always stress that you cannot rely on the tools to be perfect. They are great and they get us to a certain point, but then you have to be ready to roll up your sleeves and dive in.
What’s next – applications, the image/video files that apparently aren’t parsing correctly, interesting databases and plists new to iOS 11 and the pesky maps. That one is still driving me crazy! Stay tuned for more iOS 11 blogs and an upcoming one on Android 7 and 8.
Thanks to Lee, Tony, Mike and Sarah for keeping me sane, sending reference material, testing stuff and helping me sort these timestamps out. Like parenting, sometimes forensicating “takes a village” too.

A Technical Autopsy of the Apple – FBI Debate using iPhone forensics

The technical basics of the case is that FBI is trying to compel Apple Inc. to help create a new capability installed on the suspect’s iPhone that would enable with the following degraded security mechanisms:

  1. Allow the FBI to submit passcode “electronically via the physical device port”
  2. Will not wipe underlying data after 10 incorrect passcode attempts
  3. Will not cause any delays after an incorrect passcode attempts

Here is what we know about the device in question so far. From court documentation we know it is an Apple iPhone 5C, model A1532, running iOS 9 [1], with serial number FFMNQ3MTG2DJ and IMEI 358820052301412[2]. Using the serial number and IMEI, we can garner some additional information that’s crucial to answering the technical questions by using free website imei.info and other resources. This particular model of iPhone contains an A6 chip. The provider is Verizon and the data capacity could be either 16 or 32 GB. The device is locked with a user generated, numeric passcode [3].

VIDEO WEBCAST — A Technical Autopsy of the Apple – FBI Debate using iPhone forensics

Video

Apple – FBI: The Details, Details, Details…

Whether or not we’re able to break the passcode on an iPhone depends a great deal on what version of iOS is installed on the device, as well as what version of hardware is involved. The combination of these two factors can mean the difference between being able to break the passcode without Apple’s assistance or having to rely on Apple for help.joe-friday

For many years, mobile forensic analysts had it easy. With iOS devices using the A4 chip (iPhone 4, iPad) and older (running iOS 7 or older) we were able to make physical images handily. A physical image is the closest thing we get to a bit by bit forensic image of the entire device. These are sometimes referred to as “the good ole days” by those of us doing mobile forensics. A physical image was considered ideal, because it gave us access to all the data stored on the phone. As time has moved forward, it has gotten more and more difficult to pull complete physical images from mobile devices of all varieties. More often, we’re able to obtain forensic backups or logical extractions of portions of the data from mobile devices.

Starting with Apple A5 chip (iPhone 4S, iPad 2) and any iOS version we can still acquire a physical and/or logical image, but we will need the passcode as well as jailbreak software, or a device that’s been previously jailbroken by the user.

The San Bernardino iPhone central to this discussion contains the A6 chip (found in the iPhone 5, iPhone 5C) and based on court documentation from the case, some version of iOS 9 is installed on the device. For this particular device, we would still need the passcode and jailbreak software to get a physical dump or just the passcode to get a logical extraction or forensic backup of the file system.

These “it depends” scenarios get complicated, and sometimes a great reference document is needed to keep track of it all.  Devon Ackerman, Special Agent/Forensic Examiner provided the great spreadsheet shown in the below images to us, and has given permission to share it.

IOS Device and Current Known Forensics Capabilities
IOS Device and Current Known Forensics Capabilities
iOS | Forensic Reference Key
iOS | Forensic Reference Key

Why can’t the FBI dump the iPhone like a hard drive?

iOS devices offer increased levels of encryption with each new release. The Apple A5 (and newer) chips offer the greatest amount of encryption and are the most difficult Apple devices so far to access when locked. These iOS devices are encrypted with 256bit AES encryption at the hardware level. The encryption key is stored between the flash memory and system area on the iOS device. This area of is referred to as “effaceable storage.” Hardware level encryption important because resulting extractions will only allow viewing of the file system and metadata, while leaving file contents unreadable due to encryption. Using the passcode to unlock the device prior to acquisition allows decryption of the data and renders it usable.

The iPhone 4S, which debuted the A5 chip, featured beefed up security which decreased the number of commands available in the boot loader, and consequently made it more difficult to physically acquire the device. The A6, A7, and A8 chips have followed suit and have become increasingly secure with each new chip release. The iPhone 4 has an bootrom exploit (24kpwn) which is used by commercial mobile forensic tools and non-commercial methods to physically access the device and bypass a lock. In the A5, A6, and A7 chips this exploit has been patched. This patch occurred well before the release of the iPhone 6 and the A8 chip.

Additionally, most logical files stored on the user partition of the disk are protected by a per-file encryption called Data Protection. This means that if we were able to get a dump of the data from the phone via chip-off or JTAG techniques (either of which could be destructive to the device) the contents of the files would still be encrypted. The following screenshots shows a physical image from a device with Data Protection. The file system is readable, however the file contents are encrypted.

iPhone Physical Image – Note the file system structure and associated metadata:

iPhone Physical Image

 

Data Protection Encrypted IMG_0001.JPG File
Data Protection Encrypted IMG_0001.JPG File

 

Decrypted IMG_0001.JPG File
Decrypted IMG_0001.JPG File

As far as we are aware, it is not possible at this time to extract the iPhone hardware keys along with a brute force of the passcode to decrypt the file contents.

What about those auto-magical password cracking tools I see on CSI Cyber?

Just because you see actor-investigators, actor-analysts, and actor-technicians quickly and effortlessly solve all the nearly-impossible tech problems presented to them in the span of an hour long episode does not necessarily mean things ever work that way in real life. Remember, these shows are largely fiction with a few juicy tidbits of truth thrown in here and there for good measure. Brute force password cracking on TV rarely fails, and is usually successful just barely in the nick of suspense filled time.

Three (real) and popular commercially available password cracking solutions for iPhone are described below:

1.    One of the auto-password guessing tools is called the IP-BOX. The IP-BOX is a black box that originates from phone unlocking, hacking, and repair market which can be used to defeat simple 4 digit pass codes on iOS devices running versions of iOS through iOS8.1.2. Following testing and validation, this box has been used by law enforcement (with valid legal authority) quite effectively to unlock iPhones for evidentiary purposes, until the exploits being leveraged the device were patched by Apple. Again, from the court documentation available, the San Bernardino iPhone is likely running some version of iOS9, thus the IP-BOX would not be effective.

2.    Cellebrite’s Advanced Investigative Services (CAIS) offers an iPhone unlocking service using tools and processes that are proprietary and publicly unknown. We are aware of a number of great success stories related to use of Cellebrite’s services to unlock iPhones in criminal cases. Use of this service requires an agency to provide the physical device to Cellebrite in hopes of getting the device and passcode in return. This service is advertised to only work on the iPhone4S (or newer) devices running iOS 8.0 to 8.4.1. The service also states that the “device wipe” functionality is bypassed. Cellebrite also has a user lock recovery tool for use on iOS and Android devices that relies on brute force attacks. This tool is only effective with iOS devices running versions of iOS 7.

3.    Secure View’s svStrike is similar to the IP-BOX, but with added capabilities including the ability to brute force up to a 6-digit passcode (versus 4-digit). The documentation does not state whether the “device wipe” functionality can be bypassed.

You have the suspects thumb, could the FBI just use Touch ID on the Apple iPhone?

If only. Unfortunately, the iPhone we’re talking about here was an iPhone 5c, and Touch ID was introduced with the more fully featured iPhone 5s.

Ironic, isn’t it? One less security feature to attempt to exploit actually means this particular iPhone is more secure.

Assuming an alternate universe, where the suspect had a Touch ID capable model of iPhone and Touch ID was enabled by the suspect, there would have been a very limited time window during which his hands could have been used to attempt to unlock the phone. Let’s face it though – there was a whole lot going on in those first few hours of terror. Mass casualties and injured people, a large crime scene, stretched resources and buckets of adrenaline. Search warrants were being written and executed. The existence of this particular iPhone likely was not yet even known, let alone who it belonged to. To quarterback after the fact and say that the cops should have matched the dead terrorist’s thumb to this particular iPhone in the midst of the chaos is asking people who are already heros to have been comic book super heros.

Here are the technical limitations they would have faced: According to Apple’s security documentation to use Touch ID, users must set up their device to require entry of a passcode to unlock it. When a recognized enrolled fingerprint is scanned via Touch ID, the device unlocks without asking for the device passcode. The passcode can be used instead of a fingerprint, and the passcode is still required when the device is restarted, when the device has not been unlocked for more than 48 hours, when the device has received a remote lock command, after five unsuccessful attempts to match a fingerprint, or when setting up or enrolling new fingerprints with Touch ID.

In this case, because of the iPhone 5C hardware, Touch ID wasn’t even an option. Therefore we face the following passcode options: 1) A four digit simple passcode. This is the most common passcode for pre-iOS 9 devices. 2) A six digit PIN, introduced with iOS 9. More digits means more difficulty and more time for a brute force attack. 3) A complex passcode. Complex alphanumeric passcodes can also be used on iOS devices, making our brute force attempts even more difficult. Most forensic tools can crack simple passcodes if the iOS version is supported. At best, complex passcodes can be bypassed if the iOS device can enter DFU mode (not damaged) and the device is supported for physical acquisition, which is not the case with this iPhone.

Oh, so it’s just a Apple iPhone pin code, why can’t the FBI just brute force it now?

Brute force can be attempted and may work using the tools discussed above.

However, should the user have their iPhone enabled to wipe after 10 failed attempts, the data on the device could be wiped and rendered useless within minutes of running the brute force attack. This is the risk we aim to avoid, at all costs.

iPhone Touch ID Settings
iPhone Touch ID Settings

While iOS devices used to warn the user of an impending wipe of the device following too many failed passcode entry attempts, this is not the case anymore. Based upon data found in iCloud backups and information provided by the employer-owner of the phone, investigators in the San Bernardino case have reason to believe that the Erase Data function was turned on. A blind brute-forcing attempt to break the passcode in this case would not have been wise.

Could the Apple iPhone iCloud backups be of help to the FBI?

Yes.  If the device has iCloud backups enabled then the backup files can be recovered.  In this case, the last iCloud backup file that was recovered and examined by the FBI was dated October 19, 2015 which is over a month before the attacks occurred. [1]  iCloud backup files contain user data as specified through their specific iPhone settings including email, contacts, calendars, photos, and Apple keychain data. iCloud backups are only performed when the device is connected to a WiFi network and plugged in. As long as the settings are turned on and maintained, iCloud backups would occur regularly when connected to a WiFi network.  Any changes to the configuration of the iCloud backup settings require the user’s iCloud password and the correct password to be entered into the iPhone. If the password to the user’s iCloud account changes, the device user would need the enter the new password into the device prior to successfully backup their data into the iCloud.

The iCloud password was remotely reset by the owner of the device, San Bernardino County, hours after the attack eliminating the possibility of an automatic backup if the device connected with a known WiFi network.[2]  Also, a Mobile Device Management (MDM) solution should be considered by any government or corporate owned phones used by employees.  MDM solutions  would help prevent locking out the organization from the phone that they own and could secure the data for eventual examination.

I heard Apple has helped out the FBI before, why is this different?

Previously, when presented with search warrants compelling their assistance, Apple has provided law enforcement agencies with the extracted contents of older iPhone devices running iOS 7 or older. They did this by running a specialized RAM disk on the devices to bypass the passcode to obtain the data. As of iOS 8 Apple has stated that this process is no longer an option due to how the encryption process has changed. From Apple’s “Legal Process Guidelines

“For all devices running iOS 8.0 and later versions, Apple will not perform iOS data extractions as data extraction tools are no longer effective. The files to be extracted are protected by an encryption key that is tied to the user’s passcode, which Apple does not possess.“

I hear Apple holds the key, can you explain?

One ring key to rule them all!  When an iOS device boots it verifies the Boot ROM code against the Apple Root CA public key, this is the first step in the secure boot chain. This ensures that iOS devices will only boot with Apple provided iOS software. If another version of the iOS software was created (either by Apple or other 3rd parties) the device would still be required to verify the Boot ROM against the Apple Root CA public key to successfully load.  Only Apple has a copy of their private key and this is a critical reason why the government cannot simply write their own version of iOS.

One of the critical security mechanisms for distributable software is this verification process.  If a private key is lost or stolen, hackers could write backdoors, espionage software, or other malicious capabilities into their software that the device would automatically trust and load that malcode.

Ok, I get it. This is hard. Can they get the data from anywhere else? I heard the FBI has other cellphone evidence from the Apple iPhone. Surely this can this be used? (…and don’t call me Shirley!)

Some data related to use of the iPhone 5c likely exists in other locations, including the suspect’s iCloud account, the hard drive of any computers the iPhone was backed up to, the carrier, and potentially other cloud based accounts related to apps in use on the phone. Also, conversations have at least two sides, and anyone the suspect was communicating with could have relevant information stored within their phones as well.

With iOS 9, if Apple Continuity was turned on, perhaps there might even be relevant mobile phone related data stored on other iOS/OS X devices. But considering that the suspects may have discarded computing devices and hard drives in a nearby lake, this potential lead could be a dead end as well.

According to the court filing, two other cell phones were examined in this case. Both of those phones were found “destroyed” and “discarded” in a dumpster behind the residence. These phones may contain information useful to the investigation, or which could potentially lead to the passcode for the iPhone 5c. Many times, “destroyed” phones can be repaired to get to relevant evidence, many times pass codes are more easily recovered from different mobile devices, and many times passcodes are reused between devices. Time will tell.

If the FBI can get to the Apple iPhone data, what else can they find?

If the FBI can get to the data, a plethora of information may be accessible. The iPhone most likely contains recent conversations, call logs, Internet searches, chats, application usage, locational data and much more. Our smartphones are the most personal devices we own and contain information that provide deep insight into our lifestyle.

Merely successfully getting to the data is sometimes just the first challenge.  If we are able to successfully dump the phone after obtaining or bypassing a passcode, data stored by the apps themselves often contains encrypted data.  This scenario is increasingly common, as app developers work to make user data more secure and are implementing data-at-rest security features like encrypted databases, or encrypted content within databases.  For example, Threema, is a commonly used secure communications app that is used world-wide.  The data associated with the application is all encrypted when data is dumped from the iPhone.  If the user relied upon third-party applications like Threema to chat, it’s likely the FBI would be faced with an additional hurdle – encryption that Apple cannot help with.

Can Apple even do what the FBI is asking for?

From what we know about iPhones, the A6 chip, and iOS 9, the answer is: Probably. Apple may be the only ones who currently can. Which is not to say someone else outside Apple and the FBI won’t come up with a creative solution to this problem. Our bets aren’t on McAfee’s social engineering attack though. Dan Guido from Trail of Bits describes this in a bit more technical detail, and Jonathan Zdziarski also agrees that Apple would be technically able to comply with the order given the hardware and iOS version involved.

This is interesting, may I have more information?

We have found the articles below well written and useful for learning more about this topic.

Documentation from Apple:

About the Authors:

  •  Heather Mahalik is leading the forensic effort as a Principal Forensic Scientist and Team Lead for Oceans Edge, Inc. and has extensive experience in digital forensics which began in 2003. She is currently a senior instructor for the SANS Institute and is the course lead for FOR585: Advanced Smartphone Forensics.
  •  Cindy Murphy is a Detective with the City of Madison, WI Police Department where she has been involved in digital forensics since 1999. She is a certified SANS instructor co-author of FOR585: Advanced Smartphone Forensics.
  •  Sarah Edwards is a senior digital forensic analyst who has worked with various federal law enforcement agencies. Her research and analytical interests include Mac forensics, mobile device forensics, digital profiling, and malware reverse engineering.  Sarah is the lead author for FOR518: Mac Forensics.

** Above Joe Friday “Just the FAQs” – Photo by Brian Moran @brianjmoran