iOS Forensics: HFS+ file system, partitions and relevant evidences
In order to perform a correct forensic analysis on a Apple device, a basic knowledge of storage, file allocation methods relevant files paths is always required.
So, let’s try to write down some basic information…
The HFS+ filesystem
The Hierarchical File System (HFS) is a dynamic file system formatted with a 512 byte block scheme.
Block types
There are two types of blocks in the HFS system: logical blocks and allocation blocks. The logical blocks are numbered from the first block to the last block available on the volume and will remain static. Allocated blocks on the other hand are a bit different and can be tied together as groups to be utilized more efficiently by HFS.
Files system structure
The structures of this file system include a volume header, allocation file, extents overflow file, catalog file, attributes file and a startup file
Volume Header
Sectors 0 and 1 of the volume are the boot blocks. The volume header is utilized to contain information about the structure of the HFS volume and is composed by the 1024 bytes after the reserved set of boot blocks on the partition. A backup of the volume header can be found in the last 1024 bytes of the volume, primarily used for disk repair if the original header is damaged.
The Volume Header stores a wide variety of data about the volume itself, for example the size of allocation blocks, a timestamp that indicates when the volume was created or the location of other volume structures such as the Catalog File or Extent Overflow File.
Allocation File
The purpose of the allocation file is to track which allocation blocks are used by the system or are free. The file specifies whether an allocation block is free by storing this data in a bitmap, specifying a free allocation block with a "clear bit" (zero). The allocation file does not have to be stored contiguously within a volume.
Extents Overflow File
This file tracks all allocation blocks that belongs to a file. The information recorded lists all extents used by a file and its’ allocated blocks in the proper order. This information is stored in a balanced tree format.
Catalog File
The catalog file describes the folder and file hierarchy on a volume. The catalog file contains metadata about all the files and folders, including information on modified, access, and created times. This catalog (a balanced tree) utilizes nodes to reference folders and files, and maintains the hierarchy of header, index, leaf and map nodes. The nodes are grouped together in a linear fashion to add speed to the process. Each file created is assigned a catalog ID number.
Attributes file
The attributes file is reserved for implementing named forks in the future. It is a special file, described by an HFSPlusForkData
record in the volume header, with no entry in the catalog file. An attributes files has a variable length key and three data record types, which makes it roughly as complex as the catalog file.
It is possible for a volume to have no attributes file. If the first extent of the attributes file (stored in the volume header) has zero allocation blocks, the attributes file does not exist.
Startup file
The startup file is a special file that holds information needed when booting a system that does not have built-in support for HFS+. A boot loader can find the startup file without full knowledge of the volume format.
Partitions
An iOS device will have two partitions.
First partition is read only and contains the firmware: it can be written only during a firmware update. This partition contains only system files, upgrade files and basic applications.
The second partition will contain user data and applications and will be the focus of most forensic investigations.
Forensic relevant files
Into the “data partition” iOS stores, along with user’s file (photo, video, music), a lot of system and configuration files, useful during the analysis process.
Configuration files are store in two format:
SQL Lite Databases
The SQLite data format is a popular format for mobile devices and open source applications: is a relational database that can be completely contained in a small C programming library [2]. The format for this database is compact and contains some nice functionality for its size:because of these features the iOS development community has embraced SQLite.
Many of the native iOS applications such as Calendar, Text Messages, Notes, Photos, and Address Book utilize this database structure to store and organize their data.
Plists
The Property List (plist) is data file used to store various types of data on iOS and OSX. Originally Apple used the NeXSTEP format or a binary format for these files, but this was deprecated and a new XLM format was introduced. The examiner today will typically see either a XML or binary format.
The plist in an iOS device can be used to store strings, dates, Boolean values, numbers or binary values. Applications that maintain configuration data such as browsing history, favorites, configuration data, and others can place their data in a plist. When the examiner encounters a plist file that cannot be opened with a standard text editor a viewer will be needed. Plutil is a command line tool for Windows/Mac/Linux that can convert the binary plist files into human readable form for examination.
Relevant paths for forensic acquisition
I’ve already covered this topic a previous post, however I think is useful a brief recap, with several additions:
SQLite databases
DATABASE | DESCRIPTION |
/Library/CoreDuet/* | Device lock state (1=Locked, 0=Unlocked) |
/Library/AggregateDictionary/ADDataStore.sqlitedb | Dictionary |
/Library/BatteryLife/CurrentPowerLog.PLSQL | Battery life tracker, Application traces |
/private/var/networkd/netusage.sqlite | Network artifacts |
/Library/Health/healthdb.sqlite /Library/Health/healthdb_secure.sqlite | Activity, Personal information, more |
/Library/Caches/com.apple.routined/cache_encrypted*.db /Library/Caches/com.apple.routined/StateModel*.archive | Frequent Locations |
/Library/Caches/cache_encrypted*.db /Library/Caches/lockCache_encrypted*.db |
Cell and WiFi locations |
/Applications/* | Examine relevant app directories to obtain additional data |
/Library/BullitenBoard/ClearedSections.plist | Logs of cleared notifications |
/Library/Keyboard/UserDictionary.sqlite | User created auto-correct |
/Library/Accounts/Accounts3.sqlite | Accounts, user information, etc. |
/Library/Databases/CellularUsage.db | SIMs used in device, including most recent |
/Library/TCC/TCC.db | Applications permissions |
/Library/Databases/Datausage.sqlite | Application traces |
/Library/com.apple.itunesstored/itunesstored2.sqlitedb | Application traces |
PList files
PLIST | DESCRIPTION |
/Lockdown/device_values.plist | Activated state, BT address and more |
/Preferences/com.apple.homesharing.plist | iCloud account information |
/Preferences/com.apple.assistant.backedup.plist | Cloud sync settings |
/Preferences/com.apple.coreduetd.plist | sync device |
com.apple.commcenter.plist | Device phone number, Network carrier, ICCIDs and IMSIs |
com.apple.identityservices.idstatuscache.plist | iCloud sync, Email, FaceTime, Email, more |
com.apple.accountsettings.plist | Email accounts pushed to device |
com.apple.Maps.plist | Last latitude and longitude, map search history |
/Library/Maps/Bookmarks.plist | Maps bookmarks |
com.apple.Maps/Maps | History.mapsdata (iOS 7) |
com.apple.Maps/Maps | GeoHistory.mapsdata (iOS 8 – iOS 11) |
com.apple.MobileBluetooth.devices.plist | Synced devices |
CloudConfi gurationDetails.plist | Cloud configurations |
/SystemConfi guration/com.apple.wifi.plist | WiFi |
/SystemConfiguration/preferences.plist | WiFi and more |
/Library/DataAccess/AccountInformation.plist | Email sync data |
/Library/DataAccess/iCloud-[iCloud email account name]/* | iCloud Email account information and offline cache |