Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Usage of pure rust SCCA library #23

Closed
SecSamDev opened this issue Feb 8, 2024 · 4 comments · Fixed by #24
Closed

Usage of pure rust SCCA library #23

SecSamDev opened this issue Feb 8, 2024 · 4 comments · Fixed by #24
Assignees
Labels
enhancement New feature or request

Comments

@SecSamDev
Copy link

SecSamDev commented Feb 8, 2024

I have developed a pure rust prefetch parser, it is still in development and is designed to work with the Forensic-RS framework, but it can work in this project so as not to use bindings to C code.

https://crates.io/crates/frnsc-prefetch

It does not use the Windows-exclusive RtlDecompressBuffer function that other implementations use, which allows it to be used on any platform compatible with the standard Rust library.
It also gives you accurate traces and metrics, such as which blocks were loaded into runtime memory, as a resource, or fetched from disk without going through the prefetch.

The logs generated during processing can be accessed through Rust code by initializing the logger. They are not sent directly to stdout or stderr. logger

You can also check for anomalies detected during processing through the notification system and create hooks when certain anomalies occur. notifications

@janstarke janstarke self-assigned this Feb 8, 2024
@janstarke janstarke added the enhancement New feature or request label Feb 8, 2024
janstarke added a commit that referenced this issue Feb 8, 2024
@janstarke
Copy link
Member

I tried to use your library and, guess what, it is working pretty well. Is this something you had in mind?

@SecSamDev
Copy link
Author

I'm glad to hear it works.
It was one of the Windows artifacts that I wanted to know more about. I am also working on other parsers and in parallel improving the usability of the framework.
So the feedback is appreciated.

@janstarke
Copy link
Member

I see a lot of crates flying around which all implement the same or similar windows data types, such as several time stamp format. There are implementations in my crates, in yours as well, in the ones by @omerbenamram and so on. I think we should concentrate them in special crates in order improve code reuse. What do you think about it?

@janstarke janstarke linked a pull request Feb 8, 2024 that will close this issue
@SecSamDev
Copy link
Author

SecSamDev commented Feb 8, 2024

I added the filetime type at the last minute so that the field wasn't just a u64.
Actually the type is defined in the framework and not in the parser, although integration with third packages could be facilitated using "From" and "Into".

The idea of the framework is precisely that, to reuse common structures. The file system allows, for example, to access the files of a triage ZIP extracted with KAPE without the person implementing the parser having to implement said part; it is the tool that uses the parser that must provide the file system. The same thing happens with the Windows registry, the parsing library does not have to select the registry reader, it is the person who uses it who must supply it. Thus the tool can be applied to both live systems and extracted artifacts.

In any case, any improvement, change or suggestion is welcome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants