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

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

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