Open kevthehermit opened 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
This issue is stale because it has been open for 200 days with no activity.
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...
I don't think it's been fixed.
Ok, open it stays then... 5;P
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.
Describe the bug
windows.filescan
reports all files to be of size216
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
vol -f /mnt/d/Projects/dump.raw windows.filescan
Expected behavior The correct Size is reported
Example output
Additional information Dump files correctly saves and extracts the correct size of file object