Analysis of the Scan of the Month 26

by Claus Lund
<clauslund at bigmailbox dot net>


Questions and Answers
The Forensic Process
Obtaining the disk image
Initial survey of the disk image
The FAT12 file system
The FAT and root folder of the disk image
The data section of the disk image
File #1
File #2


The following is the documentation of the steps taken during the analysis of the Honeynet Project's Scan of the Month 26. The object of this month's challenge is to assist law enforcement in analyzing a floppy disk recovered during a fictional criminal investigation.

Questions and Answers

Who is the probable supplier of drugs to Jimmy Jungle?
A name, "John Smith", was recovered from the disk image. And John Smith is probably Jimmy Jungle's supplier.

What is the mailing address of Jimmy Jungle's probable drug supplier?
John Smith's mailing address is:
212 Main Street
Jones, FL 00001

What is the exact location in which Jimmy Jungle received the drugs?
The following location was marked on a map recovered from the disk:
Pier 12
Boat Lunch
This is believed to be the location where Jimmy Jungle received the drugs.

Where is Jimmy Jungle currently hiding?
The following location was marked on a second map that was recovered from the disk:
12 Jones Ave

What kind of car is Jimmy Jungle driving?
The make of Jimmy Jungle's car is still unknown at this point. However it is believed that the answer lies inside the two image files recovered from the disk. It looks like Jimmy Jungle used a steganography program to hide information in the pictures but I was unable to find the right program and/or passphrase to recover the hidden information.

Bonus Question: Explain the process that was performed so that there were no entries in the root directory and File Allocation Table (FAT), yet the contents of each file remained in the data area?
Jimmy Jungle QuickFormat'ed the disk. Performing a QuickFormat writes a new boot sector and erases everything from the two FATs and the root folder but it leaves the data section alone. However information uncovered during the investigation suggests that Jimmy Jungle either did not use the standard MS Windows utility to format the disk or he went in and deliberately changed the OEM identifier after he finished the QuickFormat.

The Forensic Process


The platform used for the majority of the process of this investigation is a Pentium 4 with SuSE Linux 8.0.

Obtaining the disk image

The disk image was downloaded from The Honeynet Project's website. The MD5 sum for the .ZIP file was verified and the file was unzipped. Then the MD5 sum for the raw disk image was verified.

$ md5sum scan26.zip
c8e2454b970538de26a0fa887017109b  scan26.zip
$ unzip scan26.zip
Archive:  scan26.zip
  inflating: scan26
$ md5sum scan26
e9c7d0c87ab0ecce09bf90362b830a74  scan26

Initial survey of the disk image

When examining an unknown file it is often sensible to run it through strings. The plain-text strings present in any given file will often reveal a lot about the origin and use of it.

$ strings scan26 > strings.out

A quick survey of strings.out reveals a few things that might prove to be useful:

The second step of this initial survey is to mount the disk image to the loopback interface to see if there are any files that are readily available:

$ mkdir scanmount
# mount -t vfat -o ro,loop scan26 scanmount
# ls -l scanmount
total 8
drwxr-xr-x    2 root     root         7168 Dec 31  1969 .
drwxr-xr-x    4 clund    users         856 Feb 10 19:12 ..

It unfortunately looks like Jimmy Jungle deleted everything on the disk.

The FAT12 file system

FAT stands for "File Allocation Table" and Bill Gates first implemented this file system some time in the 1970's. Since its creation the FAT file system has grown to be the most used file system on IBM PC compatible computers. Figure 1 depicts the layout of a FAT volume. The specification for the FAT file system was obtained from Microsoft [1].

Layout of a FAT volume

Figure 1: Layout of a FAT volume

The initial 62 bytes of a FAT12 volume describes how the file system is organized (see table 1). The specification for the FAT12 boot sector was also obtained from Microsoft [1].

OEM Identifier038
Bytes per Sector0B2
Sectors per Cluster0D1
Reserved Sectors0E2
Number of FATs101
Root Entries112
Number of Sectors132
Media Descriptor151
Sectors per FAT162
Sectors per Track182
Heads per Cylinder1A2
Hidden Sectors1C4
Large Sectors204
Physical Disk Number241
Volume Serial Number274
Volume Label2B11
System Identifier368

Table 1: BIOS Parameter Block for FAT12

It is now possible to understand the layout of our floppy image by examining the BIOS Parameter Block (BPB) of scan26. KHexEdit is used to view scan26 and the contents of the BPB are broken down in table 2.

FieldHexValue / meaning
OEM Identifier22 52 56 52 62 49 48 43"RVRbIHC
Bytes per Sector00 02512
Sectors per Cluster011
Reserved Sectors01 001
Number of FATs022
Root EntriesE0 0014
Number of Sectors40 0B2880
Media DescriptorF03 1/2 Floppy, 1.44MB
Sectors per FAT09 009
Sectors per Track12 0018
Heads per Cylinder02 002
Hidden Sectors00 00 00 000
Large Sectors00 00 00 000
Physical Disk Number000
Volume Serial Number44 06 DA 1616DA-0644
Volume Label4E 4F 20 4E 41 4D 45 20 20 20 20NO NAME
System Identifier46 41 54 31 32 20 20 20FAT12

Table 2: BIOS Parameter Block for the FAT12 file system on scan26

The only thing that looks strange is the OEM Identifier. When you format a diskette in MS Windows then this field is set to MSDOS5.0. The strange OEM identifier may or may not have any meaning. One possible answer could be that Jimmy Jungle (or some program he uses) has specifically changed this. Everything else looks like a standard floppy disk BPB. Using the numbers in the BPB it is now possible to understand the organization of the FAT volume from the floppy image. A diagram illustrating this is shown in figure 2. The numbers indicate the number of the sector (decimal) and the address (hex) where each section of the file system begins.

Layout of the FAT volume on scan26

Figure 2: Layout of the FAT volume on scan26

The FAT and root folder of the disk image

KHexEdit is used to visually examine the FATs and root folder of image26. Both FATs and the root folder are discovered to be completely empty. But since it is already known that there is data on the disk image then it tells us that Jimmy Jungle did a QuickFormat of the floppy. If he had just deleted the files then the FATs would be empty but the records in the root folder would remain undisturbed until a new file was written to the disk.

It is unknown whether Jimmy Jungle intended to destroy the data on the disk or if he deliberately deleted the FAT and root folder in an attempt to hide the data. But if he wanted to delete the data then he should have been a little more patient and performed a regular formatting of the disk because then it would have been a lot harder to obtain any useful data from it. No information would have been readily available on the image of the disk and the forensics experts would instead have had to work on a microscopic level on the actual disk to try to recover the data.

The data section of the disk image

KHexEdit is used in this step too. The data section is examined from its' starting point at address 0x4200. The findings from this initial inspection are:

Figure 3 visualizes the layout of the data section.

Layout of the data section of the file system

Figure 3: Layout of the data section of the file system

File #1

After reading up on the specification for the JPEG File Interchange Format [2][3] it becomes clear that the first file on the disk image is indeed a JPEG file. The JPEG file's starting marker is two bytes long and the value of it is FFD8 (located at 0x4200). The ending marker for a JPEG file is FFD9 (located at 0xC158). The first file is read from the image:

$ dd if=scan26 of=file1.jpg ibs=1 skip=16896 count=32602
32602+0 records in
63+1 records out

Comments can be included in the header of JPEG files. The comment marker is FFFE and the first two bytes after the marker indicate the length of the comment (including the two length bytes). It is noticed that our JPEG file has two comments included in it. One comment is at 0x0018 to 0x0061 the other comment is at 0x0066 to 0x1EC4. It looks like we have some kind of encoded or encrypted data in the comments. Figure 4 shows a screen capture of the first few lines of the JPEG file. The start of image marker, the JFIF string and two comment markers have been highlighted.

Screen capture of the start of the JPEG file

Figure 4: Screen capture of the start of the JPEG file

The JPEG is viewed and it is an image of a map with the location "Danny's, Pier 12, Boat Lunch" marked with an X. Figure 5 is a resized version of the JPEG image. The original file is available here.

Resized version of the first file on the disk image

Figure 5: Resized version of the first file on the disk image

The comments in the JPEG file aroused some suspicion that Jimmy Jungle might have used steganography to hide information so stegdetect from OutGuess [4] was downloaded and installed. Running stegdetect on the JPEG file revealed that a program called Invisible Secrets might have been used to embed data in the file.

$ stegdetect file1.jpg
file1.jpg : invisible[7771](***)

The three *'s indicate that stegdetect is very sure that Invisible Secrets is the program Jimmy Jungle used (stegdetect's rating goes from one to three *'s with three being the highest level of confidence). Invisible Secrets 2002 v3.2 is downloaded [5] and installed on an MS Windows workstation. The hope is that the string "pw=help" actually holds the password to reveal and decrypt the hidden information. A few mutations of "help" (help, pleh, HELP, PLEH, pw=help) are tried with each decryption algorithm but unfortunately each attempt is promptly shot down with an "ACCESS DENIED" error message. After trying to hide some files in a test JPEG image it becomes clear that if Invisible Secrets is the program Jimmy Jungle used then the two comments in file1.jpg do in fact contain all the hidden data. So if everything else fails then it might be possible to launch a brute force attack to try to decrypt the data.

File #2

The second glob of data on the disk image begins at 0xC200. The first two bytes are 4D42 and a quick search on Google for "4D42 header" reveals that we might have a Windows BMP header.

After reading up on the format for the BMP header [6] it is clear that this file is a BMP. The first four bytes after the 4D42 signature lists the size of the BMP (see figure 6). And in our case 0xC200 + 0x11CC76 does line up perfectly with where the data section of the disk image turns into all F6's.

Screen capture of the start of the BMP file

Figure 6: Screen capture of the start of the BMP file

The file is extracted from the disk image:

$ dd if=scan26 of=file2.bmp ibs=1 skip=49664 count=1166454
1166454+0 records in
2278+1 records out

The BMP is viewed and it is another map like the image in the JPEG file. This time a second location, "Hideout, 22 Jones", is marked with an X. Figure 7 is a resized version of the BMP image. The original file is available here.

Resized version of the BMP image on the disk image

Figure 7: Resized version of the BMP image on the disk image

Earlier in this investigation it was noticed that this part of the data section contains a lot of FF and FE values. Since the JPEG file has a hidden message in it then the BMP might also have data hidden in it. Invisible Secrets embeds data in a 24 bit BMP by using the LSB of every byte. Changes to the LSB in a 24 bit BMP will not be noticeable by the human eye but a small script to amplify the changes made by the steganography program was produced [7]. The script sets the entire byte to 0 whenever the LSB is 0. Figure 8 shows a resized version of the output from the enhanceLSB script.

Resized version of the BMP image after the LSB has been enhanced

Figure 8: Resized version of the BMP image after the LSB has been enhanced

It is quite obvious that part of the BMP file contains hidden data. Invisible Secrets is again used to try to recover the hidden data. The same mutations of "help" are again used but none of them are successful.


The process used in this investigation was very straightforward and good for smaller disk images however if we had had a full image of a large harddrive then the approach would require some tweaking. In particular it would have been practical to write some scripts that could automatically cut up the disk image into pieces of known files and other pieces of data with no links in the FAT. Detailed knowledge of the FAT12 file system, the JPEG file format and the BMP file format were needed to answer most of the questions raised in this month's challenge. Knowledge of steganography and cryptography was also needed however this investigation was not successful about uncovering the answer to the fifth question.


[1] MS Windows NT Workstation 4.0 Resource Guide, Chapter 17 - Disk and File System Basics

[2] http://www.obrador.com/essentialjpeg/HeaderInfo.htm

[3] http://www.w3.org/Graphics/JPEG/jfif.txt

[4] http://www.outguess.org/detection.php

[5] http://www.neobytesolutions.com/invsecr/index.html

[6] http://www.fastgraph.com/help/bmp_header_format.html

[7] enhanceLSB script