Harlan Carvey has given us a great tool in RegRipper and it’s undeniable that many examiners have found it to be a useful addition to their toolbox. RegRipper has a very specific purpose – parse the Windows registry. With some modification, we can turn RegRipper into WindowsRipper, an extremely powerful Windows triage tool. Using WindowsRipper we can parse much more than just the registry. Read on and watch the video to see just what WindowsRipper could become.

Adam James, a coworker who did the coding for this project, and I took a look at RegRipper and decided it could be morphed nicely into an amazing triage tool. The first thing Adam did was modify RegRipper to work against a mounted drive. You can read his explanation in the previous post or simply know that his code allows RegRipper to look at a mounted drive, find the Windows installation folder and walk through all of the User profiles found on the drive parsing each NTUSER.dat file. The code was recently posted on the RegRipper.net site.

Using this updated version of RegRipper, we can now ask it parse some other items within the Windows OS. As a proof of concept, we have RegRipper calling Harlan’s script for LNK file parsing, launching an external GUI program, and also executing a plugin that calls a command line function. This last item will let us launch any other program that has a CLI simply by running a RegRipper plugin.

RegRipper’s current architecture is laid out nicely for becoming a triage tool. When you run RegRipper, you can choose a “plugin” for each specific registry hive. Each plugin consists of numerous modules, which can be run on their own using rip.exe. For instance, looking inside the NTUSER.dat plugin, we see that it runs the following modules.

# List of plugins for the Registry Ripper
#————————————-
# NTUSER.DAT
logonusername
acmru
adoberdr
aim
applets
fileexts
comdlg32
compdesc
# The controlpanel plugin is intended for Vista systems only
# User hives from systems prior to Vista will show ‘not found’
controlpanel
#listsoft
#logon_xp_run
mmc
mndmru
mp2
mpmru
mspaper
officedocs
recentdocs
realplayer6
runmru
tsclient
typedurls
muicache
userassist
user_run
vncviewer
winzip
user_win
winrar
wallpaper
vista_bitbucket

Using this architecture, we can build a plugin that consists of modules for a specific purpose. For instance, in addition to incident response work we also receive HR cases that often involve inappropriate use (typically porn). We could build a plugin called “Inappropriate Internet Use” to call modules to parse parts of the registry, internet history, recent internet searches, and create thumbnail pages of the internet cache.  Many of these report items would be created by calling outside executables, bypassing the need for coding a custom module. The plugin would look something like this:

# List of plugins for WindowsRipper
#————————————-
# INAPPROPRIATE INTERNET USE
logonusername
recentdocs
typedurls
recentsearches (calling Nirsoft’s MyLastSearch)
internethistory (calling Pasco)
cachedthumbnails (calling Easy Thumbnails)

Hopefully this example shows the potential that this type of a tool has. We’re even working on a timeline plugin.

With a strong community effort, WindowsRipper could grow based on a large library of custom modules. Users could create their own plugins based on these modules. Some modules could include PhotoRec for file carving, MD5Sum for hashing, many of the Nirsoft.net tools and a host of others. We can launch all of these against a mounted drive and compete with other triage programs such as Drive Prophet.

We recorded a short video of our WindowsRipper proof of concept in action. This video shows RegRipper parsing items other than registry and launching external programs from both the main executable and a custom plugin. View the video here.

What we have done is a rough mockup in just a few hours. The plugins and code we have written isn’t clean enough to be released yet – but it could be. Please let us know your thoughts on turning RegRipper into WindowsRipper. Good idea? Bad idea?

In the past I have been blogging over at Binary Intelligence, a joint blog shared with co-worker Jim O’Gorman. Both Jim and I have been busy with work and other projects and have somewhat outgrown the site. I wanted a place where it would be easier to post content that included videos, custom scripts and code, and other downloadable items that didn’t work out so well on a site hosted by Blogger.

I’ve imported most of the content from Binary Intelligence over to here, but because of the way the import works every post lists me as the author. Keep in mind that anything written prior to this post (May 23rd) may have been written by Jim. Binary Intelligence will most likely be dormant, but may see a post every now and then.

Hopefully this new format works out as well I would like it to.

This post was written by guest blogger Adam James. Please feel free to post any questions or comments for him on this blog.

————————————————-

Modifying RegRipper to automatically run against a selected mounted drive.

When using RegRipper I began running into user to computer interface problems. Namely, for some reason I would select a hive file to process, but forget to tell RegRipper what plugin file to use against it. After doing this several dozen times and having to rerun the reports after realizing I had done it, I started thinking about ways to modify RegRipper to alleviate my obvious “stupid” user issues. I figured since I can’t remember to select the plugin types I want, why can’t the program just throw all the available plugins against the hive and determine which ones should work against it. Then that got me thinking… for that matter why am “I” having to know where all these registry hives are at. I have to extract them from an image, remember where I took them from, and then run RegRipper against each one. That is way too much work. I wish RegRipper would just do that all for me so I can do what I really care about, look at the great output from the program.

To accomplish this task there were a couple of problems that needed to be solved. The rest of this post will be about how a proof of concept that I did solved these problems.

Problems:

1.RegRipper is intended to only run plugins against a single and specified type of registry hive. The plugins can be run against any single hive it is just not likely that any of the key value pairs will be successfully foundoHow if it is not of the correct type.

2.RegRipper expects the user to know the location of each registry hive that needs to be processed.

Potential Solutions:

1.Modify RegRipper to allow the user to select one or more registry hives. Have RegRipper attempt to determine each hive’s type and then run only the plugins that are intended for that hive against it.

This is pretty easy… right? All we need to do is (a)come up with some code to determine a hive file type, (b)programmatically determine what hive type a plugin is supposed to run against, (c)allow the user to select multiple hives, and then (d)iterate through all of the hives. That doesn’t seem too bad.

a.To determine the hive type, Harlan has already provided us with code in rip.pl that tries to guess the hive type, so that is done, we just need to add it to RegRipper. For my proof of concept I came up with a similar way, I just used different keys. (starts at line 563 of code)

b.To determine the hive each plugins should be run against the basic design of the RegRipper could be used. In each plugin the developer can specify what hive types the plugin should be run against. You could just pull the %config=>hive value from the plugin and use that. When reviewing the plugins I noticed that some could be potentially run against multiple hive types. I figured to keep closer to the current user experience it might be a better idea to still allow users to create their own plugin files, so I came up with my own format. Instead of putting just the plugin name in the plugin file, place the hive type you want to run it against in front of it. ie: “system:usbstor”. I had to modify the main RegRipper code to parse the new plugin file format, and also keep it backward compatible with the current plugin file format. (starts at line 434 of the code)

c.To allow the user to select multiple hive files an additional perl module is required. I used the FileOp::OpenDialog which allows the user to select multiple files. (line 251 of the code)

d.Since selecting multiple files with the OpenDialog returns an array of file names looping through them is easy to implement. (line 267 of the code)

So the first problem has been successfully solved and I no longer have to remember to change the plugin file type each time I run RegRipper against a new hive. As a side benefit I can run RegRipper against all of my exported hive files all at once if I want to also. Now on to the next problem.

2.Modify RegRipper to allow it to be run against a mounted drive. Have the program find all of the relevant hive files on the system and process them in a systematic manner.

Now this one looks a little more difficult… maybe? Ok, so we need to (a)allow the user to select a drive letter to run against, (b)grab the basic hive files from windows\system32\config, (c)parse the software hive for a list of profiles and grab the NTUSER.DAT file for each profile, (d)then iterate through all of the identified registry files. Shouldn’t be too tough, I guess.

a.To allow the user to specify running RegRipper against a mounted drive I added a checkbox to the GUI. When this box is checked the BrowseForFolder option from the FileOp perl module is used. (line 605 of the code)

b.Grabbing the basic hives from the mounted drive is a little more difficult than it first looks. Sure the standard location is C:\Windows\System32\config. I first tried this, but when running it on actual cases ran into some issues. Seems some of our corporate clients for some reason have created their own golden images that put the %systemroot% at somewhere other than C:\Windows such as C:\Win.

Now this creates a little bit of an issue, as it messes up what should have been an easy step. To resolve this on Windows XP the %systemroot% can be determined from the boot.ini file in a fairly straightforward manner. (starts at line 639 of the code) To resolve this issue in Vista and beyond is a little more difficult. The boot configurations are now stored in a registry hive called the BCD. So you have to parse the GUID and element key/value pairs to get the value that specifies the %systemroot%. (starts at line 614 of the code) If you want to replicate what is in the code I provided a link at the end of this post that should provide the relevant information about the BCD.

Lastly I tossed in some extra code just in case the boot.ini and BCD registry hives can’t be found to default to windows\system32\config. Cause it never hurts to try if nothing else was found.

c.To determine the profiles on the system Harlan has already provided the code in the profilelist plugin. I used a modification of that code to grab all of the NTUSER.DAT files. (starts at line 690 of the code).

d.The issue of iterating through multiple hive files was solved in the previous problem. For this I just had to make sure each hive file found was placed in an array to be processed. (line 267 of the code, again)

For me the proof of concept works. It is definitely a rough cut in my opinion, but the source is all there and this post explains the process if anyone wants to make improvements. I am not totally sure I really like the output file that this proof on concept results in, but it is a start. Drastically changing the output options of RegRipper is probably a more difficult undertaking than making it run against a mounted drive, so it may not be worth it.

Links

http://regripper.net/?page_id=150 (download the code)

http://search.cpan.org/~jenda/Win32-FileOp-0.14.1/FileOp.pm

http://ezinearticles.com/?Windows-Vista-Boot-Process-Overview&id=794745

http://www.geoffchappell.com/viewer.htm?doc=notes/windows/boot/bcd/index.htm&tx=5

I’ve been waiting for an Android phone to hit Verizon for a while, so I’ve been following some mobile phone blogs. This post from Boy Genius Report was interesting to me on the cell phone forensics front.

One of Cellebrite’s selling points for forensic use is that they often get previews of new devices in order to get their units up to speed for use in the carrier’s stores. The photos in the BGR post (if real) certainly give some credibility to that statement. I wonder if other cell forensic suites get similar updates.

For those forensic folk that may have not have seen this, I did a review of FTK3 for the good folks over at Forensic 4Cast. Check it out here, http://4cast.whitfields.org/?p=438.

Also, follow the 4Cast guys on Twitter at @Schizophreud and @englishgit.

As we talked previously on here before about PS3 forensics, I thought I would do a quick followup. There has been some advancement in the area of decrypting PS3s, though the process is not currently in a state that it could be considered a first stop for the average investigation.

The process requires a couple drives, the original PS3, and an amount of time. I will not be testing it out myself, but if anyone wants to try please leave a comment on how it works for you. You can see all the details up here.

Up at the Offensive Security blog, we put up a little introduction to the forensic additions to Backtrack in this new version.

I have been really enjoying the new BT, a very well put together OS. (And to think, I used to be a BSD head.) The forensic additions to it are really simple, but do the job. I tested them out quite a bit, and everything came back clean. As it is a new forensic tool, I don’t suggest anyone use it until they test it out.

Any problems with the forensic side are on me. Let me know if anything comes up, but I am confident that it is going to be very useful. The offsec and remote-exploit crew really put together something special here.

Informer subscribers have access to the Pre-Final version of BT4!

With this install, all future updates will be released though a simple apt-get upgrade. So if you don’t have a subscription to Informer already, do so now then not have to DL an updated version again.

New version has an installer, forensic boot mode, etc etc. I have been using it for a bit here, and it is a great update to the older versions. There are a ton of videos on how to interact with it up at the Offensive-Security blog.

This story is kind of funny, but kind of sad.

MARCH 18–Meet Michelle Owen. Concerned that an ex-boyfriend had used her laptop to search for child pornography, the Indiana woman asked police to search the computer for illegal images, but had her plan backfire when cops discovered two videos of her engaged in illicit acts with a dog. Owen, 24, was charged last week with two felony bestiality counts in connection with the video files, which a detective found in the laptop’s “recycle bin.” At the time Owen asked cops to search the computer, she was locked up in the Johnson County Jail on a public intoxication charge (which violated the terms of her release in a prior drunk driving case). According to a police affidavit, a copy of which you’ll find here, a cop told Owen that he had found videos of her on the laptop and asked if she “knew what those files might be.” Owen, pictured in the below mug shot, replied, “The one with the dog.” Cops believe that the dog in question, Toby, is a beagle. After asking if she was “going to be charged with this,” Owen said that the videos “were just something she did when she was drunk and barely remembers it,” adding that she tried to “delete them the next day when she was sober.”

From TheSmokingGun.com

There was recently a discussion about forensics on the PS3 game system on the HTCIA mailing list. I had put together a posting for the list regarding the encrypted drives on the PS3, that I thought I would share here as well. Despite these advancements in extracting decrypted data off of the system, the best way to do a forensics exam of the PS3 is still to create an image, then start back up the PS3 and take photos of the data you can access through the PS3 interface. Its not sexy, but it gets the job done as best possible right now.

Within the PS3 hacking community, the last couple weeks there has been a bit of a tift. One group is claiming to have found a way of decrypting the PS3 HD, while another is saying it is just a lie. Well, a tutorial recently came out with a walk through on how to “decrypt” the data. you can read it at http://streetskaterfu.blogspot.com/2009/03/hdd-decryption-tutorial.html.

I have not attempted this myself as of yet (as my PlayStation is currently into Sony for repairs), but will try to get a chance to do so soon. To summarize the process, all that is being done is first you make an image of the the PS3 HD. Afterward, place the HD back into the PS3, and copy a large file off of removable media, onto the the PS3 hard drive through the PS3 interface. Then remove the PS3 HD, and take another image. At that point, you take a diff of the two images, and you will see which data has changed between the images. This is now your known data, your scratch file.

You can then take some unknown encrypted data, and overwrite the scratch file with it. You then write the image to the PS3 HD, and place it back into the PS3. Then, through the PS3 interface you can access your “scratch file”, and copy it off to removable media for examination. The contents of the scratch file will have changed to be a decrypted version of the data which was pasted into the scratch file previously. This process could then be repeated for the entire span of unknown data on the PS3 HD, giving you a decrypted version of all the data.

Again, I have not been able to verify this at all, but it does sound logical depending on how the internal structure of the PS3 filesystem is maintained. It will be about a week or more before my PS3 is going to be back, and then I will be leaving down for a couple weeks, so I have no idea when I will get a chance to work with this. If anyone else verifies this before I have a chance, I would be very interested in hearing back from you.