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.
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.
Another year, another SANS DFIR Summit come and gone. What a whirlwind! If you have never been to the DFIR Summit in Austin, TX, I would highly recommend it. This year seemed to have more new people attending than ever before. (I don’t have the official counts, so I don’t know for certain.)
The presentation slides have been posted if you’d like to review them. In roughly 2-3 months, the videos should also be posted to YouTube. A few highlights:
#DFIRFIT or Bust – I loved this talk the most. Take a look at the slides to see why. 😉
Event Trace Logs – Nicole has been researching these for quite some time, and her presentation goes into awesome detail about these logs. If you’ve never examined ETLs, you really should.
mac_apt – macOS forensics is my jam. Yogesh’s mac_apt.py pulls [almost] all the things for forensic analysis. Obviously it requires some thought in your analysis to put together a timeline of events, but this script will be a great start in simplifying your efforts.
DNSplice – Shelly loves her DNS logs! Her python script helps put extra meaning behind the data.
Forensic 4:Cast Awards – Lee puts a lot of thought and love behind these awards, as evidenced by his 10 years of work on them. Congrats to all the winners and runner-ups!
After the conference, the DFIR Summit offers classroom training. This year I signed up for the FOR585 Advanced Smartphone Forensics course. Heather did a phenomenal job teaching the class and really made sure people understood the concepts. She even taught SQLite in a way that actually made sense! (I’ve struggled for years with SQLite queries, but now I can easily write basic queries, join tables, add case statements, and order columns.)
The final highlight of the DFIR Summit was the NetWars challenge. This year SANS added a Coin Slayer challenge where you could win a challenge coin from a particular course, assuming you answered all questions from all four levels correctly. There ended up being seven people who won Coin Slayer coins – two in Reverse-Engineering Malware and five in Smartphone Forensics. I happened to be one of the lucky ones to earn a Smartphone Forensics coin within the final three minutes of the competition.
All in all, the DFIR Summit was more than worth it! If you get a chance to go, absolutely do it. The Summit will be held in Austin, TX next year July 25-26 (conference) and July 27-Aug 1 (training). Hope to see you there!