First we obtain the "image.zip" file, verify the checksum and extract
it.
We get the "image" file, which is an image of the intercepted diskette and as expected it has a size of 1.44MBytes (the size of a Floppy disk).
One thing that catches our eye is that the compressed file is really small compared with the extracted version. This means that the amount of information is not big (which does not mean that it's not important!).
Knowing that we start with something as simple as an hexdump of the file
xxd image > image.dmp
We take a look at image.dmp and see that there's plenty of "f6" characters. This clearly looks like the default "bytes" when there's no content in the diskette. So we decide to strip the informationless parts of the file.
grep -v f6f6\ f6f6\ f6f6\ f6f6\ f6f6\ f6f6\ f6f6\ f6f6 image.dmp > nonblank.dmp
We now have a file that's less than 4% of the original one, which confirms that most of the diskette does not contain information.
We can now take a visual look to "nonblank.dmp". We inmediattely identify the boot sector that identifies the floppy as formated with "MSDOS5.0", which means that some version of Windows was used to format it.
At Offset 200 we find the beginning of the first copy of the FAT as expected (see http://www.manningjames.com/college/sem2/fat12.htm or your favourite FAT filesystem documentation). We see that it seems that there are no files at the beginning of the diskette, which makes us think that something was deleted (usually in a blank diskette the first files created use the first sectors).
For the moment we keep moving. At Offset 1400 we see the second copy of the FAT, also as expected. We can see that both are equal
xxd -s 0x1400 -l 0x100 image|perl -p -e 's/000014/000002/'>fat2.txt
#we do the perl substitution so both text files are equal.
xxd -s 0x200 -l 0x100 image>fat1.txt
diff fat2.txt fat1.txt
We keep moving and at offset 2600 we find (again as expected) the Root
directory.
In it we see what seems to be 3 entries;
- The first one is deleted and belongs to a file named "Jimmy
Jungle.doc" (and "JIMMY~1.DOC" for short)
- The second one is named "cover page.jpgc" (and "COVERP~1.JPG"
for short)
- The third one is named "Scheduled visits.exe" (and "SCHEDU~1EXE"
for short)
We keep moving and see nothing interesting until we arrive to the first
sector used by files at offset 4200.
There we see what (as seen before in the FAT entries) seems like the
contents of a file. We keep seeing unreadable content until we reach offset
4c00 where we see the following text;
------------------------------------------
Jimmy Jungle
626 Jungle Ave Apt 2
Jungle, NY 11111
Jimmy:
Dude, your pot must be the best <96> it made the cover of High Times Magazine! Thanks for sending me the Cover Page. What do you put in your soil when you plant the marijuana seeds? At least I know your growing it and not some guy in Columbia.
These kids, they tell me marijuana isn't addictive, but they don't stop buying from me. Man, I'm sure glad you told me about targeting the high school students. You must have some experience. It's like a guaranteed paycheck. Their parents give them money for lunch and they spend it on my stuff. I'm an entrepreneur. Am I only one you sell to? Maybe I can become distributor of the year!
I emailed you the schedule that I am using. I think it helps me cover myself and not be predictive. Tell me what you think. To open it, use the same password that you sent me before with that file. Talk to you later.
Thanks,
Joe
-------------------------------------------
This seems to be a text file, but it could also be part of the file that started on offset 4200. In fact after this and until offset 9200 we keep seeing content that seems to belong to a MS Word document.
So we save the three parts found so far (before the text, the text and
after the text) in three different files. But we also create one file as
the union of those three (in case it all is a single big file).
xxd -s 0x4200 -l 0x0a00 image|xxd -r -s -0x4200 - > firstpart.file
xxd -s 0x4c00 -l 0x0400 image|xxd -r -s -0x4c00 - > secondpart.file
xxd -s 0x5000 -l 0x4200 image|xxd -r -s -0x5000 - > thirdpart.file
cat firstpart.file secondpart.file thirdpart.file > complete.file
In offset 9200 we see what looks like a JPEG file is seen (the "JFIF" string indicates it). This seems to go on until we reach offset d000, but it is important to not one string found just before the end of the file. At offset 000cf20 we find
pw=goodtimes
which does not seem to be part of a normal JPEG file.
So we exctract the JPEG file;
xxd -s 0x9200 -l 0x3e00 image|xxd -r -s -0x9200 - > jpeg.file
Next we find a typical signature of a ZIP compressed file (the "PK" string). This file seems to reach up to offset da00, where there's nothing else left except for an empty last sector on the diskette. So we extract the compressed file
xxd -s 0xd000 -l 0xa00 image|xxd -r -s -0xd000 - > zip.file
Now we have all the "content" of the diskette extracted. We are now going to check what we got
file *.file
complete.file:
Microsoft Office Document
firstpart.file: Microsoft
Office Document
jpeg.file:
JPEG image data, JFIF standard
secondpart.file: Non-ISO
extended-ASCII English text, with very long lines, with CR line terminators
thirdpart.file: data
zip.file:
Zip archive data, at least v2.0 to extract
With a graphical viewer we can open the jpeg.file. So it seems fine.
It seems to be the cover of the "High Times".
With a wordviewer (I use aviword) we can see that the "complete.file"
can be opened without problem.
With unzip we can open the zip.file. It requests a password, which
happens to be "goodtimes". This provides a file named "Scheduled
Visits.xls" which we can view with "gnumeric" (which reads ".xls" files)
to reveal the timetable that is mentioned on the message found in the word
document. We can get there the schools Joe Jacobs frequents.
We now try to mount the image to see what can we see on the directory (we know more or less what to expect)
mkdir /disk
mount -o nodev,loop,noexec,ro image /disk
As soon as we enter into the /disk directory we see that the results
are somewhat unexpected. Probably this is the result of attempts to mask
the files, so we better go to the OS that created and worked with the Diskette.
We look for a Windows machine to be able to see what happens with the
directory entries.
Before leaving linux we prepare a floppy with the contents of the image;
dd if=image of=/dev/fd0
Now we take the diskette to a Windows machine.
The first thing we see is that if we try to copy the two files that
we find none of them gets correctly copied.
In the case of the file named "Schedu~1.exe" we see that in fact it
is the zip.file, but it shows a size of only 1K when. We also notice that
it´s only showing the short file name. The long file name is not
being shown.
On the case of the file named "cover page.jpgc" we see, when we select it, that it has some "extra" blank spaces at the end. When we try to copy it it fails (File System Error 1026).
So now it´s clear that the root directory entry has been altered (and who knows if something more like the FAT!). We don´t follow more through this path as we already have the files we wanted.
Last (but not least) we try to identify which microsoft application
was used to save the graphic file. To do that we create sample files with
different applications capable of generating a JPEG/JFIF image. Then we
compare those files with the one we have recovered. Inmediattely cathes
our eye that the one generated with Paint
has an almost identical beginning of file. We also check that this "fingerprint"
is different for the rest of applications we test (MS Photo Editor, MS
Imaging, xnView and ACDSee).
As we can see in the word document the supplier and his address
are
Jimmy Jungle
626 Jungle Ave Apt 2
Jungle, NY 11111
At the end of the file there's the line "pw=goodtimes" that allows
to unzip later on a compressed file.
Key High School
Leetch High School
Birard High School
Richter High School
Hull High School
This information is found in the excel spreadsheet contained in the
Zip file extracted with the password found in the previous question.
The word document has been deleted, the graphic file and the Zip
file have their entries on the root directory altered. It´s not relevant
for the investigation the kind of alteration performed.
See the analysis done.
Microsoft Paint. The proof is in the "signature" the application
leaves when it saves JPG files. The first sector (512 bytes) of the recovered
grafic file matches almost completely the first sector of ANY image saved
with Paint (a check to http://www.w3.org/Graphics/JPEG/jfif.txt reveals
that the differences are in the some of the parameters like the size of
the image). This does not happen when we save JPG files with other applications.
