Monday, July 07, 2008

Deleted Keys in the Registry

Have you ever thought, what happens when keys are deleted from the Registry? Yeah, me, too. Where do they go? Well, as it turns out, they appear to hang around, in Registry hive file "unallocated space".

A bit ago, Jolanta Thomassen asked me to help with ideas (and be her sponsor) for her master's thesis, and I threw out Registry "slack" or unallocated space recovery...which she picked up and started running with right away. So far, she's done a great job of locating "deleted" Registry cells, the most interesting (to forensic examiners) of which are cells representing Registry keys, as keys have pointers to their parent keys (so that you can reassemble the full path of the key), timestamps (aka, LastWrite time), as well as pointers to their values. All of these maybe useful to a forensic examiner.

Not only that, but she's writing her code in Perl! This makes it easy for me to understand, add print() statements to (ie, "poor man's debugger"), and modify. For example, I've borrowed her search code, and added in my own code for parsing the key cells, etc., so that I can better see and understand what's going on. In some ways, it's not too different from looking for processes in a memory dump using a brute force approach...you read in values, and make decisions about the type of cell you've found based on those values.

Okay, so I've focused on Registry keys, as I tend to think that they are the most useful to a forensic analyst, for the reasons stated above. By themselves, Registry values found in hive file "unallocated" space may not be entirely useful...without any time-based information, or anything else to reference to (ie, like a key), they're about as useful as finding some text in the pagefile or file slack.

Addendum: Got some code working (finally!) to track backwards through the hive file once a "deleted" key has been found, and attempts to reassemble the full path name of the key. Jolanta already has this working, but I wanted to give it a shot. Below is an excerpt from my code outupt (still with debug info showing):

0x0008e474 456
Software\Microsoft\Windows\CurrentVersion\Explorer
\MountPoints2\{2490fb13-f08b-1
1d8-958e-806d6172696f}\
Shell

LastWrite = Mon Sep 26 23:37:22 2005
Subkeys = 0
Values = 1
Ofs_LF = 0xffffffff

0x0008e4e4 344
Software\Microsoft\Windows\CurrentVersion\Explorer\
MountPoints2\{2490fb13-f08b-1
1d8-958e-806d6172696f}\
Shell\AutoRun

LastWrite = Mon Sep 26 23:37:22 2005
Subkeys = 0
Values = 1
Ofs_LF = 0xffffffff

0x0008e32c 784
Software\Microsoft\Windows\CurrentVersion\Explorer\
CD Burning\Current Media

LastWrite = Mon Sep 26 23:34:10 2005
Subkeys = 0
Values = 6
Ofs_LF = 0xffffffff

Notice with the first two keys above, the second is a subkey of the first, yet actual data from the first key's structure states that there are no subkeys available. Interestingly, names, LastWrite times and links to values are retained when a key is deleted, but links to subkeys are not.

Another interesting artifact retained in deleted Registry keys can be seen in the output of one of the code samples Jolanta sent me:

$$$PROTO.HIV\Software\Microsoft\Windows\CurrentVersion\
Explorer\CD Burning\Curre
nt Media
Last modified: Mon Sep 26 23:34:10 2005
-->REG_BINARY; TotalBytes; 00 88 10 00 00 00 00 00;
-->REG_BINARY; FreeBytes; 00 00 00 00 00 00 00 00;
-->REG_DWORD; Media Type; 2;
-->REG_DWORD; UDF; 1;
-->REG_SZ; Disc Label; PDServer25;
-->REG_DWORD; Set; 1;


Interesting...it looks as if on 26 Sept 2005, someone burned a CD with the label "PDServer25". This demonstrates some pretty interesting potential for time-based information that may be useful to a forensic examiner.

5 comments:

Anonymous said...

Oh registry guru...this is great stuff!

Question. In my mind, I've always been under the working assumption that the Windows registry works very similarly to an Access database. If you remove a record or records from the database it looks "gone" but that space is still sitting there. To optimize the Access database you have to do a compact and optimization action on it to "shrink" it and negate the spaces generated.

What imact (if at all) would registry defragers have on this process you outline? Would they compact that space and cause those phantom values to go away?

I ask as while "most" home users probably wouldn't consider doing a registry defrag, it certainly could be something that might impact the results and effectiveness.

A very fascinating post! Thanks for sharing!

--Claus

H. Carvey said...

Claus,

Dude! Excellent question! While Jolanta is working on her thesis, that's definitely something to keep in mind for testing...ie, grab arbitrary hive files and document the 'deleted' keys. Then run a defrag utility, and see what remains. This may need to be run via VMWare session, perhaps using something like F-Response.

Maybe it's something that Jolanta could pick up as part of her thesis, or work to be done after she's completed it. I'd like to see her get something really solid completed, and use that for the basis of testing.

Also, it might be a good idea in the mean time to look into exactly how the defraggers work...

Anonymous said...

EnCase has an option to scan the unallocated hive area for keys and values for a few months now.
It also parses the security info out as well

Anonymous said...

My experience so far is that no deleted keys can be recovered immediately after a defragger was used. Most registry defraggers claim to restore registry hives from scratch. They parse the registry tree and re-index records to remove all unused space.

To be sure, I have just asked Lars Hedered (the author of the popular NTREROPT tool) and he has confirmed that his program strips out all unused space. However if anyone would like to do some testing of how different defraggers work, I would suggest using Lars' ERUNT and ERDNT. ERUNT can backup registry hives and ERDNT can restore them (without any modifications, according to Lars). So a test could involve taking backup of a hive, running defragger on it and comparing both files. The original hive can then be restored and another defragger could be used on it, and so on...

Anonymous said...

good job