Honeynet Scan of the Month 24

October 2002

Brian Carrier (carrier (at) cerias.purdue.edu)


To complete this challenge, TASK 1.52 and Autopsy 1.62 were used. Both are free and available at:


Analysis can be done any any of the major UNIX platforms (Linux, OS X, FreeBSD, or Solaris). Installation directions for each tool can be found in the tar file.


The image.zip file was downloaded from the Honeynet website and validated using md5sum. It was then unzipped and the image file was placed in the morgue directory. All images and configuration files must be placed in the morgue directory for Autopsy. The fsmorgue file for Autopsy was as follows:

imagefat12A:\ EST5EDT

The MD5 value of image was then placed in md5.txt so that we could verify its integrity through Autopsy. The md5.txt file had the following contents:



Autopsy was used as the graphical interface during the entire investigation. The first step was to validate the MD5 value of the image. To do this, 'Image Integrity' was selected from the main menu of Autopsy and the 'validate' button next to 'image' was selected. The value (ac3f7b85816165957cd4867e62cf452b) was verified. (screen shot)

Next, the image contents were examined by selecting 'File Browsing'. There were three files in the root directory (screen shot):

cover page.jpgc
Jimmy Jungle.doc (deleted)
Scheduled Visits.exe

Each was examined in alphabetical order.

cover page.jpgc

Selecting cover page.jpgc showed a File Type of PC formatted floppy with no filesystem. This was not what we would expect from a 'jpg' file, and it was uncertain why there was a 'c' at the end of the name. To get more information, the file details were examined by selecting the directory entry number (#8). This showed that only sector 451 was used, but the size of the file was 15585 bytes (screen shot).

Since the file is 15585 bytes and each sector is only 512 bytes, there should be ((15585 + 511) / 512) = 31 sectors. (NOTE: TASK does not use clusters when analyzing FAT, refer to the documentation in TASK for more information). Something has been done to this file to make it difficult to read. To get a better understanding of the image and what could have been done to this file, the remaining files were examined next.

jimmy jungle.doc

Examining Jimmy Jungle.doc showed a File Type of Microsoft Office Document, which matched the extension. The file started at sector 33 and had a size of 20480 bytes. TASK does not automatically recover deleted FAT files. So it had to be done manually.

When FAT deletes files, the starting sector is still known, but the remaining ones are not because their entries in the File Allocation Table are set to 0. If the file was not fragmented (i.e. it had consecutive sectors), recovery will be easy if the sectors have not been allocated since the deletion (i.e. they are still set to 0). We tried that theory first.

The first step was the find out how many sectors were needed for the file. The file size was 20480 bytes and the sector size was 512 bytes. Therefore, the file would require ((20480 + 511) / 512) = 40 sectors. We knew the file started at sector 33 and if the file was not fragmented then it would have allocated sectors 33 to 72.

The next step was to look at the File Allocation Table (FAT) to identify if these sectors were currently allocated. The FAT can be found using the 'File System' link ( screen shot). The FAT has the following contents:

73-103 (31) -> EOF
104-108 (5) -> EOF

This shows that sectors 73 to 103 are allocated to the same file and 104 to 108 are allocated to the same file. We can also see that the sector of the first cluster was 33. That means that the first sector that can be allocated for a file would be 33. This supports our theory that this file was located in clusters 33 to 72. The next step was to extract those sectors so that we could analyze the data.

To extract the data, the 'Data Browsing' link was selected and '33' was entered as the sector number and '40' as the number of consecutive sectors. This extracted 40 sectors, starting at number 33. The result was both binary and ASCII values, but text from a letter to 'Jimmy Jungle' about the quality of pot could be seen. To remove the binary values from the output, the 'strings' link was selected (screen shot).

'Export' was used to save the data to disk so it could be viewed in a word processor (result). The MD5 of the sector chain was calculated on the command line:

% md5sum image-Sector33.raw
MD5 (image-Sector33.raw) = b775eb6a4ccc319759d9aaae1e340acc

Viewing the resulting document in Microsoft Word showed the address of Joe's supplier. The document in HTML can be found here.

scheduled visits.exe

Examining the Scheduled Visits.exe file showed a file type of Zip archive data, at least v2.0 to extract. As the extension was .exe and not zip, this was suspect. 'Export' was used to save the data to disk so that the archive contents could be extracted. The resulting file had the following MD5:


The unzip command was used to unzip the file, but an error was given that the "End was not found". Either it was corrupt or there was a second file in the archive that we did not have. Examining the directory entry details (#5) ( screen shot) showed that the size of the file was 1000 bytes and it had sectors 104-105.

We recall from the FAT contents that sectors 104-108 formed a "sector" chain. TASK will only show as many sectors as are needed for the given file size. So, even though 104-108 formed a chain in the FAT, only the first two will be shown if the file size is 1000 bytes (((1000 + 511) / 512) = 2). Therefore, it could be that the suspect modified the file size so that the final three sectors would not be examined. To test this theory, the entire chain was extracted.

The 'File System' mode was used and the 104-108 (5) link was selected (this is the equivalent of using 'Data Browsing' mode and extracting 5 sectors starting at 104). 'strings' was used to identify embedded information and the string Scheduled Visits.xls was seen twice (screen shot). That could be the name of the file in the archive. 'Export' was used to save the file to disk. It can be found here and has the following MD5:


When unzipping this file, no error was generated, but we were prompted for a password (which the previous Word document mentioned).

cover page.jpgc Revisited

Now that we had a better idea about the floppy layout and we had done a brief examination of all the files, the first file was revisited before spending a lot of time looking for the password. Sectors 33-72 were known to be the word document, 73-103 formed a sector chain that we had not seen yet, and 104-108 were used by the zip file. The jpg file pointed to 451, which according to the FAT was not allocated (yet the file was allocated).

It was noticed that the size of the jpg file was reported to be 15585 bytes, which would require ((15585 + 511) / 512) = 31 sectors. That matched the length of the 73-103 sector chain. The sector chain was viewed in Autopsy (from the 'File System' link), which reported a file type of JPEG image data. 'strings' was run on it next to identify embedded information. At the bottom of the file, the 'pw=goodtimes' string was noticed ( screen shot). This could be the password we were looking for. The sectors were exported and the following MD5 was calculated:


Opening the image with an image viewer showed us that Jimmy Jungle was featured on the cover of 'POT SMOKERS MONTHLY'. The file can be found here.

scheduled visits.exe Revisited

goodtimes was used as the password on the zip file and it worked. The 'Scheduled Visits.xls' file was created.

md5: 0988df42266ff538fb6101e7bc9d8e05
size: 16896 bytes

The xls file was opened with Microsoft Excel to find a list of high schools and visit dates. Its contents are shown here.

Final Steps

To be thorough, the remaining sectors were examined. Using Autopsy we saw that sectors 109 and 110 were filled with 0xf6. 'dd' and 'hexdump' were used to quickly check the rest of the disk:

dd if=image bs=512 skip=109 | hexdump
0000000 f6f6 f6f6 f6f6 f6f6 f6f6 f6f6 f6f6 f6f6
015a400 0000 0000 0000 0000 0000 0000 0000 0000

This showed that the rest of the image was 0xf6 and 0x00, as 'hexdump' (by default) does not repeat values that are the same as the previous line.


1. According to the document found in sectors 33 to 72, Joe Jacob's supplier was:

Jimmy Jungle
626 Jungle Ave Apt 2
Jungle, NY 11111

2. The password for the zip file was found in the slack space of coverpage.jpg (at byte offset 288 of sector 103).

3. The list of other high schools can be seen here

4. Hiding techniques:

5. The process used to recover the data is shown above using TASK and Autopsy.