Has 1 multiply-claimed block(s), shared with 1 file(s): (There are 2 inodes containing multiply-claimed blocks.)įile /file1.txt (inode #12, mod time Thu Oct 15 18:48:32 2015) Pass 1D: Reconciling multiply-claimed blocks Pass 1C: Scanning directories for inodes with multiply-claimed blocks Multiply-claimed block(s) in inode 13: 2048 Multiply-claimed block(s) in inode 12: 2048 Pass 1B: Rescanning for multiply-claimed blocks Running additional passes to resolve blocks claimed by more than one inode. Pass 1: Checking inodes, blocks, and sizes dev/xvdb was not cleanly unmounted, check forced. Since we can’t run file system checker (fsck) on mounted partitionsĮ2fsck: Superblock invalid, trying backup blocks. I hope you can spot the difference between our previous file1.txt and file2.txt output ans this one, right? Now lets run fsck to repair this. Mount -o sb=393216 /dev/xvdb /mnt -t ext3 To summarize, we figure-out the block address (2048) of file1.txt with debugfs-stat command, then replaced file2.txt block address 2049 with 2048.īy following unmounting and remounting – we ensure our above changes written to disk. Here type file1.txt block address here (2048) Direct Block #0 2048Īnd quit. It gives up ability to modify inode contents! run Now lets point file2.txt to this block with another debugfs command named mi which is powerful command. Okay, debugfs stat output tells us the file1.txt data block address is 2048 To modify file system structure, we will a command called debugfs – an ext2/ext3/ext4 file system debuggerįirst fetch the data block address of file1.txt (i.e where ‘this is file1’ is stored).ĭebugfs: stat file1.txt Inode: 12 Type: regular Mode: 0644 Flags: 0x0 We are going to corrupt file system in such way that file2.txt will also point to file1.txt content!!!! Worked! Just go ahead and explore everything is fine on mountpoint! Fun 2: Multiply owned blocks – No, Its MY block!Ī Lets check out our existing file contents.Ĭat /mnt/file1.txt /mnt/file2.txt this is file1 so we need to convert our address like 98304 * 4 = 393216 we will try again with alternate superblock option “-o sb=” now: Mount command expects block address in 1KB. Umount /mnt & mount /dev/xvdb /mnt mount: you must specify the filesystem typeįailed right? that’s what we wanted □ Now how to fix this ? For cases like this ext3 has backup superblock (have look at above mkfs.ext3 output more closely!) All you need to do is tell mount command to use that copy of superblock. Run following command which will zero-out super block!ĭd if=/dev/zero of=/dev/xvdb count=1 bs=1024 seek=1Ībove command,writes 0’s on superblock location at offset 1024! Now lets try to mount it : Our first task is to corrupt the super block. Let the fun begin! Fun1: Attack Super block Verify everything looks fine on mount point. Go ahead and mount it then create 10 files.įor i in do echo "this is file$i" > /mnt/file$i.txt done We are going to corrupt the system and then repair, restore sanity.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |