1

Some of my breakpoints perfectly survive multiple restarts.

But many interesting parts of the code I am debugging have different locations in memory after a restart. It seems the reason is, that the code is loaded into a different memory segment, after a restart. And it further looks like the parts I am looking for are at least absolutely positioned to the memory block they are in.

CLARIFICATION: I suspect that the code which stays in place during restarts is a statically linked library and the code which switches places is the main program itself. Does this make sense?

Is there a way in x64dbg(or a similar debugger) to account for that and set memory breakpoints relatively to the block they are loaded into?

And why do some Parts of the code always get loaded into the same block while others are randomly loaded into one memory segment?

EDIT: Is there furtheremore a method to somehow label constant ponters that are relatively positioned to the memory segment? It would be really helpful to directly recognize which constant im looking on instead of recalculating by hand which one in comparison to the last start it it.

EDIT3:

Here a screenshot for clarification: enter image description here

You can see that the adresses stay the same on the lower two bytes, but differ on the higher 2 bytes according to the memory block they are loaded into.

5
  • you mean some part of code inside a single binary gets loaded at different addresses ? or you mean the dlls gets loaded at different address if it is later then it could be due to aslr (address space layout randomisation)
    – blabb
    Mar 26, 2018 at 18:58
  • I can not tell that for sure, but i suspect the code that always gets loaded in the same place is a statically linked library, while the programm itself is randomly loaded into some memory block. This is what aslr does if i got that correcly, isn't it? Mar 26, 2018 at 19:12
  • In x64dbg you can see which module you’re in when you’re looking at the code. Everything is stored in the database in relative addresses so ASLR should not be a problem. Could you show a screenshot of the debugger when looking at this code?
    – mrexodia
    Mar 27, 2018 at 8:57
  • Sure, I added a screenshot to the original question. Mar 27, 2018 at 10:36
  • does 43exxx 438xxx belong to your main module the one you are loading or attaching to ? if yes then that address change is because of aslr
    – blabb
    Mar 27, 2018 at 19:01

1 Answer 1

0

windows > greater than vista implement a security feature called ASLR (Address Space Layout Randomisation )

this feature randomly changes the Base Address of the binary each time it is restarted this prevents constant address dependent exploits obsolete

for dlls the base address is changed per boot

even though the address space is randomised there can be clashes and the binary might be loaded in the same base address several times

suppose you have code like this

#include <stdio.h>
#include <windows.h>
void main (void) {
    char buff[MAX_PATH] = {0};
    GetModuleFileName(NULL,buff,MAX_PATH);
    printf("%p\t%s\n" , GetModuleHandle(NULL) , buff);
    HMODULE hntdll = GetModuleHandle("kernel32");
    GetModuleFileName(hntdll,buff,MAX_PATH);
    printf("%p\t%s\n" , hntdll , buff);
}

you can see the binary is loaded in the same address 3 times consecutively while changing its base the fourth time also you can see the dll is always loaded in same address on all 4 restarts (this address may change on rebooting )

C:\Users\printbaseaddr>printbaseaddr.exe
00C80000        C:\Users\printbaseaddr\printbaseaddr.exe
774E0000        C:\Windows\system32\kernel32.dll

C:\Users\printbaseaddr>printbaseaddr.exe
00C80000        C:\Users\printbaseaddr\printbaseaddr.exe
774E0000        C:\Windows\system32\kernel32.dll

C:\Users\printbaseaddr>printbaseaddr.exe
00C80000        C:\Users\printbaseaddr\printbaseaddr.exe
774E0000        C:\Windows\system32\kernel32.dll

C:\Users\printbaseaddr>printbaseaddr.exe
003D0000        C:\Users\printbaseaddr\printbaseaddr.exe  <<<<<<<<<
774E0000        C:\Windows\system32\kernel32.dll

you can see if your binary is ASLR enabled using any pe file explorer one way is to use dumpbin /headers and look for Dynamic Base in Dll Characteristics

C:\Users\printbaseaddr>dumpbin /headers printbaseaddr.exe | grep  Dyna
                   Dynamic base

you can patch this in the file to diasble aslr for an executable and you will notice the exe is always loaded in its prefferred base which for an exe is normally 0x400000

:\>fc printbaseaddr.exe printbaseaddrmod.exe
Comparing files printbaseaddr.exe and PRINTBASEADDRMOD.EXE
00000156: 40 00

:\>xxd -s 0x154 -l 10 printbaseaddrmod.exe
0000154: 0300 0081 0000 1000 0010                 ..........

:\>xxd -s 0x154 -l 10 printbaseaddr.exe
0000154: 0300 4081 0000 1000 0010                 ..@.......

:\>echo off
for /L %i in (1,1,10) do printbaseaddrmod.exe
00400000        printbaseaddr\printbaseaddrmod.exe
774E0000        C:\Windows\system32\kernel32.dll
00400000        printbaseaddr\printbaseaddrmod.exe
774E0000        C:\Windows\system32\kernel32.dll
00400000        printbaseaddr\printbaseaddrmod.exe
774E0000        C:\Windows\system32\kernel32.dll
00400000        printbaseaddr\printbaseaddrmod.exe
774E0000        C:\Windows\system32\kernel32.dll
00400000        printbaseaddr\printbaseaddrmod.exe
774E0000        C:\Windows\system32\kernel32.dll
00400000        printbaseaddr\printbaseaddrmod.exe
774E0000        C:\Windows\system32\kernel32.dll
00400000        printbaseaddr\printbaseaddrmod.exe
774E0000        C:\Windows\system32\kernel32.dll
00400000        printbaseaddr\printbaseaddrmod.exe
774E0000        C:\Windows\system32\kernel32.dll
00400000        printbaseaddr\printbaseaddrmod.exe
774E0000        C:\Windows\system32\kernel32.dll
00400000        printbaseaddr\printbaseaddrmod.exe
774E0000        C:\Windows\system32\kernel32.dll
2
  • ASLR is fully supported by x64dbg and is not the problem the op is having...
    – mrexodia
    Apr 14, 2018 at 9:00
  • @mrexodia thanks the op didnt comeback so i do not know what was the problem i just suggested ASLR as a possible cause to eliminate if x64 supports ASLR fully then i guess the problem lies elsewhere
    – blabb
    Apr 14, 2018 at 9:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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