Difference between revisions of "Summerschool Aachen 2004/Incident Research Lab"

From C4 Wiki
Jump to: navigation, search
(→‎Analysing the content of an old hard drive and the content of a downloaded FAT16 image)
m (Reverted edits by Oxudocopaj (talk) to last revision by Mario Manno)
 
(12 intermediate revisions by 8 users not shown)
Line 1: Line 1:
−
[http://md.hudora.de/presentations/summerschool/2004-10-04/ Slides]
 
−
 
−
== Notes on Presentations ==
 
−
 
−
 
 
== Notes on Lab Session ==
 
== Notes on Lab Session ==
 
=== Analyzing the content of an old hard drive and the content of a downloaded FAT16 image ===
 
=== Analyzing the content of an old hard drive and the content of a downloaded FAT16 image ===
Line 44: Line 39:
  
 
5. Now start analyzing the Image, add your observations to the evidence directory and upload missing stuff when done.
 
5. Now start analyzing the Image, add your observations to the evidence directory and upload missing stuff when done.
 +
 +
=== Lab Session today ===
 +
Today I started with analysing the challenge Max gave to us. The first thing I've done after checksuming the image was to mount it, extract the three files and used a tool for cracking the Zip-archive. After an attack with a word-list didn't work out and I got bored by staring at the screen while the computer was performing a brute-force search for the password, I aborted it when it finished the exhaustive search for passwords of length 5.
 +
 +
Afterwards I tried the Sleuth Kit together with Autopsy to search for deleted or hidden stuff in the filesystem and it worked quite well. It is always a pleasure to have the right tools (which also includes a hex-editor). Overall a nice challenge, I especially like these hidden motivations like "good job" or "well done".  :)
 +
 +
In the afternoon I tried to optimise our project from last week, the java application which displays a wardriving session. Though we worked only two days on it, the program is already better than gpsmap (to my view), or it least will be when a few missing features will be implemented. I didn't get to manage to speed up the displaying performance, but I learned that a java application might keep on running after a NullPointerException.
 +
 +
--[[Jan Gall]]
 +
 +
=== playing around with images ===
 +
 +
For the labsession we had gotten a 30 megabyte image from a flash-
 +
card. The first thing I did was run file over it, the reply from file 
 +
was:
 +
 +
LabAssignment.image: x86 boot sector, code offset 0x3c, OEM-ID "MSDOS5.0",
 +
sectors/cluster 4, root entries 512, sectors 62560 (volumes <=32 MB) ,
 +
Media descriptor 0xf8, sectors/FAT 61, heads 4, hidden sectors 32, serial
 +
number 0x1d6615db, unlabeled, FAT (16 bit)
 +
 +
Then I did a strings on it. Some of the things I saw were "canon digital IXUS"
 +
which turned out to be the type of the flash card being used. I also saw some
 +
directory listing of some image files. That's about all the usefull things I
 +
got out of strings.
 +
 +
Then I mounted the image (which wasn't a problem since I had another copy
 +
of the image, incase something got damaged). It gave me 3 files:
 +
 +
-rwxr--r--    1 ilja    ilja        7.3K Oct  4 11:30 Secrit.exe*
 +
-rwxr--r--    1 ilja    ilja        553K Oct  4 11:29 dcim*
 +
-rwxr--r--    1 ilja    ilja          329 Oct  4 11:28 meeting.pst*
 +
 +
file gave me some more information:
 +
 +
Secrit.exe:  Microsoft Office document data
 +
dcim:        JPEG image data, EXIF standard 0.73, 10752 x 2048
 +
meeting.pst: Zip archive data, at least v2.0 to extract
 +
 +
Secrit.exe is password protected, so is meeting.pst. I found a program
 +
that extracted some data out of EXIF files, but found nothing interesting.
 +
 +
Then I decided to use a tool called autopsy which is a frontent for another
 +
tool called sleuthkit. When I examined the the image file with autopsy
 +
I found some more files that were previously deleted. The first one I
 +
found was a jpeg file:
 +
 +
images-LabAssignment.image-home.ilja.mnt._CIM.: JPEG image data, EXIF standard 0.73, 10752 x 2048
 +
 +
I then saw if something might be encoded in there:
 +
 +
../images-LabAssignment.image-home.ilja.mnt._CIM. : negative
 +
 +
Nothing there (as it turns out the picture itself was sort of a decoy).
 +
So I looked further into the delted files and found 2 word documents who
 +
look very simular. I extracted both. One seemed to be password protected,
 +
The other however wasn't. It contained a password (the password for the
 +
meeting.pst) "Well done!". When I entered that as a password for the
 +
meeting.pst file, it extracted a file called Xstuff.mov. I first tried
 +
to play it with mplayer, but that didn't work. then I did a list of the
 +
file:
 +
 +
-rw-r--r--    1 ilja    ilja          146 Oct  4 01:24 Xstuff.mov
 +
 +
So there is no way that this is a movie. So I ran it true file:
 +
 +
Xstuff.mov: Big-endian UTF-16 Unicode English character data, with no line terminators
 +
 +
Then I did a cat and pipe it to xxd:
 +
 +
0000000: feff 0054 0068 0065 0020 0073 0065 0063  ...T.h.e. .s.e.c
 +
0000010: 0072 0065 0074 0020 006d 0065 0065 0074  .r.e.t. .m.e.e.t
 +
0000020: 0069 006e 0067 0020 0077 0069 006c 006c  .i.n.g. .w.i.l.l
 +
0000030: 0020 0074 0061 006b 0065 0020 0070 006c  . .t.a.k.e. .p.l 
 +
0000040: 0061 0063 0065 0020 0061 0074 0020 0057  .a.c.e. .a.t. .W
 +
0000050: 0065 0064 006e 0065 0073 0064 0061 0079  .e.d.n.e.s.d.a.y
 +
0000060: 0020 006f 006e 0020 0074 0068 0065 0020  . .o.n. .t.h.e.
 +
0000070: 0074 006f 0070 0020 006f 0066 0020 0074  .t.o.p. .o.f. .t
 +
0000080: 0068 0065 0020 0074 0068 0069 006e 0067  .h.e. .t.h.i.n.g
 +
0000090: 002e                                    .. 
 +
 +
So there is the answer to the question that isn't documented (as far as
 +
I knowI was unable to find a .pdf or something on Max's homepage that
 +
asked questions about these evil people). From the forensics evidence
 +
it also showed that most of these files were produced on a mac and the
 +
name 'Maximillian Dornseif' kept popping up for some odd reason :). 
 +
 +
As a side note, I came up with 2 more possible ways to get the answer,
 +
The first is to look at the password protected word file and just change
 +
the password hash in it. I haven't actually done that today, but I
 +
know it's possible, I had done it once a while ago with some document
 +
for school.
 +
 +
edit: The hard disk I used was labeled: Ilja-2004-10-04-II. I also had
 +
      another hard disk (namely Ilja-2004-10-04-I) but didn't get around
 +
      to even making an image of that. I still need to upload the image of
 +
      Ilja-2004-10-04-II to the ftp server.
 +
 +
The second was to attack the encryption used to encrypt the zip file.
 +
Apparenty the pkzip algorithm was used. And this is known to be broken.
 +
After some googling I came up with a program called pkcrack which allowes
 +
you to find the password with a known plaintext attack. So I came up
 +
with a few assumptions that probably allows you to recover the password.
 +
The plaintexts that I'd probably choose would be: secret, meeting and 
 +
place. Then ofcourse you'd still need to figure out to use unicode,
 +
but I suppose you'd figure that out after a while.
 +
 +
I spend the latter part of the afternoon with making an image of one
 +
of the hard disks and anaysing that.
 +
 +
There were these great devices given to us that allowed you to put a
 +
hard disk in them and then hook it up to your laptop with usb.
 +
Seems easy doesn't it. Unfortunatly that wasn't the case. I tried it
 +
with one hard disk for about 2 hours but nothing seemed to work.
 +
 +
My kernel did detect that something was being connected to one of the
 +
usb ports, but beyond that nothing happend:
 +
 +
Oct  4 14:14:35 nikita kernel: hub.c: USB hub found
 +
Oct  4 14:14:35 nikita kernel: hub.c: 3 ports detected
 +
Oct  4 14:14:35 nikita kernel: hub.c: new USB device 00:01.3-2, assigned address 2
 +
...
 +
Oct  4 14:31:24 nikita usb.agent[899]: missing kernel or user mode driver usb-storage
 +
...
 +
 +
So for some reason that cool gadget that allowed me to use the harddisk
 +
didn't want to play with me. After looking for the problem for 2 hours I
 +
finaly found out that it wasn't the cool gadget that didn't want to play,
 +
it was the hard disk itself. Apparently they are too old. Max then provided
 +
me with a system of his own on which I could hook up this hard disk directly
 +
(using an ide cable). This worked like a charm. Taking the image took
 +
10 minutes, I put it on my box with ftp and halted Max's machine.
 +
 +
When Cpunkt Wanted to do the same all the suddon the hard disk in Max's
 +
box died, we were unable to get it back to work :(.
 +
 +
Anyways, When I looked at the image with autopsy it didn't see it as a FAT16
 +
or some other filesystem, So after some playing with autopsy I figured I'll
 +
just let it see it as a 'raw' image. When I did some further invstigation
 +
it turned out that I had also copied the master boot record and hence it didn't
 +
get recognized as a FAT 16 image:
 +
 +
img: x86 boot sector, MS-DOS MBR, german version 5.00 to 4.00.950
 +
 +
So after determining where the MBR ended and the FAT16 started I did another
 +
dd and got the actual FAT16 image:
 +
 +
img2: x86 boot sector, code offset 0x3c, OEM-ID "MSDOS5.0", sectors/cluster 4,
 +
root entries 512, Media descriptor 0xf8, sectors/FAT 249, heads 15, hidden sectors
 +
17, sectors 254983 (volumes > 32 MB) , serial number 0x1add4063, label: "MS-DOS_5  "
 +
, FAT (16 bit)
 +
 +
Then I also mounted the image:
 +
 +
root@nikita:/home/ilja#mount img2 /home/ilja/mnt -o loop
 +
root@nikita:/home/ilja#cd /home/ilja/mnt
 +
root@nikita:/home/ilja/mnt#ls -alhp
 +
total 36K
 +
drwxr--r--    2 root    root          16K Jan  1  1970 ./
 +
drwxr-xr-x  120 ilja    ilja          20K Oct  4 17:41 ../
 +
root@nikita:/home/ilja/mnt#
 +
 +
It seemed kinda odd to me that there wasn't a single file there. Then I decided to
 +
look at the root directory entry with autopsy:
 +
 +
0      00000000 00000000 00000000 00000000    .... .... .... ....
 +
16    00000000 00000000 00000000 00000000    .... .... .... ....
 +
32    00000000 00000000 00000000 00000000    .... .... .... ....
 +
48    00000000 00000000 00000000 00000000    .... .... .... ....
 +
64    00000000 00000000 00000000 00000000    .... .... .... ....
 +
80    00000000 00000000 00000000 00000000    .... .... .... ....
 +
96    00000000 00000000 00000000 00000000    .... .... .... ....
 +
112    00000000 00000000 00000000 00000000    .... .... .... .... 
 +
128    00000000 00000000 00000000 00000000    .... .... .... ....
 +
144    00000000 00000000 00000000 00000000    .... .... .... ....
 +
160    00000000 00000000 00000000 00000000    .... .... .... ....
 +
176    00000000 00000000 00000000 00000000    .... .... .... ....
 +
...
 +
 +
Hm, the guy who sold the hard disk had apparently deleted everything on it, what a
 +
bummer. Though I decided to look a little deeper into it. I started looking at the
 +
Image sector per sector (I did 1-1100 or something) and it appeared that most data
 +
was still on the harddisk. It was just warked as being gone. I recovered files like
 +
command.com, autoexec.bat and some more stuff, there wasn't much interesting on the
 +
hard disk. It was still fun to see how a hard disk where everything appears to be
 +
deleted is still filled with information. Just as proof, here is the autoexec.bat
 +
file:
 +
 +
@ECHO Off
 +
PATH C:\MOUSE;c:\;C:\NWDOS;C:\WINDOWS;C:\MOUSE;C:\NC;C:\DB\DB3;C:\NU;C:\WINDOWS\SYSTEM
 +
MOUSE
 +
SET CBACKUP=C:\CBEDOS
 +
PATH=C:\CBEDOS;%PATH%
 +
APPEND C:\ra6
 +
PROMPT $p$g
 +
LH /L:1,35536 MOUSE
 +
LH /L:0;1,45968 /S C:\WINDOWS\SMARTDRV.EXE /X 1024 128 
 +
SET TEMP=c:\nwdos\temp
 +
KEYB GR+
 +
VERIFY OFF
 +
c:\mouse\mouse
 +
IF NOT DIREXIST %TEMP% MD %TEMP%
 +
SET NWDOSCFG=C:\NWDOS\temp
 +
SET FBP_USER=Baupha GmbH Groáschnau
 +
loadhigh C:\NWDOS\SHARE /L:100 /F:17060
 +
c:\skeybgr
 +
copy c:\nc\nc.ver c:\nc\nc.ini
 +
 +
I considered this to be a very successfull labsession. I leared quite a lot.
 +
 +
=== Lab summary ===
 +
 +
I started by analyzing the 30 MB image given to us by Max. I mounted it
 +
after setting up a read-only virtual block device for it and found four
 +
files in there, of which the password protected zip file seemed to be
 +
the most interesting. After a suggestion by Sammy, I found the password
 +
using fcrackzip with a dictionary attack, using `strings $image` as word
 +
list. I looked around a bit more using the sleuth kit and found many
 +
deleted files, but strangely none of them contained usable data.
 +
 +
After that, I kind of got distracted by the [http://www.ru-eschweilerhof.de/ Rautavistische Universität Eschweilerhof],
 +
where I learned about the Wasserl oak and the Ölsch oak (Wasserl-Eiche
 +
and Ölsch-Eiche), named after their discoverers Franz-Josef Wasserl and
 +
Hermann Ölsch :)
 +
 +
Finally, I found some nice [http://averstak.tripod.com/fatdox/00dindex.htm documentation about FAT],
 +
which I then used to investigate the file system by hand. So now I can
 +
say, "I have been through hell, I won't ever have to decode FAT file
 +
systems by hand any more" :)
 +
 +
-- [[Alexander Becher]]
 +
 +
 +
=== foo bar ===
 +
 +
I also worked on the assignment and got the password for the zip file, but unfortunately without the trailing "!". All the tools on my computer refused to open the office document, but someone told me finally.
 +
 +
After that I had a hard disk from Max's stack. Creating an image with dd_rescue took quite long as the disk contained some bad blocks. The image did not contain any interesting files (deleted or not), just a windows 98 installation with very few programs and nearly no other data.
 +
 +
--[[User:Cpunkt|Cpunkt]] 14:23, 5 Oct 2004 (CEST)
 +
 +
 +
=== hard drive ide to usb bridge and old drives ===
 +
 +
Ford and I tried to analyse two very old hard drives, a Conner (170 MB) and a Maxtor. But with both our laptops the IDE/USB connector did not work correctly accessing the hard drives. The drives were recognized correctly, but as soon as we tried to read any data (cat /dev/sda or similar) nothing happened and we got no data at all. This took quite a lot of time, because we did not think it was the IDE/USB bridge's fault but ours.
 +
 +
We then decided to work on the LabAssignment and solved this on our own.
 +
 +
--[[User:Chrisd|Chrisd]] 15:54, 5 Oct 2004 (CEST)
 +
 +
=== FAT16 ===
 +
I used strings and bvi most of the time.
 +
Let me paste the structure of a FAT16 file entry here:
 +
<pre>
 +
BYTE Filename[8] // Pad with spaces
 +
BYTE Extension[3] //
 +
BYTE Attributes
 +
BYTE Reserved[10]
 +
WORD Time // Hour*2048+Min*32+sec/2
 +
WORD Date // (Yr-1980)*512 + Mon*32 + day
 +
WORD StartCluster
 +
DWORD
 +
</pre>
 +
Afterwards i was introduced to sleuthkit/autopsy, which made the undelete files job a lot easier.
 +
 +
--[[User:Mario Manno|MM]] 17:20, 5 Oct 2004 (CEST)
 +
 +
[[Category:Summerschools]] [[Category:Hacks]]

Latest revision as of 17:36, 24 November 2010

Notes on Lab Session

Analyzing the content of an old hard drive and the content of a downloaded FAT16 image

We first took a used Maxtor 90845d4 8GB (S26361-H435-V100, SAM-2004-10-04-I) hard drive and built it in into our box for external hard drives (photos of that will be available soon). Then we used the command cat /dev/sda | strings > strings.txt in order to write all the strings contained in the image into the file called strings. The image contained a lot of strings, among other things several Windows log-in passwords. We also found a lot of text about inventories and customer data which made us guess that the hard drive was used in a company before. We later found out from Max that the hard drive was used by a computer shop before. On the hard drive there was a HPFS/NTFS filesystem installed. As we wanted to play around a little bit more with the content of that hard drive we decided to copy it to another external hard drive, mount it and further analyze its content. Copying the image from one hard drive to another took us almost three and half hours...After that we tried to mount the partition on the copied image which unfortunately didn't work out. We should have just copied the partition from the image instead of the whole image. But it was too late by the time we had realized this... During the time the image was copied we did several different things: - we took out an scsi hard drive from a Sparc 5 workstation and build it in with an scsi controller into another computer from the laboratory. - we downloaded an image and analyzed its content: There was a password protected zip file which we opened using a zip cracking tool and using the image itself as a dictionary. The password was found very easily and we could read the secret message...

--Samad Nasserian, Boris Leidner

Software packages you might find useful

You might want to look into the following tools:

  • graverobber - grab important data from system
  • ddrescue - spiced up dd
  • sleuthkit, autopsy - forensic toolkit (includes inode cat, ...)
  • fcrackzip - zip password cracker
  • nasm - netwide disasembler
  • e2undel - undelete for ext2
  • ntfstools - undelete for ntfs
  • bview - nice hex editor, vim-like
  • bsdmainutils (includes hd), or vim (includes xxd)
  • chntpw - reset windows passwords, browse registry

Have a look at the Links page!

Images to look at

Image from a Cash Register

Forensic Imaging Best Practice

1. get a disk and ensure that there is a ID on that disk. IDs should look like UU-YYYY-MM-DD-X where UU is your user ID, YYYY, MM, DD represent the date and X is a roman number used as a serial number to distinguish several hard disks you image in one day. So I might use something like md-2004-10-04-I as an ID. Write it on the disk with marker and create a directory with the same name for your evidence data.

2. Connect the disk to your computer. You might want to try to remove the original disk from one of our external USB disk and put in the disk to image. We find that "real" IDE and SCSI works better.

3. Go to you evidence directory and create a file like md-2004-10-04-I.txt where you note model, serial number manufacturer, etc. of the HD, other noteworthy thinks, your name and actual time. Then create the image with something like dd if=/dev/hdX of=./md-2004-10-04-I.image

4. Upload the your whole evidence directory to ftp://discovery.informatik.rwth-aachen.de/incoming/DiskImages/

5. Now start analyzing the Image, add your observations to the evidence directory and upload missing stuff when done.

Lab Session today

Today I started with analysing the challenge Max gave to us. The first thing I've done after checksuming the image was to mount it, extract the three files and used a tool for cracking the Zip-archive. After an attack with a word-list didn't work out and I got bored by staring at the screen while the computer was performing a brute-force search for the password, I aborted it when it finished the exhaustive search for passwords of length 5.

Afterwards I tried the Sleuth Kit together with Autopsy to search for deleted or hidden stuff in the filesystem and it worked quite well. It is always a pleasure to have the right tools (which also includes a hex-editor). Overall a nice challenge, I especially like these hidden motivations like "good job" or "well done".  :)

In the afternoon I tried to optimise our project from last week, the java application which displays a wardriving session. Though we worked only two days on it, the program is already better than gpsmap (to my view), or it least will be when a few missing features will be implemented. I didn't get to manage to speed up the displaying performance, but I learned that a java application might keep on running after a NullPointerException.

--Jan Gall

playing around with images

For the labsession we had gotten a 30 megabyte image from a flash- card. The first thing I did was run file over it, the reply from file was: 

LabAssignment.image: x86 boot sector, code offset 0x3c, OEM-ID "MSDOS5.0",
sectors/cluster 4, root entries 512, sectors 62560 (volumes <=32 MB) ,
Media descriptor 0xf8, sectors/FAT 61, heads 4, hidden sectors 32, serial
number 0x1d6615db, unlabeled, FAT (16 bit)

Then I did a strings on it. Some of the things I saw were "canon digital IXUS" which turned out to be the type of the flash card being used. I also saw some directory listing of some image files. That's about all the usefull things I got out of strings.

Then I mounted the image (which wasn't a problem since I had another copy of the image, incase something got damaged). It gave me 3 files: 

-rwxr--r--    1 ilja     ilja         7.3K Oct  4 11:30 Secrit.exe*
-rwxr--r--    1 ilja     ilja         553K Oct  4 11:29 dcim*
-rwxr--r--    1 ilja     ilja          329 Oct  4 11:28 meeting.pst*

file gave me some more information: 

Secrit.exe:  Microsoft Office document data
dcim:        JPEG image data, EXIF standard 0.73, 10752 x 2048
meeting.pst: Zip archive data, at least v2.0 to extract

Secrit.exe is password protected, so is meeting.pst. I found a program that extracted some data out of EXIF files, but found nothing interesting.

Then I decided to use a tool called autopsy which is a frontent for another tool called sleuthkit. When I examined the the image file with autopsy I found some more files that were previously deleted. The first one I found was a jpeg file: 

images-LabAssignment.image-home.ilja.mnt._CIM.: JPEG image data, EXIF standard 0.73, 10752 x 2048

I then saw if something might be encoded in there: 

../images-LabAssignment.image-home.ilja.mnt._CIM. : negative

Nothing there (as it turns out the picture itself was sort of a decoy). So I looked further into the delted files and found 2 word documents who look very simular. I extracted both. One seemed to be password protected, The other however wasn't. It contained a password (the password for the meeting.pst) "Well done!". When I entered that as a password for the meeting.pst file, it extracted a file called Xstuff.mov. I first tried to play it with mplayer, but that didn't work. then I did a list of the file: 

-rw-r--r--    1 ilja     ilja          146 Oct  4 01:24 Xstuff.mov

So there is no way that this is a movie. So I ran it true file: 

Xstuff.mov: Big-endian UTF-16 Unicode English character data, with no line terminators

Then I did a cat and pipe it to xxd: 

0000000: feff 0054 0068 0065 0020 0073 0065 0063  ...T.h.e. .s.e.c
0000010: 0072 0065 0074 0020 006d 0065 0065 0074  .r.e.t. .m.e.e.t 
0000020: 0069 006e 0067 0020 0077 0069 006c 006c  .i.n.g. .w.i.l.l
0000030: 0020 0074 0061 006b 0065 0020 0070 006c  . .t.a.k.e. .p.l  
0000040: 0061 0063 0065 0020 0061 0074 0020 0057  .a.c.e. .a.t. .W
0000050: 0065 0064 006e 0065 0073 0064 0061 0079  .e.d.n.e.s.d.a.y
0000060: 0020 006f 006e 0020 0074 0068 0065 0020  . .o.n. .t.h.e.
0000070: 0074 006f 0070 0020 006f 0066 0020 0074  .t.o.p. .o.f. .t
0000080: 0068 0065 0020 0074 0068 0069 006e 0067  .h.e. .t.h.i.n.g
0000090: 002e                                     ..

So there is the answer to the question that isn't documented (as far as I knowI was unable to find a .pdf or something on Max's homepage that asked questions about these evil people). From the forensics evidence it also showed that most of these files were produced on a mac and the name 'Maximillian Dornseif' kept popping up for some odd reason :).

As a side note, I came up with 2 more possible ways to get the answer, The first is to look at the password protected word file and just change the password hash in it. I haven't actually done that today, but I know it's possible, I had done it once a while ago with some document for school.

edit: The hard disk I used was labeled: Ilja-2004-10-04-II. I also had 

     another hard disk (namely Ilja-2004-10-04-I) but didn't get around 
     to even making an image of that. I still need to upload the image of 
     Ilja-2004-10-04-II to the ftp server.

The second was to attack the encryption used to encrypt the zip file. Apparenty the pkzip algorithm was used. And this is known to be broken. After some googling I came up with a program called pkcrack which allowes you to find the password with a known plaintext attack. So I came up with a few assumptions that probably allows you to recover the password. The plaintexts that I'd probably choose would be: secret, meeting and place. Then ofcourse you'd still need to figure out to use unicode, but I suppose you'd figure that out after a while.

I spend the latter part of the afternoon with making an image of one of the hard disks and anaysing that.

There were these great devices given to us that allowed you to put a hard disk in them and then hook it up to your laptop with usb. Seems easy doesn't it. Unfortunatly that wasn't the case. I tried it with one hard disk for about 2 hours but nothing seemed to work.

My kernel did detect that something was being connected to one of the usb ports, but beyond that nothing happend: 

Oct  4 14:14:35 nikita kernel: hub.c: USB hub found
Oct  4 14:14:35 nikita kernel: hub.c: 3 ports detected
Oct  4 14:14:35 nikita kernel: hub.c: new USB device 00:01.3-2, assigned address 2
...
Oct  4 14:31:24 nikita usb.agent[899]: missing kernel or user mode driver usb-storage
...

So for some reason that cool gadget that allowed me to use the harddisk didn't want to play with me. After looking for the problem for 2 hours I finaly found out that it wasn't the cool gadget that didn't want to play, it was the hard disk itself. Apparently they are too old. Max then provided me with a system of his own on which I could hook up this hard disk directly (using an ide cable). This worked like a charm. Taking the image took 10 minutes, I put it on my box with ftp and halted Max's machine.

When Cpunkt Wanted to do the same all the suddon the hard disk in Max's box died, we were unable to get it back to work :(.

Anyways, When I looked at the image with autopsy it didn't see it as a FAT16 or some other filesystem, So after some playing with autopsy I figured I'll just let it see it as a 'raw' image. When I did some further invstigation it turned out that I had also copied the master boot record and hence it didn't get recognized as a FAT 16 image: 

img: x86 boot sector, MS-DOS MBR, german version 5.00 to 4.00.950

So after determining where the MBR ended and the FAT16 started I did another dd and got the actual FAT16 image: 

img2: x86 boot sector, code offset 0x3c, OEM-ID "MSDOS5.0", sectors/cluster 4,
root entries 512, Media descriptor 0xf8, sectors/FAT 249, heads 15, hidden sectors
17, sectors 254983 (volumes > 32 MB) , serial number 0x1add4063, label: "MS-DOS_5   "
, FAT (16 bit)

Then I also mounted the image: 

root@nikita:/home/ilja#mount img2 /home/ilja/mnt -o loop
root@nikita:/home/ilja#cd /home/ilja/mnt
root@nikita:/home/ilja/mnt#ls -alhp
total 36K
drwxr--r--    2 root     root          16K Jan  1  1970 ./
drwxr-xr-x  120 ilja     ilja          20K Oct  4 17:41 ../
root@nikita:/home/ilja/mnt#

It seemed kinda odd to me that there wasn't a single file there. Then I decided to look at the root directory entry with autopsy: 

0      00000000 00000000 00000000 00000000     .... .... .... ....
16     00000000 00000000 00000000 00000000     .... .... .... ....
32     00000000 00000000 00000000 00000000     .... .... .... ....
48     00000000 00000000 00000000 00000000     .... .... .... ....
64     00000000 00000000 00000000 00000000     .... .... .... ....
80     00000000 00000000 00000000 00000000     .... .... .... ....
96     00000000 00000000 00000000 00000000     .... .... .... ....
112    00000000 00000000 00000000 00000000     .... .... .... ....  
128    00000000 00000000 00000000 00000000     .... .... .... ....
144    00000000 00000000 00000000 00000000     .... .... .... ....
160    00000000 00000000 00000000 00000000     .... .... .... ....
176    00000000 00000000 00000000 00000000     .... .... .... ....
...

Hm, the guy who sold the hard disk had apparently deleted everything on it, what a bummer. Though I decided to look a little deeper into it. I started looking at the Image sector per sector (I did 1-1100 or something) and it appeared that most data was still on the harddisk. It was just warked as being gone. I recovered files like command.com, autoexec.bat and some more stuff, there wasn't much interesting on the hard disk. It was still fun to see how a hard disk where everything appears to be deleted is still filled with information. Just as proof, here is the autoexec.bat file: 

@ECHO Off
PATH C:\MOUSE;c:\;C:\NWDOS;C:\WINDOWS;C:\MOUSE;C:\NC;C:\DB\DB3;C:\NU;C:\WINDOWS\SYSTEM
MOUSE
SET CBACKUP=C:\CBEDOS
PATH=C:\CBEDOS;%PATH%
APPEND C:\ra6
PROMPT $p$g
LH /L:1,35536 MOUSE
LH /L:0;1,45968 /S C:\WINDOWS\SMARTDRV.EXE /X 1024 128  
SET TEMP=c:\nwdos\temp
KEYB GR+
VERIFY OFF
c:\mouse\mouse
IF NOT DIREXIST %TEMP% MD %TEMP%
SET NWDOSCFG=C:\NWDOS\temp 
SET FBP_USER=Baupha GmbH Groáschnau
loadhigh C:\NWDOS\SHARE /L:100 /F:17060
c:\skeybgr
copy c:\nc\nc.ver c:\nc\nc.ini

I considered this to be a very successfull labsession. I leared quite a lot.

Lab summary

I started by analyzing the 30 MB image given to us by Max. I mounted it after setting up a read-only virtual block device for it and found four files in there, of which the password protected zip file seemed to be the most interesting. After a suggestion by Sammy, I found the password using fcrackzip with a dictionary attack, using `strings $image` as word list. I looked around a bit more using the sleuth kit and found many deleted files, but strangely none of them contained usable data.

After that, I kind of got distracted by the Rautavistische Universität Eschweilerhof, where I learned about the Wasserl oak and the Ölsch oak (Wasserl-Eiche and Ölsch-Eiche), named after their discoverers Franz-Josef Wasserl and Hermann Ölsch :)

Finally, I found some nice documentation about FAT, which I then used to investigate the file system by hand. So now I can say, "I have been through hell, I won't ever have to decode FAT file systems by hand any more" :) 

-- Alexander Becher


foo bar

I also worked on the assignment and got the password for the zip file, but unfortunately without the trailing "!". All the tools on my computer refused to open the office document, but someone told me finally.

After that I had a hard disk from Max's stack. Creating an image with dd_rescue took quite long as the disk contained some bad blocks. The image did not contain any interesting files (deleted or not), just a windows 98 installation with very few programs and nearly no other data.

--Cpunkt 14:23, 5 Oct 2004 (CEST)


hard drive ide to usb bridge and old drives

Ford and I tried to analyse two very old hard drives, a Conner (170 MB) and a Maxtor. But with both our laptops the IDE/USB connector did not work correctly accessing the hard drives. The drives were recognized correctly, but as soon as we tried to read any data (cat /dev/sda or similar) nothing happened and we got no data at all. This took quite a lot of time, because we did not think it was the IDE/USB bridge's fault but ours.

We then decided to work on the LabAssignment and solved this on our own.

--Chrisd 15:54, 5 Oct 2004 (CEST)

FAT16

I used strings and bvi most of the time. Let me paste the structure of a FAT16 file entry here: 

BYTE Filename[8] // Pad with spaces
BYTE Extension[3] //
BYTE Attributes
BYTE Reserved[10]
WORD Time // Hour*2048+Min*32+sec/2
WORD Date // (Yr-1980)*512 + Mon*32 + day
WORD StartCluster
DWORD

Afterwards i was introduced to sleuthkit/autopsy, which made the undelete files job a lot easier.

--MM 17:20, 5 Oct 2004 (CEST)

Retrieved from "https://wiki.koeln.ccc.de/index.php?title=Summerschool_Aachen_2004/Incident_Research_Lab&oldid=15040"