3

I'm in a situation where I have an executable file. When I start it within the debugger (x32dbg), with breakpoints set to every occasion (DLL entry, DLL load, Thread start,..), to restrict the amount of actions that get executed right after the file is ran,

in the dump I see some bytes which are different from those at the same location in the exe file.

Why is this happening and how to prevent this? On the right, the exe file, bytes which are changed are all arround the file. On the left, the runtime takeout of the memory

My thought is it has something to do with dynamic linking of some sort. The values change when: the exe is saved(EVEN WITH THE EXACTLY SAME CONTENT AS BEFORE) and ran. Thus the offset where the code is placed and the specific bytes are recalculated. The only thing that loads, however, is ntdll.dll an then the first breakpoint is hit. So I guess the content of the exe is copied to the ram, that time is everything allright, then the magic part happens, where the subroutine or what knows what bytes to change and it changes them, and then the debugger gets the control.

2

The magic might be TLS callbacks that run before entry point is reached. This behavior is well documented, see for example the following article:

https://isc.sans.edu/diary/How+Malware+Defends+Itself+Using+TLS+Callback+Functions/6655

  • I looked around TLS but in ollydbg, I set all possible breaking options, even set the system entry as an initial entry. Then the first thing I did was to go to an offset in the memory to see when that overwrite happens, but it was already done. Is it still correct behaviour? should I check it with IDA or is is some other kind of system offset calculation based on some table in the PE header or what. – Patrik Staron Mar 4 at 20:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.