Pregunta Deshabilitar ASLR

Iniciado por dRak0, 7 Agosto 2014, 00:00 AM

0 Miembros y 1 Visitante están viendo este tema.

dRak0

¿Si modifico el OPTIONAL_HEADER , el DLL_CHARACTERISTICS exactamente , quedaria deshabilitado totalmente el ASLR del binario?

PD:Estoy hablando del formato de binario PE.
PD2:Si , ya lo comprobe , queda deshabilitado.
Saludos!

------------------------------------------

Consulta 2

Tengo lo siguiente:


#include <stdio.h>
#include <windows.h>

int main(int argc,char**argv)
{
PIMAGE_DOS_HEADER dosHeader;
PIMAGE_NT_HEADERS ntHeader;
HANDLE handleArchivo,mapeadoArchivo=NULL;
LPVOID direccionMapeado=NULL;
char nombreArchivo[MAX_PATH];

printf("Ingrese el archivo:");
scanf("%s",nombreArchivo);

/*
HANDLE WINAPI CreateFile(
 _In_      LPCTSTR lpFileName,
 _In_      DWORD dwDesiredAccess,
 _In_      DWORD dwShareMode,
 _In_opt_  LPSECURITY_ATTRIBUTES lpSecurityAttributes,
 _In_      DWORD dwCreationDisposition,
 _In_      DWORD dwFlagsAndAttributes,
 _In_opt_  HANDLE hTemplateFile
);
*/

handleArchivo=CreateFile(nombreArchivo,GENERIC_READ,0,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,NULL);
if(handleArchivo==INVALID_HANDLE_VALUE)
{
printf("\n%s\n","Error!");
return 0;
}
/*
HANDLE WINAPI CreateFileMapping(
 _In_      HANDLE hFile,
 _In_opt_  LPSECURITY_ATTRIBUTES lpAttributes,
 _In_      DWORD flProtect,
 _In_      DWORD dwMaximumSizeHigh,
 _In_      DWORD dwMaximumSizeLow,
 _In_opt_  LPCTSTR lpName
);
*/


mapeadoArchivo=CreateFileMapping(handleArchivo,NULL,PAGE_READONLY,0,0,NULL);
if(!mapeadoArchivo)
{
printf("\n%s\n","Error!");
return 0;
}

/*
LPVOID WINAPI MapViewOfFile(
 _In_  HANDLE hFileMappingObject,
 _In_  DWORD dwDesiredAccess,
 _In_  DWORD dwFileOffsetHigh,
 _In_  DWORD dwFileOffsetLow,
 _In_  SIZE_T dwNumberOfBytesToMap
);

*/

direccionMapeado=MapViewOfFile(mapeadoArchivo,FILE_MAP_READ,0,0,0);

dosHeader=(PIMAGE_DOS_HEADER)direccionMapeado;

printf("\n%x MZ , PE Header offset :0x%x\n",dosHeader->e_magic,dosHeader->e_lfanew);

ntHeader=(PIMAGE_NT_HEADERS)(direccionMapeado+dosHeader->e_lfanew);

printf("PE SIGNATURE:%x Machine:%x",ntHeader->Signature,ntHeader->FileHeader.Machine);
printf("\nDireccion Mapeado:%x   ImageBase:%x",direccionMapeado,ntHeader->OptionalHeader.ImageBase);


char a[MAX_PATH];
scanf("%s",a);

}



Funciona lo mas bien , no tiene mucha vuelta. Mi pregunta es , ¿porque la direccion de mapeado es diferente al ImageBase?Segun tengo entendido el ImageBase es la direccion que le indicamos al loader donde empezar a mapear.La unico que se me viene es que justo haya estado ocupado ese lugar y el loader haya asignado otra direccion. Aclarenme esto.
Gracias

karmany

Parece ser que la Image Base la estás obteniendo del PE header del archivo mapeado.
Observa el archivo que estás abriendo en tu código, y ábrelo con un editor de PE Header, comprueba el valor de la Image Base y creo que es la misma que te da tu código del archivo mapeado.

Luego la dirección de mapeo es la dirección virtual que te da MapViewOfFile (If the function succeeds, the return value is the starting address of the mapped view.)

dRak0

Que tal karmany?

Mira , lo que hago es :

Tengo un binario con formato PE.
Lo abro con un editor hexadecimal o alguna tool que me facilite la lectura de los encabezados PE.
Voy a OPTIONAL_HEADER , Obtengo el valor del ImageBase.

Ok. Suponole que es 0x00400000.

Entonces , se supone que el Loader , va a buscar en el encabezado este valor y tratara de cargarlo en esa Direccion de Memoria Virtual. Todo ok hasta aca.

Entonces , solo de curioso , me puse a ver si conseguia obtener este header desde memoria. Ok.
Abro archivo . CreateFile()
Mapeo.CreateFileMapping()
Dame La direccion del mapeo.. MapViewOfFile()

La duda es: Esa direccion de mapeo ,¿es la direccion donde se encuentra el DOS_HEADER en memoria?Si asi lo es , tendria que ser igual al ImageBase.

Voy a probar con varios , quizas , esa direccion (ImageBase) justo estaba ocupada y el loader tuvo que cargarlo en otro lugar.Segun recuerdo el ImageBase es la direccion virtual de preferencia, pero puede que este ocupada y se cargara en otro lugar.


Pregunta 2:

Toy tratando de hacer algo parecido en un proceso remoto.¿Alguna idea?

Yo pense en algo asi:

OpenProcess() ->Obtengo handle del proceso.
Aca el problema , ¿Como obtener la ubicacion exacta donde esta cargado el binario en memoria?

Se me habia ocurrido checkear el archivo en disco , buscar el ImageBase , y apartir de ahi hacer un ReadProcessMemory , si existe el MZ es que estamos bien ubicados.
Igual la idea es hacerlo sin abrir el archivo en disco.

Bueno Una vez obtenido la posicion inicial , ya se donde esta todo el resto.Hago un WriteProcessMemory y listo.

MCKSys Argentina

#3
Hola!

Por la 1er pregunta: Si abres el ejecutable con CreateFile, para qué necesitas hacerle Filemapping? Basta con ir hasta el offset donde esta el campo ImageBase y leerlo.

Ahora, si el ejecutable no tiene ASLR, entonces SIEMPRE se cargará en la dirección establecida por la ImageBase. Esto es por algo muy sencillo: NO existe NADA en memoria al momento en que el loader carga el ejecutable. Por eso, siempre se cargará en esa dirección (como dije antes, si no tiene ASLR).

Lo anterior responde también tu segunda pregunta, si el ejecutable no tiene ASLR...  ;)

Saludos!
MCKSys Argentina

"Si piensas que algo está bien sólo porque todo el mundo lo cree, no estás pensando."


dRak0

Gracias por las aclaraciones.

¿Tenes idea como llegar hasta el ImageBase desde memoria?(Aclaro:Sin fijarme en el archivo del disco duro)

MCKSys Argentina

Con GetModuleFileNameEx sacas el path del exe y luego lo parseas en disco.

Si no quieres leer del disco, vas a tener que usar cosas como GetProcessWorkingSetSize y otras hierbas parecidas.

Revisa la MSDN para ver las APIs disponibles acerca de procesos.

Saludos!
MCKSys Argentina

"Si piensas que algo está bien sólo porque todo el mundo lo cree, no estás pensando."


.:UND3R:.

A mi se me ocurre tomar un patrón como la cabecera P32 "mz" y luego desplazarse hasta el campo de ImageBase.

Solicitudes de crack, keygen, serial solo a través de mensajes privados (PM)

dRak0

#7
Pense igual que vos UND3R pero... podes encontrar muchos MZ , como identificas si es una dll o tu programa?Hay varios en un mismo proceso.

Offtopic:http://www.patterndiagnostics.com/Training/Accelerated-Memory-Dump-Analysis-Version3-Public.pdf Mirenlo esta interesante.

.:UND3R:.

Puedes diferenciarlo sabiendo que las dll poseen una dirección a una tabla llamada Export Table Address:

http://win32assembly.programminghorizon.com/pe-tut7.html

No sé si serviría, pero la idea es más o menos así, ir encontrando patrones tras patrones.

Saludos

Solicitudes de crack, keygen, serial solo a través de mensajes privados (PM)

x64core

Cita de: »®et2lib©« en  8 Agosto 2014, 16:19 PM
Gracias por las aclaraciones.

¿Tenes idea como llegar hasta el ImageBase desde memoria?(Aclaro:Sin fijarme en el archivo del disco duro)

Con GetmoduleHandle pasando valor cero, MSDN

Cargar un ejecutable es distinto de mapearlo, si el ejecutable es cargado y tiene directorio de relocalización entonces Windows
cambiara algunos valores de la imagen en memoria, como por ejemplo IMAGE_NT_HEADER.ImageBase.

Si el ejecutable es mapeado y tiene directorio de relocalización tambien se cambiará IMAGE_NT_HEADER.ImageBase, la dirección
retornada por MapViewOfFile es la misma, no se resuelven los directorios, etc. Pero si ejecutable no tiene el directorio entonces
Windows comprueba si el archivo se puede mapear en IMAGE_NT_HEADER.ImageBase sino es una diferente y el valor en
IMAGE_NT_HEADER.ImageBase no es cambiado.

Es como dijo karmany pero nadie hizo caso, o mejor dicho nadie entendío lo que dijo ya que no lo sabian.