Difference between revisions of "Summerschool Aachen 2004/Forensics Presentation"

From C4 Wiki
Jump to: navigation, search
m (Wiederhergestellt zur letzten Änderung von Mario Manno)
Line 1: Line 1:
= 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 [http://pax.grsecurity.net/docs/aslr.txt here]
The proof of concept exploit to break pax can be found [http://lists.immunitysec.com/pipermail/dailydave/2004-May/000514.html 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"

Revision as of 22:45, 18 February 2006