Forensic Artifact Analysis of the Burner App for the iPhone

In April of this year, I saw a thread on Forensicfocus.com discussing a new smart phone app called “Burner” which lets users purchase disposable phone numbers for short-term use. The application has some very practical uses for online activity – such as selling items on Craigslist – but it also has some obvious implications for anybody performing digital forensics work.

At this moment, none of the commercial mobile device forensics tools I have available to me parsed the data from the burner application. I’m sure that will change if the app continues to grow in popularity.

I recently had an opportunity to install Burner on my iPhone 5 and examine the artifacts left on the phone after I used it. I also wrote a Python script to parse information from the burner.sqlite file and generate a HTML report. I’ve affectionately named the script ‘Oven Mitt’. Burner leaves quite a bit of data intact on the device. Additionally, a lot of what it does cover up can be acquired by other means.

As expected, Burner stores its data in var\mobile\Applications directory on iOS devices. The specific sub-directory will vary from phone to phone, but the easiest way to locate the files is to search for any files with ‘burner’ in the filename. The var\mobile\Application\<varies>\Documents directory contains a SQLite file named Burner.sqlite which contains most of the information we’ll be looking at. The var\mobile\Applications\<varies>\Library\Preferences directory contains a plist file named com.adhoclabs.burner.plist which contains some interesting configuration information, including the number of times the Burner app has been executed. However, this post is focused on examining and parsing the Burner.sqlite file.

The first table in the database worth looking at is the ‘ZBURNER’ table which contains any currently valid Burner numbers. The Z_PK field is the primary key for Burner numbers on the device. When a temporary number expires it is ‘burned’ and removed from this table. A user can also manually burn a number by hitting the burn button and agreeing to the following warning:

One interesting note about this field is that primary keys don’t seem to be reused. Even when there are no entries in the table a recently created number was assigned the Z_PK value of 4 which (correctly) indicated that I had used three previous numbers on that device.

Other fields of interest in this table include:

• ZNUMBER: The temporary phone number associated with this burner entry
• ZFRIENDLYNUMBER: the ZNUMBER field in a more human readable format
• ZABOUT: The user provided nickname for the temporary burner number
• ZCREATED: The date/time the burner number was created
• ZEXPIRES: The date/time the burner number will expire
• ZUPDATED: The date/time the burner number was updated

All timestamps within the database are in UTC and use Mac absolute time which is the number of seconds that have passed between 1/1/2001 and now. The following Python code performs the necessary conversion to a human readable format.

bmd = datetime.datetime(2001,1,1,0,0,0)

realtime = bmd + datetime.timedelta(0,int_dtn) # int_dtn is the timestamp from the database field

The most interesting table in the database is the ZCALLITEM table. The ZCALLITEM table on my phone contains call records and SMS text content from numbers which expired over a month ago but is missing content from numbers which I manually burned earlier this week. It appears as though numbers which burn themselves due to expired time leave their activity history intact in the ZCALLITEM table while numbers which are manually burned remove the content.

Similarly to the ZBURNER table you can discover that content has been removed by looking at the primary key in the Z_PK field. In the picture below you can clearly see that two records are missing. Each of these records were SMS messages sent with a Burner number which I then manually burned.

Noteworthy fields in the ZCALLITEM  table include:

• ZDATE: The date/time of the activity
• ZTYPE: The activity type. Options include sms, outbound_sms, outbound and call
• ZCALLITEMTOINBOUNDNUMBER: Foreign key to the ZINBOUNDNUMBER table. This is the table that stores the phone number that calls or SMS messages were placed to or received from and is obviously a key field.
• ZBODY: For SMS messages this field contains the content from the message. For missed calls where a voicemail is left this field contains a link to the voicemail message. I’ll discuss voicemail more below.
• ZCONNECTED: This field is ‘1’ for sms messages or calls which connected. If a call was missed then this field is a ‘0’
• ZCALLITEMTOBURNER: This field matches activity from this table to the ZBURNER table by primary key. If no entry exists in the ZBURNER table than this field will be blank. You might still be able to associate activity from the ZCALLITEM table to a specific number by pairing data to traditional iOS forensics data.

In the Oven Mitt screenshot below you can see that, according to the Burner.sqlite database, Burner was used to place outgoing calls to a number in the 520 area code on 7/9/2013 at 18:40 and 18:44. The table contains the numbers that were called but not the burner number being used at that time, since the number has been subsequently burned and removed from the ZBURNER table

If an examiner wanted to determine the temporary burner number that was being used at that time, s/he could use a traditional iOS forensics tool to examine the call logs for any records matching up with the timestamps from Burner.

In the below screenshot from a commercial forensics tool, you can see two outgoing calls to a 202 number with timestamps that match the Burner records perfectly. The examiner now knows both the 520 numbers that were called and the temporary 202 that Burner used to place the calls.

Voicemail:

As I mentioned earlier the ZBODY field in the ZCALLITEM table contains a link to audio file with the voicemail for any missed calls where a voicemail was left. A missed call from 7/10/2013 generated a link from twilio.com while a missed call from 7/18/2013 used a link pointing to s3.amazonaws.com. I’m not sure if Burner rotates between various services or switched services this last week. Burner also stores a local version of the audio in the var\mobile\Application\<varies>\ directory.

“Oven Mitt” was written in Python 2.7, uses only native libraries and can be downloaded here. The script is designed to be placed in a directory with the Burner.sqlite file. When it’s run the script will parse the contents of the ZBURNER, ZCALLITEM and ZINBOUNDNUMBER tables and generate a HTML report that shows the burner numbers currently active on the phone and the history from the ZCALLITEM table in a human readable format.

Although, this is far from a conclusive study, I wanted to take a quick look at Burner artifacts on the iPhone and create a script which can help parse the contents. I encourage you to manually verify any results as I only had access to one device to test this on. Also, if there’s any interest I can try to procure an Android device to take a look at the artifacts on that system.

If you have any feedback or questions feel free to shoot me an email using the contact form.