Analysis of the Project Honeynet Scan of the Month #24
Erik Cabetas, Computer Science major, University of Florida
ErikSL2 AT yahoo.com
The purpose of this months challenge is to use forensic data analysis to assist law enforcement in a fictional crime scenario. In this scenario a low level drug dealer named Joe Jacobs has been apprehended. It is my goal to analyze a floppy disk that was in the possession of Mr. Jacobs and provide law enforcement with any evidence that can assist in their case against Mr. Jacobs. In this analysis I hope to provide answers to the challenge questions as well as provide verbose details so others may learn from my analysis.
1.1 Setup of Analysis Environment
All analysis was done from one directory, the following subdirectories were created:
- recovered/ This directory contains all recovered files
- mounted_image/ This directory is where the image is mounted to
- autopsy_files/ This directory contains files produced by, or associated with The Autopsy Forensic Browser
Download and verification:
The image was mounted using the following command:
$mount -o loop,ro,noexec,nodev ./image ./mounted_image
The following fsmourge file was created for use with Autopsy. The dls, body and timeline files were created during the course of the investigation. Also note that the time zone was not provided, nor was it needed to answer the challenge's questions:
image fat / EST5EDT
image.dls dls image
1.2 Investigation Tools Used
In this investigation the following programs were used:
file v3.37, md5sum (textutils v2.0.21), unzip v5.5, dd (fileutils v4.1), xxd v1.10, ImageMagick 5.4.3, Microsoft Word 10,
Microsoft Excel 10
The Autopsy Forensic Browser 1.61 and TASK 1.51, both authored by Brian Carrier, were
used extensively. My thanks goes out to the author for providing the forensics community with such useful tools.
From first observation of the mounted disk we see that some things are "not right". The file command reports that the "cover page.jpgc" file's header is "PC formatted floppy". The file command also reports that "Scheduled Visits.exe" has a valid zip file header. The unzip command , however reports that there is something wrong with the file structure. These clues were noted.
$ls -ali mounted_image/
1 drwxr-xr-x 2 root root 7168 Dec 31 1969 ./
4 -rwxr-xr-x 1 root root 15585 Sep 11 08:30 cover page.jpgc *
5 -rwxr-xr-x 1 root root 1000 May 24 08:20 schedu~1.exe*
mounted_image/cover page.jpgc : PC formatted floppy with no filesystem
mounted_image/schedu~1.exe: Zip archive data, at least v2.0 to extract
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive. In the
latter case the central directory and zipfile comment will be found on
the last disk(s) of this archive.
note: mounted_image/schedu~1.exe may be a plain executable, not an archive
unzip: cannot find zipfile directory in one of mounted_image/schedu~1.exe or
mounted_image/schedu~1.exe.zip, and cannot find mounted_image/schedu~1.exe.ZIP, period.
Using Autopsy we can make summaries of the disk layout. From Autopsy's file browsing mode we note that there is a deleted file "Jimmy Jungle.doc". The inode for this file points to sector 33 and the file size is 20480 bytes. From our sector summary we see that sectors 33-72 are marked as free and this range happens to be 20480 bytes in size. So assuming the deleted file exists in this sector range we use dd to extract the data from the image. Our assumption proves correct; we have recovered the file "Jimmy Jungle.doc". The file command reports the extracted file as a "Microsoft Office Document", and the md5sum is B775EB6A4CCC319759D9AAAE1E340ACC. After successfully recovering the file and opening it in Word we find information relevant to the investigation. We also find further information from the file properties...the author is "0000", it was last saved by "0000tl", and it had been revised 9 times.
Again from file browsing mode we investigate further into the listing for "cover page.jpgc". Inode 8 is associated with this file, and points solely to sector 451. Browsing this sector using the hex display of inode browsing mode reveals that the entire sector is overwritten with the value 0xF6. This would explain why the file command originally labeled this file as PC formatted, 0xF6 is the constant used to format a disk. A quick look at the data in the sectors around sector 451 reveals that inode 8 references an unallocated and formatted disk region. Assuming that this inode was manipulated and not just totally fabricated, we continue our search for the file data.
From our sector summary we see that sectors 73-108 are marked as being allocated and are thus a good area to focus on. Using the hex display in data browsing mode we open sector 73 and see that this sector begins with the SOI(start of image) marker 0xFFD8 as defined in the JPEG File Interchange Format standard. The sector also contains the null terminated string "JFIF" (0x4A46494600) which is identified in the standard as part of the APP0 marker. Now that we have identified the start of the JPEG file we must find where it ends. Conveniently the JPEG standard defines an EOI(end of image) marker 0xFFD9, we can use this value to find where the JPEG file ends. One way of finding the EOI value would be to just search the entire image for the value, but this would not be an effective way of finding the end of the file because there is a good chance that 0xFFD9 appears more than once in the image. Luckily we already have a hint of where to find the EOI value!
From the sector 103. At the offset 0x000CF20 the string "pw=goodtimes" was found, this clue should be noted as we continue the investigation. To find the end of the JPEG file we make the assumption that the EOI marker in sector 103 matches the SOI marker found in sector 73. We then use dd to extract the sector range 73-103. Our assumptions prove to be correct, we have recovered the file "cover page.jpg". The file command reports the extracted file as "JPEG image, data, JFIF standard 1.01, resolution (DPI), 96x96", and the md5sum is 28CFE7FE68F5B13071A2CE0B87FF1E9B. Other information can be extracted from the JPEG file using the identify program from ImageMagick.
$identify -verbose "cover page.jpg"
Image: cover page.jpg
Format: JPEG (Joint Photographic Experts Group JFIF format)
Type: true color
Depth: 8 bits-per-pixel component
Resolution: 96x96 pixels/inch
Background Color: white
Border Color: #dfdfdf
Matte Color: grey74
User Time: 0.0u
Elapsed Time: 0:01
We have found files in the sector ranges 33-72 and 73-103. From the sector summary we know that the allocation block ends at sector 108. From inode browsing we know that there is a valid zip file header at sector 104. From our first observation analysis with the file and unzip commands we know that the "Scheduled Visits.exe" file might be corrupted in some way. Putting these clues together we make the assumption that file might actually start at sector 104 and end at sector 108. Using the hex display of data browsing mode we see that sector 108 contains the central file header signature as defined by the .zip file format specification. This is found in reversed byte order at offset 0x00091C of the disk image. Viewing of the sector range leads us to believe that the file exists in that range. We then use dd to extract sector range 104-108 and our assumptions again proves to be correct. We have now recovered the file "Scheduled Visits.zip". The file command reports the extracted file as "Zip archive data, at least v2.0 to extract" and the md5sum is 4E0BE275E3040701145E3235DD43EA4A.
When we try and unzip the extracted file we are prompted to enter a password. Using the clue that we found earlier in the slack space of the "cover page.jpg" file we try the password "goodtimes". Our attempt succeeds and we are rewarded with the file "Scheduled Visits.xls". The file command reports this file as a "Microsoft Office Document" and the md5sum is 0988DF42266FF538FB6101E7BC9D8E05. By the extension we can assume the file is an Excel spread sheet. When we open it, we see a listing of dates and places. From the file properties we learn that the file was authored by "CSTC", last saved by "CSTC", and the company name is "AFRL"
Now that we know the physical location of the files inside the disk image we can construct recover.sh, this is a shell script that recovers the files from the disk image and produces verification information in the form of md5sums.
2.2 Summary of Relevant Disk Information
These summaries were extrapolated from information found using Autopsy.
Summary of Sectors
#each sector is 512 bytes in size
0-32 marked as allocated
33-72 marked as free
73-108 marked as allocated
109-2878 marked as free
Summary of Inode/Sector Mapping
#each inode structure references certain sectors that contain the file's data
#these are the disk's inode/sector references
inode(2) -> sectors( 19 20 21 22 23 24 25 26 27 28 29 30 31 32 )
inode(5) -> sectors( 33 )
inode(8) -> sectors( 451 )
inode(11) -> sectors(104 105)
Summary of FileSystem Info
#times may be different, as the timezone was never given
Name cover page.jpgc (COVERP~1.JPG)
Written 2002.09.11 08:30:52 (EDT)
Accessed 2002.09.11 00:00:00 (EDT)
Created 2002.09.11 08:50:26 (EDT)
Name Jimmy Jungle.doc (_IMMYJ~1.DOC)
Written 2002.04.15 14:42:30 (EDT)
Accessed 2002.09.11 00:00:00 (EDT)
Created 2002.09.11 08:49:48 (EDT)
Name Scheduled Visits.exe (SCHEDU~1.EXE)
Written 2002.05.24 08:20:32 (EDT)
Accessed 2002.09.11 00:00:00 (EDT)
Created 2002.09.11 08:50:38 (EDT)
#times may be different, as the timezone was never given
#this timeline is included for completeness
SIZE MAC PERMISSIONS UID GID INODE NAME
Mon Apr 15 2002 14:42:30
20480 m.. -/-rwxrwxrwx 0 0 5 /Jimmy Jungle.doc (_IMMYJ~1.DOC) (deleted)
20480 m.. -rwxrwxrwx 0 0 5 <image-_IMMYJ~1.DOC-dead-5 >
Fri May 24 2002 08:20:32
1000 m.. -/-rwxrwxrwx 0 0 11 /Scheduled Visits.exe (SCHEDU~1.EXE)
Wed Sep 11 2002 00:00:00
1000 .a. -/-rwxrwxrwx 0 0 11 /Scheduled Visits.exe (SCHEDU~1.EXE)
20480 .a. -rwxrwxrwx 0 0 5 <image-_IMMYJ~1.DOC-dead-5 >
20480 .a. -/-rwxrwxrwx 0 0 5 /Jimmy Jungle.doc (_IMMYJ~1.DOC) (deleted)
15585 .a. -/-rwxrwxrwx 0 0 8 /cover page.jpgc (COVERP~1.JPG)
Wed Sep 11 2002 08:30:52
15585 m.. -/-rwxrwxrwx 0 0 8 /cover page.jpgc (COVERP~1.JPG)
Wed Sep 11 2002 08:49:48
20480 ..c -/-rwxrwxrwx 0 0 5 /Jimmy Jungle.doc (_IMMYJ~1.DOC) (deleted)
20480 ..c -rwxrwxrwx 0 0 5 <image-_IMMYJ~1.DOC-dead-5 >
Wed Sep 11 2002 08:50:26
15585 ..c -/-rwxrwxrwx 0 0 8 /cover page.jpgc (COVERP~1.JPG)
Wed Sep 11 2002 08:50:38
1000 ..c -/-rwxrwxrwx 0 0 11 /Scheduled Visits.exe (SCHEDU~1.EXE)
3.1 Answers to Challenge Questions
Throughout these answers the assumption is made that the information found in recovered files
is genuine and that Mr. Jacobs is not attempting to fool investigators with false leads.
1. Who is Joe Jacob's supplier of marijuana and what is the address listed for the supplier?
From the recovered file "Jimmy Jungle.doc" we find the following name and address:
626 Jungle Ave Apt 2
Jungle, NY 11111
2. What crucial data is available within the coverpage.jpg file and why is this data crucial?
Within the slack space at the end of the file we find the ASCII string "pw=goodtimes",
"goodtimes" was the password for the zip file that was recovered between sectors 104-108.
3. What (if any) other high schools besides Smith Hill does Joe Jacobs frequent?
The following schools are frequented by Mr. Jacobs:
Key High School
Leetch High School
Birard High School
Richter High School
Hull High School
4. For each file, what processes were taken by the suspect to mask them from others?
The "Jimmy Jungle.doc" file simply was deleted from the disk and the inode links set to zero, the information in inode 5 reflects this.
The "cover page.jpgc" file has an extension of ".jpgc". This was changed from the extension normally associated with JFIF files, ".jpg" or ".jpeg". Additionally the file was changed so that inode 8 no longer pointed to the sectors that contained this file, but instead the inode pointed to sector 451 which was located in a PC formatted disk region
The "Scheduled Visits.exe" file has an extension of ".exe". This was changed from the extension normally associated with zip files, ".zip". Additionally the inode was changed so that it didn't point to all the sectors that made the "Scheduled Vists.exe" file. Furthermore the file size value in the inode was changed to 1000 bytes.
5. What processes did you (the investigator) use to successfully examine the entire contents of each file?
A detailed report of my investigative procedures can be found in Section 2.1
Bonus Question: What Microsoft program was used to create the Cover Page file. What is your proof
Off the top of my head the only Microsoft program I know that can produce jpeg files is "Microsoft paint" that comes with windows. To confirm or deny the file was made with this program we open a new image in Microsoft paint and add some random data, we save it as "test.jpg". The file command reports "test.jpg" as "JPEG image, data, JFIF standard 1.01, resolution (DPI), 96x96". We compare the file header of "test.jpg" to that of the recovered "cover page.jpgc", both manually using xxd and also using the identify program. From this comparison we find that they are exactly the same in all the major parts of the JPEG file structure(ex. APP0 marker, APP0 length, identifier, version, units, etc.). In fact they are an exact copy from 0x0000000 to 0x00000A3. Additionally both the files use the value 0xA28A2800 to to pad the end of the JPEG file. With this information I am confident that "Microsoft Paint" was the program used to make the file "cover page.jpc".
3.2 Personal remarks
This was a fun challenge, my thanks goes out to the Honey Net Project and the Digital Forensic Research WorkShop for giving people the chance to hone their skills in a peer reviewed environment. I also would like to thank Brian Carrier and all authors of open source software....keep up the good work!
4.1 Listing of Files submitted:
http://www.w3.org/Graphics/JPEG/jfif3.pdf - This is the JFIF standard
http://www.pkware.com/support/appnote.html - This is the zip file format specification