AUTHOR

Name: Yvette
Last Name: Agostini
Profession: System Engineer
e-mail: vodka@s0ftpj.org



ANALYSIS

First of all I downoladed the compressed floppy image file:
vodka@voodoo:~# wget http://www.honeynet.org/scans/scan26/scan26.zip

I set permissions on the file so that it will be readable only:

vodka@voodoo:~# chmod -w scan26.zip

vodka@voodoo:~# ls -al scan26.zip
-r--r--r--    1 vodka vodka   198866 feb 18 16:15 scan26.zip

I do a check on the md5sum for the compressed floppy image:

vodka@voodoo:~# md5sum scan26.zip
c8e2454b970538de26a0fa887017109b  scan26.zip

I decompress the floppy image:

vodka@voodoo:~# unzip scan26.zip -d evidence/
Archive:  scan26.zip
  inflating: evidence/scan26

I set permissions on the file so that it will be readonly and I check the md5sum for it.

I mount the decompressed floppy image via loop device:

vodka@voodoo:~# mount ./scan26 ./testing -o loop,ro

By using the mount command I verify the file system type:

vodka@voodoo:~# mount
.........
/home/vodka/evidence/scan26 on /home/vodka/evidence/testing type vfat (ro,loop=/dev/loop0)

I try to list the contents of the floppy image by using ls:

vodka@voodoo:~# ls -al testing/
totale 8
drwxr-xr-x    2 root     root         7168 gen  1  1970 .
drwxr-xr-x    3 root     root           96 feb 18 17:42 ..

It seems the floppy is empty.

I unmount the the floppy image and execute a strings command on it to determine if something is contained in the disk and to have some hints about the type of data (only the possibly interesting data from the output of the command are listed here):

vodka@voodoo:~# strings scan26 | less
NO NAME    FAT12
............
Invalid system disk
Disk I/O error
Replace the disk, and then press any key
IO      SYSMSDOS   SYS
WINBOOT SYS
............
kcpkt
kA$4
pw=help
John Smith's Address: 1212 Main Street, Jones, FL 00001

It is possible to identify that:

the FAT type is FAT12, which is typical of floppy formatted by DOS or Windows OS's (in this case we can suppose it is a windows flavour due to the presence of the string "WINBOOT")

The disk has no volume name

A pw=help, probably a password useful to gain access to something, probably a ciphered file

An address: John Smith's Address: 1212 Main Street, Jones, FL 00001, which could be the pusher's address.

Note: another quick way to accomplish the above task is by a shell script like this one (tnx Fabio!!)

#########################################################

##!/bin/sh
for i in `seq 1 140000`
         do
                 echo -n "offset $i :"
                (
                   dd if=scan26orig of=ntani skip=$i 2>/dev/null | \
                   file ntani | \
                   grep -v empty
                 )
         done

#########################################################

I continue the analysis using an hexadecimal editor (slackware version of vi) in order to unveil the contents of the floppy image and I see that the root directory, and the two FAT are filled with 0. For this reason no files were showed by issuing the ls command and, for the same reason, the df command on the mounted loopdevice gave no indication. In fact, in the root directory portion and in the FAT are contained the informations (starting sector, name and dimension) needed to identify the files stored in the magnetic support.

The OEM ID field does not give any indication about the OS under which the disk has been formatted.

A lot of data are found in the sectors following the root directory and the two FAT.
In order to identify the type of data and every possible hint about the length of the files I notice that FFD8 is the "magic number" related to jpeg images files.

At offset 4200 I see the beginning of a file:

00004200  ff d8 ff e0  00 10 4a 46  49 46 00 01  01 01 00 48  ����..JFIF.....H

The beginning of a jpeg file is marked by FFD8, the end of the file is marked by FFD9, so I put the data in between of these markers in a new file named modifiedscan2
Issuing a file command on it I obtain:

vodka@voodoo:~# file modifiedscan2
modifiedscan2: JPEG image data, JFIF standard 1.01, resolution (DPI), "SnUG<B3>-
D5<D2>#fk<BD>v< hi<D4>`<E8><A8><A4>-    Y<AB>", 72 x 72

The comment field seems broken, but the image contained in the file is readable using a graphic viewer. Looking at this file using Electric Eyes (an image viewer) I am able to identify the place where supposedly the drug deal happens:

shoreline drive - Danny's Pier 12 boat lunch

At offset 0c200 I see another known magic number "42 4d" which indicates a BitMap image.
0000c200 <42>4d 76 cc  11 00 00 00  00 00 36 00  00 00 28 00  BMv�......6...(.

The end of this file is marked by "00 01", so I did some try to identify the end of this file and finally copied the portion of data in a new file, named modified3.

Issuing the file command on it I obtain:
vodka@voodoo:~# file modified3
modified3: PC bitmap data, Windows 3.x format, 720 x 540 x 24

Viewing this file with Eeyes I see the the address where Jimmy Jungle is hiding:

22 Jones Avenue

It seems to me that no other files are in this floppy images, or I am not able to identify them.

But the presence of the string "pw=help" suggest some form of data encryption/hiding and I consider steganography, due to
the presence of a jpeg image. Jpegs, especially those reproducing photographic images, are often used as "container" for hiding different kind of information.

Using stegdetect on the file named modifiedscan2, I verify my hypothesis:

vodka@voodoo:~# stegdetect modifiedscan2
modifiedscan2 : invisible[7771](***)

It indicates an high probability that the jpeg image contains hidden data and the software which probably has been used to hide them (invisible secrets for windows).

I downloaded a trial version of Invisible Secret software on my win2k box and tried to extract the hidden data from the file modifiedscan2, using the password "help", without any success.

Due to lack of time I abandon the task without knowing which kind of car is Jimmy Jungle driving.
I think that this information is related both to the strings pw=help found in the disk image and the OEM ID field in the boot-sector of the floppy, but I have no time left to verify this hypotesis.