Mensajes

Has sido bastante malévolo... 

No creo que haya mucha gente que sepa a qué enfrentarse, así que me veo casi en la obligación de mostrar a los usuarios a qué se enfrentan ya que es algo no normal.

Muchas gracias por el crackme, a ver si alguno se anima a resolverlo.

Un detector de packer me ha mostrado lo siguiente:

Espero que os ayude.

[CRACKME: Inocent Crackme por Invisible_Hack]

CRACKME: Inocent Crackme por Invisible_Hack

Autor: Invisible_Hack
Nombre: Inocent Crackme
Fecha: 17 de mayo de 2009
Tamaño: 20 KB
Compilador y/o Packer: Visual Basic 6.0 código nativo
Objetivos:
    Conseguir la clave correcta.
Dificultad: 0-1 (1-10), es muy sencillo.
Descarga del crackme:
mismo link
Post Original:
http://foro.elhacker.net/ingenieria_inversa/inocent_crackme_by_invisiblehack-t255079.0.html
Tutorial con la solución:
-

[me comprometo]

Eso te ocurre normalmente porque te encuentras en una zona Virtual, es decir, que no estás en la zona donde has insertado el código.
Fíjate:
En este programa la ImageBase = 400000 y la primera sección es la siguiente:

Código [Seleccionar] Expandir

Nombre      Virtual Offset     Virtual Size     Raw Offset     Raw Size
.text             00001000         00000076       00000400     00000200

Viendo esa sección: ¿Cuál es la última dirección en donde puedes escribir? ¿Dónde acaban los bytes y dónde empieza la zona virtual?
Pues es muy sencillo fíjate:
-Realmente hay 200 bytes de código en la sección .text
-Al cargarlo en memoria te aparecerán 1000 bytes(Section Alignment) en esa sección.
-Es decir, el último byte que puedes modificar estará en:
00400000 (ImageBase) + 00001000 (Virtual Offset sección .text) + 00000200 = 401200, no puedes escribir después, te dará error. Realmente tienes que restar un byte.

Por lo tanto, si aumentas 100h bytes y te queda así:

Código [Seleccionar] Expandir

Nombre      Virtual Offset     Virtual Size     Raw Offset     Raw Size
.text             00001000         00000076       00000400     00000300

Cuando se cargue en memoria: ¿Dónde se encuentran esos 100h bytes nuevos que has puesto?
-Respuesta: entre 401200 y 401300. Realmente creo que es 4011FF y 4012FF

PD. Mira, como no he visto ningún programa para poder añadir bytes a la última sección, me comprometo desde hoy a hacer un programa para poder hacer todo este trabajo de una sola vez. Así no habrá que añadir bytes ni modificar nada, y con un visor PE se podrán ver los resultados..

Yo tengo ese libro comprado.
Te quiero comentar que ese libro está más destinado a aplicaciones de 16 bits que a 32bits. Es un libro impresionante  pero todos los códigos y ejemplos están a 16 bits y no sé Riki_89D si es realmente lo que buscas.

Claro, es que te estás olvidando de una cosa importantísima que tienes que hacer a mano:
-Añadir físicamente los bytes que has añadido en el PE header. Esto lo puedes hacer fácilmente con el programa Ultraedit: Botón derecho --> Añadir bytes

En principio, sólo con modificar el RawSize de la última sección y añadir con UltraEdit los bytes al final, te tiene que funcionar.
El problema que te puede ocurrir es que superes el valor de Section Alignment con los nuevos bytes que añades. En un primer momento tampoco te tiene que dar problema, porque Windows cuando cargue la aplicación en memoria modificará su Virtual Size y lo aumentará. Sin embargo, te digo lo del problema porque hay un valor que no será modificado y es posible que lo necesites modificar: SizeofImage; SizeofImage es el tamaño total del PE Image en memoria y por eso si pones un valor muy elevado, tal vez tengas que aumentar el SizeofImage. Aumentarlo es muy fácil, simplemente debes examinar el número de bytes que has añadido realmente y el valor de Section Alignment. Modificar SizeofImage va unido a la modificación de Virtual Size.

En tu primer ejemplo que haces, tienes un RawSize = 0000CA00
Le has sumado 200h bytes --> 0000CC00 = nuevo RawSize
Después modificas el valor de SizeofImage. Eso que haces no es correcto del todo, aunque puede valer, ya que el valor de SizeofImage tiene que ser múltiplo de SectionAlingment. En todo caso tendrías que sumarle 1000h bytes. Sin embargo, si te fijas,:
RawSize_original = 0000CA00
RawSize_final = 0000CC00
Como Section Alignment = 1000h no necesitas sumarle a SizeofImage nada ya que:
0000C000(multiplo de 1000h) + 00001000(Section Alignement) = 0000D000 y 0000CC00 no pasa de 0000D000. Esto quiere decir que tus datos nuevos aparecerán en memoria.

Por lo tanto en este ejemplo que has puesto,simplemente con modificar el RawSize y aumentar los bytes con UltraEdit, te tiene que funcionar.


PD. Otra cosa importante que me dejo es que si añades como te he dicho en el párrafo anterior, bastantes bytes y pasan del siguiente múltiplo de Section Alignment (en el ej. anterior sería que RawSize pasara de D000) debes modificar el Virtual Size de la última sección ya que sino cuando se cargue en memoria el programa, tus datos no se verán. Esto es importante.
Y además cuando aumentes el Virtual Size (sobrepasando el siguiente múltiplo de Section Alignment) debes aumentar el SizeofImage(en múltiplo de Section Alignment).

Finalmente si tienes dudas, sube un archivo que quieras y modificamos la última sección.

Yo nunca lo he probado.
Ahí lo tienes:
http://www.ech2004.net/download.php?archivo=213&tipo=h

.. lo que no entendía es por que podía ser el VirtualSize mayor que el RawSize

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:

Código [Seleccionar] Expandir

Nombre      Virtual Offset     Virtual Size     Raw Offset     Raw Size
UPX0              00001000         00005000       00000400     00000000
UPX1              00006000         00001000       00000400     00000400
.rsrc             00007000         00001000       00000800     00000200

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:

Código [Seleccionar] Expandir

00406324  cmp esp,eax
00406326  jne short 00406322
00406328  sub esp,-80
0040632B  jmp 00401000
00406330  db 00...


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:

Código [Seleccionar] Expandir

Nombre      Virtual Offset     Virtual Size     Raw Offset     Raw Size
.sección          00000000         00000006       00000000     00000010

mi sorpresa es que cuando añado el VirtualSize (menor que el RawSize) me dice que tiene que ser mayor

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

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:

[Mayo de 2009 - Página de Shaddy]

Mayo de 2009 - Página de Shaddy

Desde hace un tiempo tenemos disponible la página Web de Shaddy. En un principio podemos acceder a sus fantásticos tutoriales, pero que por contra no son para Newbies.

En él se habla de temas dispares como: explotando vulnerabilidades, scripts en Phyton para desempaquetar, distintas protecciones y hasta el análisis de un driver desde ring3 mediante OllyDBG (hay que prepararlo previamente.).

Unos tutoriales que harán progresar a los que ya tienen unos conocimientos de Ingeniería Inversa.

Su página:
http://abssha.blogspot.com/

[CRACKME: CrackMe1 por hateXlove]

CRACKME: CrackMe1 por hateXlove

Autor: hateXlove
Nombre: Crackme v1
Fecha: 04 de mayo de 2009
Tamaño: 93 KB
Compilador y/o Packer: UPX / Borland C++
Objetivos:
    Conseguir la clave correcta.
Dificultad: ? (1-10)
Descarga del crackme:
mismo link
Post Original:
http://foro.elhacker.net/ingenieria_inversa/crackme2_p33r-t254258.0.html
Tutorial con la solución:
Tutorial en el mismo link realizado por el autor del crackme.