ext3/ext4

Design prin­ci­ples:

• Data blocks are close­ly togeth­er due to per­for­mance reasons.
• Impor­tant meta data is stored mul­ti­ple times.
• Meta­da­ta of files and direc­to­ries is stores in an index node (inode). A inode con­tains meta data (own­er, group, per­mis­sions, …) and a ref­er­ence to data blocks. 
  • inode = 2 => root directory
• Superblock:
  • A block only with con­fig­u­ra­tion data like num­ber of blocks in the filesys­tem, num­ber of blocks pro block group, …
  • Is stored mul­ti­ple times on a filesystem.
• Block group:
  • A large area on the filesys­tem. Ext tries to store all blocks of a file in the same block group due to (HDD…) per­for­mance reasons.
• When a file is delet­ed, ext over­writes direct­ly the address of an inode with zero and sets the changed data to the delete data. This makes it hard­er to retrieve delet­ed data. 
  • In NTFS, the file­name is stored in the MFT mas­ter file table. In ext, the file­names are not in the inodes and can there­fore not nec­es­sary be recov­ered when files / data was par­tial­ly delet­ed. File carv­ing can then be used.
• Process:
  • The sys­tem opens inode = 2 for the root directory.
  • This con­tains a list: 
    • 0 0 0600 etc 400
    • 0 0 0777 tmp 500
  • The user wants to open tmp. Then, the sys­tem reads the inode at posi­tion 500.
  • This inode has 
    • 1000 1000 0644 file.txt 6330
  • If the user wants to access the file at posi­tion 6330, the sys­tems loads the mem­o­ry from this position.
• Jour­nal­ing
  • Since ext3
  • Changes are logged before the action was per­formed on the file system.
  • Only when the action was logged and com­mit­tet, then the changes were applied on the filesystem.
  • Show the jour­nal:
    jls -o 4096 ext_image.img

Information about the file system

Gen­er­al information

fsstat /dev/sda1

Infor­ma­tion of an inode (2 = root directory):

istat /dev/sda1 2

Get the par­ti­tions of an image

mmls server.img

mmls shows the start off­set of each par­ti­tion. Show details of the par­ti­tion which starts at 4096:

fsstat -o 4096 server.img

Show all files of a partition:

fls -o 4096 server.img > /tmp/server_files.txt

Cre­ate a time­lime of cre­at­ed files from the filesystem:

fls -pro 4096 -rm '/' server.img > bodyfile.txt
mactime -b bodyfile.txt -d -h > timeline.txt

Get the con­tent of a file. Assume, we found this in the body­file. Here, we have also the inode.

0|/etc/ssh/sshd_config.d/hardening.conf|13437|r/rrw-r--r--|0|0|...

We can now use the inode to get the file info:

istat -o 4096 server.img 13437

And we cat get the (ascii) file with

icat -o 4096 server.img 13437

Tip: If you are ana­lyz­ing an image, try to get inodes in a sim­i­lar range. If you have an inter­est­ing file, e.g. a mal­ware file, try to get inodes a bit before and after­wards. Maybe there are oth­er files which were cre­at­ed in the same time.

Recovering data

• Try extun­delete to recov­er files. 
  • extun­delete /dev/sda1 –restore-file /tmp/SSH/file
  • extun­delete /dev/sda1 –restore-direc­to­ry /tmp/SSH/

base64 search

Use GitHub — hey­itsmikeyv/base64-keystrings: Find key search strings to locate base64-encod­ed ver­sions of ASCII strings. to search also for base64 strings.