Summerschool Aachen 2004/Forensics Lab

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 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.

I've also had a look at Distorted.dmg, which seems to be an apple disk image file. I've found out that the format is called UDIF, Universal Disk Image Format, and that it might be encrypted or at least compressed. Unfortunately apple didn't document this format, and the tool 'hdiutil', that's shipped with MacOS X, is not open source. I only found the manpages for this tool online.

--Cpunkt 16:43, 5 Oct 2004 (CEST)

Lab notes (born again)

ufs.image.gz
------------

%%% gunzip ufs.image.gz
%%% file ufs.image 
ufs.image: Unix Fast File system (little-endian), last mounted on /mnt/test0, last written at Tue Oct  5 19:39:35 2004, clean flag 0, number of blocks 8192, number of data blocks 7959, number of cylinder groups 4, block size 16384, fragment size 2048, minimum percentage of free blocks 8, rotational delay 0ms, disk rotational speed 60rps, TIME optimization
%%% sudo vnconfig -r vnd0 ufs.image # read-only
%%% sudo mount -r /dev/vnd0d /mnt   # read-only
%%% ls -nilsAR /mnt
total 6
3 2 drwxrwxr-x  2 0  5   512 Oct  5 19:29 .snap/
5 4 -rw-r--r--  1 0  0  3666 Oct  5 19:35 test.txt

/mnt/.snap:
total 0
4 0 -rw-r--r--  1 0  5  0 Oct  5 19:29 bla.txt
%%% head -3 /mnt/test.txt 
PING www.ccc.de (213.73.91.29): 56 data bytes
64 bytes from 213.73.91.29: icmp_seq=0 ttl=50 time=21.730 ms
64 bytes from 213.73.91.29: icmp_seq=1 ttl=50 time=22.360 ms
%%% tail -6 /mnt/test.txt 
64 bytes from 213.73.91.29: icmp_seq=54 ttl=50 time=22.074 ms
64 bytes from 213.73.91.29: icmp_seq=55 ttl=50 time=36.852 ms

--- www.ccc.de ping statistics ---
56 packets transmitted, 56 packets received, 0% packet loss
round-trip min/avg/max/stddev = 21.189/31.437/57.019/8.411 ms
% sudo umount /mnt
% ils ufs.image
6|f|0|0|1096997738|1096997734|1096997738|0|0|0|0|0
% ffind ufs.image 6
* /deleted.txt
% fls -r ufs.image
d/d 3:  .snap
+ r/r 4:        bla.txt
r/r 5:  test.txt
r/- * 6:        deleted.txt
% # run a file(1) on every 4k block -> nothing useful

ufs2.image.gz
-------------

%%% gunzip ufs2.image.gz
%%% file ufs2.image 
ufs2.image: data
%%% # oops
%%% sudo vnconfig -r vnd0 ufs2.image # read-only
%%% sudo mount -r /dev/vnd0d /mnt    # read-only
%%% # no error message?
%%% ls -nilsAR /mnt
total 8
3 2 drwxrwxr-x  2 0  0   512 Oct  5 19:36 .snap/
4 6 -rw-r--r--  1 0  0  4286 Oct  5 19:37 test.txt

/mnt/.snap:
total 0
5 0 -rw-r--r--  1 0  0  0 Oct  5 19:36 bla.txt
%%% head -3 /mnt/test.txt 
PING www.ccc.de (213.73.91.29): 56 data bytes
64 bytes from 213.73.91.29: icmp_seq=0 ttl=50 time=25.097 ms
64 bytes from 213.73.91.29: icmp_seq=1 ttl=50 time=22.474 ms
%%% tail -6 /mnt/test.txt 
64 bytes from 213.73.91.29: icmp_seq=64 ttl=50 time=39.571 ms
64 bytes from 213.73.91.29: icmp_seq=65 ttl=50 time=39.969 ms

--- www.ccc.de ping statistics ---
66 packets transmitted, 66 packets received, 0% packet loss
round-trip min/avg/max/stddev = 21.012/33.959/50.789/8.332 ms
%%% # this looks familiar ...
%%% sudo umount /mnt
%%% ils ufs.image
ils: Error: ufs2.image is not a FFS file system

# Ok, so this apparently is a UFS2 file system, for which TSK has no
# support. And fsdb(8) gives an empty directory listing. So what?

Distorted.dmg
-------------

#include <rants/os/macos/binary_formats.h>

ISO9660.cdr.gz
--------------

(gunzip + file)
--> actually a FAT12 image file --> mount

%%% ils -f fat ISO9660.cdr 
21|f|0|0|1096970902|1096927200|1096970902|100777|0|0|0|0
24|f|0|0|1096970914|1096927200|1096970914|100777|0|63140|790|0
%%% icat -ffat ISO9660.cdr 24 | diff -qs - /mnt/kimble.txt 
Files - and /mnt/kimble.txt are identical

--> Why did you delete it?

%%% ffind -ffat ISO9660.cdr 24
* /3790-118663715-1.txt (_790-1~1.TXT)

--> An autosave file?

#include <rants/os/macos/charset.h>

Plus a picture and a video.

strings(1) shows remains of a DOS C++ executable compiled by Borland
C++: SanDisk Corporation SDPCMD, D:\PROGRAM\sdpcmd.exe

Sparse.sparseimage
------------------

#include <rants/os/macos/binary_formats.h>

NetBSD has pdisk(8), but it does not recognize this file:

%%% pdisk -l Sparse.sparseimage 
pdisk: No valid block 1 on 'Sparse.sparseimage'

At least strings(1) is your friend: There is a URL to "GottFaulbaers
Schlafmulde" <http://jm.tosses.info/>.

--Alexander Becher

Even more lab notes

I played with the ISO9660.cdr which is a FAT12 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: FAT12
• 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

--Lutz Böhne

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 :-)

-- Ernest Hammerschmidt