I will buy your book if you include the following 😉
How to recover usable registry information from the unallocated areas of the registry file itself.
If you recall the option in Encase, when mounting a registry file, "calculate unallocated space", that UA contains registry information that is no longer live in the registry.
But it has the potential to be of value to an investigation.
Ivalen,
> How to recover usable registry information from the unallocated areas of
> the registry file itself.
You're going to have to elaborate on that one…I'm not really clear on what you mean by "unallocated areas of the registry".
> If you recall the option in Encase, when mounting a registry file,
> "calculate unallocated space", that UA contains registry information that
> is no longer live in the registry.
Recall? Dude, I'm not a big fan of EnCase, particularly when it comes to Registry analysis. However, you then say "UA contains registry information"…so which is it? Unallocated areas of the Registry, or Registry data in unallocated space?
> I will buy your book if you include the following
I've already started discussing locating Registry keys and values in memory dumps (can be easily applied to the pagefile and unallocated space, as well) in my blog.
Give me a little time to play with the tool this week and I'll make a more solid suggestion as to how I see the plugin idea working.
Check your PM.
I did…nothing of note there.
I keep thinking about your idea…again, my original thought was to provide the Excel output to address this. I can provide that functionality quite easily…I've already written a tool for parsing the Event Logs that use this functionality.
The issues I see with providing the kind of graphic you're talking about is that (a) honestly, it's probably out of my reach at this point in time (and I couldn't be expected to provide something like that for free…), and (b) I can see how it can quickly get cluttered and become usable. By providing a basic functionality, my hope is to bring this sort of analysis within reach of more analysts.
What I'm really looking for is to expand the use of this kind of analysis. The purpose of tools like those I've written isn't to reduce an analysts job to pushing a button, but instead automating the data extraction so that the analyst can focus on correlation and analysis. Too often, we simply don't do this kind of analysis…it's new, it's different, and it's time consuming the first time you do it. But if you document it the first time, and then automate it, it becomes easier after that.
For example, I've done analysis of MS SQL and found certain pertinent Registry keys. Well, it's been a while since I've done the analysis, but I have my notes. If I put those notes into a thoroughly documented plugin, then not only do I have the ability to perform that data extraction again in the future without skipping a beat, but I can then pass that along to others. Someone else can then run the tool, and then email me (or someone else) the results and ask, "what do you think?"
I'd like to see this thread continue, and I hope to see input (in this thread, in other threads, and even via direct email) on this topic. For example, if you'd doing Registry analysis, what do you do? What more would you like to do? If you're not doing it, why? Is it b/c it simply isn't pertinent to your examinations? I've found a great deal of extremely useful data in the Registry, from showing that a user was logged on, to showing that a particular user did or did not access files.
How to recover usable registry information from the unallocated areas of the registry file itself.
.
Do you mean recovering deleted registry artifacts ?
I may be wrong (and in that case I'd like that) but I did a little testing on win XP registry and although I did find very thin remains of registry keys I had created and then deleted, they were already truncated and seemed to vanish with time.
I don't think you can pull much usable information from "unallocated areas of the registry"
If you recall the option in Encase, when mounting a registry file, "calculate unallocated space", that UA contains registry information that is no longer live in the registry.
I might be wrong once more, but I don't think that this option of Encase means that you can recover registry artifacts from that area. I think it just takes all the unallocated areas lying inside the registry files and spits it out in the big "unallocated space" container, in case some of these areas contain keewords, embedded pictures or other artifacts, possibly from before the clusters were used by the registry…
Once again, I'm not quite clear myself about these subjects and these are just the result of a little testing and practice … Use this at your own risks, I shall decline any responsibility … wink
The issues I see with providing the kind of graphic you're talking about is that (a) honestly, it's probably out of my reach at this point in time (and I couldn't be expected to provide something like that for free…), and (b) I can see how it can quickly get cluttered and become [un]usable. By providing a basic functionality, my hope is to bring this sort of analysis within reach of more analysts.
Ok, fair enough. Here's my thought Yesterday I extracted a Subject's NTUSER.DAT file and ran your PNU.EXE against it. I know what the dates of interest are, so my next step was to copy the activity for each day during that period into a separate document so that I can analyze and present the data in chronological order, oldest to newest. It would be nice to have a command-line switch to "automagically" reverse-sort by date (If you tell me it's already in there I'll be REALLY embarrassed!) Another desirable switch would be to convert UTC to local Time Zone. It's so much easier to see a series of events presented in local time and not have to remind folks "Ok. subtract 5 hours from UTC to get the right time."
This is not because I'm lazy, but I've noticed that it's all to easy to make errors when I copy-past from the PNU output to my "presentation" version.
I see a need for both academic analysis of forensic artifacts as well as the practical, "point-'n'-click" tools that help backlogged examiners and LEOs get their job done.
> How to recover usable registry information from the unallocated areas of
> the registry file itself.
>You're going to have to elaborate on that one…I'm not really clear on >what you mean by "unallocated areas of the registry".
Well it's not a difficult concept. The registry file is a file that contains stuff. Stuff organized in to discrete chunks.
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.
> If you recall the option in Encase, when mounting a registry file,
> "calculate unallocated space", that UA contains registry information that
> is no longer live in the registry.
>Recall? Dude, I'm not a big fan of EnCase, particularly when it comes to >Registry analysis.
Well I see you promoting in there often enough, who knows. I can understand why you're not a big fan of encase, it is after all not written in perl, and perl can do oh so much more…
>However, you then say "UA contains registry information"…so which is it? >Unallocated areas of the Registry, or Registry data in unallocated space?
I'm perfectly clear about what I mean - don't try to paint the picture that I don't simply because you do not understand my statement.
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.
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.
Greetings,
Your posting is straying from professional into personal. You might want to consider editing it a bit to keep the tone of the discussion professional.
-David
> How to recover usable registry information from the unallocated areas of
> the registry file itself.>You're going to have to elaborate on that one…I'm not really clear on >what you mean by "unallocated areas of the registry".
Well it's not a difficult concept. The registry file is a file that contains stuff. Stuff organized in to discrete chunks.
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.
You mean searching for information within the slack space of registry files?
Greetings,
Your posting is straying from professional into personal. You might want to consider editing it a bit to keep the tone of the discussion professional.
-David
Agreed.