Tag Archives: ios

Android and iOS acquisition Recommendations

I have been meaning to update this blog for years, so here goes. This blog is going to cover what I recommend to get the most data from iOS and Android devices. Many tools exist to successfully extract data from mobile devices and I am sharing some of my favorite methods that have proven to be successful for me over the years.

ANDROID Acquistion

Since most devices are using File Based Encryption (FBE), physical acquisition may not be possible. For devices that can be physically acquired, that should render the most data. The next best option to collect the most data from the phone is Full File System access. HOT devices should be acquired quickly. To explain HOT – If the device is in an AFU (after first unlock) state, make sure you acquire it and ensure the device doesn’t reboot, if possible. A reboot will put the device into a BFU (before first unlock) state and may be difficult or impossible to acquire without the passcode.

Things you will need:

  1. Install ADB on your forensic workstation https://www.xda-developers.com/install-adb-windows-macos-linux/
  2. Your forensic tools of choice.
  3. Mattia Epifani’s Android Triage script https://blog.digital-forensics.it/2021/03/triaging-modern-android-devices-aka.html

Android Acquisition Recommended Steps:

  1. Obtain a Physical or Full File System extraction with Cellebrite UFED, Premium or Premium ES. These are my preferred tools, others can be used as well.
    • If a Full File System is not possible for a specific model, verify the chipset and try Android Qualcomm/Qualcomm Live under Generic profiles.
    • Make sure you open the extraction prior to returning the device to ensure the data is not encrypted!
UFED Generic Profiles
Qualcomm Live Android Option
  1. File System Acquisition
    • This may simply be a backup and backups don’t get a lot with newer Android devices.
    • Try Generic Android on Cellebrite UFED if you are not finding the specific model to be working.
  2. Logical Acquisition using a forensic tool – especially if ADB isn’t going well for you. I recommend using more than one tool or a single tool and also capturing an ADB backup for validation purposes.
    • Note that most tools will install a software agent in order to extract data from the device. This is normal and accepted. If you are ever questioned on what the software agent is doing, simply extract the APK and examine it manually to review the permissions.
  3. FREE WAY – ADB Backup (capture both the device (all) and SD/media (shared))
    • adb backup –all
    • adb backup – shared
  1. Make sure you acquire the SD card and SIM card if one is present.
    • I like to remove these and acquire separately to ensure nothing is overlooked.
    • Make sure you write-protect the SD card.
  2. Use Cellebrite UFED to conduct a Chat Capture. I love the generic option as any screen can be captured and parsed for analysis.
    • I like to use chat capture to grab the settings screen of the device and to access application data that may not be extracted with the methods above. This method is great for apps that are not parsed or extracted.
  1. Extract cloud data – IF YOU HAVE AUTHORITY! My tools of choice for this are Physical Analyzer and Elcomsoft. Magnet and Oxygen work well too.
  2. I like to run some ADB commands to the device to ensure I extracted all information and that I am aware of what exists on the Android. The script from Mattia that is mentioned above can capture all of these commands for you with a nice GUI.
  3. ALWAYS open the extraction to ensure you got what you hoped. If you have a physical dump, Autopsy is the fastest you will gain access to your data! And it’s free. (https://www.sleuthkit.org/autopsy/). You can also use FTK Imager or a similar tool that is free for quick access.

Android acquisition leaves traces behind on the device. If you conduct covert operations – tread carefully here. Don’t go too far without knowing the footprint your tools and methods are leaving behind. These topics are covered more in the FOR585 class http://for585.com/course, in blogs and webinars found at https://www.cellebrite.com/en/resources/. Also note that multiple extractions may be necessary to capture the most information from these devices.

iOS Acquisition Recommendations

For iOS acquisition my methods have remained steady and I am not as paranoid as I am with Android. You can choose to work on a Windows or Mac. I do both. Honestly, most of my acquisitions take place on my Windows forensic workstation, but I do have a Mac that I use for jailbreaking.

Things you will need:

  1. Install iTunes if you plan to create a backup on Windows. Finder will work on the Mac.
  2. Install iBackupBot (I prefer this tool over the other free ones because of the option to dump the crash logs http://www.icopybot.com/download.htm
  3. Your forensic tools of choice.
  4. ArtEx – if you are examining a jailbroken device. Read Ian Whiffin’s blogs! http://www.doubleblak.com

Recommended iOS Steps:

  1. Determine the iOS device type and type of iOS device.
  2. Obtain a Full File System Extraction.
    • I prefer using Cellebrite UFED checkm8.
  1. If the device is already jailbroken, I will use Cellebrite UFED Full File System. Other tools will work as well.
    • If I get a Full File System extraction I stop at this point other than obtaining log files, which is mentioned in steps 6 and 7.
  2. Conduct a File System/Advanced Logical Extraction – YOU MUST ENCRYPT the extraction!
    • This can be done in most tools. I use Cellebrite UFED and make sure to encrypt the backup. Cellebrite will use 1234 to do this.
    • If using another tool make sure the option to encrypt the extraction is there or you will MISS a lot of data starting with iOS 13. Refer to my other blogs for more information on this.
  3. If you want to be thorough, obtain a logical and/or backup file of the device. I typically stop at the Full File System or file system dump since it contains the backup if I trust my tool (refer to my old blog for more info on this topic).
  4. Connect the device to iBackup bot and export the crash logs.
  1. Collect sysdiagnose logs and extract them. This can be done nicely with Elcomsoft. More information is at www.for585.com/sysdiagnose
  1. Ensure the tools you used did not enable iTunes encryption by connecting the device to iTunes and making sure “Encrypt Backup” is not selected. This should be performed prior to giving the device back to the suspect/custodian/witness.
  1. Extract cloud data – IF YOU HAVE AUTHORITY! I prefer the same tools mentioned above in the Android part of this blog.

Everyone has their preferences on tools and acquisition methods. A Full File System is the best bang for your buck on most devices. Make sure you validate your extracted data and reach out to the vendors you leverage if issues arise.

Rotten to the Core? Nah, iOS14 is Mostly Sweet

By Heather Mahalik

This blog is a cursory glance of iOS14, which was officially released this week. To keep with my previous trends, I focus on basic artifacts that impact almost every investigation and then dive in and take a bite from the apple. Think of this blog as the bobbing part. 😊 For this blog, I tested the tools that I have available to me personally. If you think something is missing – share it. If you are a vendor and think something is missing – share it with me and I will try it for myself. At this point in time, an encrypted iTunes backup seemed to be the most stable option. I know that vendors are releasing updates to support iOS14 shortly, so be patient. If you DO NOT encrypt the backup, you will NOT extract Calls, Apple Maps (some databases extracted but are empty), Safari, Health and probably a lot more!

Apple didn’t go of the beaten path to much for the primary artifacts. There are some strange things I noted and those will be shared. Since iOS13, best practices are to encrypt your backups! If you do not, you will not get all the databases needed for basic examinations.

For this blog, I acquired many ways to compare the differences. The ones in bold were the best acquisition.

Mac Acquisition Tests:

  • Backup on a Mac using Finder – Encrypted
  • Backup on a Mac using Finder – No encryption set
  • Backup on a Mac using Finder – Encryption set but DID NOT save the password to the keychain

The issue I found when backing up to a Mac and saving the encryption passcode to the keychain is that the Manifest.plist does not show the encryption flag and the tools do not request the passcode for parsing.

Manifest.plist comparison

Thus, you don’t get much of anything! I loaded all of these extractions into Cellebrite Physical Analyzer and Magnet AXIOM to verify and the keychain taking the passcode really limits us examiners so pay attention when using a Mac to create a backup and DO NOT let that box stay checked or your examination opportunities will be limited.

Backing up using a Mac

Windows Acquisition Tests:

I first attempted to use a previous version of iTunes and it didn’t even see my device running iOS14. I updated and all was good from that point forward.

  • Backup with iTunes – Encrypted
  • Backup with iTunes – No encryption set

There weren’t any oddities here other than the fact that as soon as I moved my backup from the MobileSync directory, iTunes claimed it was never backed up to this PC.

iTunes backup

And a backup a few mins later.

iTunes view after backup was moved from the MobileSync directory

Keep in mind, I did about 10 backups of this device because I kept adding data and then pulling it. It makes sense if you think about it, but I know that the device stores this information, so I was surprised to see iTunes simply relying on the backup directory for this information. Bottom line do not trust what iTunes states regarding backups on the summary screen because the truth lies within the iOS device.

For this test, I created new Contacts, placed Calls (both FaceTime and regular), texted (used the new “reply to a message” feature, took photos, searched for directions (and even had to do extra drives to get really test Maps), created a note, and browsed using Safari. These are the key items that everyone should examine for most cases, so I tend to start there. My colleagues and I are going to dive into the harder artifacts (KnowledgeC, locations, Health, etc.) and will do a separate blog on that.

The common artifacts:

Contacts: var/mobile/Library/AddressBook/AddressBook.sqlitedb – parsed by commercial tools

Calls: var/mobile/Library/CallHistoryDB/CallHistory.storedata – – parsed by commercial tools

PA Parsed Call Logs
PA Call logs with Source File

SMS: var/mobile/Library/SMS/sms.db – mostly parsed by commercial tools. See below for more details.

Safari: var/mobile/Library/Safari/History.db – mostly parsed by commercial tools. Note: Make sure your tool parses history, Google searches and Tab history.

AXIOM Tabbed Sessions
PA Safari History
PA Safari History – Source

Photos: var/mobile/Media/DCIM/100APPLE/ – parsed by commercial tools – However, there is a new table. Take a look below.

PA Photos

The table ZGENERICASSET that we have relied upon for so long is now ZASSET. Thanks to Jared Barnhart for finding this first. 🙂 And thanks to Scott Koenig for this query to parse it all. https://drive.google.com/drive/folders/1v6T6OqD8eyL1xwHXDMePaXxEZ3IZssp2

Notes: var/mobile/Containers/Shared/AppGroup/group.com.apple.notes/NoteStore.sqlite – parsed by commercial tools

**NEW File and Path***

Maps: var/mobile/Containers/Shared/AppGroup/group.com.apple.Maps/Maps/MapsSync_0.0.1

var/mobile/Containers/Shared/AppGroup/group.com.apple.Maps/Maps/MapsSync_0.0.1_deviceLocalCache.db

Apple Maps is the biggest change and to be honest, I thought I lost them again. If you aren’t sure what I am referring to, please read my previous blogs on Apple Maps. I have spent countless hours trying to find locations and you know what’s sad – I don’t even like Apple Maps. I prefer Waze. However, as a researcher, I must test all things. Let’s take a historical look at Apple Maps.

History. mapsdata – was the primary storage file for Maps until iOS 8

GeoHistory.mapsdata – the primary storage file for Maps from iOS 8 – iOS 11(ish). Went to cloud storage for iOS12 and then came back and stored here again for iOS13 – again refer to my previous blogs –How the Grinch stole Apple Maps artifacts… or did he just hide them? and First the Grinch and now the Easter Bunny! Where is Apple Maps hiding?

MapsSync_0.0.1 – the new file on the block – this is the primary file storing iOS 14 Maps data.

MapsSync_0.0.1 seems to only keep the last 15 history items. This is about 3-5 directions/lookups/searches based upon my testing. I dumped my device several times to confirm this. Let’s look.

Here is how it looked when I first extracted the data.

Apple Maps Data – DB Browser for SQLite

And just two Apple Maps searches later, it looked like this.

Apple Maps Data – DB Browser for SQLite

The bad news is that none of the tools I tested parse this file. The good news? Here is a query for you. Use your tool of choice to parse it. Keep in mind the “Time Created” below will reflect the time The device was updated to iOS14. Thus, this is NOT when that search occurred. To get that information, you need to examine GeoHistory.Mapsdata – the protobuf that stores this historical information.

SELECT
ZHISTORYITEM.z_pk AS "Item Number",
CASE
when ZHISTORYITEM.z_ent = 14 then "coordinates of search"
when ZHISTORYITEM.z_ent = 16 then "location search"
when ZHISTORYITEM.z_ent = 12 then "navigation journey"
end AS "Type",
datetime(ZHISTORYITEM.ZCREATETIME+978307200,'UNIXEPOCH','localtime') AS "Time Created",
datetime(ZHISTORYITEM.ZMODIFICATIONTIME+978307200,'UNIXEPOCH','localtime') AS "Time Modified",
ZHISTORYITEM.ZQUERY AS "Location Search",
ZHISTORYITEM.ZLOCATIONDISPLAY AS "Location City",
ZHISTORYITEM.ZLATITUDE AS "Latitude",
ZHISTORYITEM.ZLONGITUDE AS "Longitude",
ZHISTORYITEM.ZROUTEREQUESTSTORAGE AS "Journey BLOB",
ZMIXINMAPITEM.ZMAPITEMSTORAGE as "Map Item Storage BLOB"
from ZHISTORYITEM
left join ZMIXINMAPITEM on ZMIXINMAPITEM.Z_PK=ZHISTORYITEM.ZMAPITEM

When examining the output, I was perplexed by the lack of results, which is when I realized that number of 15 stayed constant no matter what I searched for. It appears to be transactional in nature. Also, I went through all the coordinates and realized that the Type “coordinates of search” will not show as “navigation journey” unless selected.  For example, I searched for UMMC (no longer part of this database in my final dump, but the “coordinates of search” persist. The one set of coordinates is for the University Medical Center in Maryland (the one I navigated to) and the other a University Medical Center in Mississippi, which I never selected.

The good news – GeoHistory.mapsdata has the historical searches made in iOS13! If you do not see these in the MapsSync_0.0.1 database, go back and examine the protobuf for locations of interest. Below we can see the searches for UMMC, which are no longer in MapsSync_0.0.1 exist here.

Protobuf View in PA

What about those BLOBS stored in “zrouterequeststorage” you ask? Well, they store your starting location and your final destination. Pretty important, right? This is the literal journey.

BLOBS embedded in Apple Maps
BLOBS embedded in Apple Maps

These BLOBs are protobufs and a special shout out to Jon Baumann who stayed up late to fix his script for me. You can find his script here to parse these nasty buggers. https://github.com/threeplanetssoftware/sqlite_miner/tree/protobuf

Here is some sample output of my file. Note that it isn’t perfect (he worked on this in minutes) and may have false positives.

SQlLte-Miner-.pl output

Protoc can be used to look at the protobufs. And there are many scripts to help. One recommended by the Cheeky4n6Monkey is https://github.com/mildsunrise/protobuf-inspector.

Another consideration is going back into your tool and searching around. Cellebrite Physical Analyzer has a built in button to search in binary blobs. I did two searches here. One for my home street (not sharing that here) and one for a location I navigated to/searched for (chantilly).

Searching Binary BLOBS in PA

Another option is to convert the BLOBS from the query provided above to Hex so you see the output and are alerted. Again, this is a preference thing. Thanks Jared Barnhardt for the suggestion here!

SELECT
ZHISTORYITEM.z_pk AS "Item Number",
CASE
when ZHISTORYITEM.z_ent = 14 then "coordinates of search"
when ZHISTORYITEM.z_ent = 16 then "location search"
when ZHISTORYITEM.z_ent = 12 then "navigation journey"
end AS "Type",
datetime(ZHISTORYITEM.ZCREATETIME+978307200,'UNIXEPOCH','localtime') AS "Time Created",
datetime(ZHISTORYITEM.ZMODIFICATIONTIME+978307200,'UNIXEPOCH','localtime') AS "Time Modified",
ZHISTORYITEM.ZQUERY AS "Location Search",
ZHISTORYITEM.ZLOCATIONDISPLAY AS "Location City",
ZHISTORYITEM.ZLATITUDE AS "Latitude",
ZHISTORYITEM.ZLONGITUDE AS "Longitude",
hex(ZHISTORYITEM.ZROUTEREQUESTSTORAGE) AS "Journey BLOB(hex)",
hex(ZMIXINMAPITEM.ZMAPITEMSTORAGE) as "Map Item Storage BLOB(hex)"
from ZHISTORYITEM
left join ZMIXINMAPITEM on ZMIXINMAPITEM.Z_PK=ZHISTORYITEM.ZMAPITEM
BLOB output as HEX – DB Browser for SQLite

I plan to keep digging into Apple Maps and will blog more as I find more information. For now, use this query if you dump a device running iOS14. Don’t be afraid to make it your own too! You will see many columns that I could not get to populate with valuable information.

For iMessage, you can now reply to a single portion of the conversation. The below screenshot shows you how this appears on the device.

Reply To Message

The database has two new columns called “thread_originator_guid” and “thread_originator_part” which appear to be what the tools are not yet parsing and is what alerts you to the message the reply was to. I have yet to determine what the “thread_originator_part” means.

SMS Reply To – DB Browser for SQLite
SMS Reply To – DB Browser for SQLite

Refer to the screenshot from the phone to put this all together. Until the tools catch up, here is a query that will get you part of the way. It’s not perfect, and I plan to try to merge them. Maybe one of my friends will help write a script for it (Calling Brigs, Ian and Cheeky4n6Monkey!). The query below has been updated for iOS14.

SELECT message.rowid,
chat_message_join.chat_id,
message.handle_id,
message.text,
message.thread_originator_guid,
message.thread_originator_part,
message.service,
message.account,
chat.account_login,
chat.chat_identifier,
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 'NA'
END as "Message Date",
case when LENGTH(message.date_read)=18 then
datetime(message.date_read/1000000000 + 978307200,'unixepoch','localtime')
when LENGTH(message.date_read)=9 then
datetime(message.date_read+978307200,'unixepoch','localtime')
else 'NA'
END as "Date Read",
case when message.is_read=1
then 'Incoming'
when message.is_read=0
then 'Outgoing'
end as "Message Direction",
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 'NA'
END as "Last Read",
attachment.filename,
datetime(attachment.created_date+978307200,'unixepoch','localtime') AS "Attachment 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;

Bottom line – Apple isn’t rotten. The days I spend researching and blogging are for my family until I press submit! 😊 Please research and share! Validation is key. We all need to do it! Create test data and try it for yourself. If you find bugs, report them to vendors. If you find gaps, report them, and find someone who can build a tool to parse it. It’s our job in DFIR to educate and share. Happy hunting on iOS 14! And you may see this image coming to you publicly soon!

iOS 13 – Summary for those of you who enjoy the cliffsnotes

For those of you who don’t have time to read for585.com/ios13, here is a mini summary for you.

First – If the backup is NOT encrypted you will not get:

  • Maps
  • Calls
  • Safari
  • Health
  • Keychain
  • Wallet

Apple has upped their game on protection it seems, so you need to encrypt to extract. I used iTunes in my full blog and just testing PA 7.24 Method 1 with encryption and Method 2 is in progress. Worked like a charm and I got what I expected. You lock it up, or you don’t get much. Bottom line. Jessica Hyde wrote a post on protecting yourself from an accidental sync if using iTunes to create a backup: https://www.magnetforensics.com/blog/three-newer-things-that-may-surprise-you-about-ios-forensics/amp/ If you are using PA, you are protected from this.



While you are going to be forced to read the long blog for the juicy details, here are the file paths you need to be aware of for iOS 13:

  • Contacts /var/mobile/Library/AddressBook/AddressBookImages.sqlitedb
  • Calls /var/mobile/Library/CallHistoryDB/CallHistory.storedata
  • SMS /var/mobile/Library/SMS/sms.db
  • Maps /var/mobile/Applications/com.apple.Maps/Library/Maps/GeoHistory.mapsdata
  • Safari /var/mobile/Library/Safari/History.db
  • Photos Database /var/mobile/Media/PhotoData/Photos.sqlite

The biggest change other than encryption seems to be the use of protobufs, which Sarah Edwards is working on a blog to discuss, settings and how that may determine what is saved to device vs. cloud, Safari artifact storage, and encryption. Please read the full blog for all of the good details and stay tuned for my iOS series, webinars, etc.

Stay tuned for the release of PA 7.24 next week and also for #TipTues on Twitter where I will provide something useful, I hope. 😉

…Won’t you back that thing up: a glimpse of ios 13 artifacts

Don’t lie – the song is already in your head. And if not, maybe it will be by the end. If you know me, titles/taglines, whatever you want to call them, are not my thing. But since testing iOS 13, I feel like I have backed that thing up a billion times! I dump, I examine and then realize something so I then add/delete that “thing” and repeat. Hence the name of this blog!

First things first, Apple didn’t appear to mess with us too much with this update with a few exceptions. First, encryption is everything! Some artifacts moved, while others are back again (pending settings on the device) , some can be controlled by the user and some just stayed the same. For the artifacts that moved – this is where you need to TEST YOUR TOOLS! Do not trust a blog post from a vendor (even one from me) – TRY IT FOR YOURSELF. Testing and validation is so important. There are so many bugs in tool releases and even false claims of support. Try it and then rely on it.

At the time of writing this, Physical Analyzer Method 1 and Method 2 were not supporting iOS 13. A little birdie tells me it will be released next week and I may have seen the beta. For the tools that did acquire, iTunes was used. When this is the case, I just use iTunes so I can control the environment. I like to encrypt my backups because I want Health, Keychain, Safari, Calls, Maps and Wallet, but I did conduct an unencrypted one for comparison and for parsing in one tool that will be discussed in a bit. Did you notice I said Safari, Maps, and Calls in an encrypted backup – yep – stay tuned.

And then I did it again with 13.1 because I didn’t get my blog out fast enough. 🙁 So this blog really covers both, not that I expected major changes in a tiny update.

The backup content looks similar to iOS 12. The major difference was the name of the backup, which is shown below. The top backup is from iOS 13 and the bottom from iOS 12, but the hardware is different.

Bottom line – until I test the full release of Method 1 and Method 2 in PA and fairly compare it, I recommend doing an encrypted iTunes backup and here is why.

Artifact Locations – The good stuff

For this post, I tested my usual suspects of artifacts. The ones that every device should have. Contacts, Call Logs, SMS, iMessage, Maps, Photos, and Safari. Here is what I found:

Artifacts with no path changes or anything drastic:

  • Contacts/var/mobile/Library/AddressBook/AddressBook.sqlitedb
  • SMS/iMessage/var/mobile/Library/SMS/sms.db

My buddy Jared, who also enjoys 90s hiphop pointed out something cool to me. Look at the message below. For anyone working distracted driving cases, this could be amazing for you. Look how the messages were sent! I’m in a rush to get this out, so I hope something like this will be a quick #TipTuesday on where it exists in the sms.db. Thanks Jared!

  • Photos/var/mobile/Media/PhotoData/Photos.sqlite (nothing major about the graphics jumped out upon initial review.

I have been asked so many questions about photos.sqlite lately that it will also be a blog of its own. There is so much goodness contained there! I plan to do another blog on deleted artifacts and how to recover, if possible, so watch out for that. For fun – this is a screenshot I took today to share with Paul all for the fun of testing. You never know what I may share, right Sarah? 😉 Honestly, if you cannot make fun of yourself – you need to relax.

Artifacts with minor changes:

  • Calls/var/mobile/Library/CallHistoryDB/CallHistory.storedata

 For Calls, the data remains the same, but you need an encrypted backup to get the data. Additionally, one file was added –CallHistoryTemp.Storedata. Mine had nothing of interest, but keep an eye on this bugger. It was put there for a reason, I just don’t know the exact one yet. I initially thought that AXIOM missed the calls, but realized I gave AXIOM and unencrypted backup so it could handle the file system view.

 It is worth noting that I deleted a call and could not find it in the free pages of CallHistory.storedata. I tried Physical Analyzer, Oxygen (the trash can feature), BlackLight, AXIOM, Forensic Browser for SQLite (Paul Sanderson) and Mari’ Degrazia’s awesome script https://github.com/mdegrazia/SQLite-Deleted-Records-Parser And guess what – I didn’t find the call. So more on that in another blog. I bet it’s in the cloud… 

  • Health – (yes, I snuck this one in here because it is so valuable) /private/var/mobile/Health – examine the healthdb.sqlite and healthdb_secure.sqlite databases and take note of the new ones. I will write a complete Health blog soon. The tools may not be parsing everything, so refer to the presentation Sarah Edwards and I gave a few years ago: https://github.com/mac4n6/Presentations/blob/master/%23DFIRFIT%20or%20BUST/DFIRFIT.pdf

I do have to call out Oxygen Jet Engine here, who did a nice job on Health. Well done on connecting the device, OS version and locations. See a snippet below. More on this in my Health blog, where I plan to include Android health as well.

Apple switched the path up again – READ this part:

  • Safari/var/mobile/Library/Safari/History.db

IMPORTANT – the history.db is NO LONGER in com.apple.mobilesafari! See below. Here we have a visual of what is included in mobilesafari for an encrypted backup. The history.db. is no longer here. (NOTE: I would  examine all of these databases for relevant info. Mine didn’t have much, but I prefer Chrome.)

Take note here – at the time of testing, not all tools parsed Safari history! I assume they thought the database would remain in mobilesafari and guess what – that no longer exists. We are back to good ‘ole history.db in it’s first home in the Safari directory. Physical Analyzer, BlackLight and AXIOM parsed all of the searches I conducted in iOS 12 and 13 if an encrypted backup was obtained. NOTE – you will not get safari history in unencrypted backups anymore. You will simply get bookmarks and the dummy login for Safari, as shown below.

Additionally, it appears that Safari has moved all of the history data, which is uncommon. This history included much more data than that of iOS 13 and what is show below is history from May 2019 to present. 🙂 Makes it easier on us. Thank you Paul for sharing yours – again, I use Chrome. 

For the tools that didn’t parse Safari history, the database was there and the searches were as well. So they just need to catch up. I will explain which tools missed the artifacts at the end of this blog.

Something else worth noting is that it seems like Safari wants you to go into Private Browsing when you launch it. If this happens, you won’t find anything in history.db. Verify the setting on the iPhone. The user may not even realize it’s happening, which is what occurred while Paul and I were conducting our testing over the past few days. Screenshot of what this looks like for the user is below. Note, once Private is exited, all history is capture in an encrypted backup or Method 1 in PA.

In summary – for Safari, you MUST have an encrypted backup or an encrypted Method 1 from Physical Analyzer. I know this because we tested the beta of PA 7.24 and it works like a charm.  If it’s not encrypted by iTunes or the tool – you will not gain access to  Safari/history.db.  If the user last used Private browsing and did not close Safari, chances are good you will also get nothing. If you want to find Private Browsing traces – sign up for FOR585 Advanced Smartphone Forensic Analysis In-Depth and we will teach you. for585.com/course.  

It’s back – well, depending on your settings!

  • Maps/var/mobile/Applications/com.apple.Maps/Library/Maps/History.mapsdata  – older searches – pre iOS 11 and /var/mobile/Applications/com.apple.Maps/Library/Maps/GeoHistory.mapsdata – iOS 11 and newer searches

I have spent years on Apple Maps. Literally years… While it’s back, only some tools only parsed history.mapsdata! Again, make sure you use a tool that will parse both history.mapsdata and Geohistory.mapsdata. Verify the source of the data for everything parsed as your first clue. This is super important to ensure you aren’t missing information. Vendors – again, make sure you are doing this correctly. I found major gaps. This is what it looks like when the tool does it’s job.

You should also be able to manually examine the Geohistory.mapsdata file for confirmation.

If you see nothing at all for Maps, the user probably enabled the cloud setting for Maps, which seems to skip saving anything to the phone other than the group.com.apple.Maps.plist which stores the last search in Apple Maps and can be found here: /var/mobile/Applications/group.com.apple.Maps/Library/Preferences/. If that isn’t the case, you need to choose a tool you know properly parses Apple Maps.

Here is what the setting looks like that may keep Maps from being saved to the device. I have Maps turned off for iCloud, so the data was saved to Geohistory.mapsdata on my iPhone. On Paul’s device, his was turned on and he didn’t have a Geohistory.mapsdata. The settings seem to control what we can extract. You need to pull iCloud information to extract this and Elcomsoft does a fantastic job.

 

Tool Support

How was an iPhone setup?

I’ve realized just how important it is to blog vs just do a webcast when I was completing my course updates. I would stumble upon a webcast, but didn’t have time to watch it, so I looked in another direction. This made me realize that I should write down everything I put into a webcast. Will a webcast hold up in course? Do you have time to watch all of them? Seriously, I am curious about the impact so please let me know.

In 2019 – I am going to write down what I talk about in webcasts. If I have the time, I may try to blog about my speaking events as well (think Keynotes and SANS @Nights). Some blogs may be short and sweet, but this way when someone says, “how can I do X” I will point them to my blog. 🙂

To kick this one off, I am going to simply discuss a file that stores information on how an iOS device was setup. This is a file that I am asked about a few times a week. In many cases, it matters if the user synced from iCloud, started from scratch or restored from iTunes. So here goes!

First, you should be obtaining an encrypted backup at a minimum. If you have the ability to get a full file system dump, even better. Without encryption, I cannot guarantee that all of the files I plan to discuss in upcoming blogs will exist. Make sure your analytical tool of choice will decrypt the data. If you are trying to do this for free follow the steps below.

Creating and parsing an encrypted iOS backup for FREE:

  1. Launch iTunes on your forensic workstation. Update if necessary.
  2. Make sure you Trust the computer on the iPhone.
  3. Create an encrypted backup with a password you will remember (yep, people forget all of the time!)
  4. If you aren’t using a commercial tool or one that supports decrypting the backup, you may have to get crafty. I stumbled upon AnyTrans during my updates and it’s pretty sweet. To use this, you must know the password or crack it (refer to other blog posts in my archives.)
  5. Launch AnyTrans and it will show you if you have locked backups.

6. Select the locked backup (you know it’s locked because the option is to “unlock” it.

7. Enter the password and the backup will be unlocked! The top portion shown below is how the backup directory will look. The original backup remains and the unlocked version is called BackupUnlock. If you peek inside that directory, you will find the backup with the date it was unlocked.

8. From here, you can load the unlocked backup into iBackupBot or your tool(s) of choice (iExplorer, etc.). Note: Some commercial tools HATE this format and will not support it. The free ones seem happy enough!

Now let’s get to that file you care about. Once your backup or image is loaded into your tool, you need to locate the following file: /Library/Preferences/com.apple.purplebuddy.plist. I normally just search for purplebuddy.

This plist stores the SetupState of the device which will tell you how the device was setup by the user.

If the user selected to restore a backup from iCloud, the com.apple.purplebuddy.plist will show:

If the user setup the iPhone using iTunes, the com.apple.purplebuddy.plist will show:

It is worth noting that I am testing on an iOS 12.1.x device and I restored from iTunes in 2 ways to obtain these results. First, I wiped and set up via iTunes and then I also forced a restore of a backup via iTunes. I wanted to be sure the SetupState didn’t change. If you find that the user restored from iCloud, consider pulling cloud data if you are legally capable of extracting that form of evidence. Should you find the user restored from iTunes, you now have to find that host computer to do analysis on other potential backups. This is where the fun begins!

Bottom line, Apple has a ton of plists that are relevant. You need to hunt for them. Do a keyword search, dump your device (yep, use the free way I described above) and VALIDATE!!!

If you want to watch the webcast, check it out here: https://www.youtube.com/watch?v=AC2TpWsLPLQ



CAUTION: iBACKUPBOT and iOS10+ potential issues.

Below I am attempted to do the same thing with iBackupBot, but I ran into iOS version issues.

  1. Launch iBackupBot
  2. Make sure you Trust the computer on the iPhone.
  3. Create an encrypted backup. Notice that the tool is telling you that Backup encryption is turned on? This is good.

4. Select where to save the backup image. I recommend into your case directory for the investigation.

5. The backup will be created and then you can open it in iBackupBot for analysis. Once the backup is complete, it will prompt you to open it. If you have issues, this is an iOS10 error from what I have seen. :/ At this point, revert to iTunes.



A breath of fresh air! Conducting application analysis with Oxygen Detective

See what I did there? I am getting craftier with these blog titles. First things first – this is NOT a sponsored blog.  I am just really impressed with the bounds Oxygen is making in the mobile world.

A breath of fresh air

I have been using Oxygen for years and this last update has really impressed me. I test tools thoroughly and include the best ones in the SANS FOR585 Advanced Smartphone Forensic course that I co-author. I also use these tools for my regular job, where I aim to find gaps and then fill them with my own methods and tools. So, it’s safe to say that I spend a lot of time becoming familiar with the tools, learning what I am able to trust and where they ultimately fail me.

Normally, I  have a hard time seeing the good side of tool output because the artifacts are often so convoluted and misleading to examiners who don’t know any better. Is it the vendor’s fault – No! The phones are hard to keep up with and the version updates on each OS make it even harder, but examiners like to press the “Find Evidence” button and that makes me shiver. So… that is why I am normally opposed to those who use tools and live by what the tools report without digging in to verify. Don’t get me wrong, there is never enough time, but some things are worth digging for and verifying!

Image result for Stepping off my soapbox meme

What changed my mind about Oxygen? Well, it’s not that I was ever against the tool, I just didn’t see how it added value to my everyday work or smartphone course until this latest release. I have always loved the PList Editor and SQLite Viewer, but that is really where my love existed – until recently, that is. This tool has made my life so much easier! I am going to highlight some of my favorite new features. Why should you care? Because you are going to see smartphones with third-party applications on them. This tool is fantastic at supporting the parsing of third-party apps and when it can’t – guess what? It will give you a cheat sheet for the files you must MANUALLY examine. Now that, is the key to success right there. Don’t believe me, keep reading.

Oxygen has taken the parsing of social networking apps to a new level. This includes popular apps like Facebook, Facebook Messenger, WhatsApp and those less popular ones that will shock you when you load your image file and see the glorious application data parsed for you. Now will this tool get it right every time? No, but it gets you a little bit closer.  Tools should be used to triage what you need to focus your efforts on. Oxygen has been helping me see what I need to hone in on and then allows me to keep my deep dive all within the tool.

My normal application analysis process involves (Note: since this blog is about my Oxygen experience, I am highlighting how to do as much of the examination as possible in that tool):

  1. Scanning the Applications that are parsed by the tool (I commonly use Physical Analyzer, Oxygen, IEF/AXIOM, BlackLight, etc.)
  2. Examining the data for application installation traces
  3. Identifying apps of interest and going directly to the application directory for manual examination and verification (via File Browser in Oxygen Detective)
  4. Combing through each relevant database and examining for both active and deleted artifacts of interest (via SQLite Database Viewer in Oxygen Detective)
  5. Leveraging the SQL Editor to draft my own queries to parse and join tables of interest (No experience here? Try the query builder that is built in to learn)
  6. Examining each .PList of interest (using the Apple PList Viewer in Oxygen Detective)
  7. Examining any other files of interest pertaining to the applications (xml, dat, multimedia, etc)
  8. Examining  browser and webkit artifacts
  9. Exporting what isn’t support and dive into it using another tool

I am a firm believer that one tool cannot solve all of your investigative needs, which is why I use all of the tools available to me to my advantage and branch out from there. For example, I was working an app last week that allowed the user to share their location for a set period of time. The first tools I tried did not parse this data. Even Google maps could not render the broadcasted location from this obscure app. But guess what – Oxygen decoded it and correctly displayed the location I was sharing from that app. How do I know? Because I created test data to mimic what I found in that file on that Android device and it parsed my location information correctly.  Add another thing to the list on what is impressing me about Oxygen.

I aim learn the strengths (and weaknesses) of each tool and tool feature and impart that wisdom on my students. A tool that was great two years ago could be useless today, so you need to keep up and always test and validate with datasets you trust. Not everyone has time to thoroughly test all tools, so we, as a community need to test and share our results (hence most of my blog posts).

Let’s take a  look at some examples. For this scenario, I used Oxygen to highlight application analysis on WhatsApp and webkit artifacts. As previously mentioned, I start by looking at the apps that are parsed vs which are installed. From there, I select the ones of interest and start looking at the actual files. Below, I scanned the files associated to WhatsApp. Some of these were parsed and a lot them were not. This tool gives me a quick reference to the files associated to the application and leaves the rest to me, which I prefer and appreciate. Few tools will provide you the location for all of the files associated with the app. Often, you will find yourself needing to hop around to see the paths for all application data.

During this examination, I opened databases of interest and examined them. Some required queries and the recovery of items marked for deletion, all of which is possible within the tool. If you have other tools you prefer, simply export the file and go on your merry way. What I really like is the ability to get a glance of what is stored within each file without opening each one. Below I was examining a log file associated to WhatsApp without navigating from my list of app files. This is helpful to those of us who are lazy and do not enjoy opening every file and examining the data in separate windows.

After exhasting my examination of the apps themselves, I went to the webkit and browser for more hunting. Below, I am using Oxygen to get an idea of the webkit files available from my data dump. I normally conduct a simple keyword search in my tool of choice for “localstorage”, but this way was much easier and eliminated the need for that step. As a side note, Oxygen did a great job parsing these files. I am simply showing the raw files associated with webkit activity.

 

Below I am showing an example of a localstorage file that I wanted to customize to fit my examination needs. I drafted a SQL query and joined two tables to show the results I needed for my forensic examination. This can be exported and included in my report template. The SQL Editor was used in this example.

The mapping was great in this tool, but I have decided to omit those screenshots, since it highlights my home location.  I found it interesting at how well the pesky locations (those located in log, xml and dat files) were parsed by Oxygen. If you have heard me present on location artifacts in tools, it is commonly a WARNING to tread carefully. The tools have a hard time interpreting how the location got onto the phone. A simple example: I receive an iMessage with an attached photo. I save the photo to my device. I dump my phone and look at the locations. The location from the shared photo shows up in my report as if my device was there. This is how someone without a lot of experience may interpret that evidence. Hence, be careful! The reality is that the the cool artifacts used and created by third-party apps use are often overlooked. I was thrilled that Oxygen parsed that location information, especially because Google Maps was throwing fits when I was attempting to manually render the lat/longs. Go Oxygen!

In summary, this was just a short blog post highlighting the successes I have been having with Oxygen. Additionally, customer support has been great. Is the tool perfect? No? Is it something you need in your forensic toolbox – Absolutely. If you end up taking FOR585, you will learn more about this tool. For those who aren’t looking for training and just want to test it on their own, see the details below and ask for a demo.

I hope these tools keep growing in capabilities and keep one another competitive to be the best. It helps us as examiners! Even though I use the tools to only get so far and rely on manual investigation techniques, getting over the first few hurdles is the hardest and then you set your pace. (Yes, I ran track… :)) I believe this tool will get you over those hurdles for application analysis.

To try Oxygen Detective and see the benefits for yourself, reach out to sales@oxygen-forensic.com and ask for a demo. Mention my blog!