HoneyNet Scan of the Month October -- Scan 24

Project submission by the CERIAS Computer Forensics Research Group

http://www.cerias.purdue.edu/homes/forensics


Analysis

Our analysis was performed on a Pentium III based Laptop running Debian 3.0. We started by downloading the image from the HoneyNet web site at http://www.honeynet.org/scans/scan24/image.zip . Then the MD5 checksum of the image was generated and it matched the checksum provided with the image:
florian@schlaraffenland:~/honeynet> md5sum image.zip
b676147f63923e1f428131d59b1d6a72  image.zip
After unzipping the image, we decided to first mount the image via the loopback device to a local directory and examine if there was anything useful there.
schlaraffenland:/home/florian/honeynet # mount -o loop image mnt/

schlaraffenland:/home/florian/honeynet # ll mnt/
total 25
drwxr-xr-x    2 root     root         7168 Dec 31  1969 .
drwxr-xr-x    4 florian  users         992 Oct 22 22:20 ..
-rwxr-xr-x    1 root     root        15585 Sep 11 08:30 cover page.jpgc

-rwxr-xr-x    1 root     root         1000 May 24 08:20 schedu~1.exe
Trying to open the file 'cover page.jpgc' in an image viewer resulted in an error, and since we were operating on a Linux computer we didn't try anything with the .exe file for now.

Next, we performed a 'strings' command on the image. This yielded a very large amount of useful information already. In addition to the two file names 'COVERP~1JPG' and 'SCHEDU~1EXE', a third file name, 'IMMYJ~1DOC', hinted at the existence of a (deleted?) Word document. This suspicion was confirmed as the entire text portion of the document as well as some Word formatting strings were shown a little further down in the 'strings' output. Furthermore, the string 'pw=goodtimes' could be some sort of password configuration or reminder. Finally, the two strings 'Scheduled Visits.xls' and 'Scheduled Visits.xlsPK' hint at the presence of some Excel file somewhere on the disk, possibly in PK-zip format. As there is too much other junk in the output of the 'strings' command we limit ourselves to only show the text portion of the supposed Word document:
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 kno
w 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 s
pend 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 t
hat you sent me before with that file. Talk to you later.
Thanks,
Joe

As a next step we utilized Brian Carrier's excellent Autopsy Forensic Browser to further investigate the image. After copying the image to the autopsy server's morgue directory and starting the autopsy server we were able to use a web browser to look at the file system.

The file browsing mode of Autopsy showed three files present on the system: cover page.jpgc(COVERP~1.JPG), Jimmy Jungle.doc(_IMMYJ~1.DOC), which was marked as deleted, and Scheduled Visits.exe(SCHEDU~1.EXE). Clicking on the file names to show the file contents produced junk for the first two files. The .exe file had a PK-zip header, leading us to believe that that file is a self-extracting zip archive. This was further confirmed by executing the 'file' command on the file from the mounted image:
florian@schlaraffenland:~/honeynet/mnt> file schedu~1.exe
schedu~1.exe: Zip archive data, at least v2.0 to extract
However, trying to unzip the file with 'unzip' produced an error "End-of-central-directory signature not found". We then decided to investigate the three files individually

The JPEG file

In Autopsy we performed a keyword search for the string 'JFIF', which should be a string found at byte 6 of each JPEG image. The search reported one occurrence of 'JFIF' found at block 73 of the image, with an offset of 6 bytes. Thus block 73 had to be the start of a JPEG file. We now went into Autopsy's data browsing mode and displayed the block allocation list. The list showed that blocks 0 through 32 were allocated, blocks 33 through 72 were free, blocks 73 through 108 allocated again, and the remainder of the blocks free. Given that the JPEG file starts at block 73, the first one of a range of allocated blocks, we copied out that range to a file via 'dd':
dd skip=73 bs=512 count=36 if=image of=cover.jpg
We were now able to view the file in an image viewer. But when we further examined the file 'cover.jpg' with hexdump, we noticed that there is a block of zeroes at address 0x3ce0 and following, the string "pw=goodtimes" at address 0x3d20, and the start of the PK-zip file at address 0x3e00 (all addresses relative to the beginning of the JPEG file). As byte 0x3e00 marks the beginning of block 31 within the image, we need only copy 31 instead of 36 blocks to copy out all the blocks that belong to the JPEG image:
dd skip=73 bs=512 count=31 if=image of=cover.jpg
The last end-of-file marker for the image 'ff d9' ends at address 0x3ce0 (15584), and 15585 is the length listed for the file in the directory. If one only wanted to copy out the file, one can do the following:
dd skip=37376 bs=1 count=15585 if=image of=cover.jpg
But this way the "pw=goodtimes" string in the slack space is lost! As a matter of fact, there is an earlier end-of-file JPEG marker located ending at address 0x2231 (8753). A
dd skip=37376 bs=1 count=8754 if=image of=cover.jpg
produces a file 'cover.jpg' that looks just like the larger ones. This is our strongest clue for the bonus question, but we do not have enough knowledge about image manipulation software to be able to identify what product simply places EOF markers in the middle of files, keeping the JPEG file artificially large.

The PK-zip archive

Given that the last 5 blocks that we initially copied out with 'dd' for the JPEG file didn't actually belong to it and the first of them (block 104 of the image) contained the beginning of the PK-zip file, we examined the last block of the five (block 108) of the image with Autopsy and found the string 'Scheduled Visits.xlsPK' toward the end. Thus
dd skip=104 bs=512 count=5 if=image of=schedule.exe
copied out all the blocks belonging to the PK-zip file. Again, the actual file is only 2420 bytes large (not the 2560 that the 5 blocks occupy) -- the size of 2420 was found by trying the smallest file size under which the file was successfully unzipped. Thus to only copy the file data, one can use:
dd skip=53248 bs=1 count=2420 if=image of=schedule.exe
Unzipping the file with 'unzip' now prompted us for a password and after typing in 'goodtimes' the Excel spreadsheet file 'Scheduled Visits.xls' was extracted. We were able to view the document via Excel through a Windows session started by a Citrix server.

The Word document

Since word file was deleted from the floppy and there was a chunk of free blocks from block 33 to 72, that we saw in Autopsy's allocation list in between chunks of allocated blocks, we simply copied out that range of free blocks:
dd skip=33 bs=512 count=40 if=image of=jimmy.doc
The resulting file 'jimmy.doc' appears to be a valid word file, which could be viewed with 'kword'.

Answers to the Questions

1. Who is Joe Jacob's supplier of marijuana and what is the address listed for the supplier?

Joe Jacob's supplier of marijuana is Jimmy Jungle, and the address listed is as follows:

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?

Technically, the crucial data is not part of the file itself, but rather is found in the unallocated slack space of the file's ending block. There the string "pw=goodtimes" can be found. This data is crucial as it is the password used to uncompress the password protected PK-zip file, which contains the schedule with the times and locations of the schools the drug dealer visits.

3. What (if any) other high schools besides Smith Hill does Joe Jacobs frequent?

In addition to Smith Hill High School, Joe also frequents Key High School, Leetch High School, Birard High School, Richter High School, and Hull High School.

4. For each file, what processes were taken by the suspect to mask them from others?

The .exe file
The actual PK-zip file was password protected with the password "goodtimes". However, one could still see that the file that was contained in the archive was "Scheduled Visits.xls". Furthermore, since the password contains only letters it might be vulnerable to a dictionary password cracking attack.

In addition to the password protection, however, the actual length of the file was truncated in the directory entry. The following shows the hexdump output for the entry with the relevant bytes highlighted:

000026c0 42 69 00 74 00 73 00 2e 00 65 00 0f 00 9e 78 00  Bi.t.s...e....x.
000026d0 65 00 20 00 20 00 20 00 20 00 00 00 20 00 20 00  e. . . . ... . .
000026e0 01 53 00 63 00 68 00 65 00 64 00 0f 00 9e 75 00  .S.c.h.e.d....u.
000026f0 6c 00 65 00 64 00 20 00 56 00 00 00 69 00 73 00  l.e.d. .V...i.s.
00002700 53 43 48 45 44 55 7e 31 45 58 45 20 00 53 53 46  SCHEDU~1EXE .SSF
00002710 2b 2d 2b 2d 00 00 90 42 b8 2c 49 00 e8 03 00 00  +-+-...B¸,I.è...

The marked bytes indicate a length of 1000 bytes. To fix this, the value should be changed to 2560 bytes (00 0a 00 00) or to 2420 (74 09 00 00). Please see the above analysis part for the reasoning about the file length.
The JPEG file
This file's directory entry was also modified:

00002660 42 67 00 63 00 20 00 20 00 20 00 0f 00 f4 20 00  Bg.c. . . .... .
00002670 20 00 20 00 20 00 20 00 20 00 00 00 20 00 20 00   . . . . ... . .
00002680 01 63 00 6f 00 76 00 65 00 72 00 0f 00 f4 20 00  .c.o.v.e.r.... .
00002690 70 00 61 00 67 00 65 00 2e 00 00 00 6a 00 70 00  p.a.g.e.....j.p.
000026a0 43 4f 56 45 52 50 7e 31 4a 50 47 20 00 6d 4d 46  COVERP~1JPG .mMF
000026b0 2b 2d 2b 2d 00 00 da 43 2b 2d a4 01 e1 3c 00 00  +-+-...C+-...<..

The two highlighted bytes make up the first cluster number for the file. The indicated cluster number 420 points into a large sequence of continuous bytes with the value 0xf6. To compute the correct cluster number, we need to take the first block on the floppy that belongs to the file (73). The first 33 blocks on the image are reserved for the boot sector (block 0), the first FAT table (blocks 1-9), the second FAT table (blocks 10-18), and the root directory (blocks 19-32). Also, the first 2 clusters (0 and 1) are reserved. Thus cluster number 2 starts at block 33. This makes block 73 identical to cluster 42. To fix the directory entry, the highlighted bytes need to be changed to 2a 00. The long file name of the JPEG file is also messed up as it lists the file's suffix as ".jpgc" followed by numerous spaces and special characters. While this seems odd it doesn't really mask the contents from anyone.
The Word document
First of all, the file was deleted from the floppy. This shows in the file's directory entry as follows:

00002600 e5 64 00 6f 00 63 00 00 00 ff ff 0f 00 bc ff ff  åd.o.c...ÿÿ..¼ÿÿ
00002610 ff ff ff ff ff ff ff ff ff ff 00 00 ff ff ff ff  ÿÿÿÿÿÿÿÿÿÿ..ÿÿÿÿ
00002620 e5 4a 00 69 00 6d 00 6d 00 79 00 0f 00 bc 20 00  åJ.i.m.m.y...¼ .
00002630 4a 00 75 00 6e 00 67 00 6c 00 00 00 65 00 2e 00  J.u.n.g.l...e...
00002640 e5 49 4d 4d 59 4a 7e 31 44 4f 43 20 00 68 38 46  åIMMYJ~1DOC .h8F
00002650 2b 2d 2b 2d 00 00 4f 75 8f 2c 02 00 00 50 00 00  +-+-..Ou.,...P..

The byte e5 at address 0x02640 indicates that file was deleted. The value needs to be changed back to 4a ("J") -- actually any valid character would work. However, this did not fix the problem so we examined the cluster number, which pointed correctly at cluster number 2, and the file size (20480 bytes) was also correct. We therefore further looked at the file allocation table (FAT) and found that the entries for clusters 2 through 41 had the value of 0:

00000200 f0 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00  ðÿÿ.............
00000210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
00000230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 2b  ...............+
00000240 c0 02 2d e0 02 2f 00 03 31 20 03 33 40 03 35 60  À.-à./..1 .3@.5`
                  

The second FAT starting at address 0x1400 looks exactly the same. So, the FAT entry for the file had been zeroed out. Given this, we can say we were lucky that all clusters for the file were in one continuous range. To reconstruct the FAT entry, one needs to consider that 2 clusters share 3 bytes. Given six half-bytes 123456, they belong to the cluster numbers AB in the following fashion:

412: A
563: B

Also, the actual FAT entry for a cluster is the next cluster it points to with the very last entry being 0xfff. Thus the correct FAT entry for the file for both FAT1 and FAT2 needs to look like this:

00000200 f0 ff ff 03 40 00 05 60 00 07 80 00 09 a0 00 0b  ðÿÿ.@..`..... ..
00000210 c0 00 0d e0 00 0f 00 01 11 20 01 13 40 01 15 60  À..à..... ..@..`
00000220 01 17 80 01 19 a0 01 1b c0 01 1d e0 01 1f 00 02  ..... ..À..à....
00000230 21 20 02 23 40 02 25 60 02 27 80 02 29 ff 0f 2b  ! .#@.%`.'..)ÿ.+
00000240 c0 02 2d e0 02 2f 00 03 31 20 03 33 40 03 35 60  À.-à./..1 .3@.5`

5. What processes did you (the investigator) use to successfully examine the entire contents of each file?

The analysis section above and our answer to Question 4 should describe the processes sufficiently.

Appendix

Tools used

Autopsy Forensic File Browser
dd
strings
hexdump
khexedit
unzip
file
kword
MS Excel

References

"FAT: General Overview of On-Disk Structure", Microsoft Corporation, http://www.nondot.org/sabre/os/files/FileSystems/FatFormat.pdf

People

The members of the CERIAS Computer Forensics Research Group can be found here