This is my first post here, so hello everyone and thanks for keeping such a useful forum. I'm just finishing up a MSc course in Forensic Informatics and for my Thesis I took the topic 'Windows Memory Acquisition and Analysis'. I know a little work's been done on this already so this was partly an attempt at amalgamating the research done so far, partly suggesting new avenues for research and partly new research into a couple of aspects.
You can read it here
http//
I'd be very grateful to hear what any of you think, and if anyone finds it useful then that's great.
Let me know what you think!
Nick.
Nick,
Interesting paper. Very comprehensive, although it doesn't cover anything new. The consolidation is a good thing, though, putting everything in one place.
I can see by the date on your thesis that you didn't have a chance to look at the code I've released.
Again, good paper.
Harlan,
Thanks for the comments. I have seen your code, although I have to admit I haven't yet tried it. I did come across some information relating to what you've produced but didn't have the time (or space within my word limit!) to go into it further - I only had 6 weeks to research, produce and write it up although I could have done with a lot longer. I'll try and continue on with the topic and post anything I find although I don't know when I'll get the time…
Nick,
This is a new area of research that will be beneficial in a lot of ways, and needs more exposure and development.
Unfortunately, there are many people doing development in this area, but are restricted by their employers from divulging the information. Some are able to get it public, under the understanding that it's only right, considering they got the info from open source avenues.
H
Nick,
A link to your paper was just posted over on the FIRST discussion list. I'm trying to start an actual discussion thread on it, as I do believe that it is a viable and valuable area of research.
I'd like to get your thoughts, though, on things such as enumerating all processes through a "brute force" lookup of EPROCESS blocks versus enumerating only the active process list, as well as additional areas of research.
Harlan
Harlan,
Indeed it is a very important area, and it's good to see people starting to take it seriously (rather than hiding behind the guise of 'preservation of evidence'). Do you have a link to the FIRST discussion (assuming it's open or I can join it)? It's not the handiest name for searching on google )
I have to agree with you about the freedom of information - it's always annoyed me when I'm researching something that I know someone else knows about but just won't tell me! I'm (for now at least) in the fortunate position of not being tied to a company and yes, all the information I used is publically available, if a little difficult to find.
I'm still not sure of the best way to look for EPROCESSes. Obviously browsing the list is sussceptible to hiding, but it does at least garauntee that the results are real hits, not false positives. That's the main problem I see with any kind of heuristic search, unless it's based on something concrete (like I mentioned with looking for 0039000 and 'System' but that obviously only works with the System process). I'd be happier if we could come up with a method for looking through the thread scheduler - if you can find the ETHREADs running then you can get the parent EPROCESS and voila!… I didn't come across anything at the time but I may be able to have another look some time. With that though, we again run into the problems above - the required information is not publically available and so if I find anything while working for a company I may not be encouraged to tell…
> Do you have a link to the FIRST discussion
No, I don't, b/c it's closed.
> I'm still not sure of the best way to look for EPROCESSes.
Brute force searching. Andreas posted on this, and I've found it to be extremely effective. It's relatively easy to rule out false positives regardless of the OS version…my code for Win2K, for example, demonstrates this. Translating this to extracting all of the ETHREAD structures is relatively trivial, as well.
> …the required information is not publically available…
Yes it is…some of it, anyway. I've posted in my blog, as well as with my code. Some folks have been able to release some things b/c they've used freely available info (from myself, and from Andreas) as the basis for their work.
Is the breadth of all info currently publicly available? No, perhaps not…but there's a great deal available.
Morning Nicholas,
I read your thesis through with my morning coffee - it's a very good paper. Although you said it is an almalgamation of other research, it shows you have thought about a number of different avenues of research, and I certainly picked up a few things. A few points if you are interested
1. The Dispatcher Ready Queue is a nice thing to check, but be aware that it is possible to possible to completely remove threads from the kernel's dispatcher and write your own to schedule CPU time to your hidden threads. I would recommend using this in a "cross-view" approach, and correlate it with other structures and lists.
2. It is possible to perform sufficient checks on an EPROCESS scan in memory to ensure that you do not get false positives. Andreas lists a most of them, and there is also quite a good list at http//
3. I've been intending on writing a tool to force large amounts of paging on processes in a controlled way, to test page file merging in a reliable way. If I have time, I will write it outside of my employer's time (unlike my memory analyser!) so that I can share it out.
4. You didn't mention VMWare .vmem files (maybe you couldn't get funding for a copy of VMWare workstation or something!), but using VMWare to construct test cases and parse the resulting vmem file is about the quickest and best way of testing tools written for this purpose.
Anyway, good work again, and thanks for posting it.
Regards,
Tom Goldsmith
Unfortunately, bugcheck has yet to release his source code, albiet continuing promises to do so.
Re .vmem files and "cross-view" approach…that may come perhaps from the time at which the research was conducted.
I wasn't really referring to actually getting the GrepExec source code - in fact, you don't need it. I was using that example to point Nicholas at some ways to reduce false positives when scanning for EPROCESS structures.
My main point was that generally he posts a lot of information about the Windows kernel, and with a little bit of extra research using articles such as these, some really useful information can be found. You don't learn nearly as much by just reading the source code 😉