funcionamiento de archivos ejecutables, ( DUDAS )

[-Xenon-]

bueno queria comentar las dudas que tengo, navegando por internet y incluso leyendo tutoriales basicos de asm, no me llega a quedar claro de como un sistema operativo coge un ejecutable y opera con el, asi que os comento:

he puesto este post aqui, por que se que slasher es el puto amo en este tema... de hecho al leer lo que dejaste en el lab, me an asaltado muchas dudas basicas!



pongamos que tenemos un ejecutable compilado, un hola mundo! en vb por ejemplo, hasta donde yo se el archivo en si es un conjunto de 0 y 1, un revoltijo binario

lo que yo creo que se es esto:

el SO, coge el archivo y lo carga en memoria, una vez almacenado en la memoria, empieza a leer el archivo y a ejecutarlo, y cuando termina con el lo borra de la memoria

aqui mis dudas: vamos a ponerle datos al ejemplo

imaginemos que el archivo pesa 100 ( una medida redonda )

segun el esquema de los archivos PE, imaginemos que las diferentes secciones del ejecutable empiezan en:

mz header -----empieza en el 1
real mode ----- empieza en el 15
pe file signature ---empieza en el 20
pe file header ---empieza en el 25
.text secion header ---- 27
.bss secionheader ---29
.rdata secion header ---32
.debug secion header------50
.text secion -------  60
.bss secion  --------70
.rdata secion  -------80
.debug secion  --------90

no se que es cada parte que he puesto, solo le he asignado un numero como suponiendo imaginariamente, que cada una de esas secciones empiezan en ese byte o kilobyte, lo he puesto en decimal y en cifras pequeñas para entendernos mejor, estoy dando tantos pelos y señales para que se me pueda contestar mejor, y entender mejor! sorry si me estiendo mucho!

una vez que se carga todo ese bloque que es el programa en memoria DONDE LEE EL SO?

donde empieza a leer?

desde 1?

por que si aumento manualmente el archivo añadiendo en alguna sección mas tamaño, el archivo queda inservible?

que provoca eso?

en alghuna secion marca que pesa 100 y si ya pesa mas se jode el invento?

si es asi por que no cuando se le mete mas peso a mano, bastaria con cambiar donde especifica que pesa 100 y poner lo que realmente pesa ahora?

donde va el codigo real del programa?

donde las variables?

por que cuando leo esto:
The Portable Executable File Format from Top to Bottom
por que me suena a chino?

soy torpe y lento? o es que me falta de leer algo mas basico para entenderlo?

como puedo saber en el ejecutable donde va cada cosa para poder meterle mano y jugar con el?

ejemplo:

si quiero cambiar la variable donde pone "hola mundo", como puedo buscarla en el codigo compilado y modificarla? sin programas esternos, solo con un editor hexadecimal, ya se como lo haria pero quiero saber en que porcion deberia ir, si la busco segur que la encuentro buscando ala derecha del editor hexadecimal la palabra, pero no entiendo donde va almacenada, no se si me esplico...

bueno seguro que me olvido de preguntar muchas cosas, pero quizas alguien que entienda pueda entender con esto, el nivel que tengo en el tema, y pueda quiarme y recomendarme la lectura de algo QUE PUEDA ENTENDER

gracias un saludo!!

[byebye]

todas las dudas que tienes las tienes contestadas si te lees el formato PE. que no lo entiendas todo a la primera no quiere decir que no lo entiendas a la segunda, lee un poco, practica saca conclusiones y sin prisas.

[-Xenon-]

gracias, lo seguire intentando, es que enseguida me desespero cuando por mas que me esfuerzo no consigo visualizar la lectura y a medida que avanzo, mas se que no se nada.. es un poco estraño

pero se intentara, no queda otro remedio

[Slasher-K]

Por empezar, el tamaño de un ejecutable no puede ser de 100KB porque tiene que ser múltiplo de 8.

Las secciones están alineadas en memoria en un offset que también es múltiplo de 8, y eso es por una cuestión de la arquitectura del microprocesador.

Cuando el loader del sistema operativo carga el ejecutable en memoria crea el thread principal y comienza a ejecutar el código del punto de entrada. El punto de entrada está especificado en el registro AddressOfEntryPoint de la cabecera opcional PE. Ese offset es relativo al inicio del archivo y está dentro de la sección de código (Sección .text)

Todas las secciones están descriptas en las cabeceras de sección, que están justo después de la cabecera opcional PE. Cada cabecera de sección ocupa 42 bytes de datos (no estoy seguro porque no tengo la documentación a mano, pero creo que era eso). Los primeros 8 bytes son el nombre de la sección, que es una cadena terminada en nulo por lo que puede tener un nombre de 7 bytes como máximo, incluyendo el "." (.text, .data)

En las cabeceras de sección están los datos de dicha sección, como el offset relativo al inicio del archivo (RVA o Relative Virtual Address), tamaño, tamaño de los datos crudos, etc. Los datos crudos (raw data) son los datos de la sección en cuestión, excluyendo las tablas que se encuentran en el inicio de la sección.

Si le agrego datos a un archivo queda "inutilizable" porque se desplazan los datos más bytes hacia adelante, por consiguiente cuando el programa busque determinados datos en una posición no los encontrará. En el caso que sea código el programa va a ejecutar instrucciones no válidas y se cerrará.

El código del programa está en la sección .text, que generalmente es la primera y está en el offset 4096 decimal, pero eso depende del linker. Dentro de la sección de código está el punto de entrada, como lo dije anteriormente.

Las variables y datos no inicializados están en la seccíón .data. Para modificar el "Hola mundo" hay que buscar la tabla de cadenas, porque si por ejemplo yo escribo el siguiente código:

Código [Seleccionar] Expandir


Sub Main()
Call MsgBox("Hola mundo")
End Sub


Cuando se compila pone "Hola mundo" en una parte del archivo y en la llamada a MsgBox reemplaza la cadena por la dirección de "Hola mundo".

Ahora tengo poco tiempo y ando sin inet, cuando puedo extiendo un poco más este tema que es muy interesante, pero lo mejor es investigar con un editor hexadecimal (recomiendo mucho el WinHex) y un debugger (OllyDbg).

Leete los siguientes documentos que postee hace un tiempo en el foro de Programación general, pueden ayudarte mucho  a entender cómo trata Windows a los procesos y la memoria.

Administrador de memoria de Win32
Procesos y Subprocesos en Windows

Saludos.

[-Xenon-]

lo de que pese 100 lo decia como ejemplo imaginario

oye muchas gracias!! precisamente fue al leer tu proyecto del laboratorio, cuando vi que poco sabia del tema

gracias una vez mas por tu tiempo