Support dumpfiles with offset
After scan file in vmem, it is hard to dump only one file, cause 'FileScan' display offset, but not virtuladdr.
python3 vol.py -f test.vmem windows.filescan.FileScan
I suggest to add 'offset' to support it.
python3 vol.py -f test.vmem windows.dumpfiles.DumpFiles --offset 0x7fe7fdd0
Hello @wooyin - the dumpfiles plugin already supports dumping files by virtual or physical offset. Is that not working properly?
% python3 vol.py windows.dumpfiles -h
Volatility 3 Framework 1.2.1
usage: volatility windows.dumpfiles.DumpFiles [-h] [--pid PID] [--virtaddr VIRTADDR] [--physaddr PHYSADDR]
optional arguments:
-h, --help show this help message and exit
--pid PID Process ID to include (all other processes are excluded)
--virtaddr VIRTADDR Dump a single _FILE_OBJECT at this virtual address
--physaddr PHYSADDR Dump a single _FILE_OBJECT at this physical address
I think this can be marked as closed? Feel free to reopen it if you believe your issue is a still a problem... 5:)
Doing --virtaddr gives me the error volatility: error: unrecognized arguments: ‑‑virtaddr
Hi @ajmeese7 - what is the full command line you use when you get that error?
I don't remember now, it was something to the effect of ./vol.py -f memory.dmp -o ./dumped_files windows.dumpfiles.DumpFiles --virtaddr 0x3e1745d0 though. I think I ended up getting my problem resolved by using --physaddr, but in the process of debugging I saw this related issue and figured I'd mention that I ran into the same problem.
I don't remember now, it was something to the effect of
./vol.py -f memory.dmp -o ./dumped_files windows.dumpfiles.DumpFiles --virtaddr 0x3e1745d0though. I think I ended up getting my problem resolved by using--physaddr, but in the process of debugging I saw this related issue and figured I'd mention that I ran into the same problem.
Yeap, as you mentioned,python3 vol.py -f path/to/my.mem -o output/dir/ windows.dumpfiles --physaddr 0x... works, but --virtaddr doesn't work
@ikelos seems this may still be an issue, would you consider reopening so it can be investigated further?
Sure, no problem, although I can't guarantee it'll get more attention than it managed to get in the last 260 days I'm afraid.
Doing
--virtaddrgives me the errorvolatility: error: unrecognized arguments: ‑‑virtaddr
virtaddr and physaddr
According to the source code of windows.dumpfiles, for a physical address, it is needed to switch to a memory layer. vol 3 switches to a memory layer according to a flag is_virtual, which is set as True by --virtaddr or False by --physaddr.
if self.config.get("virtaddr", None) is not None:
offsets.append((self.config["virtaddr"], True))
elif self.config.get("physaddr", None) is not None:
offsets.append((self.config["physaddr"], False))
So theoretically, even if the user passes a physical address with --virtaddr, it should not raise the error unrecognized arguments: ‑‑virtaddr as mentioned.
Reproduce the error
In the normal case:
(Here the address is a physical address)
And I copied and pasted the ‑‑virtaddr from @ajmeese7 's comment to reproduce the error.
Then I realize it is because of the inputing method.
Conclusion
It is caused by the different ASCII values of Non-Breaking Hyphen(8209) and -(45), though they look alike.
I believe this issue can be closed now @ikelos , thank you!