During DFRWS '08, I thought it might be worthwhile to have an easy way to make RegRipper plugins. In fact, I asked Harlan if he had a plugin generator; back then, he said he just had some templates that provided basis for the plugins. Since then, I've been busy.
Recently, Harlan posted that the v0.40 update for Parse::Win32Registry came with a GTK-perl registry hive viewer. Naturally, I became very interested in modifying James' work to make the RegRipper plugin generator that had been on my mind in August.
To setup shop, I had to get Parse::Win32Registry and checkout this script. Quickly, I realized that there were quite a few dependencies for Gtk2-perl. Once all those were resolved (in a clean XP VMware WS 6.5 virtual machine, it didn't seem to like my host OS instance), I launched up the viewer. First, let me say that it's marvelous. James did a really slick job of programming this UI and his entire perl registry package. Until now, I hadn't looked too closely at its internals, but it's truly great code.
Default regview.pl 0.40 opening SYSTEM hive
Once I got it running, I thought that I only had one thing to do: hack up the UI to enable plugin generation. Well, at first, it appeared that plugin generation was too complicated to use a single template (which was my original idea). I needed to have a good understanding of the current RR plugin features as well as the other programming libraries in-use (GTK2-perl, Parse::Win32Registry, perl). I started writing a small document, in which I articulated the processes of some RR plugins. A lot of the plugins that Harlan wrote were pretty unique, but all followed similar strategies: from a starting registry key, traverse some subkeys, maybe select a few of those subkeys, and find some (or maybe all) values of the subkeys.
So, I thought, why not look at a RR plugin as something that traverses this registry tree with a filter? So, I wrote a special RR plugin that accepts a starting point, depth, a key filter per depth and a value filter per depth (plus one). This special RR plugin was further modularized by extracting plugin specific information to Harlan's %config hash in each RR plugin.
So, now I've got a bare-bone template plugin. From this, I hacked up James' UI (forgive me, at some point in the next weeks I want to remove my code from regview and make my own module). I've added the ability to create a new RR plugin based on a selected key or value. Below is a screenshot of me creating the Widcomm Bluetooth plugin.
Hacked Up regview UI
OK. So, in this SS, I've selected a key (Widcomm) and then from the Generate menu, clicked "from selected key." Next, the Plugin Detail Specification dialog appears. Here, I select an output folder, depth, name and description. Once depth is chosen, we can click on the Modify Filters button to bring up the Plugin Filter Specification dialog. This dialog has a dynamic number of input boxes, depdending on the user-specified depth.
The filter dialog is where the magic happens. From these boxes, a set of perl regular expressions are built within the a new plugin. In this example, I selected the key Widcomm, and would like to get subkeys of Widcomm that start with Devices and LinkKeys. From there, I want to traverse all subkeys. I've specified for all values (other than those from a fourth level subkey) to include all words (perl's \w). The fourth-level subkey value must start with ServiceNameUTF8. A few OKs and:
RR Plugin Created!
What, you don't believe me? :)
btwindcomm RR plugin output
Right now, I've committed my the code to my code page. A tag exists in the soruce tree called tuesday_morning that contains the script and template that you need to get going. There are bugs and I haven't coded proper error handling -- so, you you can break it easily. This Bluetooth demo is the last thing that I've tested, so it is probably broken in other areas. I'll bugcheck Tuesday afternoon and tag a new version on Wednesday.
With regard to Harlan's Bluetooth post, I still have further investigation to perform. Apparantly, there are different Bluetooth stacks., which undoubtedly means different registry keys. I'll play with MS-XP and MS-Vista stuff sometime this week.
In my small investigations of RR plugins, I noticed that the applets plugin could also rip Wordpad's recently opened files, so I updated applets.pl.
That is all for now.
6 comments:
Jason,
Great work, my friend! Wow! I've had some folks ask me about something like this, but that was about the time that I was writing a number of plugins that required a bit more than just grabbing subkeys, values or just a single value. Anyway, this is a huge step in the right direction! Thanks for your work in this area...
Very cool, had been planning to do this myself for a while. Have you guys thought about maybe doing plugins as a simple xml format. It's not far from what you have, and that way we could share plugins across dev platforms (e.g. i'd like to use these in pyflag without rewriting them).
@Harlan: It was my pleasure! It is also possible to enable users to select output functions such as common decoding methods and ROT13. In a later version, I fully intend to include this functionality. In addition to filtered enumeration, I also plan to include the ability to select a static set of the key/values.
@Darren: You're right in that other output formats aren't that far away. Integration with PyFlag would be marvelous! Is XML format something that others have been asking about too? Are there other formats that should be considered as well?
Was actually referring input format rather than output format. But output format of xml would be helpful too :)
On the input format I was thinking of using an xml format to specify the plugin, so the base registry key, the filters in xml. Then have different generators such as yours work on that format, to generate code to do the extraction.
Awesome work Jason, I showed this blog post to the last SPARSA meeting. Your name showed up in my RSS fead on another blog. You should check out the new SPARSA blog:
http://ritsparsa.blogspot.com
Thanks Josh. I'm anxious to see content from the SPARSA blog.
Post a Comment