write loader with memory hooker
 

hi



I have an exe file that is locked with a Rocky 4 dongle
And I have to write a loader to crack it

There is also a dll file that is locked and the exe file is not packed

this dll file packe with : x64 Themida / Winlicense v3.0.0.0 - 3.1.3.0 ( PACKED mode )

The only problem I have is that the offset changes every time and I don't know how to write a loader

Basically, it should be inside the sections of the dll file, but I don't know why it is like this
please guide me



After loading kernel32.ReleaseMutex, the codes I want will be displayed (pic 3)

https://forum.tuts4you.com/uploads/m...06c4783ba8.mp4

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.

If you have a sample code, or if possible, give an example because I didn't fully understand
I can't do anything about this problem

the memory address is not in the memory space of the executable PE file
stack memory/private memory airspace

Because it is loaded in the address of the private memory and it cannot be found and the address changes every time

The PE file does not describe the entire memory space of an executable. It only contains the data required to execute a program, and the OS keeps the right to add additional regions without the user's awareness.
For example...Things such as the heap, the stack and other internal memory regions required for a process to function and operate are not the responsibility of a PE file (or any executable file for that matter).

A PE doesn't define a heap, it requests a heap to be allocated for it from the OS (AllocateHeap is a Windows API that does that). There's no need to actually eat up space for a heap "placeholder" in the PE file. The same goes for the stack, the PEB, and other memory objects a process has.

Additionally, a user(i.e. programmer) does not usually need to even call AllocateHeap for it's process to have a heap. OSes usually allocate a default heap for the process when loading it (either by the loader itself or by startup code the OS runs before control is given to the PE's Entry Point). Other times the compiler prefixes the code with code that allocates a heap.

So check all those other locations too.

Wrong. Tyro detected. Microsoft literally since they made PE file format let's you control the size of both the stack and the "local heap" right in the PE optional header towards the start of the file.

Certain aliases giving bad information doesn't surprise me ;)

@Ayumi's answer seems to be from here:
The answer is right but additional point to add:
The sizes are defined explicitly by the PE file. Only the location in memory is up to the OS.

It is outside space dll file
The main problem is that it is changing in the external private memory and the address every time

@mcr4ck can you send target ?