Reverse Engineering RET Homepage RET Members Reverse Engineering Projects Reverse Engineering Papers Reversing Challenges Reverser Tools RET Re-Search Engine Reverse Engineering Forum Reverse Engineering Links

Reverse Engineering Team Blog

04.04.05

Entry point is not the entry point!

Posted in General Posts at 11:10 am by andreageddon

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 razz i write a paper on it when i’m done this work.
Cheers!
AndreaGeddon

4 Comments »

  1. 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!

  2. 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

  3. 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.

  4. 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

Leave a Comment