Open Source iPhone Exploits

There are numerous and costly--and closed source--methods for recovery data from the Apple iPhone, iPod Touch, and iPad.  If you are lucky enough to be part of Law Enforcement, then you have free access to Johnathan Zdziarski's tools and methodology (Thank you, Johnathan).  But what to do if you don't have the proprietary tools, or they just don't work on the version of iOS you encounter?

Allow me to introduce the libimobiledevice project.  It is a library that communicates to the aforementioned Apple devices, with the addition of Apple TV devices, but does not use any proprietary libraries, nor does it require jailbreaking to accomplish its goals.    I'll let the description on the project home page take over from here: libimobiledevie "allows other software to easily access the device's filesystem, retrieve information about the device and it's internals, backup/restore the device, manage SpringBoard® icons, manage installed applications, retrieve addressbook/calendars/notes and bookmarks and (using libgpod) synchronize music and video to the device."

That said, it is not designed as a forensics tool.  I may be characterizing it wrongly, but in short, it brings iTunes-like capabilities to Linux.  It does not give full filesystem access to the device, just the media folder and sub folders.  This means you can access the Photos and videos taken with the device, as well as access the music catalog through your file browser.  But be careful--you have read/write access.

Best practice requires that you disable automounting in your system to avoid changing data on the device when  you connect it to your system.  This can be done in a Gnome desktop by using gconf-editor to disable automounting in nautilus ( apps | nautilus | preferences | media_automount [uncheck] ).  It's a good idea to disable media_automount_open and enable media_autorun_never while you're at it.  You won't find your iPhone with fdisk when you connect it, which might leave you wondering just how in the world you're going to mount it?

Libimobiledevice is incorporated into Ubuntu and Linux Mint Debian Edition (my preference) and uses the Gnome Virtual File System (GVFS) for mounting the Media folder of devices in the .gvfs/ folder of your home directory.  But you've disabled automounting, so you need another method that allows read-only mounting.  That's handled with ifuse, but you'll likely have to install it.  With ifuse, the device can be mount read-only in a location you specifiy.  The device is automatically identified unless you choose to identify the device by its UUID (only necessary if you have more than one device connected at a time).  You mount with "ifuse [options] location", such as "iphone -o ro /mnt/analysis".  If you happen to have a jailbroken device, then adding the '--root' parameter will give you full logical access to the user partition on the device.

Mounting with ifuse, on a device that has not been jailbroken, gives access to the same to the device as libimobiledevice through GVFS, only with write protection.  Media files can be useful, as I indicated in an earlier post, but how does an investigator get to the meaty stuff, like SMS messages, call history, and the like?

Well, there are tools that have been built to use the imobiledevice library, aptly called imobiledevice-utils in the Debian package management system.  The utilities consist of the following tools: idevicebackup, ideviceimagemounter, idevicescreenshot, ideviceenterrecovery,  ideviceinfo, idevicesyslog, idevice_id, and idevicepair.  Of particular interest are ideviceinfo, and idevicebackup.

The ideviceinfo tool displays data about the phone itself, including the device name, serial number, OS version, and phone number.  Even locked phones provide useful data, though not as robust as an unlocked phone.  The idevicebackup tool works like iTunes backup.  It creates a device backup in a location specified by the user.  idevicebackup2 is required for iOS 4.3. and above, but can only be obtained by building it from source, which is available through a link on the imobiledevice website.  The backup includes photographs, videos, and databases from the device, including SMS messages, call history, address book, etc!

The files in an iPhone backup are renamed in hex and are referenced in two mbdb databases that index the original name, location and MAC times for the backup files.  The mbdb_parse.py utility can be used to identify the files.  I am working to modify mbdb_parse.py to automate renaming of the files, but the standard output can be used like an ls -lh output.  The limitation of mbdb_parse.py is that it displays user/group values in hex and MAC times in unixepoch time.  I have been able to modify the program to allow me to rename the files into their original names, but the program is not ready for release as yet.

I will cover forensic processing of the backup in a later post.

iPhone Forensics Tools

I've written a couple of articles about my experience with iPhone data ("iPhone Sings like a Jailbird", "Recovering Data from Deleted SQL records", and "Parsing the iPhone SMS Database"), and recently I have been helping others with some iPhone data recovery.  Those experiences have led me to create a few simple iPhone forensics tools.  I'll list them in name order and briefly describe them:

1. iphone_ab
   iphone_ab is a tool to parse the iPhone address book, which is stored in a SQLite file called AddressBook.db.  The tool links two tables to produce a simple output containing first and last name, phone number/email address, record creation date and record modification date.  There is much more data that can be mined from the database, but this is the basic data that interest most investigators.
   
   
2. iphone_ch
   iphone_ch is a tool to parse the iPhone call history, which is stored in a SQLite file called call_history.db.  The tool reads the 'call' table and reports the date, call type, phone number, and call duration of each record.  Unixepoch time is converted to local time and call flags are interpreted (Incoming, Outgoing, etc.).
   
   
3. iphone_cs
   iphone_cs is a tool to parse the iPhone consolidated.db, which is a SQLite file that stores gps data used by apps.  Experimentation shows that one table in particular, the CellLocationLocal table, records the location of the iPhone handset when it runs apps that use location data.  Don't think location data is restricted to mapping apps--I have seen dictionary apps that ask to use your location.  Now, why is that?  In a word: advertising.  iphone_cs will parse the CellLocation, CellLocationLocal, and WifiLocation tables for GPS data and allow the data to be formatted for mapping tools like gpsbabel or websites like GPSVisualizer.com.
   
   
4. iphone_images
   iphone_images is a tool that will search a path for images and videos (identified by mime type) and provide the EXIF data by use of the excellent exiftool.  Alternatively, files containing GPS data can be parsed to export data suitable for mapping.  Finally, videos purchased through the Apple Store can be sifted for the Apple Store user name and real name of the purchaser.
   
   
5. iphone_music
   iphone_music is a tool that will search a path for audio files, particularly those in the 'iTunes Control/' folder (though not restricted to these files).  iTunes uses random filenames for music it transfers to an iPhone or iPod.  The tool, at its most basic level, reveals the song name, album, and artist to help owners identify their device by its content (think recovered stolen device).  The tool can also produce rich metadata, again, thanks to exiftool, as well as single out those songs purchased through the Apple Store and report Apple Store credentials like iphone_images.
   
   
6. iphone_sms
   iphone_sms is a tool to parse the iPhone SMS database, located in a file called sms.db.  The tool reads the message table and reports the date, message type (sent, received, etc.), phone number, and text message in each record.  Unixepoch time is converted to local time and message flags are interpreted (Sent SMS/MMS, Received MMS , etc.).

All of the tools, written for BASH, attempt to follow the Unix principal of make one tool to do one thing and do it well.  They each have a variety of options that can be read by invoking help, e.g., 'iphone_sms -h'.  The database tools do not find the target database for you, since your iPhone data may come from a variety of sources (iPhone images, backups, etc.).  Output for all files is to stdout (the screen) but may be redirected to a file.  For example, to redirect the mapping data from iphone images and videos, the command 'iphone_images -m /private/var/mobile/Media > images_gps.txt' could be used.

I hope you have success with the tools.  Please contact me with any errors you detect and/or feature suggestions you might have.  I am already contemplating an "export" function to, for example, export the images to a directory that were the source of the GPS data the mapping output from iphone_images.

You can download iphone_tools here.

iPhone songs sing like a jail bird!

I received an iPhone yesterday that was suspected to be stolen.  Proving the suspicion was another matter.  The was found to have data (photos, mostly) only related to the suspected thief, but the investigator noted that the phones statistics had been reset and suspected the original owners data was deleted.  He brought me the phone for examination to prove his hunch.  The phone was not reported stolen anywhere that we could find.

My first thought was the SIM card.  Problem was, the phone had no service, and the SIM card only revealed the assigned phone number and carrier.  While that might lead to the owner, it would be a while after the drafting and execution of a search warrant.  In fact, it could have been weeks before that got us anywhere.

I obtained some basic phone data with the libimobiledevice-utils package.  I quickly learned that the iPhone 3G was running the 4.3.1 iOS.  I also quickly discovered that the libimobiledevice package (v1.04) in Debian Testing was not going to help me too much because of a bug.  Luckily, it was a known bug, and compiling the latestest stable package (v1.06 at this writing) from libimobiledevice.org fixed me right up.

The iPhone tools I use are not yet equipped to obtain the user partition of iOS 4.3 or higher.  They cannot image unallocated space in iOS 4 in any event.  I have successfully used idevicebackup (one of the libimobiledevice-utils) to backup and iphone and exam the sms, contacts, and other databases, but I could not successfully complete this task because the iPhone refused the backup request (I later did this in Windows with iTunes, however).

So, there I was without full user partition access, no means to recover deleted files, and that was suspected, and no backup of application databases that might lead to owner identification.  I could see photos, and music, and nothing more when I mounted the phone with ifuse.  The photos had already been ruled out as a possible source of original owner information.  That left the music.

I knew from previous research that songs and videos purchased through iTunes contain the real name and iTunes username of the purchaser.  The username is most often the user's email address, in my experience.  The data is stored in the 'name' and 'apID' atoms of the mpeg-4 format.  You can learn more about atoms and the format specifications at the AtomicParsley website.

I used the find command to locate the .m4p (music) and .m4v (video) files that are indicative of media purchased through iTunes.  Of the more that 3k of music files, I found about 50 that were .m4p format and contained three different but related usernames (same last name).  Not surprisingly, the names did not match the suspected thief.  Each username had an associated email address, but a I was able to cross reference the names with other records and find a burglary victim.

So, while we are used to the performing artists singing their songs, forensic computer examiners need to keep in mind that iTunes songs sing themselves, providing purchaser real name and username/email address!

More NSRL Talk

I've spent a bit more time study the NSRL problem.  It is a fantastic but unwieldy database of hash values that is under utilized (at least in my experience).  I spoke in my last post about importing the NSRL database into SQLite so the data can be better managed.  I added at the end of the post that I had created a pair of shell scripts, 'getnsrl' and 'mknsrl' to automate SQLite creation.

I am happy to report that I have extended mknsrl to fully handle the NSRL database.  My first version only imported the file table which contains the hash values.  I thought, incorrectly, that this would be sufficient for generating has sets.  I had not fully understood the NSRL Reference Data Set (RDS) construction, which actually consists of five CSV files:

• NSRLFile.txt
• NSRLMfg.txt
• NSRLOS.txt
• NSRLProd.txt
• version.txt

The NSRLFile.txt is broken into four parts that need to be concatenated together.  Currently, this database contains over 62 million lines, far exceeding the capabilities of the spreadsheet programs for which it is formatted.  The database consists of 'known' files, not be confused with 'known good' files.  The database contains hash values for well know hacker programs, for example, and eliminating them through hashing may be problematic to the investigation.  There needed to be a way to export specific hash sets from the RDS for the data to be truly useful.

getnsrl

I wrote getnsrl to make processing the four iso files containing the NSRL RDS easy.  The files must be mounted, and the database files extracted from a zip file.  getnsrl does this automatically, appending the names of the NSRLFile.txt CSV files to distinguish them and prevent overwriting.  On my system, this takes about four minutes.  The user need only put the iso files in a common directory (not required, but easier on the fingers) and issue 'getnsrl RDS*'.  The tool provides feedback and start/stop times.

mknsrl


I wrote mknsrl to allow for easy importation of the CSV files to a standalone SQLite database.  It creates virtual tables from the CSV files and then imports them into regular tables.  The NSRLFile.txt files are not (and should not be) concatenated before processing as this is done by mknsrl while inserting the data into the database.  Though importing the files to a standard table is not required to use the CSV files with SQLite, I favored this approach because the database can be used independently of the CSV files.  I just found it simpler to manage, and it has the added benefit of indexing if the user so chooses, since indexing virtual tables is not possible with SQLite.  mknsrl reports its progress, start/stop times, and some database statistics.  It no longer does any indexing (as in the first version).  I leave that to the user to decide what to index if indexing is desired.  On my system, it took about 12 minutes to import the NSRL RDS data.  The statistical analysis can be commented out to save a few minutes, if desired.

Why use mknsrl?

The chief advantage of mknsrl is database control.  Hash sets can be produced of any product in the database, which is not easy to do with the traditional methods for handling the RDS data.  NSRL has recommended that the four NSRLFile.txt be concatenated and then reduced to uniq hash values, leaving about 18 million records.  The problem is, you can't reliably know the source of the file this way, and you may hash out a program file of interest.

mknsrl allows any hash set or group of hash sets to be extracted from the database with a sqlite query in the following form:

$ sqlite3 -csv -header nsrl.db "select * from file where [expression];"

I used the following expression to create a hash set of all "Windows" operating systems in about 5 minutes (note the nested SELECT statement that makes this possible):

$ sqlite3 -csv -header nsrl.db "select * from file where opsystemcode in (select opsystemcode from os where opsystemname like '%Windows%'"

Your ability to create hash sets is limited only by your ability to craft SQLite queries.

If you would like to look at or use 'getnsrl' or 'mknsrl', you can find them at https://sites.google.com/site/slosleuth/.

Taming the NSRL Hash DB Beast

Background

I've been trying to extend Sleuthkit in a variety of ways, such as by adding a table to the Sleuthit databese to capture file/mime types and improve strings extraction over that of the traditional 'blkls | strings > file' variety.  I came to the realization that elimination of files through hashing could speed these processes.  This is not a new concept to me or anyone else in data forensics, but I do believe hash elimination is under used.  I think this is due in large part to the unwieldy size of the National Software Reference Library (NSRL) hash database.

The Problem

As of January 2011, The NSRL data is distributed in 4 .iso files and contains a whopping  62,294,036 file entries.  The NSRL tries to help you manage the data volume by directing you to concatenate the NRSLFile.txt files (each containing over 4.7 million rows) found in each .iso and then export only rows with unique hash values.  Such an action reduces the total number of rows to a paltry 18,840,521. However, the unique operation (easily performed with 'uniq' on the command line) hampers the ability of knowing the application or operating system from which the file came.

Size is not the only difficulty, however.  After all, in most cases, large size just means longer processing time.  But the CSV format of the database is a major obstacle.  The field separator used in the database is the comma (',').  But, many of the filenames listed in the db contain commas, and while, text fields are quoted, numeric fields are not.  These conditions are not an obstacle for spread sheets, but keep in mind that OpenOffice Calc can handle only 1,000,000 rows.  And, these conditions make it difficult to work with traditional command line text tools like 'cut', 'sed', and 'awk'.

Ideally, it would be best to have the NSRL db in a database like SQLite, where hash sets could be created based on products and operating systems.  In this way, one could easily export a hash set for Windows XP if that was the type of system being investigated.  However, SQLite splits on all field separators it encounters regardless of what comes before them (meaning they cannot be escaped).  Therefore, trying to import the NSRLFile.txt data fails because there are filenames with commas in them.

The Solution

I am happy to report that there is a solution to the problem with SQLite, however.  A CSV module has been written to overcome this difficulty.  It allows SQLite to query a CSV file directly Using the module is not immediately apparent, so I document the process here:

1. Decompress the csvfile.zip containing the module source code.
2. Change to the csvfile/ directory and issue the 'make' command.  If you get an error, it is probably because you don't have the SQLite headers installed (libsqlite3-dev package in Debian/Ubuntu).
3. Copy the resulting virtcsv.so module to somewhere common, like /usr/local/lib because you will need to load the module each time you query the database you create.
4. Create a new database with 'sqlite3 nrsl.db'.
5. Load the CSV module at the SQLite prompt with '.load /usr/local/lib/virtcsv.so'
6. Create a virtual table to connect to the NSRLFile.txt at the SQLite prompt with 'CREATE VIRTUAL TABLE hashes USING CSVFILE(NSRLFile.txt, CP1252, ',', '"');' where:
• hashes is the table name you are creating
• NSRLFile.txt is the CSV file you are attaching
• CP1252 is the code page Windows Latin 1 (default)
• , (comma) is the field separator in the CSV file (default is ';' [semicolon])
• " (double quote) is the string delimiter (default)
7. View a sample of the data with 'select * from hashes limit 10;'

The process above shows the process for importing one file.  The fact of the matter is, that if you concatenate the four NSRLFile.txt files provided by the NSRL, the file is too large for SQLite to handle.  The files need to be imported to individual tables and queried together to produce hash sets.  Further, Indexes should be created to speed queries (Edit: SQLite will not allow virtual tables to be indexed, so the data must be imported to regular table.  I have written a script to automate this, see below.).  I won't go into those process here, but a good online tutorial for using SQL can be found at W3Schools.  Keep in mind that SQL (shown at W3Schools) and SQLite have some differences, but there are few inconsistencies for basic database query.

Edit:  I've written two scripts to automate the process.  The first, 'getnsrl', will mount the four RDS .iso files and extract/rename the NSRLFile.txt csv files to ready them for processing.  The second, 'mknsrl', will create virtual tables from each csv file and import them into a 'hashes' table.  It will also index the table based on the operating system the files come from to speed searches and hash table exports.

"Tracking" Down Credit Card Dumps

I have been examining numerous computers and media cards to support fraud investigations in the past year.  One group of thieves has been installing skimmers (devices that record magnetic stripe data) in the magnetic stripe readers on doors of certain banking institutions that limit access to their ATMs after hours.  Then the thieves install micro video cameras in the light fixtures of the ATMs to capture the users' pin codes.  The thieves later match the recorded pin code to the skimmed account number at the door, encode new cards, and pillage bank accounts by getting cash at another ATM location.

It is not difficult to find the ATM videos on the media cards from the cameras or on the computer hard drives.  The credit card/ATM card numbers can be bit tougher, however.  Searching for 16 digit numbers in a Windows computer will yield a huge volume of false hits.  And, if the operation has been running for a while, many of the account numbers will be deleted.   Searching unallocated space is necessary to be thorough and to ensure your suspects' get the full reward of their illicit activities.

All of the skimmers I have encountered are serial devices that communicate with software made for Windows-based computers by means of a USB-to-serial cable.  The cables do not look dramatically different than a standard USB cable, but they contain a chip that bridges the two protocols.  In a Windows computer, a USB driver for the cable must be installed before the program can communicate with the device.

The applications that communicate with the skimmer devices write the data to disk differently--some create a database while others use text files.  In my experience, both formats contain the complete track 1 and/or track 2 data.  Magnetic stripes contain three tracks, the first two in common use and encoded with particular standards.

Track 1 (IATA)

Track 1, known as "International Air Transport Association" format, has alphanumeric data.  It takes on the following format (from wikipedia):

Track 1, Format B:

• Start sentinel — one character (generally '%')
• Format code="B" — one character (alpha only)
• Primary account number (PAN) — up to 19 characters. Usually, but not always, matches the credit card number printed on the front of the card.
• Field Separator — one character (generally '^')
• Name — two to 26 characters
• Field Separator — one character (generally '^')
• Expiration date — four characters in the form YYMM.
• Service code — three characters
• Discretionary data — may include Pin Verification Key Indicator (PVKI, 1 character), PIN Verification Value (PVV, 4 characters), Card Verification Value or Card Verification Code (CVV or CVK, 3 characters)
• End sentinel — one character (generally '?')
• Longitudinal redundancy check (LRC) — it is one character and a validity character calculated from other data on the track. Most reader devices do not return this value when the card is swiped to the presentation layer, and use it only to verify the input internally to the reader.

Targeting track 1 data in a grep search is very simple:

$ grep -E ^'%.[0-9]{16,19}\^' file

Track 2 (ABA)

Track 2, known as the "American Banking Association" format, contains only numeric data.  It takes on the following format (from wikipedia):

Track 2: This format was developed by the banking industry (ABA). This track is written with a 5-bit scheme (4 data bits + 1 parity), which allows for sixteen possible characters, which are the numbers 0-9, plus the six characters  : ; < = > ? . The selection of six punctuation symbols may seem odd, but in fact the sixteen codes simply map to the ASCII range 0x30 through 0x3f, which defines ten digit characters plus those six symbols. The data format is as follows:

• Start sentinel — one character (generally ';')
• Primary account number (PAN) — up to 19 characters. Usually, but not always, matches the credit card number printed on the front of the card.
• Separator — one char (generally '=')
• Expiration date — four characters in the form YYMM.
• Service code — three digits. The first digit specifies the interchange rules, the second specifies authorisation processing and the third specifies the range of services
• Discretionary data — as in track one
• End sentinel — one character (generally '?')
• Longitudinal redundancy check (LRC) — it is one character and a validity character calculated from other data on the track. Most reader devices do not return this value when the card is swiped to the presentation layer, and use it only to verify the input internally to the reader.

Targeting track 2 data in a grep search is also straight forward, though a reading of the above standard suggests the following search can miss.  I haven't seen any different start sentinels or separators than those in the expression:

$ grep -E ^';[0-9]{16,19}=' file

Though the preceding search has worked for me, the specifications for track 2 allow for other start sentinels and field separators.  A better but slower search would be:

$ grep -e ^'[:;<=>?][0-9]{16,19}[:;<=>?]'

Tracking Down Both Tracks at Once

I composed the following search to track down both tracks, and display the date and time of the swipe typically captured by the skimmer device.  The "-B1" argument shows one line of data before the hit, which is where the date and time are recorded.

$ grep -E -B1 ^'%.[0-9]{16,19}\^|;[0-9]{16,19}=' file

You may have noticed the caret ("^") preceding the single quoted search in each of the grep expressions.  It requires the expression to be matched at the beginning of a line of data.  This is a search optimization.  I will now demonstrate two additional optimizations, one for searching allocated files, and the other for unallocated space (using the the sleuthkit tool "blkls"):

Searching mounted file systems (find files, export 7-bit strings, grep for track data):
$ find . -type f | while read i; do strings "$i" |  grep -E -B1 -H --label="$i" ^'%.[0-9]{16,19}\^|;[0-9]{16,19}='; done

Searching unallocated space of a forensic image (export unallocated, filter out 7-bit strings showing offset, grep for track data)
$ blkls -o63 image.dd | strings -td  |  grep -E -B1 ^'%.[0-9]{16,19}\^|;[0-9]{16,19}='

Difficult Disk Imaging

In the past few weeks, I've had the opportunity to make forensic disk images of what one might call "non-standard" devices.  The devices were a Lenovo Thinkstation D20, an Acer Netbook, and an MacBook Air.

Lenovo Thinkstation

The Lenovo presented a few problems.  First, it was seized and disassembled by non-computer-forensics professionals.  Translated: the drives were removed and not marked as to their bays or cabling.  Two drives were identical in size and the third was over three times larger.  All were were SAS (Serial Attached SCSI) drives which have non-standard connectors.  I had no connectors to remove the drives and image them individually (though cannibalization from the Lenovo was possible), and the computer specs suggested that there was a raid array on the two drives of matching size.

What did I do?  I decided to use CAINE, a forensic boot disc, and an external hard drive.  CAINE would allow me to use the Lenovo for the specialized connectors needed for the SAS drives, and allow the hardware controller on the motherboard to reassemble RAID array.

The first step was to ensure I could boot the system with CAINE.  I was unable to boot from CD-ROM using the Lenovo's optical drive (which was unusual, to be sure) but I was able to get a USB version of CAINE booted.  I ensured, by adjusting the BIOS, that the USB would be the first device to boot.

I reinstalled and connect the drives, uncertain as to proper order, and booted CAINE.  Lucky for me, the on-board RAID controller detected the disks, reported there have been a change in the devices (the drive order), and then correctly reassembled the array.  CAINE reported two drives (the large disk, with the OS as it turns out), and the array.  I imaged both to the external drive with Guymager, a graphical front end for libewf, an open sourced disk imaging library and toolset that produces images in expert witness format.

Acer Netbook

The Acer Netbook was probably the least troublesome device, but did not lend itself well to disassembly.  Drive removal and hardware write-blocking are the ideals in forensic disk imaging.  However, this isn't always possible or convenient.  In the case of the Acer Netbook D255, there was no simple hard disk cover to remove.  Hard disk access appears to involve keyboard removal and an underlying cover, or seven case screws and an almost surgical separation of plastic catches.  Simply put, I didn't want to break the netbook, and I know that some storage devices have ROM chips that prevent them from being read when disconnected from the particular motherboard anyway.

Again, CAINE to the rescue.  In the case of the ACER, there was no boot menu.  Changes to the BIOS were needed to ensure the USB device booted before the internal hard disk.  I tried to boot CAINE with an attached USB optical drive and with a USB version of CAINE.  The ACER did not register the USB optical drive in the BIOS, but the USB flash drive with CAINE was detected.  I booted from the USB, mounted a external hard drive, and imaged the drive with libewf.

MacBook Air

This was my first encounter with the MacBook Air.  Like the Acer, the construction of the device discouraged disassembly.  I know that the Macs won't boot from a FAT formatted USB because of the EFI boot schema.  However, booting from CD-ROM is possible by pressing and holding the "C" key immediately after powering the computer.

I attached a USB CD-ROM drive because the AIR does not have an optical drive like other MacBooks.  I initially booted with CAINE, but the graphics drivers were incompatible with the Mac.  I attempted a graphics safe-mode boot and a text-only boot, but the same result: a garbled display that made proceeding impossible.

I obtained a second forensic boot disk called DEFT.  It is a newer release than CAINE and I hoped it had updated graphics drivers that might overcome the problem.  The initial boot froze the system.  DEFT boots into text mode, and there are no other menu choices.  However, a series boot options at the bottom of the boot screen reminded me of some boot issues I have experienced in that past several versions of Ubuntu, on which both these forensics distributions are based.  I passed the "nomodeset" option in the F6 menu (curiously named "Password"),  and DEFT booted to a text screen.  I was also able to boot to a GUI with the deft-gui command.

With this in mind, I revisited CAINE.  I have a preference for CAINE because I understand how it works and it's implementation of write-blocking and have tested it.  The CAINE developer, Nanni Bassetti, is ever-ready to help new users and explain his techniques.  I do not know how DEFT works and the information is not readily available, at least not in English.  This is not to disparage DEFT in anyway.  I'm just trying to highlight the fact that we must use tools that we understand and have tested.

I again booted the MacBook Air with Caine.  At the boot screen, there is no obvious way to pass boot options.  However, pressing escape brings up a boot command line.  Pressing tab displays the boot options on the original boot screen.  I passed the arguments "textonly nomodeset" and CAINE successfully booted to a console.  At the console, I was able to start the GUI with "startx".  I accomplished imaging as before, with libewf and an external USB hard disk drive.