Digital forensics and incident response (DFIR) has hit a tipping point. No longer just for law enforcement solving cybercrimes, DFIR tools and practices are a necessary component of any organization’s cybersecurity. After all, attacks are increasing daily and getting more sophisticated – exposing millions of people’s personal data, hijacking systems around the world and shutting down numerous sites.
SANS has a smorgasbord of DFIR training, and we also offer a free Linux distribution for DFIR work. Our SANS Investigative Forensic Toolkit (SIFT) Workstation is a powerful collection of tools for examining forensic artifacts related to file system, registry, memory, and network investigations. It is also available bundled as a virtual machine (VM), and includes everything one needs to conduct any in-depth forensic investigation or response investigation.
The SIFT Workstation was developed by an international team of forensics experts, including entrepreneur, consultant and SANS Fellow Rob Lee, and is available to the digital forensics and incident response community as a public service. Just because it’s freely available and originally designed for training, though, doesn’t mean it can’t stand up to field investigations. The SIFT Workstation incorporates powerful, cutting-edge open-source tools that are frequently updated, vetted by the open source community and able to match any modern DFIR tool suite. Don’t just take our word for it. Thousands of individuals download SIFT yearly, and it’s used by tens of thousands of people all over the world, including those at multiple Fortune 500 companies. And recently, HackRead named SIFT Workstation in a list of the top 7 cyber forensic tools preferred by specialists and investigators around the world.
SIFT got its start in 2007, during the time SANS instructors were developing virtual machines (VMs) for use in the classroom. In its earliest iterations, it was available online as a download, but was hard-coded and static so whenever there were updates, users had to download a new version. By 2014, SIFT Workstation could be downloaded as an application series and was later updated to a very robust package based on Ubuntu. It can also be installed on Windows, if there is an Ubuntu subsystem running on the system.
In November 2017, SANS unveiled a new version of SIFT Workstation that allows for much more functionality, is much more stable, and is comprised of specific tools such as the Package Manager. This time the package supports rolling updates, and uses SALT, a Python-based configuration management platform, rather than a bootstrap executable and configuration tool.
The new version can work with more than 200 tools and plug-ins from third-parties, and newly added memory analysis functionality enables the SIFT Workstation to leverage data from other sources. New automation and configuration functions mean the user only has to type one command to download and configure SIFT. Because SIFT is scriptable, users can string together commands and create automated analysis, customizing the system to the needs of their investigation.
Download SIFT Workstation today, and get started on your own DFIR initatives. And look into our FOR508: Advanced Incident Response and Threat Hunting course for hands-on learning with SIFT, and how to detect breaches, identify compromised and affected systems, determine damage, contain incidents, and more.
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.
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.
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.
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.
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.
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.
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
FOR585 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
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.
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
Domenica 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
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!
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.
· 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.
Immerse yourself in six days of the best in SANS DFIR training. Here are the courses you can choose from:
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 celebrate 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.
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
– 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.
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.
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.
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).
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!
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.
Don’t believe me that this causes issues yet, take a look at how it looked in one tool.
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.
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.
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).
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.
There is a huge range of features now controlled / enabled by current generation automotive infotainment and telematics systems (Figure 1 – Source), including but not limited to:
Satellite (GPS) navigation
Bluetooth connectivity (the vehicle has its own phone number that SMS messages can be sent to and some systems will even read your SMS text messages to you)
Audio player – on CD, MP3, USB or Bluetooth
Internet access (Hotspot) – enables web browsing for multiple passengers via an in-built Wi-Fi connection, and can also provide real-time traffic updates for GPS navigation systems
Satellite TV tuners – for passengers or for everyone as long as the car is parked
Cameras – an array of cameras literally showing a bird’s-eye view of the car, making maneuvering in tight spaces even easier then ever before
Screen mirroring – wirelessly connect mobile devices to the automobile and mirror its user interface on the car’s larger touchscreen
As automotive infotainment and telematics systems evolve and become more powerful, the value of the historical data they contain from an evidence perspective grows as well.
Automotive Infotainment and Telematics Systems Are Not Crash Data Recorders
It is important to understand that automotive infotainment and telematics systems are not the same as crash data recorders (CDR), or event data recorders (EDR). In a CDR, safety sensor data such as brake position, speed, steering wheel position and airbag deployment is recorded at high frequency but only for a matter of seconds leading up to a crash. In an automotive infotainment and telematics system data is collected from primarily non-safety related components (i.e. speed and coordinates from GPS at a lower frequency but for a substantially longer time period). Hence while CDR systems can determine a point of impact an automotive infotainment and telematics system can perhaps show the longer term driving habits of the vehicle’s driver.
Abundant Information but Difficult to Get To
While there is an abundance of available information, vendors of automotive infotainment and telematics systems have not made them easy to acquire. The forensic product vendor Berla (https://berla.co/) use various methods to extract the data. To get to the data, one must use Berla’s iVe kit, which is composed of iVe software and hardware components for accessing numerous systems from various automakers (i.e. Ford, GM, FCA, BMW, Toyota, and Volkswagen to name a few). For some systems it is as simple as plugging a USB or on-board diagnostics (OBD-II) cable from the iVe kit into a system running the iVe desktop application and walking through the on-screen steps for performing an acquisition. For some other supported systems, an iVe device interface board (DIB) from the kit is attached to the infotainment/telematics module’s PCB as outlined in the in-app instructions. The DIB is then connected to a computer running the iVe application, as well as the kit’s power supply (for certain modules). Depending on the particular type of system being acquired, iVe will offer the option for either a physical image, logical image, or both. For certain modules, one must also remove the protective solder mask from certain pads on the module’s PCB prior to connecting the DIB, though a scratch pen is included in the iVe kit, and instructions with photos showing the specific pads to scratch are included in the application.
It’s the Wild Wild West All Over Again
It is also important to note that a CDR has a definitive government requirement (CFR-2011-title49-vol6-part563) that defines not only what data is to be stored but also the format in which that data is stored. In contrast, infotainment and telematics system vendors are all over the map regarding what data is stored and how and where it is stored. Furthermore, specifically what data is stored can vary from one vehicle model to another, even when the same system appears present in two different vehicles. This requires the forensic tool developer to have a deep understanding of the data structure for each vendor’s product as well as for each car model in order to be effective. It reminds the author of the early days of mobile device forensics.
The following is a broad example of available data types for iVe-supported systems. Any given manufacturer’s system will have a select subset based on features present for that particular system. The data stored may also vary based on the vehicle’s use, actions of the occupant(s), which features were used, etc. The types of data stored can also change when a given manufacture updates the firmware of a system.
To see if a particular vehicle is supported, and what information may be available on the system, use the iVe supported vehicle lookup on Berla’s website. The lookup is also included in the iVe application itself.
Vehicle / System Information
Original VIN Number
Installed Application Data
Wireless Access Points
Tracklogs and Trackpoints
Active and Inactive Routes
Access Point Information
GPS Time Syncs
Oh My! Guess What I Found on eBay?
An eBay seller was parting out a wrecked 2015 Silverado pickup truck (Figure 2) including its infotainment system, an NG 2.0 HMI module (Figure 3, 4, 5).
SMSC OS81092AM MOST Bus Controller – 50 Mbps, Automotive
Texas Instruments DS90UR905QSQ Serializer – FPD-Link II, 24-Bit Color, Up to 65MHz, Automotive
Lets acquire some data
Preparation for acquisition (Figure 6) involves scratching insulating material away from specific PCB pads, as specifically outlined in iVe’s instructions, to permit connectivity with the PC board traces. The fiberglass scratch pen has strands that tend to come apart during the removal process, so gloves and safety glasses are highly recommended. The iVe DIB is then connected to the PCB. Proper alignment of the DIB pins on the PCB is critical.
The PCB is powered with the variable power supply (Figure 7) that is included in the iVe kit. It is important to ensure the voltage is adjusted to 12V prior to connecting the leads to the PCB power connector.
The iVe application includes an acquisition wizard to walk the user through each step for setting up the acquisition.
The iVe DIB is connected to the computer running iVe, and power is applied. After successfully testing the hardware connections by clicking the ‘Detect’ and ‘Test’ buttons (Figure 8) in the software, the acquisition can be started. For the HMI module, iVe allows for a logical image to be acquired.
Once extraction has completed, analysis can be performed, and reports can be generated. iVe’s data export functionality supports .csv, tab-delimited, and .kml for GPS data, and reports can be exported in HTML or PDF format.
Below is some of the data collected by iVe for the HMI device in this test.
Attached Devices (Figure 9)
SMS Messages (Figure 10)
Call Logs (Figure 11)
Contacts (Figure 12)
Device Events (Figure 13)
Voice Recordings (Figure 14)
Carved Files (Figure 15)
Music (Figure 16)
Summary of HMI Device
No crash data but good data to establish habits and patterns of the driver
Examples of available historical data included
Some GPS Information
Media (i.e. Music)
More Can Possibly Be Parsed from Recovered DB Files
Another Visit to eBay
We already imaged an NG HMI so this time I was looking for an OnStar Gen 9 device to analyze (Figure 17).
SMSC OS81092AM MOST Bus Controller – 50 Mbps, Automotive
Texas Instruments DS90UR905QSQ Serializer – FPD-Link II, 24-Bit Color, Up to 65MHz, Automotive
Lets acquire some data
As with the previous acquisition, the iVe DIB is attached to the PCB and the computer running iVe. The variable power supply is tested to ensure it is set at 12V before connecting it to the PCB power connector. The step-by-step acquisition wizard in the iVe software is followed to begin the data extraction (Figure 18). iVe allows for a physical extraction on the OnStar Gen 9.
Below is some of the data collected by iVe for the OnStar Gen 9 device.
The 10th Annual Digital Forensics and Incident Response Summit Call for Presentations is open through 5 pm EST on Monday, January 16, 2017. If you are interested in presenting or participating on a panel, we’d be delighted to consider your practitioner-based case studies with communicable lessons.
The DFIR Summit offers speakers the opportunity for exposure and recognition as industry leaders. If you have something substantive, challenging, and original to offer, you are encouraged to submit a proposal.
Check out some of the DFIR Summit 2016 talks:
We are looking for Digital Forensics and Incident Response Presentations that focus on:
DFIR and Media Exploitation case studies hat solve a unique problem
New Forensic or analysis tools and techniques
Discussions of new artifacts related to smartphones, Windows, and Mac platforms
Focusing on improving the status quo of the DFIR industry by sharing novel approaches
Challenges to existing assumptions and methodologies that might change the industry
New, fast forensic techniques that can extract and analyze data rapidly
Focus on Enterprise or scalable forensics that can analyze hundreds of systems instead of one at a time
The technical basics of the case is that FBI is trying to compelApple Inc. to help create a new capability installed on the suspect’s iPhone that would enable with the following degraded security mechanisms:
Allow the FBI to submit passcode “electronically via the physical device port”
Will not wipe underlying data after 10 incorrect passcode attempts
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 , with serial number FFMNQ3MTG2DJ and IMEI 358820052301412. 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 .
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.
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.
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:
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.
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.  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. 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.
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.
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.
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
The Summit brings together DFIR practitioners who share their experiences, case studies and stories from the field. Summit attendees will explore real-world applications of technologies and solutions from all aspects of the fields of digital forensics and incident response.
The 9th Annual Digital Forensics and Incident Response Summit Call for Presentations is now open. If you are interested in presenting or participating on a panel, we’d be delighted to consider your practitioner-based case studies with communicable lessons.
The DFIR Summit offers speakers the opportunity for exposure and recognition as industry leaders. If you have something substantive, challenging, and original to offer, you are encouraged to submit a proposal.
Deadline to submit is December 18th, 2015.
Summit Dates: June 23 & 24, 2016
Post-Summit Training Course Dates: June 25-30, 2016
I can honestly say that the most common question I am asked by examiners, investigators, students and even my neighbors is, “which phone is the most secure?” Obviously, the concern behind the question varies. Some want to secure their own device, and others, like myself, want to prove everyone in DFIR wrong by cracking into the toughest and most secure devices.
Smartphone security has gotten drastically stronger in 2014. This year, we are expecting even more challenges when examining smartphones. When thinking about the forensic aspects of smartphone security and encryption, we have to consider two things:
How are we going to get access to the data?
Even if we get a dump of the device, can we decrypt and examine the data?
What happens if I can access the data, but the application data is encrypted?
Let’s look at a few devices to consider our options. First, Windows Phone 8 (WP8) brought us new issues that commercial forensic kits could not fully support. The good news is that these devices only comprise approximately 2.5% of the smartphone market. The bad news – criminals still use them! My co-author for FOR585, Cindy Murphy, worked with others in DFIR to get over this hurdle when it really mattered. A criminal investigation forced Cindy into action when she realized the critical part of the crime was a Nokia 520 running WP8. Cindy essentially formed a “team” to divide and conquer on this WP8 device. They successfully obtained a JTAG image of the device and manually parsed the data. FYI, if you haven’t looked at a smartphone dump in awhile, it’s no longer just a few files you need to sift through like legacy mobile device images. You are now looking at a small hard drive of evidence needing to be manually parsed. This task alone could take a lot of patience and a really long time.
What makes WP8 devices so secure compared to the others? WP8 devices brought change that we, smartphone examiners, haven’t faced in the past. This is the first OS introduced into the smartphone community that utilized BitLocker technology to support data encryption on the device with AES 128, which utilizes a Trust Platform Module (TPM) to protect the encryption key once the data is secure. These two factors have caused heartache for us smartphone examiners who have one of these devices appear in our evidence lineup. Fortunately, Cindy and her “team” were able to obtain a physical image, bypass the encryption and parse the relevant evidence to support her criminal investigation. Their work can be found here: http://dfir.to/Win8Phone-Forensics If you haven’t read this paper, you should!
Cindy and her “team” worked directly with Cellebrite developers to provide a recent release supporting the Nokia 520 and similar WP8 devices, thus making your life easier. In FOR585 we stress the importance on understanding how the data is stored and parsed by your tool. One tool cannot uncover and decode all data on a smartphone. It’s your job to learn the file system structures, data formats, encoding schemas and all of the other fun bit of smartphone forensics. Additionally, in Cindy’s case, one single tool did not parse or interpret all of the data from this device. The smartphone forensic tools could not handle the data dump. You will find this is true for some smartphones, so you need to understand all concepts of smartphone data. Your toolbox must contain both smartphone forensic tools as well as standard DFIR tools (yes, the same ones your learned about in FOR408 and FOR572). Below we see X-Ways being used to examine a WP8 smartphone image.
Here are some cheat sheet locations where evidence on the WP8 resides (for more details on how to manually parse the data, please refer to the referenced paper, above):
Application data and other traces of user activity were located on this device and required manual examination, custom Python scripts and intensive reconfiguration of raw data. Keep in mind that all 3rd party applications are different, store data with different obfuscation levels and require manual parsing (aka, don’t trust your tool – be smarter than it and validate your findings).
Now let’s consider the other devices that are trying to outsmart us. BlackBerry has always been secure. Pre-paid phones have locked data ports and knock-off devices are counterfeit, so support is inconsistent. iOS devices containing the A5-A8 chips are difficult if they are locked. There are methods for bypassing the lock, such as using the host computer Lockdown files as well as attempting to crack the PIN with the IP-BOX. If the user doesn’t back up their iOS device with a computer and uses a complex passcode… let’s just say you may not be getting access to that device, unless of course it’s jailbroken and not 64-bit. So may considerations, right?
Then there is Android Lollipop, which introduced the first default full disk encryption for this OS. How this will change our methods is TBD. I suggest you sign up for a FOR585 class to see how these devices can be accessed when you seem to have been outsmarted.
When considering which SANS course to take next, consider this – smartphone operating systems contain file systems similar to those discussed in FOR408 and FOR518, but need to be handled in a unique way. What about network traffic on smartphones? Here’s something to consider that you may have learned in FOR572 that should lead you to take FOR585 next.
“This class is critical for any forensicator in 2015,” said Phil Hagen, SANS Certified Instructor and course lead for FOR572, Advanced Network Forensics and Analysis. “One thing we focus on from the network side is to hunt for adversaries in an environment and identify which endpoints require detailed examination. When those are workstations or servers, the analysis path is very well-established. However, if that endpoint is a modern mobile device, a forensicator must have the skills necessary to perform a comprehensive examination. With ’smart’ mobile devices, the techniques are often vastly different than those required for traditional computing devices.”