Tom, thanks for reading, I'm glad you liked it.
In answer to your points (and Harlan's)
I've just read up on Andreas' work - for some reason I hadn't noticed his tool when I was researching (or the bugtrack info) but it does look pretty comprehensive. As with the dispatcher ready queue though, it would be possible to alter enough values in a malware process to avoid detection - there are always going to be workarounds. The best solution would have to be a combination though, and it's never going to be perfect.
If you get anywhere with your paging tool, it would be interesting to look at - it did occur to me to use a VM to look into it but by the time I realised it would be an option it was rather late in the day. And no, I didn't have a copy of it either )
My main problem with the whole thing was that I had to go from memory novice to something approaching knowledgable in about a month I'm not surprised I missed a few things here and there… I just haven't really beed involved in it for very long so there's a lot going on that I didn't know about. I'll keep at it though, if I get time.
> it would be possible to alter enough values in a malware process to avoid detection
Really? This is something that has been posited, but to my knowledge, never actually tested. For example, can you alter the DISPATCHER_HEADER values provided by Andreas, and still have a viable, running process? For example, my lsproc.pl script looks for a size value of 0x1b and a type value of 0x03…you're saying that you can change these values so that they're different (ie, size = 0x3f, type = 0x13) and the process will still be recognized by the OS?
You're right that values within the EPROCESS block can be altered to "hide" malware processes, but as of yet, those have been limited to the FLINK and BLINK values, which is the core of Jamie Butler's DKOM technique.
I guess I'm surprised to hear you say that you had to ramp up from novice to expert in a month, and then you state rather definitively that "it would be possible to alter enough values in a malware process to avoid detection", without any qualification.
It certainly is an interesting topic - I started working on it a little less than a year ago, and have been doing bits and pieces since then. Through the course of it, you learn a lot more how hardware works, the Windows kernel works, how malware hides etc
You are correct in saying that you can alter values to prevent detection, but I believe that you do reach a point where the system just won't operate without certain things in place. For example, the article at http//
Also, I believe Joanna initially assumed that PIDs on a system had to be unique - it turns out they don't. I also assumed initially that process IDs had to be within a certain range and BlackLight's PID bruteforcing checks PIDs between about 0-20,000. Actually, Windows XP (on VMWare at least) seems to sometimes have a weird psuedo-process with hardly any valid values, and a PID which is actually a pointer to the Idle process. I therefore had to modify my detection routine to show this, as it is at least notable. To make matters more complex, you don't even need an EPROCESS structure - you can schedule your code to run in kernel threads instead -/
It comes down to just trying to cover all the bases without being too strict about your criteria; fuzzy matching might be in order.
I guess I'm surprised to hear you say that you had to ramp up from novice to expert in a month, and then you state rather definitively that "it would be possible to alter enough values in a malware process to avoid detection", without any qualification.
Harlan, there is no need to be quite so agressive in your reply - you don't need years in the field, just a good solid understanding of the material.
As I stated in a few of my posts here, you don't even need an EPROCESS structure per se to have valid, executing code. An EPROCESS structure is just a container of metadata and the like, threads do all the work. Also, you can write your own scheduler to provide your threads with CPU time. So technically he is correct, you probably can munge those values and still have executing code - the scheduler wouldn't understand it, but your own could.
My caveat here is that I've never tried to do all these things in combination, but rootkit writers constantly prove assertions like yours incorrect. In future maybe it would be helpful to ask people what they mean rather than essentially calling them ignorant because they haven't been in the field quite as long as yourself.
> it would be possible to alter enough values in a malware process to avoid detection
I guess I'm surprised to hear you say that you had to ramp up from novice to expert in a month, and then you state rather definitively that "it would be possible to alter enough values in a malware process to avoid detection", without any qualification.
Fair enough, I should have said 'might' but I didn't call myself an expert, nor would I by any means.
Regardless, the fact remains that there will always be workarounds…
> no need to be quite so agressive in your reply
Sorry, that wasn't my intention. As someone studying this field, I saw a general statement that I was looking to get clarification on, that's all. No offense was intended.
> rootkit writers constantly prove assertions like yours incorrect.
Assertion? I didn't make any assertions that I was aware of…
> …rather than essentially calling them ignorant…
And I certainly didn't call anyone "ignorant", or anything of the sort.
My question was a simple one, not intended to be offensive (something I obviously didn't succeed at), and nothing more than a query for additional information…that's all, nothing else.