search

DFIRKuiper / Kuiper

Digital Forensics Investigation Platform
736 stars 110 forks source link

YARP issue #74

Open nyrm-f opened 1 year ago

nyrm-f commented 1 year ago

Hello,

I've run into a few registry hives where kuiper will list a yarp issue, example for ntuser.dat

Screen Shot 2022-10-16 at 11 30 01 PM

I manually run yarp on the same ntuser.dat and get this:

Screen Shot 2022-10-16 at 11 31 18 PM

I ran regipy on it and it printed with no issues https://github.com/mkorman90/regipy

Screen Shot 2022-10-16 at 11 36 19 PM

Not sure if a yarp setting needs to be change or maybe use regipy instead

msuhanov commented 1 year ago

Hello.

I'm the author of the yarp library. Based on the screenshot you posted, it seems there is an issue with an input file, not with the library.

Can you upload a sample hive file (including transaction log files) to investigate the problem? What tool did you use to copy these files? Are they from a running (live) system?

nyrm-f commented 1 year ago

hello @msuhanov ,

Thanks for the reply. I unfortunately cannot share the sample hive file. I used velociraptor to copy the file.

yes it did come from a live system.

is it perhaps how YARP was implemented?

Not sure if it was clear in my second screenshot, but I was able to get regipy to parse out the same hive that YARP was unable to.

I'm no expert when it comes to parsers, but since I was able to parse the hive with regipy and not YARP thats what make me think it was YARP.

What do you think?

Thanks

msuhanov commented 1 year ago

but I was able to get regipy to parse out the same hive that YARP was unable to

There is a format violation within the file. A tool can refuse to parse the file, or report the violation and parse what it can, or silently ignore the violation and extract as much data as possible (this is also limited to the implementation, which can extract less data than expected by the user).

The yarp-print tool can handle damaged and truncated primary files if no related transaction log files are available (or when the --no-recovery argument is given). This allows the tool to handle carved or otherwise damaged primary files. But if transaction log files are available (and the --no-recovery argument is not given), it is assumed (by the tool) that the damage can be repaired by replaying the log.

It is unclear what happened in your case. Velociraptor had at least one issue that could result in damaged files being produced.

I'm no expert when it comes to parsers, but since I was able to parse the hive with regipy and not YARP thats what make me think it was YARP.

Can you run the yarp-print tool manually against the file in question? (I recommend using the latest version.)

yarp-print --deleted NTUSER.DAT # Should produce the same error as reported.
yarp-print --deleted --no-recovery NTUSER.DAT # Things may work well here.

(Under the Windows operating system, execute "set PYTHONIOENCODING=utf-8" in the same cmd session before running the tool.)