Honeynet Project Scan of the Month - Scan 26 (February 2003)

Nick DeBaggis

Eloy Paris


This is a submission to the Honeynet Project February 2003 Scan of the Month. In the case involving Joe Jacobs from the October Scan 24 challenge, evidence was found implicating his dealer, Jimmy Jungle. A result of the previous forensic investigation was a search warrant on Jimmy Jungle's residence, the search turned up a single floppy disk in the vacated residence. During this investigation, we have uncovered several other suspects related to this case. Namely, Jimmy's probable suppler, John Smith, and Jimmy's pickup location contact, Danny. We have successfully extracted and analyzed all hidden data and have answered all the questions posed by the police. It is our belief the evidence obtained in this case will assist the police in conducting a rapid and successful investigation.

The analysis is in some parts very detailed. If you are a grader, have several submissions to read and can't go over all the details, or are just a casual reader, feel free to go directly to Section 1, “Questions”, which contains the answers to all the questions of this challenge. The questions (and answers) provide a good summary of the most important aspects of this challenge. However, just reading the answers is not the best way to understand some of the details nor the process we followed to analyze the forensic disk image, so we encourage you to read the whole submission.

Table of Contents

1. Questions
1.1. Q1: Who is the probable supplier of drugs to Jimmy Jungle?
1.2. Q2: What is the mailing address of Jimmy Jungle's probable drug supplier?
1.3. Q3: What is the exact location in which Jimmy Jungle received the drugs?
1.4. Q4: Where is Jimmy Jungle currently hiding?
1.5. Q5: What kind of car is Jimmy Jungle driving?
1.6. Bonus: 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?
2. Initial Inspection
3. Analysis
A. Files
B. References
C. Work Methodology
D. Thanks

1. Questions

1.1. Q1: Who is the probable supplier of drugs to Jimmy Jungle?

A: John Smith is Jimmy Jungle's most probable supplier of drugs. We have reached this conclusion after reading the Microsoft Word document John.doc, which was hidden using steganography in the JPEG file stored in the floppy disk image at offset 16896. The John.doc file was also password protected with Microsoft Word's password protection scheme. The string "pw=help" found in the unallocated disk space of the floppy unlocked the file.

The Word document contains the following text:

Dear John Smith:

My biggest dealer (Joe Jacobs) got busted. The day of our scheduled
meeting, he never showed up. I called a couple of his friends and they
told me he was brought in by the police for questioning. I'm not sure
what to do. Please understand that I cannot accept another shipment
from you without his business. I was forced to turn away the delivery
boat that arrived at Danny's because I didn't have the money to pay
the driver. I will pay you back for the driver's time and gas. In the
future, we may have to find another delivery point because Danny is
starting to get nervous.

Without Joe, I can't pay any of my bills. I have 10 other dealers who
combined do not total Joe's sales volume.

I need some assistance. I would like to get away until things quiet
down up here. I need to talk to you about reorganizing. Do you still
have the condo in Aruba? Would you be willing to meet me down there?
If so, when? Also, please take a look at the map to see where I am
currently hiding out.

Thanks for your understanding and sorry for any inconvenience.


Jimmy Jungle

We believe this letter warrants further investigation of Mr. John Smith and his relationship with Jimmy Jungle. The person named Danny should also be questioned.

1.2. Q2: What is the mailing address of Jimmy Jungle's probable drug supplier?

A: By running the strings Unix command on the floppy disk image we see that there is one mailing address stored in a random location of the image. This address is:

1212 Main Street
Jones, FL 00001

The address is stored with the comment "John Smith's address", which does not leave much doubt about where to find Mr. John Smith.

1.3. Q3: What is the exact location in which Jimmy Jungle received the drugs?

A: The Microsoft Word Document we mentioned in Question 1 implies that drugs are delivered by boat at Danny's. Looking at the map in the JPEG file, we can see that Danny's is located at Pier 12 on Shore Line Drive, close to the intersection between Shore Line and N. Main Street.

1.4. Q4: Where is Jimmy Jungle currently hiding?

A: 22 Jones Ave. - near the intersection of Smith Ave.

Jimmy Jungle's hiding place is shown in the bitmap image. The bitmap image was found at offset 49664 of the forensic floppy image and has a length of 1166454 bytes.

Bitmap of Jimmy's hiding place (bitmap.bmp). Note: this file is rather large, if you are on a dial-up connection then you may want to save some time and take a look at (bitmap.jpg) to get the visual perspective of the original file. Though understand that the bitmap.bmp file is the real file we extracted and contains the hidden Jimmy.wav file.

1.5. Q5: What kind of car is Jimmy Jungle driving?

A: Jimmy Jungle drives a blue 1978 Mustang with Ontario license plates.

Finding the HTML comment string "PW=right" in the dfrws.org site allowed us to extract the WAV sound file "Jimmy.wav" using Invisible Secrets 2002 with the Twofish encryption algorithm selected. When played, we hear Jimmy directing the listener to meet him at the pier: "This is Jimmy, meet me at the pier tomorrow. I drive a blue 1978 Mustang with Ontario license plates".

1.6. Bonus: 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?

A: The steganographic image files were copied to the diskette, the diskette was then formatted either through Windows or DOS using the format command with the quick format switch applied. A test was performed on a PC running Windows 98 to compare with the forensic image; the results matched, the FAT and root directory were empty but the data area retained the original files. The quick format option clears and reinitializes the FAT and root directory while leaving the data area intact, thus "quickly formatted". For DOS the command is: format a: /q. This may be done through Windows as well, right-click the floppy drive object and choose Format - Quick.

2. Initial Inspection

Our initial inspection of the forensic floppy image followed the typical examination path. We first verified the MD5 hashes supplied for this challenge. We then checked the file type of the scan26 binary disk image, proceeded to mount the disk image and performed a directory listing on it:

$ file scan26
scan26: x86 boot sector
$ sudo mount -o ro,loop,nodev,noexec scan26 mnt/
$ ls -l mnt/
total 0

This appears to be an empty floppy disk so a low-level analysis should uncover any data that may still be on the disk. Using several tools to analyze the image will produce the offsets to any interesting data on the disk. The tools used during this phase of the examination consisted of: emacs, vi, strings and khexedit.

We now begin to do a manual examination of the scan26 image and as shown below we find all offsets to the interesting data left on the disk.

The first thing we notice is the empty FAT1 and FAT2 sections of the disk, these appear normal for an empty disk as the leading 3 bytes followed by all null bytes signify the FAT is empty. We follow down to the beginning of the disk data area at offset 0x4200 and notice the root directory is also empty along the way.

Fat 1:
0000:0200 f0 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000:0210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000:0220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000:0230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

Fat 2:
0000:1400 f0 ff ff 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000:1410 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000:1420 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0000:1430 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

We have arrived at the beginning of the disk data area, we see there is the tell-tale signature for a JPEG image here: 0xff 0xd8 and JFIF. Following down through this JPEG until we hit the two bytes 0xff 0xd9 which signify the End Of Image for a JPEG, we can now calculate the file length for the JPEG as 0xc15a - 0x4200 = 32602 bytes.

Start of JPEG:
0000:4200 ff d8 ff e0 00 10 4a 46 49 46 00 01 01 01 00 48 ......JFIF.....H
0000:4210 00 48 00 00 ff fe 00 4c 11 53 6e 55 47 b3 2d 44 .H.....L.SnUG.-D
0000:4220 35 d2 23 66 6b 1d bd 76 3c 89 68 69 d4 17 60 e8 5.#fk..v<.hi....
0000:4230 a8 a4 2d 09 59 19 ab 28 1a de 5e 98 60 c2 a5 c3 ..-.Y..(..^.`...

End of JPEG:
0000:c140 80 88 88 08 88 80 88 88 08 88 80 88 88 08 88 80 ................
0000:c150 88 88 08 88 80 88 88 3f ff d9 00 00 00 00 00 00 .......?........
0000:c160 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................

Proceeding down we find another tell-tale signature, this one for a BMP image. Following down through the BMP we eventually hit the formatting codes 0xf6 that are typical of a Windows/MSDOS formatted disk. These codes will signify the end of the bitmap image since they mean those positions are unallocated on the disk. We could also simply grab the file size from the bitmap header. The file size is located at offset 0xc202 for 4 bytes length (just after "BM"), reading them in little-endian order we have 0x0011cc76 = 1166454 bytes.

Start of bitmap:
0000:c200 42 4d 76 cc 11 00 00 00 00 00 36 00 00 00 28 00 BMv.......6...(.
0000:c210 00 00 d0 02 00 00 1c 02 00 00 01 00 18 00 00 00 ................
0000:c220 00 00 40 cc 11 00 00 00 00 00 00 00 00 00 00 00 [email protected]
0000:c230 00 00 00 00 00 00 ff ff ff ff ff ff ff ff ff ff ................
0000:c240 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................

End of bitmap:
0012:8e60 ff fe fe ff fe ff ff ff ff fe ff ff fe ff ff fe ................
0012:8e70 ff fe fe fe ff fe f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 ................
0012:8e80 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 ................

Again, we subtract to find how many bytes are between: 0x128e76 - 0xc200 = 1166454 bytes, which matches the size in the BMP header.

Moving on we find two ASCII text strings located in the unallocated disk space towards the end of the disk. Running the Unix strings command on the image also reveals these strings.

0012:bb40 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 ................
0012:bb50 70 77 3d 68 65 6c 70 f6 f6 f6 f6 f6 f6 f6 f6 f6 pw=help.........
0012:bb60 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 ................

0015:6750 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 f6 ................
0015:6760 4a 6f 68 6e 20 53 6d 69 74 68 27 73 20 41 64 64 John Smith's Add
0015:6770 72 65 73 73 3a 20 31 32 31 32 20 4d 61 69 6e 20 ress: 1212 Main
0015:6780 53 74 72 65 65 74 2c 20 4a 6f 6e 65 73 2c 20 46 Street, Jones, F
0015:6790 4c 20 30 30 30 30 31 f6 f6 f6 f6 f6 f6 f6 f6 f6 L 00001.........

This certainly looks like a potential password and John Smith's address. We continue to the end of the image file with no other findings, so we will now commence to the analysis phase using the information we have.

3. Analysis

Note that nearly all of our analysis was conducted prior to finding the hidden HTML comments in the dfrws.org web site, if we had found these earlier, this section would have been much shorter. Armed with file offsets and lengths, we can now extract the files from the scan26 image file. First we summarize with a table of offsets and lengths for reference.

Table 1. Disk image data types with offsets and lengths

DescriptionHex OffsetDecimal OffsetDecimal Length
jpeg.jpg graphics file0x000042001689632602
bitmap.bmp graphics file0x0000c200496641166454
ASCII string0x0012bb5012276007
ASCII string0x00156760140272055

Extract and check the file type for the JPEG graphic:

$ dd if=scan26 of=jpeg.jpg bs=1 count=32602 skip=16896
32602+0 records in
32602+0 records out
$ file jpeg.jpg
jpeg.jpg: JPEG image data, JFIF standard 1.01, resolution (DPI), "SnUG.-D5.#fk.v.h.............Y.", 72 x 72

Notice how the file command spit out part of the JPEG comment section, but the comment is not entirely human readable. This is a tip-off that something may be hidden in the JPEG file. Since a JPEG comment can contain upto 65533 bytes of data and a JPEG file can contain multiple comments without rendering them to the screen, the comment area is a good hiding place. The drawback is the file size is increased using this method of hiding.

Extracting the Windows bitmap from the forensic disk image:

$ dd if=scan26 of=bitmap.bmp bs=1 count=1166454 skip=49664
1166454+0 records in
1166454+0 records out
$ file bitmap.bmp
bitmap.bmp: PC bitmap data, Windows 3.x format, 720 x 540 x 24

This gives us basically the same image as the JPEG, but there is a new location drawn on the map, and the file format is obviously different. To quickly recap, we now have the following information about our scan26 image:

  • A JPEG image showing "Danny's Pier 12 Boat Lunch" and containing a strange comment section .

  • A large 24 bit color BMP image showing a "hideout".

  • A string showing "pw=help"

  • Another string showing John Smith's address.

Let's work on the JPEG first. We run Niels Provos' stegdetect tool on it to determine the possibility of it having steganographic content.

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

Stegdetect seems to think the JPEG has steganographic data embedded in it and was created with Invisible Secrets steganography software. The numbers reflect the potential length of the stego data. At this point, we decided to download and install Invisible Secrets and a handful of other Windows based stego packages. We tried to decrypt the JPEG using the password "help" with no results. We also thought about the reason for the disk having "dfrws.org" written on it (see the police report) and so made a trip to their site. A brief examination of the site produced very little.

A manual extraction of the two JPEG comment sections revealed a little more information to us. We did find that the first comment section contains 74 bytes of data and the second comment section contains 7775 bytes of data. An assumption we made was the first comment contained the encryption key hash and/or some type of structure descriptor of the encrypted data, and the second comment contained the actual encrypted/compressed data. This assumption produced little since we don't know exactly how Invisible Secrets stores that information.

Jumping ahead to the BMP image, we can visually see that a "hideout" has been added with an address. But our intuition says there may be stego in the BMP as well. So for the bitmap image, a small C program was written to enhance the image based on the value of a specific bit in each color byte of image data (see Appendix A, Files). Since a 24 bit bitmap typically contains only a header section and raw RGB triplets, it was fairly easy to determine that a Least Significant Bit insertion based steganography was applied to it (this is a common way to embed stego in a BMP image so the file size does not change). The image below is a consolidated image map of our bit enhancement procedure. From top left to bottom right (reading across) we have the enhanced images of bit 7 through 0. It's quite obvious bit 0 is very different; it looks random, which is typically a sign of compressed and/or encrypted data.

A Google search for "analyzing steganography" turned up the site: http://www.pipo.com/guillermito/invisiblesecrets/ which has a very good analysis of how Invisible Secrets 2002 implements steganography in an image file. Take special notice to the similarities between our enhanced bit 0 image and the examples on that site.

We are now confident both graphics files contain steganography. We are also confident it is Invisible Secrets steganography. But, the password "help" is not working out for us. We again brought up the issue about "dfrws.org" being written on the floppy disk, and decided to take a more detailed look at the dfrws.org site. This time we closely analyzed the HTML source code and found the key to Jimmy Jungles' whereabouts and next move. In the HTML comments on the page http://www.dfrws.org/dfrws-overview.html we found the following:

Invisible Secrets
Algorythm= twofish

We used these passwords and settings to extract the files John.doc and Jimmy.wav from the JPEG and BMP respectively. The JPEG's password is "lefty" and the BMP's is "right". As far as the "pw=help" string, well that was used as the Microsoft Word password protection on the John.doc file.

It is our recommendation to obtain an additional search warrant for the dfrws.org site's web server hard drive as this may give more information regarding this case. It's apparent Jimmy Jungle has some type of access, legal or illegal to that site's web server since that is the only way those comments got into the HTML source.

A. Files

The following files where generated during this Scan of the Month:

  • jpeg.jpg: Graphic in JPEG format that contains a map with the location where Jimmy Jungle receives drugs. This file uses steganography to hide the Microsoft Word file John.doc.

  • bitmap.bmp: Graphic in Windows Bitmap (BMP) format that contains a map with the location where Jimmy Jungle is hiding. This file uses steganography to hide the WAV file Jimmy.wav.

  • John.doc: Microsoft Word document that provides information about Jimmy Jungle's drug supplier. This document was hidden using steganography inside a JPEG file, and also has Microsoft Word's password protection scheme set on it.

  • Jimmy.wav: Sound media in Wave (WAV) format that contains a recording of Jimmy Jungle directing someone (probably John Smith) to meet him at the pier. This document was hidden using steganography inside a Windows Bitmap file.

  • bmplsb.c: Bitmap bit enhancer, enhances a bitmap based on the value of the selected bit.

  • bmpextract.c: Bitmap bit extractor, extracts the bitmap image data based on the value of the selected bit.

  • bmp.h: Bitmap header definition.

  • XML sources for this document: this HTML document was generated using DocBook XML. This directory contains all the files used in the generation of this document.

B. References

C. Work Methodology

This submission was prepared jointly by Nick DeBaggis and Eloy Paris. Nick and Eloy did not know each other prior to this Scan of the Month, although both had participated independently in past Honeynet Project's Scans of the Month.

For this Scan of the Month both authors worked independently while analyzing the problem and finding the answers, and then joined forces to write the final submission.

The submission was prepared using DocBook XML, and then converted to HTML using Tim Waugh's xmlto XML converter. A CVS repository was set up to keep track of changes, allow authors to work independently, and allow authors to see each other's changes.

D. Thanks

Thanks to ...

  • (Eloy) Nick, for teaming up with me on this Scan of the Month and for working so hard on it. Write ups are always hard, but you've made this one a breeze!

  • (Eloy) Ken, for providing an exceptional work environment and for encouraging me to pursue educational exercises like the Honeynet Project's Scans of the Month.

  • (Nick) Jen, for saying yes, for being the solution to my puzzle, and for tolerating my many "projects"; I am getting the better part of this deal! Eloy, for somehow finding the time to team up on this challenge and teaching me some new Linux tricks along the way.

  • (Nick) Cathy and Steve, for taking a chance, allowing me to grow into such a cool job, and not minding too much when I show up a bit late after staying up all night doing Honeynet Challenges!.

  • (Both) As always, the Honeynet Project for these nice and entertaining challenges.