Summerschool Aachen 2004/Forensics Lab
Contents
noted on the coffee table talk
The page where you can find out the amount of randomness used for randomization of the stack, libraries, ... is here
The proof of concept exploit to break pax can be found here
Notes on Presentations
Notes on Lab Session
Analysing the ufs.image.gz file system image
I looked at the image ufs.image (available from here). First I tried to recognise what file system it is. For this I used the header file fs.h that contains the structures and magic fields of the ufs and ufs2 file systems.
I first looked for the magic value of ufs2 ("0x19540119"). Just to check I looked for the ufs (1) magic value ("0x011954") which was not found.
George@GD216 ~/hdimage $ xxd.exe -a -g 4 ufs.image | grep "19015419" 0044550: 00000000 00000000 00000000 19015419 ..............T.
I then looked for the cylinder groups in the file system. The records have the following structure:
#define CG_MAGIC 0x090255
442 struct cg {
443 int32_t cg_firstfield; /* historic cyl groups linked list */
444 int32_t cg_magic; /* magic number */
445 int32_t cg_old_time; /* time last written */
446 int32_t cg_cgx; /* we are the cgx'th cylinder group */
447 int16_t cg_old_ncyl; /* number of cyl's this cg */
448 int16_t cg_old_niblk; /* number of inode blocks this cg */
449 int32_t cg_ndblk; /* number of data blocks this cg */
450 struct csum cg_cs; /* cylinder summary information */
451 int32_t cg_rotor; /* position of last used block */
452 int32_t cg_frotor; /* position of last used frag */
453 int32_t cg_irotor; /* position of last used inode */
[...]
Looking for the magic number yields 4 cylinder groups. Note that the second, third and fourth have been modified at the same time (probably when the file system was created - time 1096997352), while the first one was modified subsequently (time 1096997738). Therefore we should look for interesting files in there!
George@GD216 ~/hdimage $ xxd.exe -a -g 4 ufs.image | grep "55020900" 0008000: 00000000 55020900 6adb6241 00000000 ....U...j.bA.... 040c000: 00000000 55020900 e8d96241 01000000 ....U.....bA.... 0810000: 00000000 55020900 e8d96241 02000000 ....U.....bA.... 0c14000: 00000000 55020900 e8d96241 03000000 ....U.....bA....
reiserfs read-only mount
mount seems to change reiserfs only if it operates on a device. If you access the file directly the image won't change. If you don't use -o ro the image will certainly change.
# no change mount -o loop,ro -t reiserfs testreiser test # change losetup /dev/loop0 testreiser mount -o ro -t reiserfs /dev/loop0 test # certain change mount -o loop -t reiserfs testreiser test
lab session 12
So far I've analysed the ufs.image.gz file and ISO9660.cdr. The ufs.image is a plain 16MB UFS filesystem image. It contains one normal file '/test.txt', a snapshot directory with an empty file '/.snap/bla.txt' and a deleted file '/deleted.txt'. test.txt contains the standard output of a ping to www.ccc.de. deleted.txt is empty and was last changed at 2004.10.05 17:35:38 (UTC). From the filesystem meta information you can see that the volume was last mounted on /mnt/test0.
The name ISO9660.cdr is misleading, because this file doesn't contain a CD image but a FAT12 filesystem, created on MS-DOS 5. The image still contains some undeleted files.
ls -lR: ------- total 68 drwxr-xr-x 1 root wheel 4096 Dec 31 1979 DCIM -rwxr-xr-x 1 root wheel 0 Oct 5 12:06 Google Search- urteil kim schmitz.webloc -rwxr-xr-x 1 root wheel 63140 Oct 5 12:08 kimble.txt /mnt/yyy/.Trashes/501: total 0 /mnt/yyy/DCIM: total 8 drwxr-xr-x 1 root wheel 4096 Dec 31 1979 100CANON drwxr-xr-x 1 root wheel 4096 Aug 6 2001 CANONMSC
/mnt/yyy/DCIM/100CANON: total 2708 -rwxr-xr-x 1 root wheel 371091 Aug 6 2001 IMG_0001.JPG -rwxr-xr-x 1 root wheel 2388398 Aug 6 2001 MVI_0002.AVI -rwxr-xr-x 1 root wheel 7490 Aug 6 2001 MVI_0002.THM /mnt/yyy/DCIM/CANONMSC: total 12 -rwxr-xr-x 1 root wheel 4637 Aug 6 2001 100.CTG -rwxr-xr-x 1 root wheel 383 Aug 6 2001 D.CTG
The DCIM directory contains two jpegs and a divx - a picture of christian klein, a picture of some street taken from inside a house and a video showing the same street for some seconds. the jpegs also have exif tags attached.
From the following output you can see, that the disk was originally mounted as drive D:...
[cc@bambleweeny /mnt/yyy/DCIM/CANONMSC]$ strings 100.CTG D:\DCIM\100CANON IMG_
The file 'kimble.txt' contains the text of a criminal conviction against Kim Schmitz and some other guy. Moreover there are two deleted files on the disk, '3790-118663715-1.txt' and 'kimble-.txt'. The first one seems to be the same as kimble.txt and the second one is empty or not restoreable. The google files from the directory listing above also contain information related to 'kimble.txt'. It seems like it has been posted in a news group, probably by Andreas Bogk.
ps.: wiki sucks.
--Cpunkt 16:43, 5 Oct 2004 (CEST)
Even more lab notes
I played with the ISO9660.cdr which is a FAT16 filesystem image and the Sparse images, which contain MacOS HFS+ Partitions. I did not dig deep into the raw images, as I lack knowledge and tools to dissect HFS+.
ISO9660.cdr
- Filesystem Type: FAT16
- Seems to have been used on an Apple System, as there are Apple Resource Fork files on the filesystem.
- There does not seem to by anything interesting on the filesystem. There are some deleted files, but they don't seem to contain any "secrets".
Sparse.sparseimage
- Contains a (sparse, stuff missing) MB HFS+ partition
- Does not seem to contain interesting data
Sparse2.sparseimage
- Contains a (sparse, stuff missing) HFS+ partition
- Seems to contain a HFS+ journal file
- I was unable to copy the files Postbank.PNG and .DS_Store
- Does not seem to contain interesting data
And still more lab notes
I also played with the so-called CD image provided by Max. To save you all time and space, I came to the same conclusions Cpunkt already pointed out. I first reconstructed the previously deleted files by hand, found out they were not really interesting, lacked faith in my skills and so tried Autopsy on the image aswell. Since this didn't give any other interesting results, I quit concerning myself with this image and instead went to work reading a little more about the JVM and preparing my timetable for the next semester. I hope that Max and Dogan are able to resolve their lectures' collision (Hint: Don't move the PET away from that tuesday afternoon, please :-)
