A coworker brought me an SD card today because she could not delete any files from it. I noticed the lock switch was missing from the card, and after inserting the card into a portable reader, I confirmed the card was write protected. This got me curious: just how does the switch on an SD card work? I've relied on it for write protecting evidence, but I didn't really know how reliable the switch was.
With great gusto, I snapped the card in half to examine its contents. I did it with as much joy of discovery as a young boy has when first focusing the suns rays on ants with a magnifying glass. What I found inside surprised me: a very simple chip occupying about 1/3 of the card housing. I determined--by examining similar cards--that the switch did not bridge any electrical contacts on the chip, so write protection was not a function on the card itself.
I turned my attention to several card readers I have lying about. One has a very shallow card well, which makes visualizing the electrical contacts quite easy. I noted that on the side of the reader, in a location corresponding to the switch on an SD card, there was a spring-loaded pin. Through experimentation, I determined that the pin, when depressed, allows data to be written to the card. When the pin is extended, write-blocking occurs. The position of the "lock" switch on the card determines the position of the pin.
Thus, (and to my surprise) write blocking is a really function of the reader, not the card. It is possible for a reader to be constructed or damaged such that the lock switch has no effect! Frequent inspection and testing of a card reader used for forensic analysis is warranted.
Lesson: know your equipment!
Monday, June 13, 2011
Friday, June 3, 2011
Defeating the Droid: Let the Pillaging Begin
In my last post, Defeating the Droid, I explained how to root an Android phone, at least through version 2.2. Like other mobile devices, Android is a moving target and what works on one phone or one OS version may not work on the next. We left off with a running adb shell with root privileges. But how do we get the data we seek.
Bringing Up the Past
I mentioned previously that the adb shell is an ASH shell without auto-completion, inline editing, or command history. In other words, this car is a base model without all the bells and whistles with which you might be accustomed. Add to that a limited set of binary tools (no copy, tar, or find commands, for example) and its a bit like standing at the base of a cliff without any climbing tools.
Plan of Attack
We need tools, and we need them bad. But we don't want to change any more data on the phone than necessary. So, what to do?
Android phones use SD cards to store user media, like photos and music. This card should be removed and imaged, following standard forensic imaging protocols, as part of your examination. While the card can be imaged from within the phone, the interface is slow (took 45 minutes to image 16gb) and requires that the phone be placed in USB mass storage mode for the workstation to see it. A locked phone may make this impossible.
Significantly, removing the card allows us to replace it with one of our own containing tools for accessing data in the phone's internal memory. You can get by quite handily with one small tool: busybox.
You can copy busybox to the card before inserting it in the phone, but its not a necessity. You can also use the Android Debug Bridge (adb) utility to copy busybox to an installed card using the command:
The size of our SD card can very, depending on the amount of physical memory found in the phone. This can be quite small, as in the case of the original Motorola Droid which has only 256mb of internal storage. However newer devices, like the Droid 2, have significantly more memory with 8gb of internal storage capacity.
Sequential Processing: Starting with "dd"
I'm experienced in fingerprint development as well as computer forensics. In fingerprint processing, there is a phenomenon known as "Sequential Processing." Sequential processing simply means to do processing in such an order so that the first step does not inhibit the second step, and so on. We actually do this every day in computer forensics: we image a device before before we conduct an examination, and we use the image for the examination so as to not harm the original evidence.
It is my opinion that we should do physical imaging of the device before logical. The device we are working on has a running operating system and files are changing and being created and deleted as part of the normal process of the phone. Further, a physical image means we can recover deleted files, so we want the physical images before we do anything that could overwrite data. "dd" is the tool of choice here, and it can be deployed quickly (it is part of the resident operating system) and there is no set up involved, i.e., remounting of partitions.
So, to make the busybox on the SD card executable, we need to remount the card with the ability to execute binary files.
Bringing Up the Past
I mentioned previously that the adb shell is an ASH shell without auto-completion, inline editing, or command history. In other words, this car is a base model without all the bells and whistles with which you might be accustomed. Add to that a limited set of binary tools (no copy, tar, or find commands, for example) and its a bit like standing at the base of a cliff without any climbing tools.
Plan of Attack
We need tools, and we need them bad. But we don't want to change any more data on the phone than necessary. So, what to do?
Android phones use SD cards to store user media, like photos and music. This card should be removed and imaged, following standard forensic imaging protocols, as part of your examination. While the card can be imaged from within the phone, the interface is slow (took 45 minutes to image 16gb) and requires that the phone be placed in USB mass storage mode for the workstation to see it. A locked phone may make this impossible.
Significantly, removing the card allows us to replace it with one of our own containing tools for accessing data in the phone's internal memory. You can get by quite handily with one small tool: busybox.
You can copy busybox to the card before inserting it in the phone, but its not a necessity. You can also use the Android Debug Bridge (adb) utility to copy busybox to an installed card using the command:
# adb push busybox /sdcardFinally, the card you use should have enough space to capture the full internal memory of the phone. The adb shell allows us to copy files within the device, but not to our workstations. So, we must copy files to the SD card.
The size of our SD card can very, depending on the amount of physical memory found in the phone. This can be quite small, as in the case of the original Motorola Droid which has only 256mb of internal storage. However newer devices, like the Droid 2, have significantly more memory with 8gb of internal storage capacity.
Sequential Processing: Starting with "dd"
I'm experienced in fingerprint development as well as computer forensics. In fingerprint processing, there is a phenomenon known as "Sequential Processing." Sequential processing simply means to do processing in such an order so that the first step does not inhibit the second step, and so on. We actually do this every day in computer forensics: we image a device before before we conduct an examination, and we use the image for the examination so as to not harm the original evidence.
It is my opinion that we should do physical imaging of the device before logical. The device we are working on has a running operating system and files are changing and being created and deleted as part of the normal process of the phone. Further, a physical image means we can recover deleted files, so we want the physical images before we do anything that could overwrite data. "dd" is the tool of choice here, and it can be deployed quickly (it is part of the resident operating system) and there is no set up involved, i.e., remounting of partitions.
- Root the device. See my previous post if you don't know what I'm talking about.
- Start the adb shell if its not already running. Look for the telltale root prompt to be sure you have "rooted" the device.
# adb shell
# <-- adb shell prompt
- Determine the devices you want to image. In Android, the devices are called mtdblock devices, and are listed in /proc/mtd.
# cat /proc/mtd
dev: size erasesize name
mtd0: 00180000 00020000 "pds"
mtd1: 00060000 00020000 "misc"
mtd2: 00380000 00020000 "boot"
mtd3: 00480000 00020000 "recovery"
mtd4: 08c60000 00020000 "system"
mtd5: 05ca0000 00020000 "cache"
mtd6: 105c0000 00020000 "userdata"
mtd7: 00200000 00020000 "kpanic"
- Ideally, we want to image everything. But of particular interest are the "cache" and "userdata" block devices. The size of each device is listed in hexadecimal code. In the above case, the "cache" device is 97124352 bytes [echo $((0x5ca0000))], and the "userdata" device is 274464768 bytes [echo $((0x105c0000))]. We need to know how the devices are addressed:
# mount
rootfs / rootfs ro,relatime 0 0
...
/dev/block/mtdblock4 /system yaffs2 ro,relatime 0 0
/dev/block/mtdblock6 /data yaffs2 rw,nosuid,nodev,relatime 0 0
/dev/block/mtdblock5 /cache yaffs2 rw,nosuid,nodev,relatime 0 0
/dev/block/mtdblock0 /config yaffs2 ro,relatime 0 0
...
- We see that the "cache" mtdblock device is addressed as /dev/block/mtdblock5 and "userdata" as /dev/block/mtdblock6. We can make a dd image of each as follows:
# dd if=/dev/block/mtdblock5 of=/mnt/sdcard/cache.dd
189696+0 records in
189696+0 records out
97124352 bytes transferred in 24.001 secs (4046679 bytes/sec)
# dd if=/dev/block/mtdblock6 of=/sdcard/data.dd
/dev/block/mtdblock6: read error: I/O error
83808+0 records in
83808+0 records out
42909696 bytes transferred in 8.653 secs (4958938 bytes/sec)
Uh, oh, an error. Normally, we overcome dd errors by adding the "conv=noerror" argument, which tells dd to continue on read error. But the Android dd does not support that option. So, what do we do in such a circumstance? Give up? Hardly!
Phase Two: Busybox
Busybox can be described as "the swiss army knife of embedded Linux." It is a single executable file, about 1mb in size, containing many common Unix utilities, including cp, find, tar, and yes, dd! In order to use it, we need a version compiled for Android, but I will not discuss how to compile here. It is readily available on the Web and in Android Root kits, but I'd recommend compiling a trusted version if you can. One things certain, you cannot use the busybox binary from your workstation.
There's a catch to using busybox. We want to place it on our SD card so we don't change anything on the phone's internal memory, but busybox cannot be run from the SD card. "Why?" you ask. I'll show you:
# mount
...
/dev/block/vold/179:1 /mnt/sdcard vfat rw,dirsync,nosuid,nodev,noexec,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
So, to make the busybox on the SD card executable, we need to remount the card with the ability to execute binary files.
- If busybox was not already on your card, push it to the card from a terminal on your workstation.
# adb push busybox /mnt/sdcard
1255 KB/s (1745016 bytes in 1.356s)
- Remount your card with executable permission.
# adb shell
# mount -o remount,rw /mnt/sdcard /mnt/sdcard
# mount
/dev/block/vold/179:1 /mnt/sdcard vfat rw,dirsync,relatime,uid=1000,gid=1015,fmask=0702,dmask=0702,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=remount-ro 0 0
- Change directories to the SD card and optionally start a busybox shell. By starting a busybox shell, we attain inline editting and a shell history. In other words, entering commands becomes easier.
# cd /mnt/sdcard
# ./busybox sh
- Now we can dd that damaged "userdata" mdtblock again, this time passing conv=noerror because we will use the busybox dd. Note: because busybox is not installed on the system or in the path, we have to prepend busybox utilities with ./busybox
. To see a list of available busybox tools, issue "./busybox" alone.
# ./busybox dd if=/dev/block/mtdblock6 of=/mnt/sdcard/data.dd conv=noerror
- With busybox, we can also create archives of the logical files on the device. Again, to simplify the discussion, we'll focus on the /cache and /data directories where we saw the respective mtdblock devices were mounted. Why should we archive the logical files when we have physical images made with dd? Because the file systems in the images are "yaffs" and present special problems I won't discuss here. It is enough to say, for now, that your workstation likely doesn't support yaffs by default and you cannot mount and examine the images you created. They are only useful file carving.
Therefore, we'll use tar to make archives of the /cache and /data directories.
# ./busybox tar czvf cache.tar.gz /cache
tar: removing leading '/' from member names
cache/
cache/downloadfile-30.jpeg
cache/downloadfile-15.jpeg
...
cache/app/I-Status_Monitor.apk
# ./busybox tar czvf data.tar.gz /data
tar: removing leading '/' from member names
data/
data/tombstones/
data/tombstones/tombstone_05
data/tombstones/tombstone_00
...
data/lost+found/
Wrapping Things Up
When you've acquired the images/files that you seek, you need to get the data from the SD card to your workstation. The easiest way is to turn off the phone and remove the card, the read it directly. But you can pull the files from the card with adb, too. You might want to do this if you need the data quickly, or to free up space on a smaller card for more images/archives. To pull the files from the card to your workstation:
- Use "adb pull" to move files from the SD installed in the phone to your workstation. The command is run in a terminal on your workstation, NOT in the adb shell. You can exit adb shell or open a new terminal window if you want to remain in the adb shell environment.
# exit <-- exits the busybox shell
# exit <-- exits the adb shell to your terminal
# adb pull /mnt/sdcard/cache.tar.gz /some/evidence/directory/
# adb pull /mnt/sdcard/cache.dd /some/evidence/directory/
...
- When you are done pulling all the files you plan to transfer, remove the exploit from the install directory.
# adb shell rm /data/local/tmp/ratc.bin
Note: I chose this method of removing the exploit to demonstrate that the adb shell command can pass arguments to the adbd daemon on the phone without dropping into the shell. I hope to use this ability to script the process we've been discussing.
- Reboot the phone to kill the exploit and the phone is back in its pre-exam condition.
I'll leave the examination of the data you've recovered to you for now. Maybe in a future post, I'll highlight some key files and how to process them (hint: mmssms.db contains text messaging, and cache.cell contains GPS data).
Defeating the Droid
I received a Motorola Droid 2 for analysis. Processing the 16gb SD card was trivial as it is removable and subject to traditional imaging techniques. But what of the internal phone memory? After a lot of researching, I found there just wasn't a lot of information out there for forensic examiners. I settled on a procedure called "rooting" which I'll document here.
Caveat 1: I wouldn't call this a "forensically sound" approach, per se, in that it makes changes to the phone. But I wouldn't say this leads to automatic disqualification of the evidence, either. The technique was a necessary approach under the circumstance of current technology to meet the needs of my investigation. The techniques and their impacts on the evidence can be explained and therefore may be admissible. Your mileage may vary.
Caveat 2: The "rooting" process I describe here borrows from common techniques found on the Web that were developed by users of Android phones to gain full access to their devices. But, the process described here differs significantly. Do not follow the user-oriented tutorials for rooting devices as they require you to install files unnecessary to forensics and make significant changes to the device, sometimes erasing user data!
Preparing the Phone
Luckily, the phone I received was unlocked. I accessed the settings, disabled wireless networking, and placed the device in airplane mode to minimize changes and prevent remote access. I also disabled the password and automatic screen locking, and I determined the OS version (v2.2.2) through "Settings | About Phone", in this case 2.2.2. Two other settings are required: set the device to enter USB debugging mode when connected by USB and set it to stay awake while charging through "Settings | Applications | Development."
I have since learned that the technique I describe below will work on locked Andriod phones that have USB debugging enabled. Working with another investigator, we rooted a locked Virgin Mobile LG Optimus and a locked HTC Incredible.
Preparing the Workstation
I downloaded and installed the Android SDK which includes the very useful Android Debug Bridge (adb) utility. Installation of the Linux version involves extracting the compressed archive (tar) and copying to a directory of your choice. In my case, I chose '/usr/local'.
With the SDK installed and the device connected by USB cable, the command 'adb devices', run as root, will start the adb server and show the serial number of a USB-attached Android device. If the serial number is represented by a series of question marks, kill the sever with 'adb kill-server' and restart with 'adb root'. The Android version and phone model influence whether or not you can start the adbd daemon as root. I recommend attaching only one device at a time so that subsequent commands need not specify the device on which to operate. Use 'adb help' to list all possible commands and a brief description of their use.
Default ADB Shell Access
There is limited access to the device file system by dropping into the adb shell with the command 'adb shell'. This is true even if you are root when you start the adb server and if you start the adbd daemon with 'adb root'. You'll note that you have the standard '$' user prompt. In other words, when you launch the adb shell, you are dropped into in a shell console on the running phone with standard user privileges.
The adb shell is an ASH shell with limited binary tool availability. For example, there are no copy or find commands. There is no inline command editing or shell history. Your limited privileges prevent you from accessing the /data and /cache directories which contain the bulk of the user data you are likely seeking. Other available adb commands (not part of adb shell), can be used to recursively copy files from the device to your local system (adb pull) or place local files into the Android file system (adb push), but your limited privileges still impede you.
Escalating Permissions with Rageagainstthecage
The solution is to "root" the device. Rooting, in this case, means to escalate your privileges in the adb shell to super-user status. I could not find a rooting method that prevented any changes to the phone's file system (the exploit has to be loaded into a partition on the phone), but I settled on the small 5k 'rageagainstthecage' exploit, which is an adb setuid exhaustion attack. In a nutshell, the exploit crashes the adbd daemon on the phone and prevents it from deescalating root privileges when it restarts. I know of no 'trusted' exploits for forensics, and this seemed the soundest approach to minimize changes to the running operating system on the device.
A variety of exploits can be downloaded from the Android Devices Website, but it is not the only location for rooting information. The xda-developers website is another good resource. In the case of the Motorola Droid 2, I'll use the rageagainstthecage binary file from the developer, which includes the source code for review.
Installing and Running the Exploit
The process of rooting is straight forward: Push the file to the device, make it executable, and run. The result is a crashed adbd daemon, that when restarted, allows the adb shell to start with root permissions.
Caveat 1: I wouldn't call this a "forensically sound" approach, per se, in that it makes changes to the phone. But I wouldn't say this leads to automatic disqualification of the evidence, either. The technique was a necessary approach under the circumstance of current technology to meet the needs of my investigation. The techniques and their impacts on the evidence can be explained and therefore may be admissible. Your mileage may vary.
Caveat 2: The "rooting" process I describe here borrows from common techniques found on the Web that were developed by users of Android phones to gain full access to their devices. But, the process described here differs significantly. Do not follow the user-oriented tutorials for rooting devices as they require you to install files unnecessary to forensics and make significant changes to the device, sometimes erasing user data!
Preparing the Phone
Luckily, the phone I received was unlocked. I accessed the settings, disabled wireless networking, and placed the device in airplane mode to minimize changes and prevent remote access. I also disabled the password and automatic screen locking, and I determined the OS version (v2.2.2) through "Settings | About Phone", in this case 2.2.2. Two other settings are required: set the device to enter USB debugging mode when connected by USB and set it to stay awake while charging through "Settings | Applications | Development."
I have since learned that the technique I describe below will work on locked Andriod phones that have USB debugging enabled. Working with another investigator, we rooted a locked Virgin Mobile LG Optimus and a locked HTC Incredible.
Preparing the Workstation
I downloaded and installed the Android SDK which includes the very useful Android Debug Bridge (adb) utility. Installation of the Linux version involves extracting the compressed archive (tar) and copying to a directory of your choice. In my case, I chose '/usr/local'.
# tar xzvf android-sdk_r11-linux_x86.tgz.tar -C /usr/localUpdate the SDK to ensure you have the latest tools
# ./usr/local/android-sdk-linux_x86/tools/android update sdkCreating a link to adb somewhere in your path, such as /usr/local/bin makes running the utility easy and is recommended. I created a link with the following command:
# ln -s /usr/local/android-sdk-linux_x86/platform-tools/adb /usr/local/bin/adbWorking with the Android Debug Bridge
With the SDK installed and the device connected by USB cable, the command 'adb devices', run as root, will start the adb server and show the serial number of a USB-attached Android device. If the serial number is represented by a series of question marks, kill the sever with 'adb kill-server' and restart with 'adb root'. The Android version and phone model influence whether or not you can start the adbd daemon as root. I recommend attaching only one device at a time so that subsequent commands need not specify the device on which to operate. Use 'adb help' to list all possible commands and a brief description of their use.
Default ADB Shell Access
There is limited access to the device file system by dropping into the adb shell with the command 'adb shell'. This is true even if you are root when you start the adb server and if you start the adbd daemon with 'adb root'. You'll note that you have the standard '$' user prompt. In other words, when you launch the adb shell, you are dropped into in a shell console on the running phone with standard user privileges.
The adb shell is an ASH shell with limited binary tool availability. For example, there are no copy or find commands. There is no inline command editing or shell history. Your limited privileges prevent you from accessing the /data and /cache directories which contain the bulk of the user data you are likely seeking. Other available adb commands (not part of adb shell), can be used to recursively copy files from the device to your local system (adb pull) or place local files into the Android file system (adb push), but your limited privileges still impede you.
Escalating Permissions with Rageagainstthecage
The solution is to "root" the device. Rooting, in this case, means to escalate your privileges in the adb shell to super-user status. I could not find a rooting method that prevented any changes to the phone's file system (the exploit has to be loaded into a partition on the phone), but I settled on the small 5k 'rageagainstthecage' exploit, which is an adb setuid exhaustion attack. In a nutshell, the exploit crashes the adbd daemon on the phone and prevents it from deescalating root privileges when it restarts. I know of no 'trusted' exploits for forensics, and this seemed the soundest approach to minimize changes to the running operating system on the device.
A variety of exploits can be downloaded from the Android Devices Website, but it is not the only location for rooting information. The xda-developers website is another good resource. In the case of the Motorola Droid 2, I'll use the rageagainstthecage binary file from the developer, which includes the source code for review.
Installing and Running the Exploit
The process of rooting is straight forward: Push the file to the device, make it executable, and run. The result is a crashed adbd daemon, that when restarted, allows the adb shell to start with root permissions.
- Extract the the rageagainstthecage-arm5.bin bin from the tar file.
# tar xzvf RageAgainstTheCage.tgz.tar rageagainstthecage-arm5.bin
- (optional) Rename rageaginstthecage-arm5.bin to something easy to type, like ratc.bin.
# mv rageagainstthecage-arm5.bin ratc.bin
- Push the file to a user-accessible location on the phone where execution of files is permitted. I'd prefer a different location than the /data partition, but so far this has been my best option.
# adb push ratc.bin /data/local/tmp/ratc.bin
- Drop into the shell, make the file executable, and run. Note the prompt change after executing adb shell as root.
# adb shell <-- your root terminal
$ chmod 0755 /data/local/tmp/ratc.bin <-- adb shell
$ ./data/local/tmp/ratc.bin
[*] CVE-2010-EASY Android local root exploit (C) 2010 by 743C
[*] checking NPROC limit ...
[+] RLIMIT_NPROC={1803, 1803}
[*] Searching for adb ...
[+] Found adb as PID 3323
[*] Spawning children. Dont type anything and wait for reset!
[*]
...
[*] adb connection will be reset. restart adb server on desktop and re-login.
$ # <-- your root terminal again
You will be dumped out of the adb shell back into your terminal. Be patient, as this can take a few moments. The exploit is launching processes and creating a race condition to prevent the adb daemon from deescalating privileges on restart. If you are not dumped from the shell, run the exploit again.
- Finally, restart the adb shell (note the root prompt indicating you are now the root user on the device). DO NOT restart the adb server, as the last system message indicates. It will restart on its own , if needed, when you issue the 'adb shell' command.
# adb shell
# <-- adb shell prompt
If you receive the "device not found" error when restarting the adb shell, wait a few moments and try again: then adbd daemon on the phone has not finished restarting.
There, you've done it! You have rooted the device. The root adb shell will remain until you restart the adbd daemon with 'adb kill-server' or by rebooting the phone. The exploit will remain on the phone until you delete it in the adb shell with:
# rm /data/local/tmp/ratc.bin
You are now ready to start copying partitions and/or logical files for your examination... almost. You still lack the tools to copy files, (though not partitions), and copying whole partitions with dd, while possible, isn't as straight forward as it is with physical disks, the primary issue being the yaffs filesystem they contain. Since this post has gotten quite long, I'll discuss those issues if future posts.
Thursday, June 2, 2011
Decoding Google Chrome timestamps in SQLite databases
I had occasion to work with Google Chrome histories today. The timestamp in the History SQLite databases look like unixepoch time at first glance, but they are not. However, the Chrome timestamps are 7 digits longer than unixepoch time.
Unixepoch
Unixepoch time is the number of seconds elapsed since 01/01/1970 00:00:00. It can be converted in a SQLite statement with the datetime() function thusly:
"time" is the name of the field containing the (currently) 10-digit date string, e.g., "1307078210", and "table" is the name of the table containing the time field. The "AS time" displays the column label as "time". Without it, the column takes the full datetime() function as the column name which is a bit ugly and confusing to recipients of the data.
PRTime
The extra seven digits in the Chrome timestamp brought to mind Firefox PRTime. PRTime is the number of microseconds since 01/01/1970 00:00:00. The timestamp needs to be converted to unixepoch format before it can be converted to local time through the SQLite datetime() function. This can be done by dividing the value by one-million. In SQLite, this looks like:
Chrome Time (Webkit Format)
If there is an official name for Chrome time, I don't know it. EDIT: I have learned the name for the Chrome's format is Webkit format). What I do know, is that Chrome time IS NOT the same as PRTime. Though it is also a microsecond calculation, its base time is 01/01/1601 00:00:00. To calculate local time, Chrome time has to be converted to seconds by dividing by one-million, and then the seconds differential between 01/01/1601 00:00:00 and 01/01/1970 00:00:00 must be subtracted. But how do we figure that out?
Two ways, as it turns out. With SQLite itself, or with the Unix date command. This is how:
SQLITE:
DATE:
In both commands above, the "%s" represents unixepoch time. The commands calculate the number of seconds between unixepoch time (1970) and the subsequent date (Chrome time base, 1601). Note that the seconds are negative. Of course, this is because you have to count backwards from 1970 to 1601! With this information, we can convert Chrome time in SQLite like this:
Unfortunately, there are more time formats out there than these. You may recall I blogged about Apple's Mac Absolute Time in February. But, armed with this information, You should be able to convert the times formats I've discussed and possibly discover the solution to any others you might encounter.
Unixepoch
Unixepoch time is the number of seconds elapsed since 01/01/1970 00:00:00. It can be converted in a SQLite statement with the datetime() function thusly:
sqlite> SELECT datetime(time, 'unixepoch', 'localtime') AS time FROM table;
"time" is the name of the field containing the (currently) 10-digit date string, e.g., "1307078210", and "table" is the name of the table containing the time field. The "AS time" displays the column label as "time". Without it, the column takes the full datetime() function as the column name which is a bit ugly and confusing to recipients of the data.
PRTime
The extra seven digits in the Chrome timestamp brought to mind Firefox PRTime. PRTime is the number of microseconds since 01/01/1970 00:00:00. The timestamp needs to be converted to unixepoch format before it can be converted to local time through the SQLite datetime() function. This can be done by dividing the value by one-million. In SQLite, this looks like:
sqlite> SELECT datetime(time/1000000, 'unixepoch', 'localtime') AS time FROM table;
Chrome Time (Webkit Format)
If there is an official name for Chrome time, I don't know it. EDIT: I have learned the name for the Chrome's format is Webkit format). What I do know, is that Chrome time IS NOT the same as PRTime. Though it is also a microsecond calculation, its base time is 01/01/1601 00:00:00. To calculate local time, Chrome time has to be converted to seconds by dividing by one-million, and then the seconds differential between 01/01/1601 00:00:00 and 01/01/1970 00:00:00 must be subtracted. But how do we figure that out?
Two ways, as it turns out. With SQLite itself, or with the Unix date command. This is how:
SQLITE:
sqlite> SELECT strftime('%s', '1601-01-01 00:00:00');
-11644473600
DATE:
$ date +%s -d 'Jan 1 00:00:00 UTC 1601' -11644473600
In both commands above, the "%s" represents unixepoch time. The commands calculate the number of seconds between unixepoch time (1970) and the subsequent date (Chrome time base, 1601). Note that the seconds are negative. Of course, this is because you have to count backwards from 1970 to 1601! With this information, we can convert Chrome time in SQLite like this:
sqlite> SELECT datetime((time/1000000)-11644473600, 'unixepoch', 'localtime') AS time FROM table;
Unfortunately, there are more time formats out there than these. You may recall I blogged about Apple's Mac Absolute Time in February. But, armed with this information, You should be able to convert the times formats I've discussed and possibly discover the solution to any others you might encounter.
Thursday, May 19, 2011
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.
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.
Wednesday, May 4, 2011
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:
You can download iphone_tools here.
- 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.
- 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.).
- 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.
- 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.
- 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.
- 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.
Thursday, April 28, 2011
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!
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!
Subscribe to:
Posts (Atom)