Today’s post is an incredibly tough one to write. This morning my buddy, my best friend, my DFIR Dog passed away. He lived a great life and was loved by so many. Whenever I would work from home, he would lovingly announce his presence on conference calls, show his face on video calls, and would stare at the computer screen helping me analyze evidence. He was to be the topic of my presentation for next year’s DFIR Summit. (Who knows, maybe I will still do the presentation — bring tissues!)
Cody was rescued at 3 years old and lived to be just shy of his 13th birthday. He enjoyed being goofy, helping people, going for walks, being my anxiety companion, and being loved on by the neighbor kids and my nieces and nephews. He was incredibly smart and knew exactly how to get his way, most days. He passed peacefully in my arms at home, surrounded by love and comfort. May he rest in peace and run wild and free. Mama loves you, buddy.
The Diana Initiative is hosting a two-day conference on August 9 and 10, during the week of Black Hat and DEFCON. The conference is FREE for attendees, and this year’s theme is “Hacker Family: Our Diversity Unifies Us.” According to their website, the organization was set up to:
Encourage diversity and support women who want to pursue careers in information security
Promote diverse and supportive workplaces
Help change workplace cultures
This year’s conference schedule has been posted, and there are some really amazing talks planned. The one I am looking forward to most is Amanda Berlin’s Friday evening keynote on mental health.
There are sponsor spots still open if you or your company would like to sponsor the event. Donations are also open! If you cannot afford to donate (and that’s okay!), consider being a volunteer for the event. Regardless, you should attend! Did I mention the conference is free? Hope to see you there!
Scenario: A user connects an iPhone to a Windows 7 computer. The computer prompts the user with options of how to view the contents, sync contents, etc. The user chooses to view the files, browses to the DCIM folder, and begins to copy the photos to the computer. A few minutes into the file copy, iTunes opens on the computer and interrupts the connection to begin creating a backup. The user stops the iTunes backup, closes iTunes, and ejects the iPhone. The user unplugs the iPhone from the computer and plugs it back in to restart the DCIM file copy. Oddly, there are no photos to copy. On the iPhone, the Photos folder is empty, and there are no Recently Deleted photos. Add to this, iCloud Photo Sharing and iCloud Sync are disabled, and Photo Stream is turned off. What would you do to recover the photos?
This is what I tried when presented with this problem.
Create a forensic image of the iPhone. I used Cellebrite Physical Analyzer, Method 1 and Method 2, to capture the contents. Jailbreaking the iPhone was not an option due to MDM settings (and I wasn’t going to risk losing everything).
Carve for images. I again used Cellebrite Physical Analyzer for this. This method located 595 images, with all but two recovered images being junk portions of possible images. The two recovered images were application thumbnails and not the missing photos.
Create a forensic image of the memory on the Windows 7 computer. I used FTK Imager for this because it was already installed on the machine. It made a copy of the pagefile.sys and created a memdump.mem file. I analyzed both of these with X-Ways — still no missing photos.
Create a forensic image of the hard drive from the Windows 7 computer. I used a Logicube Falcon for the image creation, decrypted the image with EnCase, then analyzed the image in X-Ways. After carving for photos, no such luck.
My original post tonight was scrapped, mostly because I ran across APFS goodness on Twitter. Jonas Plum tweeted about releasing an open source file recovery tool for APFS volumes. Holy monkeys, y’all. Open source file recovery tool for APFS volumes! I’m excited! All the APFS tingly feelings.
Download afro here. I plan to test this tomorrow over a couple base APFS images and will blog about the findings. Stay tuned!
In the meantime, if anyone has APFS tools they would like tested, feel free to contact me. I would be happy to provide feedback.
Yesterday I mentioned extracting BLOB data from Manifest.db, which would be a painful process to do manually. Thankfully, Adrian Leong (@Cheeky4n6Monkey) wrote a python script to automate BLOB extractions from SQLite databases. It is a fairly simple script and will work on any SQLite databases, not just the Manifest.db.
The Manifest.db is a SQLite database storing information about the iTunes backup. When opened with DB Browser for SQLite, switch to the Browse Data tab to preview the contents of the tables.
In the above photo, you can see the table’s contents on the left side. When you see BLOB as the content, you will likely want to export the data to view in another application. To see the content in SQLite, on the right side, change the Mode to Binary. This will show you the BLOB content, which in this case is an embedded binary plist. (Welcome to iOS and macOS! You will quickly get used to seeing embedded binary plists, double embedded plists, and so on. It is plist Inception!)
To export the binary plist, click on Export and save the file to a new location. Change the file extension to plist and open with your plist viewer of choice. (On macOS, you can view these natively or use Xcode. On Windows, try Paul Sanderson’s BPList Viewer.)
The exported plist will include file information and dates, depending on which binary plist you exported. The highlighted item “LastStatusChange” is actually a date value of Unix Epoch. If you see a number starting with 14 or 15, count on it being a Unix Epoch date.
In the above example, the Unix Epoch value “1527733038” has been converted to a human-readable date. EpochConverter.com is a great, free resource for converting date values and allows batch conversions of dates. Other popular conversion tools are Dcode, DateDecode, Unix Timestamp, and my personal favorite epochalypse.py.
The Manifest.plist is another file in the root of the iTunes backup folder.
Like the other plists, this one lists the device name, serial number, and Unique Device ID. Some of the additional values included are identifying if the backup is encrypted, syncing to iCloud, if there is a passcode set on the device (different from backup encryption), WiFi sync capabilities, and any accessibility features enabled.
A note about the com.apple.mobile.wireless_lockdown. This is not indicating whether or not the device has WiFi enabled. This key shows whether iTunes can be synced over WiFi.
Also note (unrelated to the Manifest.plist), if you want to prevent the phone from automatically syncing when it is plugged into your computer, uncheck the box “Automatically sync when this iPhone is connected.”
Yesterday I mentioned there were a few plists and a database in the root of the backup folder. I explained the Info.plist, but today wanted to explain the Status.plist.
In some scenarios, you will only have a limited amount of time with a device, and you want to ensure you have everything you need. This plist is a quick way to check. The Status.plist will display if a backup has fully completed, if it is a full backup, and the date the backup was created.
What does it mean when IsFullBackup is NO? In Day #3’s post, I mentioned there were options to encrypt an iTunes backup. When this is not selected (i.e. you do not encrypt the backup), the IsFullBackup will be set to NO. When you do choose to encrypt the backup, the IsFullBackup will be set to YES.
Ideally, your workstation should be free of previous user and client data when you begin your collections. This is not always possible when you are at a client site and requested to image multiple devices. If you can, image the devices to an encrypted external drive or an encrypted file/partition. The big caveat to this is when you are using iTunes as your collection method, which saves the backups to its default location. On Windows, that location is: \Users\[username]\AppData\Roaming\Apple Computer\MobileSync\Backup\. On Mac, that location is: /Users/[username]/Library/Application Support/MobileSync/Backup/. Essentially, if you search for “MobileSync” or Info.plist on either OS, you will locate the iTunes backups.
Each iTunes backup per device will be named by its unique identifier. The backup will contain a numerical string of subfolders, an Info.plist, Manifest.db, Manifest.plist, Status.plist.
The data will not be collated if you perform iTunes backups with multiple devices. Each backup will be associated with its own unique identifier. The easiest way to find whose data belongs to which unique identifier is to open the Info.plist file.
Items included are:
Last Backup Date
Type of Phone
This is where you can associate the Unique Identifier backup folder name with a specific user’s device. It is helpful, especially when you have multiple phone backups on one computer.
In another post, I will explain the Status.plist, Manifest.plist, and Manifest.db.