write loader with memory hooker

[atom0s]

DLLs are not guaranteed to load at the same base address each time a process starts or the module is loaded. While they can be compiled to request a specific base address, it is still up to the system if that requested address will be used. Multiple factors can prevent it such as if another module is already using that address space, or space around the requested address that would otherwise be needed to fully load the module. Or if the system has ASLR enabled, it may be ignored entirely.

You can use various methods to locate the memory address you wish to edit though when this kind of thing is happening and the code is within a DLL instead of the main executable.

Hardcoded Offsets: A simple, but prone to breaking, method is to just use hardcoded offsets. This is an extremely basic and easy method to use but it does not generally 'survive' updates when the DLL has been modified as code will generally shift around depending on what was updated, which will break your offsets. (This is generally only useful for things that either no longer get updated, or update very infrequently that redoing offsets isn't a hassle.) To do this, you can simply locate the desired function you wish to patch in a disassembler/debugger/etc. and calculate the address offset from where the start of what you wish to patch is located and the start of the DLL itself. (Note that this assumes you're patching static memory within the DLL and not allocated/dynamic code.)

As an example, you can load the desired DLL in a tool like IDA which will generally load the DLL with a pseudo base address of 0x10000000. Then simply find the function you wish to patch and use that address in the following calculation:
(func_address - base_address) = offset

Then when you wish to patch the function inside of the process after the DLL has loaded, you can simply do the reverse calculation:
(base_address + offset) = func_address

You can obtain the base address of the DLL using an API such as GetModuleHandleA / GetModuleHandleW or similar. (There's a ton of ways to get the base address of a module if you can't use API calls as well.)

Pattern Scans: Another method that is less prone to breaking between updates is to create a pattern of data to scan for based on the bytecode used for the actual instructions of the function. Doing this will allow you to just scan for the function in each section of memory of the process until its found. This is useful for things that update frequently and shift code around but also where the code of the function you are looking for does not change often/at all.

In your second screenshot you showed a jump you are likely looking to patch. Using that same code you can make a pattern such as:
66 85 C0 ?? ?? 45 33 C9 48 ?? ?? ?? ?? ?? ?? 45 33 C0 33 C9 FF

Then you can use any number of means to scan for that pattern within the entire process memory space. (You can use various API to walk all the available memory regions of the process such as 'VirtualQuery' or specifically only look for the pattern in the actual DLLs memory space by again obtaining its base address first and combining it with an API call like VirtualQuery to only walk that modules own pages while scanning.

From that you can take the starting address the pattern was found, add the difference to skip over the starting junk in the pattern, in this case 3 bytes to get to the 'je' instruction and apply you patch as needed.


There's a ton of other ways to approach this, but this is two common/simple ways to do it.