volatilityfoundation / volatility3

Volatility 3.0 development
http://volatilityfoundation.org/
Other
2.49k stars 434 forks source link

`windows.filescan` reports all files to be of size `216` #1040

Open kevthehermit opened 9 months ago

kevthehermit commented 9 months ago

Describe the bug windows.filescan reports all files to be of size 216

Context Volatility Version: 2.5.0 Operating System: Ubuntu 22.04 Python Version: 3.10.12 Suspected Operating System: Windows 10 Command: vol -f /mnt/d/Projects/dump.raw windows.filescan

To Reproduce Run the plugin on any dump for windows 10

  1. Use command vol -f /mnt/d/Projects/dump.raw windows.filescan

Expected behavior The correct Size is reported

Example output

Volatility 3 Framework 2.5.0

Offset  Name    Size

0x910b71893a20  \Windows\System32\svchost.exe   216
0x910b73217210  \$Secure:$SDS:$DATA 216
0x910b732174f0  \$Secure:$SII:$INDEX_ALLOCATION 216
0x910b732177d0  \Windows\System32\drivers\stornvme.sys  216
0x910b73217940  \$Mft::$BITMAP  216
0x910b73217ab0  \:$I30:$INDEX_ALLOCATION    216
0x910b732181e0  \$MftMirr   216
0x910b73218630  \$LogFile   216
0x910b73218a80  \$Mft   216
0x910b73218d60  \Windows\System32\DriverStore\FileRepository\basicdisplay.inf_amd64_fc93ae411c02f280\BasicDisplay.sys   216
0x910b73218ed0  \$BitMap    216
0x910b734020a0  \$Extend\$RmMetadata\$TxfLog:$I30:$INDEX_ALLOCATION 216
0x910b73402380  \Windows\System32\drivers\dumpfve.sys   216
0x910b73402660  \$Extend\$UsnJrnl:$J:$DATA  216
0x910b73402940  \Device\HarddiskVolume3\$Extend\$RmMetadata\$TxfLog\$TxfLog 216
0x910b73402ab0  \$Directory 216

Additional information Dump files correctly saves and extracts the correct size of file object

ikelos commented 9 months ago

So dumpfiles walks the pages that make up the contents of the stored file, whereas filescan just reads the Size member of the fileobject. This is a short and therefore will not be able to talk about files larger than 65535 bytes anyway. Looks like to get the accurate size we'll need to do the same thing as dumpfiles to walk the pages...

That'll be the code in either CONTROL_AREA or in SHARED_CACHE_MAP

Blech, looks like you go through the FileObject's SectionObjectPointer... Not fun. 5:S

github-actions[bot] commented 2 months ago

This issue is stale because it has been open for 200 days with no activity.

ikelos commented 2 months ago

Did we ever resolve this or get a PR that fixed it? Just don't want it slipping off the radar if it's still an issue...

eve-mem commented 2 months ago

I don't think it's been fixed.

ikelos commented 2 months ago

Ok, open it stays then... 5;P

atcuno commented 2 months ago

This size is not related to the size of the file and my view is that the column should just be removed. There is no static file size for a file object as one FILE_OBJECT can be cached in multiple caches (SECTION, IMAGE, ...), each of which can have a different size of the file depending on its purpose (executable, data, ...).

The size we are printing now is the size of the structure:

Size

A read-only member that specifies the size, in bytes, of the file object. This size does not include the file object extension, if one is present.

From: https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/wdm/ns-wdm-_file_object

@eve-mem since you looked into this, feel free to make a PR removing the column or I can at some point soon.