Foro de elhacker.net

Hola

De siempre he tenido entendido que el VirtualSize debía ser menor que el RawSize, que el RawSize debía ser múltiplo del FileAlignment y que la diferencia debía estar rellenada con ceros.

Por ejemplo, si un ejecutable tiene FileAlignment 10 y una sección tiene un VirtualSize = 22 el RawSize debería ser 30 y que los últimos 8 bytes de la sección deberían ser ceros.

Y siempre lo he visto así en los exe's generados por el compilador, pero hoy me he puesto a añadir una sección con el Stud PE y para añadirla me pedía únicamente VirtualSize y RawSize, yo he puesto un RawSize múltiplo del FileAlignment (aunque si no es múltiplo funciona igual) y mi sorpresa es que cuando añado el VirtualSize (menor que el RawSize) me dice que tiene que ser mayor  :o :o

Si lo pongo el exe funciona, de hecho si luego lo dejo menor peta, pero por que hay que hacerlo así?? no le veo sentido, si yo quiero introducir código en esa sección no puedo meter más código del que entra, que es lo que me están diciendo....

Vamos, supongamos que quiero hacer una sección nueva que contendrá 15 bytes, si el FileAlignment es 10 el RawSize debería ser 20, pero no me deja, me obliga a poner un RawSize = 10... y donde meto yo los 5 bytes restantes???

A ver si alguien puede aclararme esto..
Salu2

bueno, que yo sepa, el RawSize es lo que ocupa cada sección en el archivo incluyendo los ceros. y el VirtualSize es lo que ocupa una vez cargado en la memoria ram.

Hacker_Zero izo un code para ampliar una sección (http://foro.elhacker.net/analisis_y_diseno_de_malware/virus_metamorph_v10_beta-t252898.15.html), igual te sirve

Claro, pues por eso mismo, no entiendo el por qué de que el virtual size sea mayor que el raw size, ampliar una sección ya se...

Tu mismo lo has dicho:

Como vas a tener más código cargado en la ram del que puedes almacenar en disco? xDDD

Pos yo siempre había entendido que el VirtualSize tiene que ser mayor o igual que el RawSize. Si sobra VirtualSize, el sobrante se rellena de 0's al cargarse en memoria . Lo que no creo que se pueda es menor, entonces no cogería el código en memoria   :P.

Saludos

PD: Es más, los redondeos que hacen los compiladores siempre redondean más largo el VirtualSize que el RawSize.

ya, si se que no tiene logica lo de ese programa.

Pon la descarga de un exe, uno que este como deberia ser y otro como te dice el programa que tiene que ser. y asi miro la diferencia

Saludos

edit:

Yo cuando miro un exe la virtualsize es donde acaban los datos y empiezan los zeros.
y la RawSize donde empieza la siguiente

la raw size tendria que ser el tamaño real (de codigo en bytes) que contiene la sección, y la virtual una vez alineada y tendria que ser superior a la raw size por el tema de redondeos.

Esto es un exe compilado con VC++, las dos primeras secciones son del compilador, la última se la he añadido con el stud pe:

Si el VirtualSize es menor me dice que aplicación Win32 no válida, lo cachondo del asunto es que si le añado una sección con un código mío (que por defecto deja el virtual size a cero)
http://e0n-productions.blogspot.com/2008/10/aadiendo-una-seccin-un-ejecutable.html

Luego puedo aumentar el VirtualSize, pero siempre menor al RawSize, podéis probarlo :P Y bueno, ya como gran colofón si amplio una sección a mano el VirtualSize tengo que dejarlo mayor para que funcione....

En fin, alguna explicación? xDDD

---

Te me has adelantado ctlon:

No se supone que es siempre al revés??? Las dos primeras secciones de la foto desde luego lo respetan y las ha añadido el compilador...

misterios del win. xD

La añadida es la ultima o algo asi?

Saludos

PD:Yo prefiero poder comparar las diferencias y hacerle pruebas que ver imágenes

si siempre te dice que necesita ser menor, a ver si el sizeofimage tendra algo que ver. prueba aumentandolo.

Curioso, al hacer los dos exe's he caído en que sería buena idea usar la función "compara" (muy útil por cierto) y he visto la diferencia entre los dos, aquí los dejo tal cual:
http://rapidshare.com/files/231186043/exes.zip.html


Al hecho a mano le he añadido una sección de 0x1000 bytes (RawSize = 0x1000) al creado con el stud pe también le he puesto un RawSize = 0x1000 peeeero al ser el VirtualSize = 0x1001, es decir, mayor, aunque al exe le añade 0x1000 bytes el size of image es 0x1001 bytes mayor...

Creo que ya he entendido por que, a la hora de crear la nueva sección el program te da dos opciones, la primera es llenar la sección con ceros, y la segunda cargar la sección desde otro exe, al darle al rellenarla con ceros y leyendo la documentación oficial...

Todo arreglado xD Ahora si entiendo el por qué  ;D

Y básicamente el raw_size es el tamaño exacto en el ejecutable, en bytes, y el virtual size tiene que ir alineado porque se alojará en la sección, pero que si... por eso no puede meter menor Virtual Size que sus bytes del fichero, se descuarenjaría todo...

Shaddy.

RawSize es el tamaño real de los bytes que hay en disco, es decir, el número de bytes que hay en la sección que te marca.
Si un exe tiene un PE header correcto, pues podrías sumar todos los RawSize de cada sección (incluída la del encabezado) y te tiene que dar exactamente lo que pesa el ejecutable.

Tanto los "Raw" como los "Virtual" se alinean en distintos tamaños, y eso nos lo da:
Section Alignment y File Alignment. Por ejemplo en esta imagen de un programa que hice:


El VirtualSize es el tamaño virtual de la sección cuando la tengas cargada en memoria.
Por ej. en el caso anterior, si ves la sección .text tiene un RawSize de 4E00 bytes, es decir, tiene realmente 4E00 bytes, sin embargo, tiene un VirtualSize de 4DF0.

Normalmente algunos compiladores, como tienen que alinear con File Alignment pues rellenan toda la sección (Raw) hasta completarla.
Fíjate, en este caso el código llega exactamente hasta 4DF0 y lo puedes ver en un desensamblador:(ImageBase: 400000 + 1000 + 4DF0 = 405DF0)


Pero como hay que alinear en el disco de 200 en 200 (File Alignment)pues hay que llegar a 4E00.

Y así queda cargado en memoria:

Ok ok gracias, si ya entendía lo que era cada uno, lo que no entendía es por que podía ser el VirtualSize mayor que el RawSize, pero vamos a ver...


No habíamos quedado (según acaba de contar Karmany) en que el RawSize debía ser mayor y ser el que tiene que estar alineado con el FileAligment?? El VirtualSize, que yo sepa y según cuenta MS:

No tiene que ir alineado con nada... Y un claro ejemplo es el exe de karmany, el VirtualSize no es múltiplo de nada  :huh:

Virtual Size puede ser menor y mayor que Raw Size.

En determinados ejemplos es muy fácil saber porqué. Fíjate en un UPX cualquiera, sus secciones pueden ser las siguientes:

File Alignment: 200
Section Alignment: 1000

1ª sección: UPX0
Virtual Size = 5000 mientras que el Raw Size es ¡cero!
¿Qué ocurrirá? Pues que cuando se cargue en memoria la sección UPX0 tendrá un tamaño de 5000 bytes y será rellenada de ceros.

Fíjate en la segunda: UPX1
Un UPX es muy sencillo saber cuándo salta al OEP, así que me voy a poner en el salto después de descomprimirse:


A partir de ahí son todo 0. Como se observa el Virtual Size son 1000 bytes pero el Raw Size son 400 entonces... ¿Qué pasa con esos C00 bytes? Pues que son rellenados con ceros.
Se puede poner el Virtual Size a 400 y será correcto también, porque como Section Alignment es 1000 en memoria la sección será de un tamaño = 1000 bytes.



Ahora vamos a ver lo contrario:

Un caso lógico que hace por ejemplo Topo es el siguiente:

Código real: 6 bytes
File Alignment: 10 bytes

Por lo tanto podríamos tener una sección con Raw Size = 10 bytes, pero realmente son 6, aunque por File Alignment le ponemos 10. La sección podría ser la siguiente:

Tampoco veo yo que te tenga que marcar ese error. Es que no te lo tiene que dar.

Mira, de todos modos te recomiendo que uses el programa Topo 1.2 para añadir secciones y ese problema ya no te lo marcará.
También te comento que los antivirus dan a Topo 1.2 como virus, así que tendrás que modificarlo.

Un saludo

Oks muchas gracias ya he entendido el funcionamiento y por qué no me funcionaba si ponía un VirtualSize mayor (por el tema del SizeOfImage).

Muchas gracias  ;-)