Submitted by: Chris Eagle (cseagle at redshift dot com)
- Who is the probable supplier of drugs to Jimmy Jungle?
Most likely it is John Smith. See analysis below.
- What is the mailing address of Jimmy Jungle's probable drug supplier?
1212 Main St. Jones, FL 00001Again see analysis below.
- What is the exact location in which Jimmy Jungle received the drugs?
Danny's Pier 12 Boat LunchDetails below.
- Where is Jimmy Jungle currently hiding?
22 Jones Ave.See below.
- What kind of car is Jimmy Jungle driving?
A Hummer, beats me, I suspect the answer lies in the stego that I couldn't figure out.
- Bonus
On a newly formatted disk, copy the jpg to the floppy, then copy the bitmap to the floppy. Delete both files, this clears the fat to show all of the space as unallocated, but the directory remains to be cleared. dd could be used to copy all zeros over the directory, and dd can also be used to copy the ascii strings into the unallocated sectors that follow the bmp file.
FAT12Next I mounted the image on a Linux loopback device as follows
JFIF
pw=help
John Smith's Address: 1212 Main Street, Jones, FL 00001
mount -o ro,loop,noatime,noexec,nodev scan26 /mnt/scan26As expected, the disk appeared to be empty. For further analysis I opted to use Brian Carrier's latest version of Autopsy, version 1.70 (http://autopsy.sourceforge.net) After creating a new case (scan26) and loading the scan26 image into the case. File Analysis turned up no files, deleted or otherwise and Meta Data revealed a zeroized directory.
Utilizing a keyword search for JFIF, sector 33 was found and using Data Unit analysis, was noted as the possible start point for a jpg image. After brushing up on the file format of a JFIF/JPG image, and tracing through various fields in the image, I chose to search for the EOI (END OF IMAGE) marker to find the end of the file.
Using hexedit I searched for FFD9 (JFIF EOI) and found exactly one match in the entire file, its offset in the file was 0xC158. Taking this to be the end of the JPG, and assuming the file to be in consecutive sectors, the following math yields the file size and number of sectors to display in Autopsy
0xC158 + 2 (2 byte EOI marker) = 0xC15A = 49498I used dd to pull the file from the image
start of sector 33 = 33 * 512 = 16896
Length of file = 49498 - 16896 = 32602 bytes
Sectors occupied = 32602 / 512 = 63.675 -> 64
dd if=scan26 bs=1 count=32602 skip=16896 of=sector33.jpgPulling this up in my browser yielded an interesting map, but not all of the required answers. Another interesting item that turned up in tracking down this JPG was it contained a rather large comment field of 7777 bytes, which made me consider the possiblity that it contained steganographic content. Running stegdetect version 0.5 against the recovered jpg yieds:
#stegdetect sector33.jpgSuggesting that Invisible Secrets may have been used to hide steganographic content with a lenght of 7771 byte which is consistant with the size of the embedded comment field.
sector33.jpg : invisible[7771](***)
I know little about steganography, and I hoped that the password
help might help in decrypting the stegonagraphic content, but I could
not get it to work. After considerable effort reverse engineering
the invisible secrets unhider, I was only able to determine that though
encryption may be used, it is certainly not Blowfish, regardless of the
password.
As a last resort I used every steganogrphy program I could find to
attempt to uncover any information from the file. Though I had no
luck I found it interesting that some programs inform you that a file
contains no stegangraphic content before you ever enter a password.
Hoping to find another file starting in the next sector, I used Autopsy to show me the next available sector (33 + 64 = 97). Autopsy seemed to think this might be a bitmap file, so I cracked open the bitmap file specification and decoded the length field to 1166454 bytes or 2278 sectors. The offset to sector 97 is 97 * 512 = 49664, so assuming once again consecutive sectors, I used dd to pull out the file
dd if=scan26 bs=1 count=1166454 skip=49664 of=sector97.bmpWARNING, amateur steganalysis follows: This turned out to be a valid bitmap file and yielded another answer, the location of the hideout. I wondered whether this file might contain any steganographic content, and though no program that I used could recover any, I did note an unusual pattern in the least significant bits of the pixel data. The large white field in the bmp suggests that most of the LSBs should be 1. This turns out to be true for a small portion of the file, but a large portion of the file fails to conform to this expectation, and may as a result contain steganographic content. I wrote a short program, exdat.c, to extract the LSBs, pack them togetehr and write the resulting data to a file. Opening the result, sector97.bmp.lsb, shows an initial field of all ones, followed by data that clearly is not all one, and might therefore contain stegangraphic content since it should be largely ones due to the large amount of white in the image.
"pw=help" in sector 2397and
"John Smith's Address: 1212 Main Street, Jones, FL 00001" in sector 2739No other useful information was noted in the remaining sectors of the disk. In the end, the disk turned out to be laid out as in the following picture:
