USB flashdisk forensic with Linux : An Introduction

Now, lets say you received a flash disk as apart of a criminal investigation into a terrorism act. You have no idea of the exact source computer of the flash disk. You have been requested to examine the flash, see if you can find some incriminating evidence, and maybe even tie it specifically back to a computer. The first thing you would do is create a backup image of the flash disk. As the flash disk is a piece of evidence, we want to preserve it in its originality the best we can. This image of the flash disk will be an exact byte-for-byte replica of the flash, copied to a special file on our hard disk. In Windows, you will click on “Z:” or “X:” to get to the flash disk drive, depends on how much disk on yor windows system. In Linux, physical devices are treated as a file. In most cases, the flash drive is /dev/sda or /dev/sdb. If you had another flash drive, it would most likely be /dev/sda1 or /dev/sdb1, and so forth.
Before inserting the flash into our computer, check whether or not the switch on the flash disk is set to be write protected or not. If it is not, then change it to a write protected state to ensure that no data can be modified on this original source disk. Note this in your Chain of Custody log that you should be keeping. Next, one would insert the flash disk into the drive. To see where the system read flash as a device, we can use dmesg command:

# dmesg | tail
[ 1316.449637] sd 2:0:0:0: [sdb] Write Protect is off
[ 1316.449650] sd 2:0:0:0: [sdb] Mode Sense: 23 00 00 00
[ 1316.449655] sd 2:0:0:0: [sdb] Assuming drive cache: write through
[ 1316.462614] sd 2:0:0:0: [sdb] 1953792 512-byte hardware sectors (1000 MB)
[ 1316.465613] sd 2:0:0:0: [sdb] Write Protect is off
[ 1316.465626] sd 2:0:0:0: [sdb] Mode Sense: 23 00 00 00
[ 1316.465631] sd 2:0:0:0: [sdb] Assuming drive cache: write through
[ 1316.465643]  sdb: sdb1
[ 1316.471823] sd 2:0:0:0: [sdb] Attached SCSI removable disk
[ 1316.471922] sd 2:0:0:0: Attached scsi generic sg2 type 0

In this point, we see that Linux read flash into /dev/sdb1 device. This will bring up a brief listing of the contents on the disk, if it is in fact readable. Next, you will want to proceed with making the image of the flash. We will a very helpful utility called dd. With this utility, you can specify an input file, an output file, and any other special parameters to replicate. In our case, the input file would be the flash drive, and the output will be a file called flash1.img within our /evidence folder.

# dd if=/dev/sdb of=/evidence/flash1.img bs=512 ; //thanks to Mr. Nanni Bassetti for the correction

The bs specifies the block size, which is 512k in this case. When copying a flash, it is best to set this at 512. When copying such devices as hard drives, you may want to set this larger, such as 1k. The block size largely affects how  quickly, or slowly, the system will copy the data. When in doubt, it is safer to go with a smaller number. Now, lets obtain a unique signature called an SHA hash of the flash disk. A SHA hash is a special cryptography algorithm. A brief synopsis of this is that no two files or disks can have the same SHA hash value if any bytes of data at all differ between them. This is extremely powerful in demonstrating in court the integrity of a file or files. So, to obtain the SHA hash of the flash disk drive dev/sdb1:

# sha1sum dev/sdb
c3dae2b3b034a0d63a328b84c66d444103d76b2b dev/sdb

That long string that starts with “c3dae…” is the returned hash value. You will want to save this information. Now, lets obtain the hash value of the image file we created. As dd tries to perform an exact byte-for-byte replica of its source, we should expect the SHA hash to be the same:

# sha1sum /evidence/image.flash1
c3dae2b3b034a0d63a328b84c66d444103d76b2b /evidence/image.flash1

Notice the SHA hash is the exact same. This is very good! We have an exact replica of the evidence. You can remove the flash and put it somewhere safe. Now, lets output this long hash to a file in our evidence folder. This will allow us  to demonstrate to a court that our analysis was performed on an exact copy of the evidence and that it was not tampered with.

# sha1sum /evidence/flash1.img </evidence/flash1img.sha1sum

To see the file you just created:

# cat /evidence/flash1img.sha1sum
c3dae2b3b034a0d63a328b84c66d444103d76b2b /evidence/image.flash1

Next, lets take advantage of a helpful utility called the “file” utility. This program takes a look at a particular file specified, and will try and look for unique “header” information to identify exactly what type of file it is. You typically expect a file that ends in .gif, such as farm.gif, to be a picture file. Likewise for .jpg files, .bmp files, etc. However, this may not be the case. You may call a file anything you would like. I can create a document within Microsoft Word, and save it as champlain.gif. This does not make it an image file. When encountering a file of unknown origin, this is a great place to start trying to figure out what was used to actually create the file. So, lets try and use the “file” utility on our image itself, to see if we can identify the file system that is present.
# file /evidence/flash1.img
We can see it is an unlabelled flash disk with the FAT file system. It appears to be in “MSDOS5.0” format, which tells us it was probably from a Microsoft operating system. Linux natively supports reading the FAT file system, so we can actually read this disk.The next step to actually reading files from the image is to do something known as mounting. When you mount a device in Linux, you are basically opening it up for access. When you first boot your Linux computer, the system automatically mounts your hard drive, CD-ROM drive, and any other disks that are connected. In our case here, we are going to be mounting the image file itself, and tricking the operating system into thinking this is a flash disk. (2)
# mkdir /mnt/analysis  # mount –t vfat –o ro,noexec,loop /evidence/flash1.img /mnt/analysis
The first line creates a directory called analysis. Remember, Linux looks at devices at a file level. We will use this directory to attach the image we are mounting to. The next line tells us to mount the file system as read-only and not allow execution of binaries that are in the image. Additionally, notice the loop parameter. This is a special method within Linux to mount the image file using a loop back interface, which is where it tricks it into thinking it is a real flash disk.Now, lets go into our newly mounted image and take a look around. To do so, we can type:
#cd /mnt/analysis
and be within the mounted image. The next step is to obtain an SHA hash of every single file on the flash disk.A defense lawyer may later question whether the data has been altered since it was received, or at any time between when it was received and trial. You will want to demonstrate that without a doubt it has not. We will output this list to a file called flash1img.sha1filehash within our evidence folder.
# find . –type f –exec sha1sum {} \;/evidence/flash1img.sha1filehash
The above command uses the find utility. This will chain the name of each file it finds and send it to sha1sum, which is what the {} indicate. Next, the “>” tells Linux to output all of this information to a file specified after it as /evidence/flash1img.sha1filehash. Now, lets take a look at a friendly list of all the files on the disk itself. We can use the “ls” command to list the contents on the flash. The “-alR” parameters are passed to the ls command and basically tell it to list all files, including dates,times, and permissions, and recursively go through the entire file system.
# cd /mnt/analysis
# ls –alR<br />drwxr-xr-x   2 bebek root   1024 2008-02-04 11:54 .
drwxr-xr-x 53 bebek bebek 4096 2008-02-04 11:55 ..
-rw-r--r--  1 bebek bebek 5774 2008-02-04 11:54 053.jrc
-rw-r--r--  1 bebek bebek 3333 2008-02-04 11:54 nitro.jrc
This will present us with a nice list of files. In our particular example above, we see an interesting file called crackdealers.d. However, when you simply try and view crackdealers.d with the cat command (cat crackdealers.d), you receive a bunch of gibberish in return. Lets see if the Linux file utility can identify what type of file this actually is.
# file 053.jrc
053.jrc: ASCII English text, with CRLF line terminators
This is interesting. Since we don’t have special application to open.jrc file installed on this machine, let us just see if we can just see of the raw text within the file to reveal more clues. To do so, we will use a utility called “strings”. This utility basically goes inside of the specified file, and pulls out any raw text that it can recognize. Since this returned information may scroll past a single screen, we will also use a utility called “less”. This handy utility will display given text one screen at a time. It allows you to use your keyboard arrow keys to scroll back and forth within the text. The “|” command basically tells Linux to take the results of the strings utility, and pipe this into the less utility.
# strings 053.jrc | less
How to Make Dynamite
Dynamite is nothing more than just nitroglycerin (read nitro.jrc) and a stablizing
agent to make it much safer to use.   For the sake of saving time, I
will abbreviate nitroglycerin with a plain NG.   The numbers
are percentages, be sure to mix these carefully and be sure to use the
exact amounts.   These percentages are in weight ratio, not volume.
no.   ingredients           amount
#1    NG                    32
sodium nitrate              28
woodmeal                    10
ammonium oxalate            29
guncotten                   1
#2    NG                    24
potassium nitrate           9
sodium nitate               56
woodmeal                    9
ammonium oxalate            2
#3    NG                    35.5
potassium nitrate           44.5
woodmeal					6
guncotton					2.5
vaseline                    5.5:
Now this is interesting. Apparently, we have some information related to dynamite cookbook. Additionally, for some reason, information about nitroglycerin is coming up in the file. Was the document created and saved on one of their computers? Lets see if we can search out any further information on the flash related to any of this. To do so, lets build a list of search words we want to seek out and put these all into a file. First, to do so, lets open a new textfile with the vi text editor.
# vi /evidence/searchcriteria.txt
Now, lets search the image for any occurrences of those words you typed in the /evidence/searchcriteria.txt file. To do so, we are going to use the grep utility. This is a very powerful text search utility. the parameters –aibf passed to the  utility basically tell it to recursively search the destination, ignore binary data (b), and to use the input file(f) /evidence/searchcriteria.txt as our word list. We are going to be searching the flash1.img file that we created earlier, which again, is an exact replica of our evidence. Any results will be outputted to the /evidence/searchcriteria.results file which we can review later.
# grep –aibf /evidence/searchcriteria.txt /evidence/flash1.img >/evidence/searchcriteria.results
Now, lets view our results file with the cat utility.
# cat /evidence/searchcriteria.results
The cat utility will return our results, but with the embedded binary also. Lets see if we can view it in a bit friendlier format with the strings program:
# strings /evidence/searchcriteria.results

Jl. Janti
So, it appears that another info hit comes up from somewhere else on the image. The number at the beginning of each line tells us the byte location on the disk of roughly where the match was found. So, lets browse out to that area of the image and see what we can find. To do so, we are going to use what is known as a HEX viewing utility called xxd. This utility will display the raw binary and hexadecimal data written to a file. This is very powerful, in that it will show you all the raw characteristics of a file, even things that someone may be trying to hide.
# xxd –s 117376 /evidence/flash1.img | less
Now, we can see the information from the hex editor.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About Spentera

We are specializing in penetration test, vulnerability assessment, computer forensics, as well as intrusion analyst and malware analysis. Customers can contact us directly at contact[at]spentera[dot]id, or use Contact Our Team menu on the sidebar.