Autor
|
Tema: Pregunta Deshabilitar ASLR (Leído 7,601 veces)
|
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) { 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) { 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]; }
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
|
|
« Última modificación: 7 Agosto 2014, 11:00 am por »®et2lib©« »
|
En línea
|
|
|
|
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.)
|
|
|
En línea
|
|
|
|
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.
|
|
|
En línea
|
|
|
|
MCKSys Argentina
|
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!
|
|
« Última modificación: 8 Agosto 2014, 16:11 pm por MCKSys Argentina »
|
En línea
|
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)
|
|
|
En línea
|
|
|
|
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!
|
|
|
En línea
|
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.
|
|
|
En línea
|
Solicitudes de crack, keygen, serial solo a través de mensajes privados (PM)
|
|
|
dRak0
|
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.
|
|
« Última modificación: 8 Agosto 2014, 16:57 pm por »®et2lib©« »
|
En línea
|
|
|
|
.:UND3R:.
|
Puedes diferenciarlo sabiendo que las dll poseen una dirección a una tabla llamada Export Table Address: http://win32assembly.programminghorizon.com/pe-tut7.htmlNo sé si serviría, pero la idea es más o menos así, ir encontrando patrones tras patrones. Saludos
|
|
|
En línea
|
Solicitudes de crack, keygen, serial solo a través de mensajes privados (PM)
|
|
|
x64core
Desconectado
Mensajes: 1.908
|
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.
|
|
|
En línea
|
|
|
|
|
|