Anyway, heard through the grapevine that v6.10 of encase has a Find Deleted option now when mounting registries. Woot for them.
>You mean searching for information within the slack space of registry files?
No I don't. I'm moving on. Thank you all.
Actually getting data out of the deleted parts of the registry is simple.
The hard part is finding a lot. The registry has its data in bins, and the first part of the unused space is corrupted /ovrwritten. but toward the end you might find a lot more; this is especially useful for some large-scale last minute deletion.
Thanks Ivalen for the EnCase hint. Are there any other programs that deal with deleted data in the registry?
The chunks have a record structure. An element of that structure describes whether or not any given chunk has been allocated data, or is free to be overwritten.
I'm very familiar with the structure of both key and value nodes in the Registry…but I don't recall having seen the element to which you're referring. Can you please tell me what that element is and where its found?
If you understood the nature of the registry file, you would know about the unallocated areas (UA) of the registry file also. Since when did UA mean all free space on a hard drive only?
Don't feel bad, I've asked this question many times, it appears to be a very difficult problem. Once studied, there is a great deal of usable information in the UA of a registry file. Since HK blocks are 4096 byte multiples, sometimes keys with several values can be recovered intact. Albeit a very manual process - something I was hoping a nice perl script may be able to handle.
I thought that I did have a pretty thorough knowledge of the Registry file structure, but apparently I do not. I have not written any checks for the specific element you're referring to, as I am completely unfamiliar with it. I have not seen in listed anywhere.
Could you provide some information about this element in the structure?
Registry Analysis has been very thoroughly discussed and analyzed. I'd recommend you start getting in to the vista realm, and not just registry analysis.
Uh, thanks. Any thoughts on where I should start?
Thanks,
Harlan
I thought that I did have a pretty thorough knowledge of the Registry file structure, but apparently I do not.
Ivalen is correct, you can sometimes get some quite useful results from unallocated areas of the registry. Registry hives are pretty much like little file systems, just as OLE files are. Windows doesn't compress hives during normal operation, so when registry keys and values are deleted the hive gets fragmented (note within the hive "file system", I don't mean on the actual file system) and data can persist after it has been removed, as long as it isn't overwritten.
I have not written any checks for the specific element you're referring to, as I am completely unfamiliar with it. I have not seen in listed anywhere.
The kernel debugger is probably your best friend here, but this article will go towards helping you out
http//
and the first result from this
http//
Regards,
Tom
Tom,
Thanks. In all this time of looking into the Registry, this isn't something I've ever run across. I'll definitely need to dig into this…it is a definite possibility for useful data.
Thanks,
H
If anyone is interested in viewing the area in a Registry file which contains the deleted data, I have for some time been using a free product, Bintext. The NTUSER file can be dragged and dropped, and by sorting the first column, it will enumerate ANSI and Unicode in a logical manner.
The only isssue is that this method will bring back live and deleted data. The file can be searched via a Textbox on the lower right. The file offset can be matched back over to your particular examination software if required. A downside is that you will require an application to reveal the live keys and data, in order to compare your findings in Bintext.
I have mentioned previously about recovering patterns of MRU entries in their unique structure to identify previous LNK files. This is an excellent product to supplement any examiners collection.
Bintext can be downloaded via the link below. Please read the disclaimer.
http//
Allan S Hay
Allan,
If anyone is interested in viewing the area in a Registry file which contains the deleted data, I have for some time been using a free product, Bintext. The NTUSER file can be dragged and dropped, and by sorting the first column, it will enumerate ANSI and Unicode in a logical manner.
Can you describe how BinText allows you to see deleted data in a hive file?
A downside is that you will require an application to reveal the live keys and data, in order to compare your findings in Bintext.
So, is there any way to tell with just BinText what the deleted data is? How do you even tell what the live data is?
I have mentioned previously about recovering patterns of MRU entries in their unique structure to identify previous LNK files. This is an excellent product to supplement any examiners collection.
Do you have a link to where you mentioned this? I'm interested in this…I found this link, but not sure how it applies
http//www.forensicfocus.com/index.php?name=Forums&file=viewtopic&t=460
Thanks,
H
Harlan,
The application will list all characters which are either ANSI or Unicode and does not display them in a treeview, as one would see in a standard registry viewer. A standard registry viewer would produce the Keys,Values and Data. So in effect you are viewing the complete array of characters which disregards whether they form part of the logical tree structure, or are in fact deleted entries.
Harlan, to answer the second query, if I knew of a way to detect deleted nk,vk and sub data I would have sold the idea a long time ago.
To answer the third query. If you look at a NTUSER file in a registry viewer and note any entry which appears in the Recent Docs. Open a hex editor and find the same entries. Note that they flow as Unicode (File Name)lnk, ANSI (File Name)lnk, and Unicode (File Name) file extension, in that strict order.
If you do the same in BinText, remembering to sort the first column, you should come across deleted MRU entries, which are not seen in a standard registry viewer as they do not form part of the logical tree structure.
Apologies to the forum, the original thread I responded to was in Digital Detective, which if I recall you may have added to. I believe it was in response to a query about HBIN's.
Allan S Hay
Tom,
I've taken a look at the information you've provided…thanks. It is extremely interesting, and extremely helpful.
Aside from unallocated space within the Registry hive files themselves, I'm curious as to what others are looking for or simply interested in finding within the Registry.
Thanks,
Harlan
So, any thoughts on what folks actually want to get from Registry analysis?
H