04.04.05
Entry point is not the entry point!
Yesterday I started a nice reversing job, a packer which is quite bastard! I loaded it with olly and… bam! The process terminates before the entry point is reached! Punching the case wasnt working, so i found the packer uses a simple but nice trick to execute code before the ep is reached, and trashes olly! It is not executed via dllmains or other external code, just the code in the exe image itself! I wont tell it for now
i write a paper on it when i’m done this work.
Cheers!
AndreaGeddon





kratorius said,
February 3, 2007 at 11:12 am
Hey andrew!
You’re not alone: i’ve been facing this kinda problem a month ago too. In my case was a damned specialistic software for mechanical engineer (I still didn’t understood what it does…).
It was not packed or crypted, but if you load it with olly, the execution terminates before the entry point’s reached.
I don’t know why, I hadn’t the time to do a deepest analysis, but I’ve added this work on my todo list and I think that I’ll wait your paper before to put my hands on this program again, so let do it asap! smile
Btw, I’m not dead, I’ve just lost the way smile The reversing-inside spirit sometimes resort in myself…
‘llooooo!
sna said,
February 3, 2007 at 11:15 am
There are a number of ways i can see this happening. First one is: Any DLL in the import table will run thru its DllMain before OllyDbg breaks in on the entry point of the main module. That should give the application an opportunity to try and find the debugger.
Then there’s the possibility that it’s using static TLS and TLS callbacks. When using static TLS there’s a special structure stored in the binary. The structure holds pointers to initialization data and callback functions among other things. There’s not much information on this but head over to EliCZ’s site and see if you can find something *hint* *hint*.
Also, if the application was installed using an installer there’s a chance it unpacked something evil that sits in the background and monitor system APIs. I would think CreateProcess() and DebugActiveProcess() would be it’s primary targets.
Regards, sna
junior said,
February 3, 2007 at 11:15 am
TLS entrypoint is the culprit i suspect. I’ve been spending some time reversing virii the last couple of weeks, and this has shown up in a few of them. Works really well for confusing heuristic scanners and emulators.
bmb said,
February 3, 2007 at 11:16 am
I agree with sna that TLS is probably the trick used here (check data directories).
If debugging HLL be carefull with those that insert code in the runtime loader.
Regards, bmb