[TUTORIAL] dwGetModuleBaseAddress aka GetModuleBaseAddress

  • Hola Invitado ¿Quieres conversar con todos los usuarios de GamerzHacking?, No esperes mas y entra al canal de Discord dando clic AQUI
  • Hola Invitado ¿Tienes una Web y quieres ser partner de GamerzHacking?, No esperes mas y entra al siguiente enlace AQUI
  • Hola Invitado ¿Quieres formar parte del Staff de GamerzHacking?, No esperes mas y entra al siguiente enlace AQUI
  • Hola Invitado ¿Eres programador y quieres pertenercer GamerzHacking?, No esperes mas y entra a postular aqui AQUI
1 dAmerica/Bogota Noviembre dAmerica/Bogota 2015
1.063
175
63
27
Lima
gamerzhacking.com
#1
Hola amigos de GamerzHacking,

Como sabrán todos los archivos .exe y .dll cuando se cargan en la memoria se denominan con el nombre de "módulos". Cuando se agrega direcciones en tu lista de trampas en el Cheat Engine, y especialmente cuando se utiliza punteros (pointers), a menudo encontraras la dirección de esta forma.

1537570702344.png

Posiblemente también lo veas de esta forma "server.dll + 00123ABC". Esto esta utilizando un offset relativo de la dirección del modulo. También ver si una dirección + offset se ve como cierto modulo, si en caso no lo observas de esa manera, tienes que habilitarlo de la siguiente manera.

1537571459134.png

Luego en el View Memory, usa el "Go to address" a la dirección. Independientemente de si se trata de datos o códigos. esto te dirá que el modulo esta con offset. Para ver todos los módulos cargados por el proceso en Cheat Engine y ver las direcciones. haz lo siguiente.

1537571665063.png

También puedes usar el Dissect PE headers para ver mas información relativa.

1537571753823.png

MZ-Start es la dirección del módulo tal como está actualmente cargado en la memoria. "Prefered ImageBase" se analiza directamente desde el header PE y es la ubicación en la que prefiere cargarse. Si esta dirección de memoria ya está tomada, se re ubicará. Cuando se ejecuta un .exe, el cargador de Windows crea un proceso para él y le da su propio espacio de memoria virtual. El cargador carga el ejecutable en la memoria y luego cualquier .dlls que el proceso llama. El header PE para el .dll, define una dirección ImageBase. El cargador de Windows intentará cargar el .dll en el espacio de la memoria virtual del proceso que lo requiere. Si ese espacio ya está ocupado, se cargará en una ubicación diferente. Si esto sucede, las direcciones de nuestros códigos no funcionarán.

Ahora digamos que tenemos un puntero:
ac_client.exe + 109B74

Ahora, la ImageBase extraída del header PE de ac_client.exe es "00400000". Solo podemos tener un ejecutable para cada proceso que es un espacio de memoria vacío hasta que se cargue ac_client.exe. No hay nada que bloquee la carga de ac_client.exe en su ImageBase. Entonces, la dirección base de un .exe es siempre la misma. El ÚNICO momento cuando no se carga un .exe en la base de imágenes almacenada en los encabezados PE es cuando ASLR (aleatorización de diseño de espacio de direcciones) está habilitado en el sistema operativo y el indicador DynamicBase está configurado para permitir que el sistema operativo aleatorice la dirección virtual del módulo .

Podemos evaluar esto antes de colocarlo en el código.

ac_client.exe + 109B74
00400000 + 109B74
509B74

Esta es la definición de una dirección estática, puede ser relativa a la dirección base de un ejecutable en el binario en el disco, pero siempre está estática en la memoria después de que se han producido las re ubicaciones.

Pero para .DLL que se puede re ubicar:

"server.dll + 004EE83" funciona en Cheat Engine porque Cheat Engine evalúa la dirección de server.dll. Cheat Engine obtendrá la dirección de server.dll y la reemplazará con la dirección en la que se carga el módulo. Entonces digamos que la dirección del módulo server.dll es 0x10000000, cheat Engine evaluará:

server.dll + 004EE83
0x10000000 + 004EE83
1004EE83

La evaluación anterior se realiza porque Cheat Engine se está ejecutando.

Pero cuando intenta utilizar esto en un entrenador externo, debe evaluar "server.dll" + 004EE83 usted mismo. Hay varias maneras de hacerlo y discutiremos uno de ellos ahora. Para hacer esto externamente, puede usar esta función que se ha usado amplia mente con el nombre dwGetModuleBaseAddress.

Básicamente utiliza la API de Windows CreateToolhelp32Snapshot para obtener una instantánea de todos los módulos cargados para el proceso dado, luego itera por todos los módulos cargados y encuentra el módulo con el nombre del módulo que le asignas. Devuelve un uintptr_t a la dirección del módulo. Ingresa el ID de proceso y el nombre del módulo y muestra la dirección del módulo. Debe configurar su proyecto en UNICODE para que esto funcione; si no es un novato, puede cambiarlo fácilmente para que funcione con MBCS.

Funcion:

C++:
//Place this anywhere in the global namespace
#include <windows.h>
#include <TlHelp32.h>

uintptr_t GetModuleBaseAddress(DWORD procId, const wchar_t* modName)
{
    uintptr_t modBaseAddr = 0;
    HANDLE hSnap = CreateToolhelp32Snapshot(TH32CS_SNAPMODULE | TH32CS_SNAPMODULE32, procId);
    if (hSnap != INVALID_HANDLE_VALUE)
    {
        MODULEENTRY32 modEntry;
        modEntry.dwSize = sizeof(modEntry);
        if (Module32First(hSnap, &modEntry))
        {
            do
            {
                if (!_wcsicmp(modEntry.szModule, modName))
                {
                    modBaseAddr = (uintptr_t)modEntry.modBaseAddr;
                    break;
                }
            } while (Module32Next(hSnap, &modEntry));
        }
    }
    CloseHandle(hSnap);
    return modBaseAddr;
}
Llamada la funcion:

C++:
uintptr_t serverdllBaseAddress = GetModuleBaseAddress(ProcId, L"server.dll");
Puede obtener más información sobre ToolHelp32Snapshot:
Taking a Snapshot and Viewing Processes (Windows)
Traversing the Module List (Windows)

Creditos
[GH]Rake
 
Última modificación: