Topic created on: November 1, 2006 13:31 CST by nezumi .
all hail, how-d'ye-do, guys!
maybe you even know me, I'm author of
"hacker disassembling uncovered", "hacker debugging uncovered",
"shellcoder's programming uncovered", "code optimization" and some other books.
I found a bug in process explorer tool. well, not a bug, a feature :)
process explorer tries to determine start addresses of threads,
but it not always works.
get the file va_thread.c (attached), compile it, run and see the bug yourself.
process explorer correctly determines the start addresses of the two first threads,
but stumbles over third, created in the malware's manner
(it allocates memory on heap, copies malicious code and calls Create[Remote]Thread).
process explorer says: the start address of the third thread is:
KERNEL32.DLL+B700h, but it's definitely wrong!
actual start address has to look like 00520000h or somewhere around it.
I don't know how process explorer determines the start addresses of threads,
but I found very simply and quite reliable way to do that.
I noticed that the start address of the thread lies on the bottom
of the user stack in the second or third dword, followed by lpParameter.
this works under Windows 2000 and Windows Server 2003,
I didn't check out Windows XP yet, but I hope, it will be the same.
I wrote quick and dirty utility proclist.c correctly determines
start addresses in the most cases and discovers malware,
which allocating memory with VirtualAllocEx to "inject" into process,
or loads malicious DLL via creating remote thread, passing address
of the LoadLibraryA/W and places name of malicious library in lpParameter.
in the first case, start address of the malicious thread belongs to
MEM_PRIVATE area (instead of MEM_IMAGE like normal exe/dll does),
and in the second case start address matches LoadLibraryA/W.
I checked this method on my malware collection and got good result.
I hope, you will find this information useful :-)
with best regards,
kris kaspersky