I think Marcus is right, this looks like copy protection.
Let's engage on a little log analysis shall we? This is something that just comes with practice ...
Just after the program starts, it does a CreateProcess:
0023:Call kernel32.CreateProcessA(406cd2f0 "C:\\Program Files\\Easy CD-DA Extractor 7\\ezcddax.exe",403810d8 "ezcddax.exe",00000000,00000000,00000001,00000004,00000000,00000000,406cd2ac,406cd61c) ret=00750ec9
ezcddax is the real program and what you launched is just a stub.
Note the 6th parameter: it's 4, which is CREATE_SUSPENDED. So, the new process isn't supposed to start.
[ snip lots of traces from CreateProcess ]
0023:Ret kernel32.CreateProcessA() retval=00000001 ret=00750ec9
Here we are at the end.
0023:Call kernel32.GetModuleHandleA(00000000) ret=00750fdb 0023:Ret kernel32.GetModuleHandleA() retval=00400000 ret=00750fdb 0023:Call kernel32.GetModuleHandleA(00000000) ret=00750ffe 0023:Ret kernel32.GetModuleHandleA() retval=00400000 ret=00750ffe 0023:Call kernel32.GetModuleHandleA(00000000) ret=00751012 0023:Ret kernel32.GetModuleHandleA() retval=00400000 ret=00751012
Interesting. GetModuleHandle(NULL) returns the HMODULE of the current process. An HMODULE is simply a pointer to the base of the file which is mapped in: in the case of an EXE it'll be the headers.
So, it looks like this program is walking its own headers in memory - probably inspecting them for signs of tampering. More and more likely that this is copy protection.
0023:Call kernel32.ReadProcessMemory(00000058,00761060,0078c96c,00000002,406cbc0c) ret=007556bd
It then reads the memory of the newly created process, 2 bytes from 0x761060. I wonder what is at that address?
Grep the log for it and bingo!
0025:Starting process L"C:\\Program Files\\Easy CD-DA Extractor 7\\ezcddax.exe" (entryproc=0x761060)
So it's reading the first two bytes of the entry point. Checking for a breakpoint perhaps?
0023:Call ntdll.NtReadVirtualMemory(00000058,00761060,0078c96c,00000002,406cbc0c) ret=404fab7a 0023:Ret ntdll.NtReadVirtualMemory() retval=00000000 ret=404fab7a 0023:Ret kernel32.ReadProcessMemory() retval=00000001 ret=007556bd 0023:Call kernel32.WriteProcessMemory(00000058,00761060,406cbc08,00000002,406cbc0c) ret=00755723
Then it writes back 2 bytes to the same address. Maybe this is the bit that lets ezcddax know it was started by the launcher program and not directly by the user. I suspect if you suppress this WPM call, the program will pop up an error asking you to run the launcher app directly. It's probably writing a jump opcode.
0023:Call ntdll.NtWriteVirtualMemory(00000058,00761060,406cbc08,00000002,406cbc0c) ret=404fabea 0023:Ret ntdll.NtWriteVirtualMemory() retval=00000000 ret=404fabea 0023:Ret kernel32.WriteProcessMemory() retval=00000001 ret=00755723 0023:Call kernel32.GetExitCodeProcess(00000058,0078ca58) ret=0074f235
Now it goes into a loop, attempting to get the exit code of the process.
0023:Call ntdll.NtQueryInformationProcess(00000058,00000000,406cb86c,00000018,00000000) ret=404f5dfa 0023:Ret ntdll.NtQueryInformationProcess() retval=00000000 ret=404f5dfa 0023:Ret kernel32.GetExitCodeProcess() retval=00000001 ret=0074f235
It's trying to find out what the exit code of the process was. Unfortunately, we don't know what the answer is because the return code is a success/failure bool, not the actual exit code. You'd have to whack an ERR in here or something to find out.
0023:Call kernel32.ResumeThread(0000005c) ret=007557c5 0023:Call ntdll.NtResumeThread(0000005c,406cb8a0) ret=4050e85e 0023:Ret ntdll.NtResumeThread() retval=00000000 ret=4050e85e 0023:Ret kernel32.ResumeThread() retval=00000001 ret=007557c5 0023:Call kernel32.Sleep(00000064) ret=007557cd
Then it tries to wake it up (remember, the remote process was started suspended) and sleeps for a moment.
0023:Call ntdll.NtDelayExecution(00000000,406cb888) ret=40507cff trace:relay:RELAY_InitDebugLists RelayExclude = L"RtlEnterCriticalSection;RtlLeaveCriticalSection;_EnterSysLevel;_LeaveSysLevel;LOCAL_Lock;LOCAL_Unlock;TlsGetValue;kernel32.GetLastError;kernel32.SetLastError" 0025:Call PE DLL (proc=0x401d3bb4,module=0x401c0000 L"ntdll.dll",reason=PROCESS_ATTACH,res=0x1)
At this point the kernel does a context switch into the new process, and it begins initializing. Note that CREATE_SUSPENDED doesn't mean nothing runs in the new process. It still gets the ATTACH notifications (at least, it does in Wine ... maybe not in real windows). So there's a lot of stuff we can ignore here generated by the startup sequence.
Let's find out what the first process is doing:
0025:Ret ntdll.RtlAllocateHeap() retval=40393550 ret=4083acae 0023:Ret ntdll.NtDelayExecution() retval=00000000 ret=40507cff 0023:Ret kernel32.Sleep() retval=00000000 ret=007557cd 0023:Call kernel32.SuspendThread(0000005c) ret=007557da 0023:Call ntdll.NtSuspendThread(0000005c,406cb8a0) ret=4050e80e 0023:Ret ntdll.NtSuspendThread() retval=00000000 ret=4050e80e 0023:Ret kernel32.SuspendThread() retval=00000000 ret=007557da 0023:Call kernel32.GetThreadContext(0000005c,406cb948) ret=0075580e 0023:Call ntdll.NtGetContextThread(0000005c,406cb948) ret=4050e7ae 0023:Ret ntdll.NtGetContextThread() retval=00000000 ret=4050e7ae 0023:Ret kernel32.GetThreadContext() retval=00000001 ret=0075580e
Context switch after the first line, and it awakens from its sleep.
It then suspends the thread, and grabs its context. Why does it suspend? Reading MSDN reveals that the target thread has to be suspended for GetThreadContext to work. The CONTEXT structure holds the register state of the thread. I wonder what it's looking for in this structure?
0023:Call kernel32.GetExitCodeProcess(00000058,0078ca58) ret=0074f235 0023:Call ntdll.NtQueryInformationProcess(00000058,00000000,406cb86c,00000018,00000000) ret=404f5dfa 0023:Ret ntdll.NtQueryInformationProcess() retval=00000000 ret=404f5dfa 0023:Ret kernel32.GetExitCodeProcess() retval=00000001 ret=0074f235 0023:Call kernel32.ResumeThread(0000005c) ret=007557c5 0023:Call ntdll.NtResumeThread(0000005c,406cb8a0) ret=4050e85e 0023:Ret ntdll.NtResumeThread() retval=00000000 ret=4050e85e 0023:Ret kernel32.ResumeThread() retval=00000001 ret=007557c5 0023:Call kernel32.Sleep(00000064) ret=007557cd
OK, and we go back into a loop. In fact, this is an infinite loop.
Probably it looks like this:
while (1)
{
int code;
CONTEXT86 context;GetExitCodeProcess(process, &code);
if (code == ???) do something;
ResumeThread(thread);
Sleep(64);
SuspendThread(thread);
GetThreadContext(thread, &context); // do something with context here
if (context.???) break ???
}So the question is, what condition will make it break out of the loop, and why isn't it getting it in Wine?
It looks like it's waiting for some condition to become true in the remote process. This will never happen because ResumeThread here doesn't seem to be waking it up! We just loop over and over, resuming it, sleeping for a while, grabbing its context to check something which never changes, and starting over.
So, I guess the problem is that ResumeThread isn't actually waking up the suspended process. Question is, why not?
Here's an idea. Hack the Sleep() call like this:
if (delay == 64) delay = 3000;
Ie, rule out the possibility that the delay between resume and suspend is so short Wine can't react in time. Then continue your investigation from there.
Good luck!
thanks -mike
