Chirashi Security » Forensics

Puttering around with BlackBerry forensics — Part 2

chopstick — Fri, 30 Sep 2011 14:53:29 +0000

Okay then. It apparently takes me a while between posts. I’ve been keeping a bit busy with several projects and it has been difficult to find the time to conduct much research or write blog posts. I do have an upcoming white-paper that I will release somewhere in November. It includes source code to the toolkit that I will release as well. The topic is loosely based on BlackBerry forensics and malware. In this case, however, it won’t be on how to find data, but will instead focus on how you can destroy or introduce large quantities of misleading data to frustrate and annoy malware controllers and forensic analysts. Probably not going to win many friends in certain circles with this, but at least I can force everyone to change their analysis methods.

Today, girls and boys, we’re going to look at the second utility I released that helps with analyzing BlackBerry data. Behold! ConParse!

ConParse

ConParse is a utility that helps you take a look inside a BlackBerry .con file. The .con file is generated when you choose to backup your BBM contacts on your device. These days, RIM allows you to back your BlackBerry Messenger (5 and above) contacts up to some remote location that we will henceforth refer to as the cloud. But if you fancied, you could also back up your BBM contact list to your device memory or SD Card. I present the obligatory screenshots below, thereby providing you with both hands and a flashlight. Access the screens by selecting Options from your BlackBerry messenger application.

Now then. If we take a quick peek inside the .con file it looks a right mess of randomly placed hexadecimal characters and readable text, much like most other binary files. Since not everyone is able to grok raw hex data when they look at it and because no prior documentation existed for it, I set out to make sense of this beast. If prior documentation did exist, then will the person who wrote it please speak with their SEO provider? Because you’re getting ripped off big time. If you care to dig through my source code, you may find some details on the file structure itself. If looking at badly written source code gives you hives, then I will try to explain it here.

The .con file header is interesting. The first byte tells you the size of a unique string of bytes to follow. So far it has always been 32 bytes. This 32 byte string is a signature or hash of your .con file. Its sole purpose is to ensure that you do not import .con files belonging to other devices. I haven’t bothered reverse engineering the .cod files yet to see what they use to generate this signature. In the tests I did, however, it is evident that the signature differs each time you generate a backup file and swapping signatures from other devices will render your backup file invalid.

20 C3DCA86024DCCC531A96199327B7F4E7224EF4FF52E7C0978C02C9E5F347D87F 7F80 00 00 70 05

In the byte sequence above (all hex), the first byte indicates the size of the signature (32 bytes), then the signature of 32 bytes follows.

Now that the signature is out of the way, the actual file header begins. The bytes 0x7F 0×80 indicate the start of the .con file. After this, the next 4 bytes indicate the size of the remaining data in the file. In this case it is 28677 bytes.

Immediately after this, the records start. You can find some of the following types of records in a .con file:

Your name and device PIN
All your contacts and groups (their PINS, names, custom names you’ve chosen for them, status messages, etc)
Your profile picture
Timezone and Country flag image filename
Base64 Code and Hex Code (Haven’t looked at these extensively yet, but could have something to do with an authorization code and/or the string used to generate your QR Code)

I’m not going to break down each record here, but will just give you the basic structure which is quite simple:

00 08 0A 32 31 30 30 30 30 41

The record above is a device PIN record. The first two bytes indicate the size of the record, then third byte indicates the record type and the remaining bytes (up to the record size) contain the data. RIM follows the same principle of storing size and type before data as it did in the IPD databases.

That’s it. You’re now a .con file expert. Go forth and dissect the crap out of the file. Use ConParse as a guideline or just use it to parse out .con files at your next party — guaranteed to get you laid.

Here’s another screenshot of the type of output you can expect from ConParse. Admittedly, it is just a couple of steps away from raw hex.

Puttering around with BlackBerry forensics — Part 1

chopstick — Fri, 22 Jul 2011 16:29:38 +0000

I’m guilty of sitting on source code which I should have released a long time ago. I make excuses to myself that I didn’t release any of it because I was waiting for someone to come along and prove to me that there was a better way of doing things. I guess the bottom line was that I was just lazy and procrastinating.

Today, I’m releasing source code to three of my projects that I’ve been incubating. 1) bbt 2) evt2sqlite 3) ConParse Take! Build! Enjoy! ~~At some point or another, I may just split them up into their own repos. For now, they all live in the bb-tools repository down at github.~~ Update: I’ve split them up now

In today’s post, I’ll cover the first tool, bbt.

bbt

bbt is a python script that analyzes the thumbnail cache from a BlackBerry. The purpose of a thumbnail cache in any system, is generally to speed up the browsing of large numbers of graphic or video files. Instead of presenting a static icon to the user, a small thumbnail of the picture or frame of the video file is shown. Apparently this is a good thing, because you can see an icon of the image that you’re clicking on and will hopefully be able to find the file you’re looking for quicker. Typically, the Operating System will find and shrink pictures found in directories of the filesystem. These shrunk pictures will then be placed inside the thumbnail cache.

When conducting a digital forensics analysis of a computer, looking for these thumbnail caches often provide clues as to what files may have existed before they were deleted off the file system. The thumbnail cache is important enough to warrant its own entry on the Forensics Wiki (albeit only the Windows thumbnail cache is spoken about). The principle generally remains the same when extended to the BlackBerry device as well. So, bottom line: being able to analyze this file is useful.

bbt will do just that for thumbnail cache files found on BlackBerry devices. There are two types of thumbnail caches on the BlackBerry device: 1) BBThumbs.dat format 2) key/dat format.

Format 1 is pre OS 5.0 and the key/dat format is post OS 5.0 The key/dat combination is interesting because it uses two files to keep track of thumbnails. They look something like thumbs86x86.key and thumbs86x86.dat (the 86×86 indicates the size of the thumbnail – 86 pixels by 86 pixels). I’ve noticed quite a few interesting things in these files and no doubt, you will too after you look through the source or play around with them long enough:

The BBThumbs.dat header is 0×24052003 (which is a hex number)
The thumbs.dat file header is 0×22062009 (hex again)
The thumbs.key file header is 0×08062009 (hex)

This is pure speculation, but if you took those hexadecimal representations and looked at just the numbers, don’t they look like dates?

0×24052003 –> 24 05 2003
0×22062009 –> 22 06 2009
0×08062009 –> 08 06 2009

Maybe birth dates of the file format itself or someone significant to someone who wrote it? Dunno.

Another interesting observation of the key/dat thumbnail cache is that it not only stores image thumbnails, but also stores details of all types of media including ‘wav’, ‘mp3′, and ‘mid’. It doesn’t store any content inside it though. The only content stored inside the files is image data.

I’m not actually going to tell you what is found inside the thumbs files in this post, but instead, I am going to tell you how to run bbt. bbt is a python script and as such will require that you have python installed on your system. I’d always recommend cloning my repository on github so that you can easily pull any updates. You may also want to sign up for a github account and watch the repository so that you will be notified of any commits I make. You could also fork the project and get to work on it yourself.

azazel:Device sheran$ ~/github/bb-tools/bbt/bbt.py
Usage: bbt.py [options]
  -h, --help: This cruft
  -k, --key : Process post OS5 thumbs.key file (requires thumbs.dat file in same directory)
  -b, --bbthumbs : Process pre OS5 BBThumbs.dat file
  -x, --extract: Extracts the thumbnails into directory specified by -o
  -o, --output : Directory to extract thumbs to (used only with -x)
azazel:Device sheran$

The output above is what you will receive if you run bbt without options. As of the latest release (0.3b), the most magical thing you can do with this tool is to extract the thumbs into a specific output directory. Additionally, bbt will parse out information about 1) What thumbnails are stored in the file (filename) for BBThumbs.dat files or 2) Where at what offset in a ‘dat’ file a specific record id is stored. Here’s some example output when parsing a key/dat pair:

azazel:Device sheran$ ~/github/bb-tools/bbt/bbt.py -k thumbs116x116.key -x -o out
*** Processing thumbs116x116.key on 2011-07-22 21:50:48.156899
Record ID C620B80A is at offset 7 in 'dat' file // [1306132653179.jpeg]
Record ID DB0B7CA3 is at offset 25930 in 'dat' file // [1306492410606.jpeg]
Record ID D2EC23E3 is at offset 52123 in 'dat' file // [1306732433796.jpeg]
*** thumbs116x116.key has 9 records
*** Processed 3 records
azazel:Device sheran$

When you parse a key/dat file combination, you need to make sure that both the ‘key’ and ‘dat’ file are in the same directory. When you run bbt, you will point it to the location of the ‘key’ file. From the output above, you can see that it has discovered 3 records, corresponding record ids and offsets where they are stored in the ‘dat’ file. Also, the filename of the thumbnail is provided. What do the offsets mean? Well, if you were to take the numbers and open up the ‘dat’ file in a hex editor, then you would land on the location where that specific record began. This is what it looks like:

The highlighted portion is the first part of the record with the correct starting offset. You may also notice that the ‘key’ file supposedly has 9 records but only 3 were processed. This happens because the ‘key’ file holds 9 record ids and 9 offsets, but only 3 of those actually match up in the ‘dat’ file. One assumption that can be made is that the files were deleted from the ‘dat’ file, but the ids and offsets still remained in the ‘key’ file.

bbt also has the ‘-x’ option which allows you to extract the thumbnails that are inside either the BBThumbs.dat file or the key/dat files. You do this by specifying the ‘-x’ option along with the ‘-o’ option to tell bbt where to extract the thumbnails to. You will need to make sure that the output directory specified by the ‘-o’ option does not already exist.

For now, that’s as much as you’re going to get out of bbt. Some features that are planned in the roadmap for bbt are:

HTML Reporting
Identification of Exif data within thumbnails
Completely parsing some of the header and record bytes that are as yet unknown

I’ll cover the other tools in subsequent posts. For now, though, the tools are all live in the github repository. All of the tools contain a basic README doc that tells you how to get started with each of the tools.

Recover Deleted Data from SQLite Databases

Mon, 29 Nov 2010 06:50:43 +0000

Recovering data from an SQLite database has many uses. Why you ask? One main reason is that SQLite has increased in popularity to epic proportions. It is the most ideal candidate for use in a resource constrained environment. Like where you ask? The industry most benefiting from SQLite at the moment is the mobile phone one. The BlackBerry, Android and iPhone platforms rely on SQLite. As a matter of fact, a large portion of the iPhone’s data storage, like Address Book or SMS Messages are stored in SQLite databases. Google Chrome and Firefox store it’s history and bookmarks in SQLite Databases. The WhatsApp application on a BlackBerry phone stores information on an SQLite Database. It’s everywhere.

With all this popularity, the inner workings of SQLite have held a sense of mystery and intrigue. But not anymore. We’ve cracked the internals of how an SQLite database stores and handles its data. We know where your unreferenced data hides and we know how to recover it. So the next best thing? Write a tool for it. Thus this post serves to introduce our new tool – SQLUn, or simply the SQLite Undeleter. The tool is very ideally suited to Forensics Analysts and investigators who focus on smartphones – most notably iPhones.

SQLUn successfully recovers data from not only unreferenced areas of the database, but also from the slack space of referenced records. In this manner, a Forensic Analyst is certain that data is recovered from every nook and cranny of the database and no area is left unturned. To aid Law Enforcement analysts, SQLUn also has the ability to manage information based on a specific case number. Additionally, data integrity is maintained by conducting SHA1 hashes of all relevant records and databases. Data is further protected by disabling writes to the database and working off a duplicate copy rather than the database file itself. This feature is added to ensure that the database remains intact even if the operator forgets to take a backup.

By now, I’m pretty sure that you’re dying to get your hands on this little gem and I don’t blame you. If you want to become a beta tester for the application, email us at sql-beta@zenconsult.net and we will take it from there. Please provide some details about yourself including where you work and why we should consider you for beta testing the product. If you work in the Law Enforcement industry, please mail us from your agency email address for expedited handling of your beta tester request.

You want the BlackBerry Event Log? beg damnit!

Thu, 01 Jul 2010 07:03:41 +0000

It’s been quite a while since my last post. I’ve been a bit on the busy side with work, family and a bit of research. Inspired by a friend and fellow researcher – Cst. Shafik Punja, I decided to look deeper into BlackBerry connectivity via USB. If I succeeded at understanding this topic, I would be able to directly connect to a BlackBerry device and collect all the information that I wanted. I wouldn’t be bound by tools like JavaLoader or the Desktop Manager and would have the freedom to write my own tools. Well, I succeeded at understanding this and went a step further, I’m releasing a tool today.

I know that many forensic analysts are always looking at ways to pull data off mobile devices without installing invasive tools. So I set about coding a tool to do something simple — pull the BlackBerry Event Log (you can open the event log from a BlackBerry device by holding down “ALT” and typing “LGLG”) from a BlackBerry device. Sure, JavaLoader does this, so to differentiate the tool from JavaLoader, I made it a little more intelligent. I called it beg – BlackBerry Eventlog Grepper. beg can add a little bit of sanity to the madness that is the BlackBerry event log. In other words, it translates the seemingly gibberish looking data to a more human friendly format.

Example Event Log Output:

guid:0x3B91E1630F0745BC time:2010/06/30 22:45:40.0 severity:Always Log type:String app:net.rim.tunnel data:Clos-MagicRudyAPN.rim
guid:0x316C1626A9DDC375 time:2010/06/30 22:45:40.0 severity:Always Log type:String app:net.rim.tcp data:clos
guid:0xB2EC7A712090AD8F time:2010/06/30 22:45:46.0 severity:Always Log type:String app:net.rim.smsui data:UTSC
guid:0xB2EC7A712090AD8F time:2010/06/30 22:45:46.0 severity:Always Log type:String app:net.rim.smsui data:UTSC
guid:0xB2EC7A712090AD8F time:2010/06/30 22:45:54.0 severity:Always Log type:String app:net.rim.smsui data:UTSC
guid:0xB2EC7A712090AD8F time:2010/06/30 22:45:54.0 severity:Always Log type:String app:net.rim.smsui data:UTSC
guid:0xB2EC7A712090AD8F time:2010/06/30 22:45:57.0 severity:Always Log type:String app:net.rim.smsui data:UTSC
guid:0x647E5DBBC34B5549 time:2010/06/30 22:46:09.0 severity:Always Log type:String app:net.rim.clock data:+CHG
guid:0xDAA64EAD4E49C5D5 time:2010/06/30 22:46:09.0 severity:Always Log type:String app:net.rim.usb.pwd data:CbCn
guid:0x5D41D4729582C2DA time:2010/06/30 22:46:09.0 severity:Always Log type:String app:RootRegister data:usbConnectionStateChange:1

I started by looking at the phone calls that are written to the event log. One thing you may notice from the event log is this: If you delete a call from your call history, the event log does not delete it. So if you pull the event logs, you will be caught in a lie. I know that my friend in Law Enforcement would find this invaluable, so I started there. For now, beg is able to dump the event logs, dump only the phone event logs and translate the phone event logs into something more readable. The output looks something like this:

sheran@devbox:~/progs$ ./beg -p -r
Connected to 20fe2f60
2010/06/30 21:07:55.0: Incoming Call from +622157939018
2010/06/30 22:29:19.0: Outgoing Call to 02114045
2010/06/30 22:30:37.0: Outgoing Call to +628119917931
2010/06/30 22:41:54.0: Outgoing Call to +6281219684934
2010/06/30 22:53:27.0: Outgoing Call to +6281219684934
sheran@devbox:~/progs$

Inner workings

First, I’d like to quickly go over the two main ways that you can connect to your BlackBerry device. One of the initial methods I used was to write a Python script to take advantage of the libusb and PyUSB libraries. I would then send raw commands back and forth. These commands were sniffed from legitimate connections made between the BlackBerry and either JavaLoader or Desktop Manager. The second method was to use an already existing library called Barry. Barry was developed to allow Linux users to sync their BlackBerry devices on . Since most of the work was already done, I decided to go with method 2 – using the Barry library. So bear in mind that you will need to install the Barry library and it’s pre-requisites first.

To use beg, just download it and untar/gzip it to a folder. Then, have a look through the README file. It contains everything you would ever need to know. For the moment, beg only works on Linux distributions and does require the Barry library and libusb library. Support can always be found by getting in touch via the Contact page.

BlackBerry Hidden Program Revealer v0.1

Fri, 17 Jul 2009 18:16:01 +0000

Okay, for real this time. Continuing from my previous post, I’ve got version 0.1 of the HiddenProgs app available for download. Grab your copy here. The way I installed it was to just navigate to the link using my Bold. By downloading the program, you’re acknowledging you’ve read and understood the disclaimer below.

Description

The program has 2 options. One is the Reveal option. This option is only visible in your Menu when the Etisalat BlackBerry Spyware is detected on your handheld. If it isn’t there, then the option doesn’t show up.

The second option is the Show Hidden Programs. As the name suggests, it gives you a look into all the programs that are marked as hidden on your handheld. This also includes libraries.

For now, I would urge you to browse around the hidden programs and see if you come across anything suspicious. I think, as a general rule of thumb the net.rim.* libraries and programs can be trusted.

How to use

Start the program, it should tell you whether or not the spyware was detected on your handheld. If it is detected, then press the Menu and select Reveal. Then quit the application, go to Options->Advanced Options->Applications, click on Registration and uninstall it. That should be it.

I would really like to hear your comments and most importantly would like to have your help in improving this program. Please try it out and either post a comment or mail me directly. My email address is in the About option.

Thanks, and be safe!

Disclaimer (sorry, got to put this in)

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDER “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

Etisalat BlackBerry Spyware Revealer

Thu, 16 Jul 2009 19:30:13 +0000

[Update: The spyware revealer tool is now ready and so is the whitepaper. I've added links to navigate easily]

Navigation

You can download the software revealer here
You can download the spyware removal guide here
You can download the whitepaper here

Now onto the rest of the original article:

Okay, so I put aside the write up for awhile to complete my BlackBerry App that will reveal the Etisalat Spyware if it is installed on your BlackBerry. So far, I have tested it on my simulators and it works well. I’ve posted some screenshots here. Now as luck would have it, I did get a hold of a set of BlackBerry Code Signing Keys. This would allow me to distribute this app and people would be able to use it and, hopefully, benefit from it. But not all of that luck was good. I tried installing the keys and the registration with the central BlackBerry servers is failing. I have mailed RIM about this and I am waiting their response. What does this mean? Well, sadly, I cannot release the tool because of this so no-one is going to be able to clean their BB’s over the weekend. Bummer. I’ve got the source which I will release at the same time. In the meantime, if anyone is interested in the source, leave a comment and I’ll pick it up from there on. So while I wait for the Keys to come through, I’ll get to work on the writeup.

The App:

I called it the Hidden Program Revealer (yeah, I know, as original as some of the shop names in Dubai.) So far all the app does is start up and look for the name of the Etisalat application and determines if it is installed. It detects if it is hiddenand will give you an option to reveal it if it is. At that point, you can go to Options->Advanced Options->Applications->Registration->Delete to remove the spyware completely. Additionally, I wanted to make the app a bit more useful for the future and I put in an option to reveal all hidden programs and libraries on your handheld. This will give you an opportunity to search for anything suspicious. If you do find some other suspicious apps, then mail me the name and I’ll ship a custom app for you to reveal it and uninstall it. I think a good rule of thumb, much like Tripwire is to install a known, good copy of the BlackBerry device software, run my utility and baseline the hidden apps on your device. That way, you will know if anything is changed. This is actually the direction I want to go with my app as well.

For now, only screenshots.

Screenshots of my BlackBerry App running on the sim:

Memory Card Forensics

Tue, 19 Jun 2007 17:23:00 +0000

So I’m looking into forensics and I remember reading about how some guys would buy used hard drives belonging to hospitals or banks and do some recovery on the data and come up with some interesting stuff and I think, why not try it on Memory Cards?

Sure, it’s not an original idea, but a quick look on one of the local online auction sites says that for a relatively small amount, I can buy someone’s memory card and potentially have access to a fair amount of his personal data.

Depending on where the card was used, I’m looking at quite a number of possibilities relating to information that I can dig up. Contact details, people he’s called, photos and videos he’s taken (could be some raunchy stuff on there as well ) and literally anything he’s stored on his card. I’m betting on the fact that Mr. Average Joe will not do a DoD wipe on his SD card before deciding to sell it.

But to test this theory, I thought I’d try out one of my own memory cards. If you look at my post for “Installing CarvFS on Ubuntu 7.04″, you will get an idea of in-place carving. I will adopt this technique for sniffing through my own (and eventually others) memory cards. So here goes:

I have this USB Disk which is 64Mb in size and I think it will be perfect for this demo. I first mount it and take a look at the contents:


sheran@azazel:~/Personal/research$ sudo mount /dev/sdb1 /media/usbdisk
sheran@azazel:~/Personal/research$ ls -alrt /media/usbdisk
total 17
drwxr-xr-x 8 root   root    4096 2007-06-19 12:21 ..
drwx------ 2 root   root   12288 2007-06-19 12:24 lost+found
drwxr-xr-x 3 sheran sheran  1024 2007-06-19 12:24 .
sheran@azazel:~/Personal/research$ df -kh /media/usbdisk
Filesystem            Size  Used Avail Use% Mounted on
/dev/sdb1              61M  1.3M   56M   3% /media/usbdisk
sheran@azazel:~/Personal/research$

That’s pretty much the disk. I had run cfdisk and mke2fs previously on the Windows formatted USB Disk. I now image it with ‘ewfacquire’ which you don’t get to see, but I end up with the file usbdisk.E01. I can now mount this file using CarvFS.


sheran@azazel:~/Personal/research$ sudo -s
root@azazel:~/Personal/research# carvfs /mnt/carvfs/ ewf usbdisk.E01
/mnt/carvfs//f183a8e2b50834552f9302b08251d4db
root@azazel:~/Personal/research# cd /mnt/carvfs/f183a8e2b50834552f9302b08251d4db/
root@azazel:/mnt/carvfs/f183a8e2b50834552f9302b08251d4db# ls -alrt
total 63616
-rw-rw-rw- 1 root root     2545 1970-01-01 04:00 README
-rw------- 1 root root       85 1970-01-01 04:00 ocfa.missing
-r--r--r-- 1 root root 65135616 1970-01-01 04:00 CarvFS.crv
d--x--x--x 3 root root        0 1970-01-01 04:00 CarvFS
drwxr-xr-x 3 root root        0 1970-01-01 04:00 .
drwxr-xr-x 3 root root     4096 2007-06-19 13:28 ..
root@azazel:/mnt/carvfs/f183a8e2b50834552f9302b08251d4db#

Now I run ‘scalpel’ in preview mode with the configuration file set to grab graphic files:


root@azazel:~/Personal/research# scalpel -p -c ./scalpel_gfx.conf /mnt/carvfs
/f183a8e2b50834552f9302b08251d4db/CarvFS.crv
Scalpel version 1.60
Written by Golden G. Richard III, based on Foremost 0.69.

Opening target "/mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS.crv"

Image file pass 1/2.
/mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS.crv:  16.1%    10.0 MB    00
/mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS.crv:  32.2%    20.0 MB    00
/mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS.crv:  48.3%    30.0 MB    00
/mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS.crv:  64.4%    40.0 MB    00
/mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS.crv:  80.5%    50.0 MB    00
/mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS.crv:  96.6%    60.0 MB    00
/mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS.crv: 100.0%    62.1 MB    00:00 ETA
Allocating work queues...
Work queues allocation complete. Building carve lists...
Carve lists built.  Workload:
gif with header "x47x49x46x38x37x61" and footer "x00x3b" --> 0 files
gif with header "x47x49x46x38x39x61" and footer "x00x3b" --> 146 files
jpg with header "xffxd8xffxe0x00x10" and footer "xffxd9" --> 22 files
png with header "x50x4ex47x3f" and footer "xffxfcxfdxfe" --> 0 files
** PREVIEW MODE: GENERATING AUDIT LOG ONLY **
** NO CARVED FILES WILL BE WRITTEN **
Carving files from image.
Image file pass 2/2.
/mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS.crv:  16.1%    10.0 MB    00
/mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS.crv:  48.3%    30.0 MB    00
/mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS.crv:  96.6%    60.0 MB    00
/mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS.crv: 100.0%    62.1 MB    00:00 ETA
Processing of image file complete. Cleaning up...
Done.
Scalpel is done, files carved = 168, elapsed = 3 seconds.
root@azazel:~/Personal/research#

And I find 146 GIF files and 22 JPGs. Usually, scalpel can be used to extract these files and place them in another directory. The beauty of CarvFS is in the fact that you can add symlinks to the CarvFS image and these symlinks directly refer to offsets within the ‘usbdisk.E01′ image. CarvFS comes with a tool called ‘scalpelcp’ which does just this. I had to edit the script so that it works fine, because there was a problem with the “$basepath” variable. But anyway, here goes:


root@azazel:~/Personal/research# scalpelcp
Usage: scalpelcp  

this tool is meant to be used in conjunction with scalpel (>= 1.6)
run in preview mode (that is using the -p option that scalpel provides)
on carvpath pseudo files.
Scalpelcp will parse the audit.txt file and populate the scalpel output
directory with symlinks to valid sub-carvpaths extracted from the audit file

root@azazel:~/Personal/research# scalpelcp ./scalpel-output/ /mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS/
Target=/mnt/carvfs/f183a8e2b50834552f9302b08251d4db/CarvFS
symlinked 168 filenames to zero-storage carvpaths
root@azazel:~/Personal/research# cd scalpel-output/

oot@azazel:~/Personal/research/scalpel-output# ls
00000000.gif  00000034.gif  00000068.gif  00000102.gif  00000136.gif
00000001.gif  00000035.gif  00000069.gif  00000103.gif  00000137.gif
00000002.gif  00000036.gif  00000070.gif  00000104.gif  00000138.gif
00000003.gif  00000037.gif  00000071.gif  00000105.gif  00000139.gif
00000004.gif  00000038.gif  00000072.gif  00000106.gif  00000140.gif
00000005.gif  00000039.gif  00000073.gif  00000107.gif  00000141.gif
00000006.gif  00000040.gif  00000074.gif  00000108.gif  00000142.gif
00000007.gif  00000041.gif  00000075.gif  00000109.gif  00000143.gif
00000008.gif  00000042.gif  00000076.gif  00000110.gif  00000144.gif
00000009.gif  00000043.gif  00000077.gif  00000111.gif  00000145.gif
00000010.gif  00000044.gif  00000078.gif  00000112.gif  00000146.jpg
00000011.gif  00000045.gif  00000079.gif  00000113.gif  00000147.jpg
00000012.gif  00000046.gif  00000080.gif  00000114.gif  00000148.jpg
00000013.gif  00000047.gif  00000081.gif  00000115.gif  00000149.jpg
00000014.gif  00000048.gif  00000082.gif  00000116.gif  00000150.jpg
00000015.gif  00000049.gif  00000083.gif  00000117.gif  00000151.jpg
00000016.gif  00000050.gif  00000084.gif  00000118.gif  00000152.jpg
00000017.gif  00000051.gif  00000085.gif  00000119.gif  00000153.jpg
00000018.gif  00000052.gif  00000086.gif  00000120.gif  00000154.jpg
00000019.gif  00000053.gif  00000087.gif  00000121.gif  00000155.jpg
00000020.gif  00000054.gif  00000088.gif  00000122.gif  00000156.jpg
00000021.gif  00000055.gif  00000089.gif  00000123.gif  00000157.jpg
00000022.gif  00000056.gif  00000090.gif  00000124.gif  00000158.jpg
00000023.gif  00000057.gif  00000091.gif  00000125.gif  00000159.jpg
00000024.gif  00000058.gif  00000092.gif  00000126.gif  00000160.jpg
00000025.gif  00000059.gif  00000093.gif  00000127.gif  00000161.jpg
00000026.gif  00000060.gif  00000094.gif  00000128.gif  00000162.jpg
00000027.gif  00000061.gif  00000095.gif  00000129.gif  00000163.jpg
00000028.gif  00000062.gif  00000096.gif  00000130.gif  00000164.jpg
00000029.gif  00000063.gif  00000097.gif  00000131.gif  00000165.jpg
00000030.gif  00000064.gif  00000098.gif  00000132.gif  00000166.jpg
00000031.gif  00000065.gif  00000099.gif  00000133.gif  00000167.jpg
00000032.gif  00000066.gif  00000100.gif  00000134.gif  audit.txt
00000033.gif  00000067.gif  00000101.gif  00000135.gif
root@azazel:~/Personal/research/scalpel-output#

And here are all my symlinked files. If you do a long listing you can see how the files are actually symlinked:


root@azazel:~/Personal/research/scalpel-output# ls -alrt | tail -n 5
lrwxrwxrwx 1 root   root      67 2007-06-19 13:44 00000003.gif -> /mnt/carvfs/f183a8e2b50834552f9302b08251d4db
/CarvFS/1206784:269.crv
lrwxrwxrwx 1 root   root      67 2007-06-19 13:44 00000002.gif -> /mnt/carvfs/f183a8e2b50834552f9302b08251d4db
/CarvFS/1205760:200.crv
lrwxrwxrwx 1 root   root      68 2007-06-19 13:44 00000001.gif -> /mnt/carvfs/f183a8e2b50834552f9302b08251d4db
/CarvFS/1203712:1231.crv
lrwxrwxrwx 1 root   root      66 2007-06-19 13:44 00000000.gif -> /mnt/carvfs/f183a8e2b50834552f9302b08251d4db
/CarvFS/1203200:50.crv
drwxr-xr-- 2 root   root    4096 2007-06-19 13:44 .
root@azazel:~/Personal/research/scalpel-output#

Lastly, all that’s left is to start up an image viewer program or plain old nautilus and see what the directory holds:

That’s it for now. I’m off to buy some more memory cards. Be very careful if you know me and hear me ask you innocently, “Hey, can I borrow your camera?”

Installing CarvFS on Ubuntu 7.04

Mon, 18 Jun 2007 17:19:00 +0000

In place carving can save you a fair amount of space. There was a paper written about it and the Dutch National Police Agency also wrote a tool called CarvFS that does exactly this. What CarvFS allows you to do is mount an EWF image or raw ‘dd’ image and reference blocks of data by using a specific directory listing format. At it’s simplest level, you could run ‘strings’ on a set of 1024 bytes beginning at the first byte by doing this:
root@azazel:/mnt/carvfs/524a4efcaa84cf7391705b2b292644a6# strings CarvFS/0:1024.crv NO NAME FAT16 root@azazel:/mnt/carvfs/524a4efcaa84cf7391705b2b292644a6#

I’ll leave you to work out why this is useful; alternatively you can also read my “Memory Card Forensics” post. Here is how I installed CarvFS:

Downloaded the source packages for CarvFS, libcarvpath, libewf and fuse. They can be found here:

CarvFS 0.2.1
libcarvpath 0.1.4
libewf-beta-20061223
fuse 2.6.5

There’s no specific order, but make sure that libewf, fuse and libcarvpath are installed before CarvFS.

I believe fuse should already be running as a kernel module in 7.04, so the kernel module will not be built.

Then, once you install CarvFS, you’re pretty much ready to go. I had one problem when I ran carvfs I received a library not found error for libfuse.so.2. The library itself was in /usr/local/lib, but there was no entry in /etc/ld.so.conf. So I added the entry and ran ldconfig and all was well.

How will you test CarvFS? First, you will need either a raw ‘dd’ image or an EWF image. libewf will install a tool called ‘ewfacquire’ which you can use to make EWF images. Here is an excerpt of one of my sessions:

sheran@azazel:~/Personal/research$ ewfacquire /dev/sdb1 ewfacquire 20061223 (libewf 20061223, zlib 1.2.3, libcrypto 0.9.8) Information about acquiry required, please provide the necessary input Image path and filename without extension: usbdisk Case number: 1923 Description: USB Disk Evidence number: 12 Examiner name: Sheran Notes: 64Mb USB Disk used for Forensics tests Media type (fixed, removable) [fixed]: removable Use compression (none, fast, best) [none]: best Use EWF file format (smart, ftk, encase1, encase2, encase3, encase4, encase5, linen5, ewfx) [encase5]: Start to acquire at offset (0 >= value >= 65135616) [0]: Amount of bytes to acquire (0 >= value >= 65135616) [65135616]: Evidence segment file size in kbytes (2^10) (1440 >= value >= 2097152) [665600]: The amount of sectors to read at once (64, 128, 256, 512, 1024, 2048, 4096) [64]: 512 The amount of sectors to be used as error granularity (1 >= value >= 512) [64]: The amount of retries when a read error occurs (0 >= value >= 255) [2]: Wipe sectors on read error (mimic EnCase like behavior) (yes, no) [yes]: ... ... ... ...
It goes on to acquire an EWF image of my 64Mb USB Disk.

The next step would be to mount it. Create a mount point for it first. I use /mnt/carvfs.

sheran@azazel:~/Personal/research$ sudo carvfs /mnt/carvfs ewf usbdisk.E01 /mnt/carvfs/fad545a8c4c86973eb0ae33da06e9c80 sheran@azazel:~/Personal/research$

Now that the image is mounted, switch to the root prompt (I wasted some time on this one) and then go into the mounted image:

root@azazel:/mnt/carvfs/fad545a8c4c86973eb0ae33da06e9c80# ls -alrt total 63617 -rw-rw-rw- 1 root root 2545 1970-01-01 04:00 README -r--r--r-- 1 root root 1397 1970-01-01 04:00 ocfa.xml -r--r--r-- 1 root root 65135616 1970-01-01 04:00 CarvFS.crv d--x--x--x 3 root root 0 1970-01-01 04:00 CarvFS drwxr-xr-x 3 root root 0 1970-01-01 04:00 . drwxr-xr-x 5 root root 4096 2007-06-18 17:43 ..
I then ran a strings on the first 512 bytes like so:
root@azazel:/mnt/carvfs/fad545a8c4c86973eb0ae33da06e9c80# strings CarvFS/0:512.crv MSDOS5.0 NO NAME FAT32 3 f`f;F fXfXfXfX NTLDR Remove disks or other media. Disk error Press any key to restart root@azazel:/mnt/carvfs/fad545a8c4c86973eb0ae33da06e9c80#
That’s about it.

I know my instructions probably suck big time, but I didn’t want to waste too much time in actually telling you how to do some of the other things. Anyway, if you’re sniffing around CarvFS you probably know how to do most of the stuff anyway. If, however, you still want to know stepwise details, drop me a comment or mail me.

Till then.