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
Basics
lsof -n -P -p 24315
Advanced UNIX File System Overview
- jfs developed in the late 80
- xfs, historic background: media servers
- reiserfs
- veritas VxFS, hpux upgrade, snapshots for consistent backups
Techniques
- variable allocation units
- binary trees instead of linear tables
- journaling
software
- EnCase (support reiserfs), police background
- no public software for VxFS,JFS,XFS known
actual data vs. meta data
- search allocated disk blocks, partly allocated blocks (slack), unallocated for deleted data
- generate timeline, deleted filenames, hidden files from metadata
- forensic software should not link to anything, should not rely on os, live analysis without bringing down system
Classic Unix Filesystems
original unix fs
- superblock, inode list, user data
- superblock: layout information
- inode list: meta data container, name,size,blocks
- recently freed inode list
- linear layout, slow, fragmentation, simple split between data/metadata
indirect block addressing basics
- 12 direct blocks and the 13/14 block are (double) indirect blocks
- inodes have fixed length
- indirect block itself is a single disk block, completely devoted to allocating real data
- flexible, unefficient
berkeley fast file system
- (~ext2,ffs) solaris freebsd
- BOOK moris bach, unix filesystem design
- cylinder groups, placement policies, superblock backup copies, fragmentation
cylinder groups
- cylinder groups, reach data without physical hd head movement
- metadata per cylinder group (cg): superblock, cg header, inode list
- maintain locality, one directory should stay in one cg
- number of cg stored in superblock
- linux ext2 calls cylinder groups "block groups"
- inodes are on fixed position on disk, ok for forensics
- inodes don't get reused immediatly, undelete possible
fragmentation
- not in ext2
- block size: small files vs large files problem, i.e.: space vs. speed
- 4k blocks get fragmented, blocks don't get numbered anymore, fragments do
- file a (9kb) in frags: 0,4,8 -> last block full or not, determined by file size and last fragment number
- if file grows it has to be copied
- inode 2 always = root directory
superblock
- dirty flag, used in mount, umount
- has magic string
- read only at most times, size information
Layers
- file system sub layer
- data unit
- inode
- human interface
Advanced Filesystems / JFS
variable block size
- contiguosly stored data, nice
- less meta data
- acl in inode 3
Allocation Trees
- 16 extents (like 12 block addresses in berkeley) (256gb?)
- 17 extent starts tree, replaces 16 ext. in header with tree root
- tree needed for fragmented files, sparse files
- sparse files contain big empty holes which don't count on used diskspace, used for: db, uml, copy on write
- extent header: offset, length
Deletion
- meta data from deleted files stays on disk until reuse
- solaris, hpux follow tree to zero out deleted files inodes
- lazarus perl: reassemble blocks without allocation data
- filenames survive deletion in jfs, length may be recovered
Directory Entries
- 8 dirs fit in one jfs inode (9th slot starts tree)
- linear linked list
- tree keyed by name
- directories are b+ trees
dynamic inode allocation
- inode number was fixed
- static alloc (cg) doesn't work well with big video
- inode lists are files (journal too)
- inode files start directly after superblock (?), at fixed position
forensics
- inode reuse is uncommon for other fs
- inode file may be overwritten
meta data
- filesystem is a file in the meta file system (...)
- inode number is stored inside inode file (easy cloning)
Journaling
- viewer: jfsutils
- kept in a file or separate partition
- provide "time machine"
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.
# reiserfs image creation dd if=/dev/zero of=testreiser bs=4k count=10240 mkreiserfs -f testreise
# 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/
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
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 :-)
Bertelsmann harddisc
Samad and I tried to work on the problem we had yesterday. We weren't able to mount a single partition out of a file image of a harddisc and today we looked for a solution. At last we found a hint on a page where was described how to use the mount utility with an "offset" option. This option enabled us to get the NTFS partition in the image mounted.
Now we had to examine the partition. At first we found some odd directory called backup with lots of logfiles dated from 1999 til May 2004. These logfiles showed accesses of cash registers - when did a user logged on and so on. In another directory we found a mailbox of Microsoft Outlook Express with about 280 emails in it. The emails were adressed from stores of the company Bertelsmann to other stores or to the managemment, also vice versa. They contained some information about advertisements, purchasing of store items, campaigns and also some private communication between employees. Sometimes Word documents or Excel tables were attached and we were able to gain some email adresses of employees of Bertelsmann.
--Samad Nasserian, Boris Leidner
Yet another lab note
Today I also first looked at the FAT-12 ISO-image, and afterwards I dealt with the HFS images. Since there's written a lot about this images here I will not repeat this again.
Afterwards I bothered with the recomp-1.image. file told me that it is a x86 boot sector, so I used fdisk to look for partitions and extracted a FAT32 partition with dd (yes, if you know this steps it is very simple). It seems to have been deployed in a NT4.1 system, but when I mounted it, there was only an empty root directory and autopsy didn't see any deleted files. Nevertheless there was a huge amount of data in the image, but since there was not much time left I did not try to recover this files manually, but just had a look at it.
The disk was used by Bertelsmann and had a FoxPro database on it. It seemes to be a book keeping DB, there were many personal orders of DVDs or books in it, including adresses and bank connections. Overall I found 26678 times the string Konto-Nr, so you would get quite rich if you charge each account with 10 euro, and probably only a few customers would notice it. There were also daily business volumes listed and sources of webpages including JavaScript. I did not figure out yet if there are also pages with more sensitive sources.
-- Jan Gall
