{"id":165,"date":"2024-12-29T20:33:30","date_gmt":"2024-12-29T20:33:30","guid":{"rendered":"https:\/\/hireaprohacker.com\/?p=165"},"modified":"2024-12-29T20:34:26","modified_gmt":"2024-12-29T20:34:26","slug":"%e6%81%a2%e5%a4%8d%e5%b7%b2%e5%88%a0%e9%99%a4%e6%96%87%e4%bb%b6%e7%9a%84-5-%e7%a7%8d%e6%96%b9%e6%b3%95","status":"publish","type":"post","link":"https:\/\/hireaprohacker.com\/zh\/5-ways-recover-your-deleted-files\/","title":{"rendered":"5 \u79cd\u6062\u590d\u5df2\u5220\u9664\u6587\u4ef6\u7684\u65b9\u6cd5 \uff01"},"content":{"rendered":"

How to Recover Your Deleted Files<\/strong><\/h2>\n

Introduction<\/strong><\/h1>\n

When a file is \u201cdeleted\u201d, its contents aren\u2019t typically erased from the storage device that it was stored on. More often than not, the blocks that stored the file are marked as unallocated and the filesystem pointers are removed from it. The implication is that the file still exists on the disk until it is overwritten. Recover Your Deleted Files<\/p>\n

There are many methods to recovering the raw, unallocated data.\u00a0This website<\/a>\u00a0lists many tools that can be used for file recovery in different scenarios. In this article, I\u2019ll be walking through 5 different tools that can be used to recover data.<\/p>\n

Setup<\/strong><\/h1>\n

I\u2019ll be using doing forensic analysis on a drive that I created and attached to my Kali Linux VM. To see how this is done, you can reference\u00a0this article<\/a>. On this drive, I saved and then deleted an image file and text file. Recover Your Deleted Files<\/p>\n

\"\"<\/p>\n

I\u2019ll start by doing general enumeration on the disk image. Then, I\u2019ll showcase a variety of file recovery techniques used by forensic analysts that allowed me to recover the deleted files. Many of the tools used will be from the\u00a0Sleuth Kit<\/a>\u00a0(TSK).<\/p>\n

Before starting, I\u2019ll unmount the filesystem, create a duplicate of it, remove write permissions from the duplicate, and verify the integrity of the duplicate against the original hash of\u00a0\/dev\/sdb<\/code>. Recover Your Deleted Files<\/p>\n

$ <\/span>cd<\/span> ..\/ && umount \/mnt\/secret # unmount \/mnt\/secret<\/span><\/span><\/span><\/pre>\n
$ dd if=\/dev\/sdb of=\/home\/kali\/forensics\/sdb.img # copy \/dev\/sdb into sdb.img\r\n22286+0 records in\r\n22286+0 records out\r\n11410432 bytes (11 MB, 11 MiB) copied, 0.0412053 s, 277 MB\/s<\/span>$ chmod a-w \/home\/kali\/forensics\/sdb.img # remove write access to the image\r\n                                                                \r\n$ md5sum \/home\/kali\/forensics\/sdb.img \/dev\/sdb\r\n6c49fb21916d59e0df69453959392e23  \/home\/kali\/forensics\/sdb.img\r\n6c49fb21916d59e0df69453959392e23  \/dev\/sdb<\/span><\/pre>\n
Enumeration<\/strong><\/h1>\n
Image Analysis<\/strong><\/h1>\n
Using the\u00a0file<\/code>\u00a0command reveals that the image uses an ext4 file system.<\/p>\n
\n
\"\"<\/picture><\/div>\n<\/figure>\n
Furthermore, the\u00a0stat<\/code>\u00a0command displays information about the image such as its size, time stamps, and block details.<\/p>\n
\n
\"\"<\/picture><\/div>\n<\/figure>\n
With the information that the image uses ext4, the\u00a0fsstat<\/code> command can be used to extract more detailed information about the file system, metadata, content data, and block groups. Recover Your Deleted Files<\/p>\n
$ fsstat -f ext4 sdb.img \r\nFILE SYSTEM INFORMATION\r\n--------------------------------------------<\/span>\r\nFile System Type: Ext4\r\nVolume Name: \r\nVolume ID: dc8a4fb36dce8eabee4c51cf01c2d52a<\/span><\/pre>\n
Last Written at: 2023-05-09 22:35:31 (EDT)\r\nLast Checked at: 2023-05-09 22:23:26 (EDT)<\/span>Last Mounted at: 2023-05-09 22:24:27 (EDT)\r\nUnmounted properly\r\nLast mounted on: \/mnt\/secret<\/span>Source OS: Linux\r\nDynamic Structure\r\nCompat Features: Journal, Ext Attributes, Resize Inode, Dir Index\r\nInCompat Features: Filetype, Extents, 64bit, Flexible Block Groups, \r\nRead Only Compat Features: Sparse Super, Large File, Huge File, Extra Inode Size<\/span>Journal ID: 00\r\nJournal Inode: 8<\/span>METADATA INFORMATION\r\n--------------------------------------------\r\nInode Range: 1 - 2785\r\nRoot Directory: 2\r\nFree Inodes: 2773\r\nInode Size: 256<\/span>CONTENT INFORMATION\r\n--------------------------------------------\r\nBlock Groups Per Flex Group: 16\r\nBlock Range: 0 - 11139\r\nBlock Size: 1024\r\nReserved Blocks Before Block Groups: 1\r\nFree Blocks: 9223<\/span>BLOCK GROUP INFORMATION\r\n--------------------------------------------\r\nNumber of Block Groups: 2\r\nInodes per group: 1392\r\nBlocks per group: 8192<\/span>Group: 0:\r\n  Block Group Flags: [INODE_ZEROED] \r\n  Inode Range: 1 - 1392\r\n  Block Range: 1 - 8192\r\n  Layout:\r\n    Super Block: 1 - 1\r\n    Group Descriptor Table: 2 - 2\r\n    Group Descriptor Growth Blocks: 3 - 89\r\n    Data bitmap: 90 - 90\r\n    Inode bitmap: 92 - 92\r\n    Inode Table: 94 - 441\r\n    Uninit Data Bitmaps: 92 - 105\r\n    Uninit Inode Bitmaps: 94 - 107\r\n    Uninit Inode Table: 790 - 5661\r\n    Data Blocks: 5690 - 8192\r\n  Free Inodes: 1381 (99%)\r\n  Free Blocks: 6365 (77%)\r\n  Total Directories: 2\r\n  Stored Checksum: 0x7DEB<\/span>Group: 1:\r\n  Block Group Flags: [INODE_UNINIT, INODE_ZEROED] \r\n  Inode Range: 1393 - 2784\r\n  Block Range: 8193 - 11139\r\n  Layout:\r\n    Super Block: 8193 - 8193\r\n    Group Descriptor Table: 8194 - 8194\r\n    Group Descriptor Growth Blocks: 8195 - 8281\r\n    Data bitmap: 91 - 91\r\n    Inode bitmap: 93 - 93\r\n    Inode Table: 442 - 789\r\n    Data Blocks: 8282 - 11139\r\n  Free Inodes: 1392 (100%)\r\n  Free Blocks: 2858 (96%)\r\n  Total Directories: 0\r\n  Stored Checksum: 0xDFA7<\/span><\/pre>\n
Based on this output, it is clear that the block size is 1024 bits, there are 1113 total blocks, and there are 2785 inodes.<\/p>\n
In addition,\u00a0parted<\/code>\u00a0can be used to find more information on the partition table, which can be useful when using scalpel.<\/p>\n
\n
\"\"<\/picture><\/div>\n<\/figure>\n
Finally, running\u00a0strings<\/code>\u00a0on the image gives more insight as to what is in the filesystem. It appears that my\u00a0secret.txt<\/code>\u00a0file with the contents\u00a0Hello World<\/code>\u00a0is appearing from the\u00a0strings<\/code> command in addition to a failed image download attempt. Recover Your Deleted Files<\/p>\n
\n
\n
\"\"<\/picture><\/div>\n<\/div>\n<\/figure>\n
In the command\u00a0strings -a --radix=d sdb.img<\/code>,\u00a0-a<\/code>\u00a0is an option to scan the entire file and\u00a0--radix=d<\/code>\u00a0tells\u00a0strings<\/code> to show the offset that the string was found at in base 10. Recover Your Deleted Files<\/p>\n
Analyzing the Files<\/strong><\/h1>\n
This particular image does not have any files currently in it aside from deleted files, so there isn\u2019t much information to gain from mounting it and analyzing the files. In cases where it is desireable to do so, the following command can be used:<\/p>\n
$ <\/span>mount -o ro,loop,noexec,noatime sdb.img<\/span><\/pre>\n
Below, I\u2019ll explain what the options do:<\/p>\n