Hi All,
So I have been trying to reverse a piece of malware that is here - http://www.offensivecomputing.net/?q=ocsearch&ocq=976dd8be30df45c6fb2b4aaaa9ce9106 [I am guessing its the same coz the site didnt allow me to upload my file saying it had a copy]. It is called SkypeLauncher.exe.

So everything is fine so far and I can reverse it okay. I however have a few doubts with respect to how threads work in this sample and generally.

a) What happens is - 1 thread is created in Suspended state and ResumeThread is immediately called; it returns 1. The call back function is NOT triggered immediately (although documentation says if 1 is returned it should start immediately).

b) The original code continues and eventually a sleep(1000) is called. At this point that old suspended thread suddenly gets called. I'd put a BP there previously; so I know. Question is...what decides the instant the suspended thread is called? Does the OS see..Oh main thread sleeping...no work..let me call a suspended thread to use resources well? Is this the logic?

c) The third problem IMO is a very interesting one. While it has not stopped me from reversing, I really do not know why it works. The second thread continues running normally; remember first thread is still in sleep(1000). Eventually the 2nd thread comes to a recursive loop that seems to run for a very long time; I used Animate Over in Olly and it keeps going between the same instructions many many many times (I did not count how many though). The disassembly for this loop is in 1.png [attached]. It never exits; I'm sure I tried for at least 10-15 seconds. Didn't see the point in waiting longer. Now comes the interesting part (to me at least ). Instead of Trace or Animate over I ran the program [F9]. Immediately it seemed to break out of the loop and "resume" the previous sleep(1000) thread. This is shown in 2.png [attached]. I am sure it did not break out of that loop because I also ran a Hit Trace (Olly 2.01) and the instructions after that loop never got triggered even once. What is the difference wrt Thread Resumption between Trace/Animate and Run?

Am I making sense? I have also attached the malware if you want to take a look at it yourselves. All opinions of course are always welcome as usual

Thanks
Arvind

Pretty much, yes.


It's probably because the loop is waiting to communicate with the other thread. While you're debugging one thread, the OS (typically) won't run the other threads in the process.

Okay thanks. An extension of this, is that now the first thread is "waiting" for user input and the second thread is asleep (I think). When I give some form of user input (in this case its renaming a file as the malware seems to search for a specific name) the thread which waits for input is activated, triggers my breakpoints etc.
Once it handles this user input, it goes back to its never ending "waiting" state.

So what now happens to the 2nd thread which was asleep? Will it ever get signalled? As in, if it doesn't get signalled even when I do not give any user input, when will it be activated? What happens if its never activated and Exit is called in another thread? Does that automatically kill the sleeping threads too? Or does the OS 'garbage collect' automatically after a while?

This is a WinXP box and the EXE seems to be Visual C/C++.

Thnx
Arvind

don't forget also simple reason:
Debugger also affects (and/or manages in it's own way) thread suspending/resuming.