Ext2/3/4, NTFS: issues with allocated orphan files

[msuhanov]

Hello.

According to the documentation (#1, #2):

Sometimes, you will see the text '(realloc)' after the metadata address. [...] This occurs when the file name is in an unallocated state and the metadata structure is in an allocated state. This can only occur on file systems that separate the file name from the metadata (such as NTFS, Ext2/3, UFS, etc.). Seeing '(realloc)' with versions of TSK 3.0.0 and greater (because of the duplicate name suppression) is generally an indication that the metadata structure has been reallocated to a new file and therefore not likely to be the metadta or file content that originally corresponded to this file name.

If the name is not allocated, but the metadata for the file is allocated, then it will have "(realloc)" in the name. This shows that the metadata associated with this file name may not be valid any more because it could correspond to a different file.

In the Ext2/3/4 file systems, the fls tool (its version is 4.12.0) always reports orphan files (files that were deleted while opened in another program) as reallocated.

For example:

$ fls ext2_orphan.raw 8193
r/r * 8194(realloc):	1.txt

$ istat ext2_orphan.raw 8194
inode: 8194
Allocated
Group: 4
Generation Id: 894338102
uid / gid: 1000 / 1000
mode: rrw-r--r--
size: 446700
num of links: 0

Inode Times:
Accessed:	2023-02-18 22:06:43 (MSK)
File Modified:	2023-02-18 22:06:39 (MSK)
Inode Modified:	2023-02-18 22:06:46 (MSK)

Direct Blocks:
33281 33282 33283 33284 33285 33286 33287 33288 
33289 33290 33291 33292 33293 33294 33295 33296 
[...]

$ fls ext4_orphan_hardlinks.raw 12
r/r * 13(realloc):	1.txt
r/r 13:	2.txt

$ istat ext4_orphan_hardlinks.raw 13
inode: 13
Allocated
Group: 0
Generation Id: 2149838612
uid / gid: 1000 / 1000
mode: rrw-r--r--
Flags: Extents, 
size: 360176
num of links: 1

Inode Times:
Accessed:	2023-02-18 21:58:40 (MSK)
File Modified:	2023-02-18 21:58:33 (MSK)
Inode Modified:	2023-02-18 21:58:45 (MSK)

Direct Blocks:
8451 8452 8453 8454 8455 8456 8457 8458 
8459 8460 8461 8462 8463 8464 8465 8466 
[...]

$ fls ext4_orphan.raw 12
r/r * 13(realloc):	1.txt

$ istat ext4_orphan.raw 13
inode: 13
Allocated
Group: 0
Generation Id: 3480464081
uid / gid: 1000 / 1000
mode: rrw-r--r--
Flags: Extents, 
size: 121388
num of links: 0

Inode Times:
Accessed:	2023-02-17 19:18:49 (MSK)
File Modified:	2023-02-17 19:18:47 (MSK)
Inode Modified:	2023-02-17 19:18:54 (MSK)

Direct Blocks:
8451 8452 8453 8454 8455 8456 8457 8458 
8459 8460 8461 8462 8463 8464 8465 8466 
[...]

$ fls -V
The Sleuth Kit ver 4.12.0

1. In all cases, the "1.txt" file was deleted while it's open.
2. In all cases, the file system image was acquired without unmounting (so the "1.txt" file isn't closed and its inode isn't marked as deleted).
3. In one case (the "ext4_orphan_hardlinks.raw" image), the "2.txt" file was a hard link to the "1.txt" file (thus, it's one file with two names).

As you can see, the "1.txt" file is always marked as reallocated, while it's not (the inode metadata and the file data correspond to the deleted file name entry).

The existing documentation pages could be updated to reflect such a scenario (it's not uncommon in the Linux world).

Additionally, according to the documentation (#3):

Orphan files are deleted files that still have file metadata in the file system, but that cannot be accessed from the root directory.

The existing code doesn't list such orphan files in the "$OrphanFiles" virtual directory.

For example:

$ fls ext2_orphan.raw 
d/d 11:	lost+found
d/d 8193:	test
V/V 16385:	$OrphanFiles

$ fls ext2_orphan.raw 16385 | wc -l
0

(Two other images produce the same behavior.)

The existing code could be updated to list allocated inodes without file names (when the link count is zero), which are also on the orphan inode list, in the "$OrphanFiles" virtual directory.

From the file system's point of view, such files are deleted.

[msuhanov]

Let me provide additional information.

The first issue described above is about documentation. Currently, the documentation insists that files having the "(realloc)" mark are reallocated (file data doesn't correspond to a file name), while another (and not so rare) option exists (file data corresponds to a file name). I think that both options are worth mentioning (especially because examiners don't trust or simply ignore the "file name - file data" connection when they see the "(realloc)" mark).

The second issue is about code. Currently, allocated inodes having no associated file names aren't listed as orphan files. In fact, when all deleted file names of such an allocated inode are overwritten, there is no way to reach that inode using the fls tool. Its associated data is marked as allocated, but this inode is absent in the directory tree. One can see the file data using the blkls -a command, but not using the fls and icat tools together.

I have attached a sample image (gzipped). The orphan inode number is 13.

ext4_orphan_3.raw.gz

[msuhanov]

The second issue also affects the NTFS parser. Such an orphan inode isn't listed anywhere by the fls tool (not in the actual directory tree, not in the virtual directory for orphan files):

MFT Entry Header Values:
Entry: 28        Sequence: 1
$LogFile Sequence Number: 0
Allocated File
Links: 0

$STANDARD_INFORMATION Attribute Values:
Flags: Archive
Owner ID: 0
Security ID: 258  ()
Created:	2023-02-21 16:51:43.303108600 (MSK)
File Modified:	2023-02-21 16:51:44.147118100 (MSK)
MFT Modified:	2023-02-21 16:51:44.147118100 (MSK)
Accessed:	2023-02-21 16:51:43.303108600 (MSK)

Attributes: 
Type: $STANDARD_INFORMATION (16-0)   Name: N/A   Resident   size: 72
Type: $DATA (128-2)   Name: N/A   Non-Resident   size: 506961  init_size: 506961
8704 8705 8706 8707 8708 8709 8710 8711 
8712 8713 8714 8715 8716 8717 8718 8719 
8720 8721 8722 8723 8724 8725 8726 8727 
8728 8729 8730 8731 8732 8733 8734 8735 
8736 8737 8738 8739 8740 8741 8742 8743 
8744 8745 8746 8747 8748 8749 8750 8751 
8752 8753 8754 8755 8756 8757 8758 8759 
8760 8761 8762 8763 8764 8765 8766 8767 
8768 8769 8770 8771 8772 8773 8774 8775 
8776 8777 8778 8779 8780 8781 8782 8783 
8784 8785 8786 8787 8788 8789 8790 8791 
8792 8793 8794 8795 8796 8797 8798 8799 
8800 8801 8802 8803 8804 8805 8806 8807 
8808 8809 8810 8811 8812 8813 8814 8815 
8816 8817 8818 8819 8820 8821 8822 8823 
8824 8825 8826 8827 
Type: $EA_INFORMATION (208-3)   Name: N/A   Resident   size: 8
Type: $EA (224-4)   Name: N/A   Resident   size: 60

(Also, there is no corresponding index entry, the allocated file is "fully" unlinked by the driver.)