Hi all,

I got a problem with a new version of a malware (wsnpoem) I'm working at currently. This is probably a simple thing, but I'm still a beginner with OllyDbg, so maybe somebody can help me out?

Here is what the malware is doing under control of OllyDbg:
- creates another process using CreateProcess (CREATE_SUSPENDED)
- GetThreadContext of new process
- reads 4 bytes at offset [ThreadContext+0xa4]+8 out of its memory (obviously PE section start)
- Allocate memory in new process for code modules (at 0x400000) using VirtualAllocEx (COMMIT+RESERVE, PAGE_EXECUTE_READWRITE)
- Write code into this area using WriteProcessMemory
- writing 0x400000 as 4 bytes into above 4 bytes, probably to fix section address
- SetThreadContext with data previously obtained (probably adjusted)
- Finally calling ResumeThread on thread id of new process obrained in first step

And this will start the actual malware. Now I'm as far as stepping forward to the ResumeThread call. If I press F8 now, the malware starts and runs through without any chance to interrupt it - no wonder, it's in another process.

So I tried starting a second OllyDbg instance that I attach to the newly created, but still suspended process. Unfortunately, I can't see the process ID yet in order to attach to it.

But I can see the process using Sysinternals ProcessExplorer (dark grey background), and when I look at its properties and check threads, I get an error message but can now attach to it using OllyDbg. Unfortunately the 2nd process doesn't work anymore as it should (not even without OllyDbg's attach) , Sysinternals processExplorer seems having destroyed something in it.

So the question is: how can I debug this new thread in a new process from beginning on? As the thread is in another process, I can't just set a breakpoint in OllyDbg's first instance - after all the memory space is a completely different one - as far as I understood. And a second OllyDbg can't attach to the new process in time.

Any ideas would be highly welcome :-)

klaymen

I am sure more seasoned malware reversers can give you a more accurate advice.
This technique is very common in protection mechanisms:
You can figure out where is the entry point of the new process: You can see its PE header and other details while it is being set up by the initial debugged process monitored under olly.

Before the ResumeThread call is invoked, change the entrypoint instruction to a EBFE instruction, jump to my self, spinning jump or infinite loop (There is something shockingly akin to masturbation related to this instruction ).

Let the new process run.

It will try to run, but go nowhere. Now attach a second Olly to the newly created process spinning at the gate, let it run F9, pause it, then replace the entry point bytes with the original bytes, which you wrote down from previously.
Now trace the new process from its entry point, at your leisure.

Excellent idea, thanks... I'll give it a try immediately actually I could have had this idea myself...

But you did not!

I hate you naides, now I can't stop thinking about the phrase EBFE OFF

I will NOT think of EBFE OFF!
I will NOT think of EBFE OFF!
I will NOT think of EBFE OFF!
I will NOT think of EBFE OFF!
I will NOT think of EBFE OFF!
I will NOT think of EBFE OFF!


Regards,

well, no... but at least I had the idea trying out OllyAdvanced's process patcher that automates this process. It even notices I'd like to patch the child process... neat, problem solved thanks again

My next problem now is to dump the child process after unpacking stuff was done, as all section information is lacking in OllyDump. Well... I'll play around with that part tomorrow.

[philosophical shit]
Well, EBFE is the simplest expression of the failure (curse) of Von Newmann's concept of computing.
Unless an automaton is supervised, and its process can be monitored/intervened from outside the process itself , it will eventually drift to the familiar picture of an "adolescent taking a shower" situation. . .
[/philosophical shit]

Honest mommy, I was only trying to wash it! Really!

Regards,

Olly has tons of irritating bugs, among which not saving all shit if modified in different sections, refreshing when allocation memory from a different 3rd part application (until you Alt+M, you can't go to allocated memory) and this one here - the annoying child display in the processes list. Every other program sees the child being running suspended, only Olly doesn't T_T..

Yeah indeed Olly has tons of boring craps, but in this case is Normal
that Olly is unable to break on a SUSPENDED Thread, this cause the
particular nature involved into Thread Creation.

CreateProcess/CreateThread functions, are based
upon a KernelMode -> UserMode Callback LdrInitializeThunk,
these Thread Creation APIs make you think that the thread is Started
(at the API invokation moment) but this is not completely true.

Various layers needs to be passed, and thread really starts when is
reached LdrInitializeThunk that "balances" the New Thread CONTEXT
and next calls LdrpInitialize.

So became "impossible" to break on a Suspended Thread, cause it has
no called LdrInitializeThunk, and in rude words could be considered as
not existant

There are new technology debuggers that supports Process Creation,
such as ntsd, you have to set (by typing -xe cpr) the Event
CPR that stands for Create PRocess

Regards,
Evilcry