Summerschool Aachen 2004/Forensics Lab
Contents
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)
Lab notes
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/>.
Even more lab notes
I played with the ISO9660.cdr which is a FAT16 filesystem and the Sparse images, which contain MacOS HFS+ Partitions.
