After examining the forensic image of the floppy disk recovered from Joe Jacobs' house, it is apparent that Joe has been dealing to six high schools in total, and has been doing so since at least April of 2002. Joe attempted to "randomize" his visits to the high schools using an Excel spreadsheet, mapping days of the week to high schools in a not so random order. Joe Jacobs' supplier Jimmy Jungle is implicated in two of the recovered files, this also backs up Joe's statement to the detectives: "The Columbians couldn't grow it better! My supplier not only sells it direct to me, he grows it himself.". Jimmy Jungle lives at 626 Jungle Ave Apt 2, Jungle, NY 11111.
The lack of computer equipment and the presence of a floppy disk at Joe's house indicate he has used a computer offsite to do his electronic planning and communications. His place of work, if any, would be a good place to start looking for further evidence. The presence of "AFRL" in the deleted Jimmy Jungle.doc file's properties gave hits using a google.com search to the "Air Force Research Lab", perhaps Joe works there or has access to a machine there. The recovered data show the following about the machine/s Joe has been using:
The evidence shows the floppy disk files and file structures were intentionally modified to obscure covert information.
See the Recovered Data section to view the recovered file data.The bulk of this examination was performed on a PC running Mandrake Linux 8.1 with various sections performed/verified on several PCs running Windows 95 and XP.
Copy the MD5 hash for this challenge from the Honeynet web site into a new text file named image.zip.md5 and rearrange it into a valid md5sum output:
b676147f63923e1f428131d59b1d6a72 image.zip
download the image.zip challenge archive into the same directory and verify the MD5 hash of the archive:
$ md5sum -c image.zip.md5 image.zip: OK
unzip the archive if it verified ok:
$ unzip image.zip
set the image file to read only since we don't want to modify the contents:
$ chmod 400 image
create a new directory to act as the mount point for the image and another to hold any recovered data:
$ mkdir floppy $ mkdir files
check the file type of the image file to determine what type of mount we will use:
$ file image > image.ftype $ cat image.ftype image: x86 boot sector, system MSDOS5.0, FAT (12 bit)
ok, looks like a valid FAT12 formatted floppy, so let's mount it read only as root:
# mount -t msdos -o fat=12,ro,loop,nodev,noexec,noatime image floppy/
Obtaining a directory listing of the floppy image shows two files, based on typical Windows file extentions, they appear to be a JPEG image and a regular executable. The use of the ~1 indicates these files have a Windows 9x and above long filename associated with them:
$ ls -AlR floppy > floppy.dirlist $ cat floppy.dirlist floppy: total 17 -rwxr-xr-x 1 root root 15585 Sep 11 08:30 coverp~1.jpg* -rwxr-xr-x 1 root root 1000 May 24 08:20 schedu~1.exe*
checking the file types for the listed files results in the coverp~1.jpg file showing up as a DOS formatted floppy disk:
$ file floppy/* > floppy.ftypes $ cat floppy.ftypes floppy/coverp~1.jpg: PC formatted floppy with no filesystem floppy/schedu~1.exe: Zip archive data, at least v2.0 to extract
A quick look at the coverp~1.jpg file in a binary editor shows the presence of 512 - 0xF6 format code bytes used in FAT formats followed by 0x00 null bytes for the remainder of the file length; clearly this is not the JPEG image file data that the filename extension indicates. This file will require further examination later. For now let's move on to the schedu~1.exe file.
The schedu~1.exe file appears to be zipped data rather than an executable, let's try to unzip it:
$ unzip floppy/schedu~1.exe Archive: floppy/schedu~1.exe 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: floppy/schedu~1.exe may be a plain executable, not an archive
So we have two files on the recovered floppy that appear to be modified such that the casual observer would write them off as corrupted or such. The "real" data of these files will have to be recovered from the floppy image. Writing the image file back onto a real floppy disk and viewing it in Windows gives the same results for these files. Let's continue the initial reconnoissance of the image file using some of the @stake TASK tools on the image file.
Using the @stake TASK tools, we can determine the Modified, Accessed, Creation times for all files, including deleted files, on the floppy image. Since we already have some idea that the files and/or floppy low-level disk structures have been modified, we will most likely have to perform a manual examination of the low-level image structure.
We will start by running fls from the @stake TASK kit and dumping the output into the file image.body:
# fls -lf fat -m floppy/ image > image.body
next, we run mactime on the image.body file, this will show us all files, including deleted ones and the MACtimes for each file, MACtimes reveal the Modified, Accessed, and Created times on the files:
# mactime -b image.body > image.mactimes
# cat image.mactimes
Mon Apr 15 2002 14:42:30 20480 m.. -/-rwxrwxrwx 0 0 5 floppy/Jimmy Jungle.doc (_IMMYJ~1.DOC) (deleted)
Fri May 24 2002 08:20:32 1000 m.. -/-rwxrwxrwx 0 0 11 floppy/Scheduled Visits.exe (SCHEDU~1.EXE)
Wed Sep 11 2002 00:00:00 1000 .a. -/-rwxrwxrwx 0 0 11 floppy/Scheduled Visits.exe (SCHEDU~1.EXE)
20480 .a. -/-rwxrwxrwx 0 0 5 floppy/Jimmy Jungle.doc (_IMMYJ~1.DOC) (deleted)
15585 .a. -/-rwxrwxrwx 0 0 8 floppy/cover page.jpgc (COVERP~1.JPG)
Wed Sep 11 2002 08:30:52 15585 m.. -/-rwxrwxrwx 0 0 8 floppy/cover page.jpgc (COVERP~1.JPG)
Wed Sep 11 2002 08:49:48 20480 ..c -/-rwxrwxrwx 0 0 5 floppy/Jimmy Jungle.doc (_IMMYJ~1.DOC) (deleted)
Wed Sep 11 2002 08:50:26 15585 ..c -/-rwxrwxrwx 0 0 8 floppy/cover page.jpgc (COVERP~1.JPG)
Wed Sep 11 2002 08:50:38 1000 ..c -/-rwxrwxrwx 0 0 11 floppy/Scheduled Visits.exe (SCHEDU~1.EXE)
We have an additional file that will be added to the examination, the deleted file "Jimmy Jungle.doc". Let's start the data recovery process for all the files found in this image. First, we will run the image through a small perl script to extract more FAT12 related information. This script will show all Bios Parameter Block fields, root directory entries, FAT12 cluster chains and image file offsets based on those chains for each file. Examining the boot sector also reveals the presence of "NTLDR" indicating the OS used to format this disk was one of Microsoft's NT series Operating Systems. This includes NT 3.51, NT 4.0, 2000, and XP. Windows 9x/ME PCs do not use NTLDR for booting the OS.
$ ./flopcop image > image.flopcop
$ cat image.flopcop
image BIOS Parameter Block:
--------------------------------------------------
jmp_opcode = 0xeb3c90
oem_name = MSDOS5.0
bytes_per_sector = 512
sectors_per_cluster = 1
reserved_sectors = 1
n_fats = 2
root_entries = 224
total_sectors = 2880
media_descriptor = 0xf0
sectors_per_fat = 9
sectors_per_track = 18
n_heads = 2
hidden_sectors = 0
total_sectors_big = 0
drive_number = 0
unused_byte = 0x00
ext_boot_signature = 0x29
serial_number = 0xc4b1cdcf
volume_label = NO NAME
fat_type = FAT12
boot_signature = 0xaa55
boot_code =
--------------------------------------------------
33 c9 8e d1 bc f0 7b 8e d9 b8 00 20 8e c0 fc bd
00 7c 38 4e 24 7d 24 8b c1 99 e8 3c 01 72 1c 83
eb 3a 66 a1 1c 7c 26 66 3b 07 26 8a 57 fc 75 06
80 ca 02 88 56 02 80 c3 10 73 eb 33 c9 8a 46 10
98 f7 66 16 03 46 1c 13 56 1e 03 46 0e 13 d1 8b
76 11 60 89 46 fc 89 56 fe b8 20 00 f7 e6 8b 5e
0b 03 c3 48 f7 f3 01 46 fc 11 4e fe 61 bf 00 00
e8 e6 00 72 39 26 38 2d 74 17 60 b1 0b be a1 7d
f3 a6 61 74 32 4e 74 09 83 c7 20 3b fb 72 e6 eb
dc a0 fb 7d b4 7d 8b f0 ac 98 40 74 0c 48 74 13
b4 0e bb 07 00 cd 10 eb ef a0 fd 7d eb e6 a0 fc
7d eb e1 cd 16 cd 19 26 8b 55 1a 52 b0 01 bb 00
00 e8 3b 00 72 e8 5b 8a 56 24 be 0b 7c 8b fc c7
46 f0 3d 7d c7 46 f4 29 7d 8c d9 89 4e f2 89 4e
f6 c6 06 96 7d cb ea 03 00 00 20 0f b6 c8 66 8b
46 f8 66 03 46 1c 66 8b d0 66 c1 ea 10 eb 5e 0f
b6 c8 4a 4a 8a 46 0d 32 e4 f7 e2 03 46 fc 13 56
fe eb 4a 52 50 06 53 6a 01 6a 10 91 8b 46 18 96
92 33 d2 f7 f6 91 f7 f6 42 87 ca f7 76 1a 8a f2
8a e8 c0 cc 02 0a cc b8 01 02 80 7e 02 0e 75 04
b4 42 8b f4 8a 56 24 cd 13 61 61 72 0b 40 75 01
42 03 5e 0b 49 75 06 f8 c3 41 bb 00 00 60 66 6a
00 eb b0 4e 54 4c 44 52 20 20 20 20 20 20 0d 0a
52 65 6d 6f 76 65 20 64 69 73 6b 73 20 6f 72 20
6f 74 68 65 72 20 6d 65 64 69 61 2e ff 0d 0a 44
69 73 6b 20 65 72 72 6f 72 ff 0d 0a 50 72 65 73
73 20 61 6e 79 20 6b 65 79 20 74 6f 20 72 65 73
74 61 72 74 0d 0a 00 00 00 00 00 00 00 ac cb d8
image Image file offsets:
--------------------------------------------------
data_offset = 0x00004200 16896
fat1_offset = 0x00000200 512
fat_size = 0x00001200 4608
root_offset = 0x00002600 9728
root_size = 0x00001c00 7168
image MSDOS 8.3 filename info:
--------------------------------------------------
filename = ĺIMMYJ~1 [deleted]
file extention = DOC
file attributes - uuadvshr
= 00100000
first cluster = 0x0002 2
image offset = 0x00004200 16896
file length = 0x00005000 20480
file slack = 0x00000000 0
file cluster trace with image offset in hex
[cluster:offset]:
0002:00004200
--------------------------------------------------
filename = COVERP~1
file extention = JPG
file attributes - uuadvshr
= 00100000
first cluster = 0x01a4 420
image offset = 0x00038600 230912
file length = 0x00003ce1 15585
file slack = 0x0000011f 287
file cluster trace with image offset in hex
[cluster:offset]:
01a4:00038600
--------------------------------------------------
filename = SCHEDU~1
file extention = EXE
file attributes - uuadvshr
= 00100000
first cluster = 0x0049 73
image offset = 0x0000d000 53248
file length = 0x000003e8 1000
file slack = 0x00000018 24
file cluster trace with image offset in hex
[cluster:offset]:
0049:0000d000 004a:0000d200 004b:0000d400 004c:0000d600
004d:0000d800
As indicated by the mactime and flopcop output, the file JIMMYJ~1.DOC has been deleted from the floppy disk. The COVERP~1.JPG file has an inconsistancy in that the file size according to the FAT does not match the actual FAT cluster chain length. The SCHEDU~1.EXE file also has inconsistancies, it's file size is less than what it's FAT cluster chain is showing. We also have an idea that the COVERP~1.JPG file's first cluster is not pointing to it's actual data, this is why the JPEG is showing 0xf6 in it's first sector and 0x0 in the remainder of it's bytes. Let's run the whole image file through our gettypes perl script. This script will attempt to find known file signatures within the image and print the offset into the image when it gets a hit.
$ ./gettypes image > image.datatypes $ cat image.datatypes Possible data types found in image with offsets: hex dec type -------------------------------------------------- 0x00004200 16896 application/msword 0x00009000 36864 video/unknown 0x00009200 37376 image/jpeg 0x0000d000 53248 application/x-zip 0x0000d400 54272 text/plain 0x0000d800 55296 application/octet-stream
Matching up with the output of flopcop we can see the differences in the image offsets based on the FAT and our calculations:
| File Name | Offset by FAT | Real Offset |
| JIMMYJ~1.DOC | 0x00004200 | 0x00004200 |
| COVERP~1.JPG | 0x00038600 | 0x00009200 |
| SCHEDU~1.EXE | 0x0000d000 | 0x0000d000 |
We will now recover the JIMMYJ~1.DOC file using another perl script based on the image offset and file length from our table, this file is a multiple of 512 bytes so there is no slack space at the end of the file:
$ ./getfile image 0x4200 20480 files/JIMMYJ~1.DOC
For the COVERP~1.JPG file, we can see there has been some tampering with the low level file FAT structure as well as the additional spaces appended to the long filename entry. This file shows a length of 15585 bytes, but the cluster chain only shows one cluster. This chain should show 31 used clusters for a total of 15872 bytes to hold the file. Since we have already seen that the file contains 512 bytes of 0xf6 followed by remaining 0x00, we will have to manually scan the image for a marker to find the actual file contents and offset. Our gettypes script found what we hope is the offset to this data, but we will look for the marker that signifies a JPEG image as an added measure. Searching the file in a binary editor for the string "JFIF" produces a hit at offset 0x9206.
Aligning to the start of the sector - 0x9200 and extracting 15872 bytes should give us the JPEG image with it's slack space:
$ ./getfile image 0x9200 15872 files/COVERP~1.JPG
The last file, SCHEDU~1.EXE, has also been modified to obscure it's contents. The cluster trace shows 5 clusters used for a total of 2560 bytes, but the directory entry only shows a 1000 byte file. Extracting the full 2560 bytes from offset 0xd000 in the image produces the full zipped archive:
$ ./getfile image 0xd000 2560 files/SCHEDU~1.EXE
Manual inspection of the image reveals there are no more hidden data within the image, the remaining hits from gettypes are within the files we just recovered and can be ignored.
Examining JIMMYJ~1.DOC reveals that Joe Jacobs is in the business of dealing to high school students. His supplier, Jimmy Jungle, appears to have sent Joe the COVERP~1.JPG file along with a covert password. We now have to search the COVERP~1.JPG file for this password. Since we recovered the file along with it's slack space, we can do a strings search on the file to see if the password is in plain view:
$ strings -t x files/COVERP~1.JPG > coverpage.strings
Examining the output reveals the text string "pw=goodtimes" at offset 0x3d20. This is a good candidate for our zip file password. Let's try to extract:
$ unzip -P goodtimes files/SCHEDU~1.EXE -d files Archive: files/SCHEDU~1.EXE inflating: files/Scheduled Visits.xls
Clearly the SCHEDU~1.EXE file is really a zip file with the file extention changed to exe. Running this file within DOS or Windows results in the error "file is not executable". Normally, a self-extracting zip file will have the exe extention, but it will also contain an executable unzipping stub program, not the case here. The exe extention was used to frustrate the casual viewing of the file contents. Renaming this file in Windows with a zip extention allows WinZip to view and extract the compressed xls file.
Viewing the "Scheduled Visits.xls" file reveals the fact Joe has been dealing to the high schools since at least April 2002. Also, he has been dealing to five other high schools in addition to Smith Hill.
Running file on our newly extracted files gives us the types:
$ file files/* > files.ftypes $ cat files.ftypes files/COVERP~1.JPG: JPEG image data, JFIF standard 1.01, resolution (DPI), 96 x 96 files/JIMMYJ~1.DOC: Microsoft Office Document files/SCHEDU~1.EXE: Zip archive data, at least v2.0 to extract files/Scheduled Visits.xls: Microsoft Office Document
Although we have uncovered plenty of incriminating evidence, let's take a few more steps. We will run the Microsoft Office Documents through Foundstone's BinText strings tool. This tool will extract ASCII strings as well as Unicode strings. Some key output values below (see appendix):
Jimmy Jungle.doc, the presence of smarttags and Word 10.0 indicates that Joe is using a PC with at least Office XP installed:
urn:schemas-microsoft-com:office:smarttags Microsoft Word 10.0
Scheduled Visits.xls, the presence of a printer description indicates what type of printer Joe is using:
HP Deskjet 970Cxi
Within Excel, the properties for the Scheduled Visits.xls file shows the author as "CSTC" and the company as "AFRL". A google search on AFRL resulted in many hits to the Air Force Research Lab, http://www.afrl.af.mil/. Is Joe affiliated with the Air Force and trying to make a few extra bucks on the side?
When viewing the COVERP~1.JPG file in an image viewer, the edges of the non-white pixels appear very grainy. Could this file contain a steganograpic message or is the grainyness a result of the jpeg's compression ratio? Downloading several stego software packages for both Linux and Windows and then analyzing the file shows there is probably not any stego in it. This is difficult to confirm though, because stego software is not standardized and so a custom package's methods of concealment may go unnoticed. It is strange that Joe knows enough about low level disk structure to modify the floppy the way he did, but he did not use any form of encryption or stego on his files ( I know this challenge would be much more difficult if that were the case ). It's also possible that Joe used a pre-canned application to modify the disk structure, eliminating much of the skill and effort required to do it manually.
1. Who is Joe Jacob's supplier of marijuana and what is the address listed for the supplier?
Based on the contents of the deleted file JIMMYJ~1.DOC, Joe Jacobs supplier name and address are:
Jimmy Jungle
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?
The string "pw=goodtimes" was found within the slack space of the COVERP~1.JPG file. This string is the password to allow the extraction of the Scheduled Visits.xls spreadsheet file from the SCHEDU~1.EXE zip file. Slack space is the allocated but unused space within a file. When a file is created on a floppy disk, it is allocated enough clusters to hold the file, but clusters are units of 512 bytes in this case. This causes files that are not a multiple of 512 bytes in size to have extra "remainder" bytes at the end of the last cluster in the file. This space can be used to hide any type of data that will fit within it. So long as the original file is not modified, this hidden data will remain intact and invisible to the normal file system rendering functions. For example, a file with size 513 bytes will be allocated to 2 clusters on a FAT 12 formatted floppy disk, since 2 clusters in this scheme is equal to 1024 bytes, the file will have 1024 - 513 = 511 bytes of slack space.
3. What (if any) other high schools besides Smith Hill does Joe Jacobs frequent?
Joe Jacobs has been distributing to the following high schools along with Smith Hill:
4. For each file, what processes were taken by the suspect to mask them from others?
The JIMMYJ~1.DOC file was deleted in the usual manner from within Windows, this was the easiest file to recover. The COVERP~1.JPG file's root directory entry was modified to point at a different cluster than the actual file data, subsequently, the FAT chain for this cluster is set to 0x000, meaning it's a free cluster. This is why the original file shows up as one sector of 0xf6 followed by 0x00, the low level fat routines allocated the proper size for the file in memory and zeroed it out, but only a single cluster was read into that memory. The SCHEDU~1.EXE file's size entry was modified to be less than the actual data size as shown by the flopcop cluster trace. In this file's case, only 1000 bytes are read into the allocated memory cutting off the rest of the file, the file is also password protected. Also, the file extention was changed from ZIP to EXE to further confuse the casual viewing of the contents. Both the SCHEDU~1.EXE and COVERP~1.JPG files have several space characters appended to their long filenames.
5. What processes did you (the investigator) use to successfully examine the entire contents of each file?
Using known Open Source and Proprietary analysis tools, the supplied forensics image was examined for known data types. The examination produced offsets into the image where the data is found and subsequently extracted from. Each extracted file was then examined in a similar manner looking for key evidence to aid in the investigation. Several custom scripts were also used in the examination to aid in finding and summarizing the data and offsets.
Bonus: What Microsoft program was used to create the Cover Page file? What is your proof ? (Proof is the key to getting this question right, not just making a guess).
Requires further investigation.
Recovered MS OfficeXP Word document contents: JIMMYJ~1.DOC, image offset: 0x00004200, file length: 20480 bytes
Jimmy Jungle 626 Jungle Ave Apt 2 Jungle, NY 11111 Jimmy: Dude, your pot must be the best - it made the cover of High Times Magazine! Thanks for sending me the Cover Page. What do you put in your soil when you plant the marijuana seeds? At least I know your growing it and not some guy in Columbia. These kids, they tell me marijuana isn't addictive, but they don't stop buying from me. Man, I'm sure glad you told me about targeting the high school students. You must have some experience. It's like a guaranteed paycheck. Their parents give them money for lunch and they spend it on my stuff. I'm an entrepreneur. Am I only one you sell to? Maybe I can become distributor of the year! I emailed you the schedule that I am using. I think it helps me cover myself and not be predictive. Tell me what you think. To open it, use the same password that you sent me before with that file. Talk to you later. Thanks, Joe
Recovered JPEG image file document contents: COVERP~1.JPG, image offset: 0x00009200, file length: 15585 bytes
Recovered password to unzip SCHEDU~1.EXE zip file, found in the file slack of cover page.jpgc, image offset: 0x0000cf20
pw=goodtimes
Recovered Zip file SCHEDU~1.EXE: image offset: 0x0000d000, file length: 2560 bytes
Archive: SCHEDU~1.EXE 2560 bytes 1 file -rw-rw-rw- 2.0 fat 16896 B- defN 23-May-02 11:20 Scheduled Visits.xls 1 file, 16896 bytes uncompressed, 2270 bytes compressed: 86.6%
Recovered MS OfficeXP Excel document contents after unzipping SCHEDU~1.EXE: Scheduled Visits.xls
File listing for the challenge entry
Scripts ------- lab/flopcop Perl, FAT12 analyzer lab/getfile Perl, get data from image at offset lab/gettypes Perl, get data types from image file Output files ------------ lab/bintext_image.txt Foundstone bintext output lab/coverpage.strings JPEG strings output lab/files.ftypes extracted file types lab/floppy.dirlist mounted floppy dir listing lab/floppy.fat1 floppy fat hex dump lab/floppy.ftypes mounted floppy file types lab/floppy.goodtimes image file hidden password hex dump lab/floppy.rootdir floppy root directory hex dump lab/image.body fls body file output lab/image.datatypes data types found in the image lab/image.flopcop flopcop script FAT12 output lab/image.ftype image file type lab/image.mactimes mactime output from image.body lab/jimmyjungledoc.txt Foundstone bintext output lab/schedu~1.exe.zipinfo initial scheduledvisits.exe zipinfo lab/schedu~1.exe.zipinfo2 extracted scheduledvisits.exe zipinfo lab/scheduledxls.txt Foundstone bintext output lab/files/COVERP~1.JPG recovered JPEG file lab/files/JIMMYJ~1.DOC recovered Word document file lab/files/SCHEDU~1.EXE recovered Zip archive file lab/files/Scheduled Visits.xls extracted Excel spreadsheet lab/floppy/coverp~1.jpg mounted original JPEG image lab/floppy/schedu~1.exe mounted original Zip archive
Thanks to the Honeynet Project and Daniel J. Kalil for an interesting and often times frustrating challenge.
N. DeBaggis