Duda sobre ejecutables

Iniciado por Tinkipinki, 22 Septiembre 2011, 20:16 PM

0 Miembros y 2 Visitantes están viendo este tema.

Tinkipinki

Hola a todos:
No se si este sera el foro adecuado para esta consulta pero bueno lo intentamos.

En un ejecutable quien decide todos los parametros de Image Base, Entry Point,
o sea , todos los parametros que podemos ver en el LordPE.
Mi duda es si todo debe seguir estas diractrices, o sea que fuera una configuracion estandard y que por ejemplo yo no pudiera tener un programa con una ImageBase por ejemplo en 00003000 en vez de 00400000.
Otra pregunta seria quien decide las direcciones de memoria a las que debe ir el programa al cargarse en la memoria, o sea las direcciones de memoria que nos aparecen al hacer un dump del programa.

Saludos

Shaddy

Cita de: Tinkipinki en 22 Septiembre 2011, 20:16 PM
Hola a todos:
No se si este sera el foro adecuado para esta consulta pero bueno lo intentamos.

En un ejecutable quien decide todos los parametros de Image Base, Entry Point,
o sea , todos los parametros que podemos ver en el LordPE.
Mi duda es si todo debe seguir estas diractrices, o sea que fuera una configuracion estandard y que por ejemplo yo no pudiera tener un programa con una ImageBase por ejemplo en 00003000 en vez de 00400000.
Otra pregunta seria quien decide las direcciones de memoria a las que debe ir el programa al cargarse en la memoria, o sea las direcciones de memoria que nos aparecen al hacer un dump del programa.

Saludos

Esos parámetros generalmente vienen definidos por el compilador. Pero los puedes crear a mano, más que parámetros podríamos llamarles reglas.

En primer lugar tenemos la cabecera 'MZ' IMAGE_DOS_HEADER que sería esta:


typedef struct _IMAGE_DOS_HEADER
{
     WORD e_magic;
     WORD e_cblp;
     WORD e_cp;
     WORD e_crlc;
     WORD e_cparhdr;
     WORD e_minalloc;
     WORD e_maxalloc;
     WORD e_ss;
     WORD e_sp;
     WORD e_csum;
     WORD e_ip;
     WORD e_cs;
     WORD e_lfarlc;
     WORD e_ovno;
     WORD e_res[4];
     WORD e_oemid;
     WORD e_oeminfo;
     WORD e_res2[10];
     LONG e_lfanew;
} IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;


Luego ya tienes la de sistemas 'NT' (elfa_new apunta a ella) IMAGE_NT_HEADERS:


typedef struct _IMAGE_NT_HEADERS
{
     ULONG Signature;
     IMAGE_FILE_HEADER FileHeader;
     IMAGE_OPTIONAL_HEADER OptionalHeader;
} IMAGE_NT_HEADERS, *PIMAGE_NT_HEADERS;


Donde:



struct IMAGE_FILE_HEADER

typedef struct _IMAGE_FILE_HEADER
{
     WORD Machine;
     WORD NumberOfSections;
     ULONG TimeDateStamp;
     ULONG PointerToSymbolTable;
     ULONG NumberOfSymbols;
     WORD SizeOfOptionalHeader;
     WORD Characteristics;
} IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER;




typedef struct _IMAGE_OPTIONAL_HEADER
{
     WORD Magic;
     UCHAR MajorLinkerVersion;
     UCHAR MinorLinkerVersion;
     ULONG SizeOfCode;
     ULONG SizeOfInitializedData;
     ULONG SizeOfUninitializedData;
     ULONG AddressOfEntryPoint;
     ULONG BaseOfCode;
     ULONG BaseOfData;
     ULONG ImageBase;
     ULONG SectionAlignment;
     ULONG FileAlignment;
     WORD MajorOperatingSystemVersion;
     WORD MinorOperatingSystemVersion;
     WORD MajorImageVersion;
     WORD MinorImageVersion;
     WORD MajorSubsystemVersion;
     WORD MinorSubsystemVersion;
     ULONG Win32VersionValue;
     ULONG SizeOfImage;
     ULONG SizeOfHeaders;
     ULONG CheckSum;
     WORD Subsystem;
     WORD DllCharacteristics;
     ULONG SizeOfStackReserve;
     ULONG SizeOfStackCommit;
     ULONG SizeOfHeapReserve;
     ULONG SizeOfHeapCommit;
     ULONG LoaderFlags;
     ULONG NumberOfRvaAndSizes;
     IMAGE_DATA_DIRECTORY DataDirectory[16];
} IMAGE_OPTIONAL_HEADER, *PIMAGE_OPTIONAL_HEADER;


Ahora, sobre la pregunta de si necesita estar en la base 0x00400000 la respuesta es: No.

No es necesario, el Sistema Operativo siempre da prioridad al ImageBase, pero en caso de no poder mapearse en esa zona de memoria lo situaría en una página sin reservar.

El caso más fácil de ver son por ejemplo las librerías, la mayoría de ellas intentan mapearse en 0x01000000 pero si te fijas en tu debugger favorito verás que siempre se van alojando de forma contigua.

En cuánto a la última pregunta deberías definir a qué secciones te refieres. Si es a la parte de las secciones (IMAGE_SECTION_HEADER) como ".text"/".data"/etc entonces el header del binario es el que lo define.

Ahora si me preguntas sobre el resto de direcciones quitando las que reservan las librerías tienes las páginas de Stack y contextos (PEB y TEB) en los últimos 100K de los 2GB.

El resto son páginas que se reservan para generar memoria (y devolver heaps).

Un saludo.

"Si buscas resultados diferentes, no hagas siempre lo mismo" (Albert Einstein)

http://abssha.reversingcode.com
http://www.reversingcode.com

Иōҳ

#2
Cita de: Shaddy en 22 Septiembre 2011, 21:46 PM

Luego ya tienes la de sistemas 'NT' (elfa_new apunta a ella) IMAGE_NT_HEADERS:


Error de tipografía es e_lfanew   :laugh:

ohh.. shaddy volvistes por estos lares :P, sin duda un 3lit3...  ;D

CitarAhora, sobre la pregunta de si necesita estar en la base 0x00400000 la respuesta es: No.

No es necesario, el Sistema Operativo siempre da prioridad al ImageBase, pero en caso de no poder mapearse en esa zona de memoria lo situaría en una página sin reservar.

El caso más fácil de ver son por ejemplo las librerías, la mayoría de ellas intentan mapearse en 0x01000000 pero si te fijas en tu debugger favorito verás que siempre se van alojando de forma contigua.

Si no me equivoco a la hroa de linkear puedes cambiar eso...


CitarAhora si me preguntas sobre el resto de direcciones quitando las que reservan las librerías tienes las páginas de Stack y contextos (PEB y TEB) en los últimos 100K de los 2GB.

El resto son páginas que se reservan para generar memoria (y devolver heaps).

Aparte de lo que te dijo Shaddy:

Cada programa tiene sus 4GB  de memoria en el espacio de direcciones, eso no quiere decir que ocupen 4gb de memoria física, si no que el programa puede direccionar cualquier dirección en ese rango.

Nox.
Eres adicto a la Ing. Inversa? -> www.noxsoft.net

Tinkipinki

Gracias Shaddy y Иōҳ por vuestras respuestas.
Con esto ya me queda mas claro lo del mapeado de la memoria.
Mi duda era si podia generar un programa con las abeceras bien definidas pero mapeado en unas direcciones fura de las que se usan por costumbre y claro esta, que luego el procesador lo entendiease y el programa funcionara.
Sabiendo que estos parametros los puedo definir en el linkador ya puedo hacer pruebas.

Saludos

Shaddy

Cita de: Иōҳ en 23 Septiembre 2011, 00:22 AM
Aparte de lo que te dijo Shaddy:

Cada programa tiene sus 4GB  de memoria en el espacio de direcciones, eso no quiere decir que ocupen 4gb de memoria física, si no que el programa puede direccionar cualquier dirección en ese rango.

Nox.

Bueno, eso en realidad no es cierto. En arquitecturas x86 (32-Bit) el máximo de memoria virtual por proceso son 2 GB (0x00000000-0x7FFFFFFF).

Cita de: Tinkipinki en 23 Septiembre 2011, 05:23 AM
Gracias Shaddy y Иōҳ por vuestras respuestas.
Con esto ya me queda mas claro lo del mapeado de la memoria.
Mi duda era si podia generar un programa con las abeceras bien definidas pero mapeado en unas direcciones fura de las que se usan por costumbre y claro esta, que luego el procesador lo entendiease y el programa funcionara.
Sabiendo que estos parametros los puedo definir en el linkador ya puedo hacer pruebas.

Saludos

Puedes definirlos en el 'linker' o puedes definirlos a mano, como ya te dije ImageBase lo puedes cambiar manualmente.

Un saludo.
"Si buscas resultados diferentes, no hagas siempre lo mismo" (Albert Einstein)

http://abssha.reversingcode.com
http://www.reversingcode.com

Иōҳ

Cita de: Shaddy en 23 Septiembre 2011, 09:05 AM
Bueno, eso en realidad no es cierto. En arquitecturas x86 (32-Bit) el máximo de memoria virtual por proceso son 2 GB (0x00000000-0x7FFFFFFF).


Iczellion  me angaño ._.

En mi experiencia tocando juegos, llege a encontrar direcciones 0xEXXXXXXX, y tomando aquellas para hacer uno que otro cheat...

Entonces a leer a Iczellion, no dude en creerle  :-\

Nox.
Eres adicto a la Ing. Inversa? -> www.noxsoft.net

Shaddy

Estarías en un entorno de 64-Bit o expresamente configurado para que el kernel tenga sólamente 1 GB. Aunque ya te digo que muy raro sería ;).

Un saludo.
"Si buscas resultados diferentes, no hagas siempre lo mismo" (Albert Einstein)

http://abssha.reversingcode.com
http://www.reversingcode.com

Иōҳ

#7
Vale, lo entiendo, yo pensaba que este temilla estaba totalmente correcto en mi cabeza, luego vienen y te dicen que no XD

:laugh:

Pero en arquitecturas x64 entonces, tienen 4gb de memoria en el espacio de direcciones?
Nox.
Eres adicto a la Ing. Inversa? -> www.noxsoft.net

.:UND3R:.

#8
Leyendo un estudio de PE me topé con esto:
Sick Troen:
Citar•   Magic  0B 01 ; esto nos dice que es un PE32, a diferencia del 0B 02 que es el PE32+ (estas limitan nuestra imagen hasta 4gb!).

PE32 32 byte y el de 64 comentan que el límite es de 4gb

Optional Header
campos estandar
MagicNumber:puede ser P32 o P32+

la diferencia:

CitarThe PE32 format stands for Portable Executable 32-bit, while PE32+ is Portable Executable 64-bit format.

Saludos

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

Shaddy

Cita de: Иōҳ en 24 Septiembre 2011, 00:36 AM
Vale, lo entiendo, yo pensaba que este temilla estaba totalmente correcto en mi cabeza, luego vienen y te dicen que no XD

:laugh:

Pero en arquitecturas x64 entonces, tienen 4gb de memoria en el espacio de direcciones?
Nox.

No, en x64 tienes hasta 256 TeraBytes ;).

Un saludo.
"Si buscas resultados diferentes, no hagas siempre lo mismo" (Albert Einstein)

http://abssha.reversingcode.com
http://www.reversingcode.com