Summerschool Aachen 2004/Forensics Presentation

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"