Kuiper icon indicating copy to clipboard operation
Kuiper copied to clipboard

YARP issue

Open nyrm-f opened this issue 3 years ago • 3 comments

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

nyrm-f avatar Oct 17 '22 06:10 nyrm-f

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?

msuhanov avatar Dec 07 '22 14:12 msuhanov

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

nyrm-f avatar Mar 21 '23 23:03 nyrm-f

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.)

msuhanov avatar Mar 22 '23 10:03 msuhanov