I promised to tell you about the TLS callbacks. Here is the discussion.
When you launch the debugger and set a breakpoint at the program entry point, one may think that the application will be suspended as soon as the process is created. In reality, this is not the case and the application can easily run out of control.
Let’s take this sample program.
If we load the executable into IDA, we will see the following:
It seems to be an empty C program. However, the author might have used a modified version of the C startup. To avoid any problems because of the C startup, we will put a breakpoint at the program entry point by pressing F2 (the entry point is always named start by IDA):
Now, if we launch the debugger by pressing F9…
Hold on.. see.. the application runs!
The application managed to run beyond the entry point despite of our breakpoint!
In reality the mistery is explained easily: a TLS (thread-local-storage) callback is used by the application. Such a callback is called by the system before the application entry point, that’s why our breakpoint was not triggered.
IDA Pro knows about TLS callbacks since long ago. If you open the entry point list (Ctrl-E), you will see that there is a function called TlsCallback_0 and the function is nicely disassembled.
What could you do to avoid such bad surprises? Here are some recommendations:
- Run the application in a confined virtual environment
- Look for TLS callbacks in the entry point list before launching the debugger
- Configure the debugger to suspend as soon as the process is created (see Debugger, Debugger options, Stop on options)
I prefer the first solution since it protects me not only from this particular loss of control but from many other problems.
