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.
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:
Danny's
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:
Hideout
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 platform used for the majority of the process of this investigation is a Pentium 4 with SuSE Linux 8.0.
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
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 su Password: # 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.
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].
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].
Field | Offset | Length |
---|---|---|
OEM Identifier | 03 | 8 |
Bytes per Sector | 0B | 2 |
Sectors per Cluster | 0D | 1 |
Reserved Sectors | 0E | 2 |
Number of FATs | 10 | 1 |
Root Entries | 11 | 2 |
Number of Sectors | 13 | 2 |
Media Descriptor | 15 | 1 |
Sectors per FAT | 16 | 2 |
Sectors per Track | 18 | 2 |
Heads per Cylinder | 1A | 2 |
Hidden Sectors | 1C | 4 |
Large Sectors | 20 | 4 |
Physical Disk Number | 24 | 1 |
Reserved | 25 | 1 |
Signature | 26 | 1 |
Volume Serial Number | 27 | 4 |
Volume Label | 2B | 11 |
System Identifier | 36 | 8 |
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.
Field | Hex | Value / meaning |
---|---|---|
OEM Identifier | 22 52 56 52 62 49 48 43 | "RVRbIHC |
Bytes per Sector | 00 02 | 512 |
Sectors per Cluster | 01 | 1 |
Reserved Sectors | 01 00 | 1 |
Number of FATs | 02 | 2 |
Root Entries | E0 00 | 14 |
Number of Sectors | 40 0B | 2880 |
Media Descriptor | F0 | 3 1/2 Floppy, 1.44MB |
Sectors per FAT | 09 00 | 9 |
Sectors per Track | 12 00 | 18 |
Heads per Cylinder | 02 00 | 2 |
Hidden Sectors | 00 00 00 00 | 0 |
Large Sectors | 00 00 00 00 | 0 |
Physical Disk Number | 00 | 0 |
Reserved | 00 | 0 |
Signature | 29 |   |
Volume Serial Number | 44 06 DA 16 | 16DA-0644 |
Volume Label | 4E 4F 20 4E 41 4D 45 20 20 20 20 | NO NAME |
System Identifier | 46 41 54 31 32 20 20 20 | FAT12 |
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.
Figure 2: Layout of the FAT volume on scan26
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.
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: Layout of the data section of the file system
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.
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.
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.
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.
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.
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.
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.
[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