SotM 26

David Barroso Berrueta
tomac@somoslopeor.com

The Challenge:

In SotM 24 your mission was to analyze a floppy disk recovered from the drug dealer Joe Jacobs. In this new challenge, your mission is to analyze the floppy recovered from his computer savy supplier, Jimmy Jungle. Once again, you will need to read the police report before continuing. Just as in the last challenge, this situation is fictional, and not based on any real characters or incidents.

Work Flow:

After reading the police report, I downloaded the scan26.zip file for finding out all question's answer. First of all, I checked that the hash was correct:

tomac@moskovskaya:~/forensics$ md5sum scan26.zip
c8e2454b970538de26a0fa887017109b scan26.zip

and then, just the same for the unzipped file:

tomac@moskovskaya:~/forensics$ unzip scan26.zip
Archive: scan26.zip
inflating: scan26
tomac@moskovskaya:~/forensics$ md5sum scan26
e9c7d0c87ab0ecce09bf90362b830a74 scan26

Both md5 hashes were correct; then, the evidence seized from the flat was valid. As I didn't know which kind of raw image was, I ran the 'file' command to check it:

tomac@moskovskaya:~/forensics$ file scan26
scan26: x86 boot sector

Then, using TASK (specially using the Autopsy browser), but for showing the process, using the 'sorter' tool, I realized that there weren't any allocated file in the disk:

tomac@moskovskaya:~/forensics$ sorter -f fat12 -i -l scan26
--------------------------------------------------
Images
- scan26

Files (3)
- Allocated (0)
- Unallocated (3)

Files Skipped (3)
- Non-Files (3)
- 'ignore' category (0)

Categories (0)

(I was supposing that the raw image was a FAT12 image because running 'strings scan26' I could see a FAT12 NO NAME line).
So, next step would be anlyze the image with a hexadecimal editor, to find out which the contents are. I usually execute 'biew' utiliy to do it. What I found, is that the image contained four different parts (besides the operating system and FAT structure stuff):

A big amount of data starting with JFIF, which could be a JPEG file.
Lot of blank disk and then something starting with BM.
Blank disk and the string 'pw=help'.
A string 'John Smith's Address: 1212 Main Street, Jones, FL 00001' at the end of the file.

First section

Checking with the hexadecimal editor and with the Autopsy software, the supposed JPEG file started in the sector 33 and its length was 64 sectors (remember, its sectors is 512 bytes long). I could have executed a 'dd' to get that portion of file, but I prefered to run 'foremost'. 'Foremost' is a tool for finding files in raw images according to its filesize and header (like using the magic file). The result was a JPG file, 32602 length, which foremost named 00000000.jpg. In that file you can see a map from the village where the drug dealer is working. I noticed that there was something strange with the JPEG file, because in the beginning of the file, there is a section (a comment section) with a lot of non random data, but it's likely to be encrypted data.

Second section

After the JPEG file, the disk is blank until the string 'BM' is found. 'BM' is one of the requisites for the BMP file to start with. The BMP header format is the following:

00	01	02	03	04	05	06	07	08	09	0A	0B	0C	0D	0E	0F
42	4D	??	??	??	??	00	00	00	00	??	??	??	??	28	00
'B'	'M'	BMP file size				Reserved				start address of datas				size of [0E-35]
10	11	12	13	14	15	16	17	18	19	1A	1B	1C	1D	1E	1F
00	00	??	??	??	??	??	??	??	??	01	00	??	??	00	00
		BMP Width				BMP Height				color planes		bits/pixel		Compression format
20	21	22	23	24	25	26	27	28	29	2A	2B	2C	2D	2E	2F
00	00	00	00	00	00	00	00	00	00	00	00	00	00	00	00
		BMP data size				width pixels/meter				height pixels/meter				color tables
30	31	32	33	34	35	36...
00	00	00	00	00	00	??	??	??	??	??	??	??	??	??	??
		color indexes				color palette or BMP data

That was exactly how our possible BMP file started:
4d42 cc76 0011 0000 0000 0036 0000 0028
0000 02d0 0000 021c 0000 0001 0018 0000

(take care with the swap) Then, our BMP filesize was (in hex) 0x0011cc76, which is 1166454 in decimal. Using the hex editor, I could realized that the BMP file started in byte 49664 (sector 97), so I ran the next command for getting the file out of the raw image:

dd if=scan26 of=nose.bmp bs=1 skip=49664 count=1166454

In this new image, I could see where Jimmy was hiding. It's an updated map from the JPEG file with the location of Jimmy's hideout.

Third section

Only the string 'pw =help' is available in this section. The only thing I can think about it, is that it's related to the 'strange section' in the JPEG file. Then, I did some extra checks against the JPEG file but without any success:

I ran the tool stegdetect to check if there was something encoded in the image file. Stegdetect is a automated tool designed to detect steganographic content create by some popular stegano tools in jpeg images. It told me that it could be something inside encrypted by the stegano tool 'Invisible Secrets'. I downloaded a shareware version and tried to decrypt the info (with the password='help') but I couldn't.
I ran the toll stegbreak, trying to do a brute force attack using an english dictionary but with no success.
I extracted the 'strange section' from the image file. As the data was ascii data, I thought that it could be a uuencoded file. I tried to uudecode it, but it didn't work.

I suspect that both the 'pw=help' string and the JPEG 'strange section' are related, it's the only part of the raw image where the Jimmy's car could be found.

Fourth section

The string 'John Smith's Address: 1212 Main Street, Jones, FL 00001' is at the end of the file.

Questions

Who is the probable supplier of drugs to Jimmy Jungle? The probable supplier should be John Smith.
What is the mailing address of Jimmy Jungle's probable drug supplier? 1212 Main Street, Jones, FL 00001.
What is the exact location in which Jimmy Jungle received the drugs? Danny's Pier 12 boat (supposed to be at lunch time).
Where is Jimmy Jungle currently hiding? 22 Jones Ave.
What kind of car is Jimmy Jungle driving?

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?

The reason for not being entries int the root directory and FAT, is that the FAT was 'reset'. This can be accomplished by means of a utility for wiping the FAT , like killfc, or using some data eraser that does not work very well (for example, for trying to format a harddisk).

Md5sums

aee13c3e61441da124125fc1f9e9b869 00000000.jpg
0bfa07f4debbc96a3f52459e6baa4a82 nose.bmp