As far as "…strip out the "Computerese" and populate the "jury-readable"…" goes, that's your/our job.
Eh, well, if I don't ask, I don't get. It was worth a shot.
It may be my "job" and I certainly *will* charge the client for doing it, but the whole raison d'ĂȘtre for computers is to make things easier, isn't it? If we can automate some of the grunt-work, we can turn cases around sooner.
-A
It may be my "job" and I certainly *will* charge the client for doing it, but the whole raison d'ĂȘtre for computers is to make things easier, isn't it? If we can automate some of the grunt-work, we can turn cases around sooner.
I look forward to seeing what you have to offer to the effort…
Thanks,
H
Harlan,
How about a section on Registry Cause and Effect.
1) What system actions modify the registry and in what way
2) What user actions modify the registry and in what way
You could reverse this and say "what actions in the registry affect system and how"
In essence, saying "when X does Y on your system you will see Z or not see Z in the registry". I'm basically suggesting that you use your excellent corollary in the addendum and use it for registry analysis.
I look forward to seeing what you have to offer to the effort…
H
Check your PM.
Aaron,
How about a section on Registry Cause and Effect.
1) What system actions modify the registry and in what way
2) What user actions modify the registry and in what wayYou could reverse this and say "what actions in the registry affect system and how"
Good idea. I see that I didn't explicitly state that but I was looking at expanding on what I've already written, including what you've mentioned above.
I thought this time around, though, I'd actually do a walk through of how to determine the cause and effect, through testing, using several examples. I can't possibly list everything, but I thought perhaps I could list a good deal, and include the process, as well.
In essence, saying "when X does Y on your system you will see Z or not see Z in the registry". I'm basically suggesting that you use your excellent corollary in the addendum and use it for registry analysis.
Good way to put it! Maybe I should've entered the corollary in the t-shirt column. đ
Right on. If you want some assistance or a reviewer just ask.
I posted a new version of the Registry tool yesterday.
One of the things I like about the plugins is the ability to get whatever I want, and manipulate it anyway I want. As an example of that, I wrote two plugins that both get the RecentDocs entries, but output them different ways.
So what is it that examiners want to get out of the Registry?
In my experience, when asking another examiner who has just finished a case specific questions about the Registry, I usually get a blank stare back…usually.
I've used Registry analysis to show…or not show…access to files, systems, and a wide range of user activity. Of course, only certain areas of the Registry can contain data pertinent to certain cases, but I'd like to get a better understanding of
- Why do some examiners NOT even consider the Registry?
- When digging into the Registry, how do you go about it (knowing, of course, that there is data in binary format that an ASCII search will not reveal…)?
- What are the "mysteries" of or questions about the Registry that you face?
I can only speculate why people don't examine the registry. I suppose folks may see it may be seen as too time consuming (as in may not yield useful results) and confusing because of the vast array of options available in the registry.
I look at it this way. The system is my main body of evidence. It's where I find artifacts and data that give me the final stage of a "crime". The registry tells the story leading up to that point. In other words the registry is where I collect my main source of anamnestic(behavioral) evidence and the system itself is where I find corporal evidence. So, what do I hope to get out of a registry exam? I use the registry to add context to the disk examination much like I would use a configuration file to help me determine how a program may have been used.
A plugin suggestion I have for you is class based searching. For instance - create a "CP class" looking for programs that may be related or activities commonly associated with CP cases and spit them out in a usable format. The same goes for intrusions.
I tend to approach the registry from the user to the system. Which is to say I look at user activities and then system configurations. I do this because the user is the primary force that changes the system in the majority of instances.
The mysteries for me are what I listed before (registry causality if you will) in my suggested addition to the new book/addendum.
A plugin suggestion I have for you is class based searching. For instance - create a "CP class" looking for programs that may be related or activities commonly associated with CP cases and spit them out in a usable format. The same goes for intrusions.
Interesting suggestion…what exactly constitutes a "CP class" in your mind?
I ask, b/c to be honest, I'm not sure. I've had customers ask me to search for sensitive data before, but they weren't able to describe what they meant (they told me that they weren't interested in CC nums or SSNs…)…either in terms of keywords or doc types (Word, PDF, etc.).
Also
- what is a "usable format" in your mind?
- what constitutes an "intrusion class" in your mind?
Thanks.