Every now and then, I get contacted by someone who tells me that they used the open source tools I’ve released in either a college course they took, or in a course provided by one of the many training vendors in the industry. I even once responded to an incident for a large energy sector organization, and while I was orienting myself to the incident, I looked over one of their analyst’s shoulders and recognized the output of the tool they were using...it was one of mine.
What I’ve seen pretty consistently throughout my time in the industry is that once tools are known, people begin downloading them, and including them in their distros/toolsets, and some even add them to training courses (colleges, LE, the federal gov’t, private sector, etc.). Howev…
Every now and then, I get contacted by someone who tells me that they used the open source tools I’ve released in either a college course they took, or in a course provided by one of the many training vendors in the industry. I even once responded to an incident for a large energy sector organization, and while I was orienting myself to the incident, I looked over one of their analyst’s shoulders and recognized the output of the tool they were using...it was one of mine.
What I’ve seen pretty consistently throughout my time in the industry is that once tools are known, people begin downloading them, and including them in their distros/toolsets, and some even add them to training courses (colleges, LE, the federal gov’t, private sector, etc.). However, they do so without ever truly understanding the nature of the tool, how and why it was designed, or what problem it was intended to solve. Further, they rarely (to my knowledge) contact the author to understand what went into the development of the tool, nor understand how the tool was intended to be used. For training courses in particular, those providing the materials and instruction do so without fully understanding how the tool author conducts their own investigations, and therefore, how the open source too fits into their overall investigative process. As a result, the instruction around that tool that’s provided is often a shadow of what how the tool was intended to be used; what you’re getting in these training courses is the instructor’s perception of how the tool can be used.
I’ve blogged a couple of times regarding various distros of tools that include RegRipper; for example, here and here. That second post includes a brief mention of the fact that, to a very limited extent, RegRipper v3.0 was included in Paraben’s E3 product back in 2022; that is to say that the full capability of RegRipper wasn’t implemented at the time, just a limited subset of plugins.
I recently heard from someone that Blue Cape Security includes RegRipper in their Practical Windows Forensics training course. If you look at the course content that’s provided, the use of RegRipper starts in section 5.1 (Windows Registry Analysis), but Registry parsing (not actual analysis) itself continues into sections 5.2 (User Behavior Analysis), and 5.6 (Analyzing Evidence of Program Execution...I know, don’t get me started...) and 5.7 (Finding Evidence of Persistence Mechanisms).
I know what you’re thinking...if I’m going to "complain" about this, why not do something about it?
Well, I’m not complaining. That’s not it, at all. All I’m saying is that if you take a training course that involves the use of open source tools that the vendor/instructor has collected, you’re getting their perspective of the use of the tool, and likely not the full benefit of the "why" behind the tool.
And yes, if I had even a hint that analysts and examiners were interested in really, truly understanding how to go about analyzing the Windows Registry, I’d develop and deliver a course, or series of courses, myself. As it is, my perspective is that folks are pretty happy with what they know.