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

Source: Apple [1]

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.


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.


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

/Library/CoreDuet/* Device lock state (1=Locked, 0=Unlocked) 
/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/*.db /Library/Caches/*.archiveFrequent Locations 
Cell and WiFi locations 
/Applications/*Examine relevant app directories to obtain additional data 
/Library/BullitenBoard/ClearedSections.plistLogs of cleared notifications 
/Library/Keyboard/UserDictionary.sqliteUser created auto-correct 
/Library/Accounts/Accounts3.sqliteAccounts, user information, etc. 
/Library/Databases/CellularUsage.dbSIMs used in device, including most recent 
/Library/TCC/TCC.dbApplications permissions 
/Library/Databases/Datausage.sqliteApplication traces 
/Library/ traces 

PList files

/Lockdown/device_values.plistActivated state, BT address and more 
/Preferences/ account information 
/Preferences/  Cloud sync settings 
/Preferences/ device phone number, Network carrier, ICCIDs and IMSIs sync, Email, FaceTime, Email, more accounts pushed to device latitude and longitude, map search history 
/Library/Maps/Bookmarks.plistMaps bookmarks (iOS 7) (iOS 8 – iOS 11) devices 
CloudConfi gurationDetails.plistCloud configurations 
/SystemConfi guration/ 
/SystemConfiguration/preferences.plistWiFi and more 
/Library/DataAccess/AccountInformation.plistEmail sync data 
/Library/DataAccess/iCloud-[iCloud email account name]/*iCloud Email account information and offline cache 


  1. HFS Plus Volume Format
  2. SQLite Database
  3. SANS FOR585: Advanced Smartphone Forensics Poster

Related posts

  1. How to sort and organize files recovered by PhotoRec
  2. How many data are shared by iOS and Android telemetry?
  3. Didier Stevens: finding Metasploit & Cobalt Strike URLs
  4. Coding on iPad Pro: my own setup
  5. How to process recent Windows 10 memory dumps in Volatility 2