Duda con Tutorial concurso 97 UnPackMe_TPPpack.exe

[.:UND3R:.]

Hola a todos bueno leyendo un poco me encontré con algunas dudas que se me originaron después de leer el tutorial

UnPackMe_TPPpack.exe:
http://ricardonarvaja.info/WEB/CONCURSOS%20VIEJOS/CONCURSOS%202004-2006/CONCURSO%2097/CONCURSO%2097.rar

Tutorial en doc:
http://ricardonarvaja.info/WEB/CONCURSOS%20VIEJOS/CONCURSOS%202004-2006/CONCURSO%2097/C97-N4%20-%20Desempacado%20de%20TPPpack%20-%20por%20marciano.rar

Mis dudas son más que nadas algo teóricas el unpackme anterior tenía las siguientes características:
-stolen byte
-iat destruida
-algunos trucos para evitar ser debuggeado

1)En ese tutorial se llega a los stolen byte directamente, marciano comenta que se copien en un .txt los stolen bytes pero mi duda es al tener todo reparado cuando cuando inserta los stolen bytes, este los inserta en la dirección en donde se detiene
el ollydbg cuando se carga el unpackme (6B010) mi duda es ¿como se logra que al colocarlo ahí los stolen bytes sin anteponerlo al falso OEP (metodo común en donde se cuentan los stolen bytes y se les resta al falso OEP)pese a eso funciona bien?


2)Cuando se termina de colocar los stolen bytes por qué algunos call están alterados y marciano pide reemplazarlos por los call que habíamos anotado en el documento de texto?

Si me aclararan eso se los agradecería demasiado

Saludos

[_Enko]

1)No he depurado el programa, pero por un vistazo rapido del tutorial creo que:
Como en este caso son "stolen kilobytes", es decir, una buena parte del codigo ha sido movida, para el caso, la rutina de inicio.
Entonces, en vez de redirigir el programa a la verdadera rutina de inicio (cambiando EP, por el OEP) que es lo que normalmente se hace, y se colocan los stolen bytes, en este caso, como los stolenbytes no estan "escondidos" sino simplemente movidos a otro lado sin saltos inecesarios, el autor del articulo decidio  mover esos stolen bytes al EP del programa.

Es decir, en vez de buscar el OEP y remplazar alli los stolen bytes, mueve  la rutina inicial (stolen kilobytes) al EP de la ejecutable, es decir, EntryPoint ejecutable empaquetada que ahora fue desempaquetada.


Creo que lo que permitio hacer esto fue que el programador del unpackme, remplazo la rutina inicial de la oep por otra rutina.  Y escondió toda la rutina inicial.
Entonces, marciano colocó la rutina completa en el EP del programa y de seguro que esta rutina inicializa la ejecutable, y luego hacen un salto far o un call far a una direccion de memoria absoluta, por eso el codigo se pudo seguir ejecutando.

2)hablando de saltos absolutos, cambiamos a CALL NEAR. Son saltos a rutinas que se encuentran dentro del mismo segmento del codigo, por ende, su direccion es relativa a la posicion actual. Una call near repetido dos veces nunca tiene el mismo opcode.
ej:

0040102A     E8 1E000000    call    KeyMeNoD.0040104D
0040102F     E8 19000000    call    KeyMeNoD.0040104D
00401034     E8 14000000    call    KeyMeNoD.0040104D
00401039     E8 0F000000    call    KeyMeNoD.0040104D
0040103E     E8 0A000000    call    KeyMeNoD.0040104D
00401043     E8 05000000    call    KeyMeNoD.0040104D
00401048     E8 00000000    call    KeyMeNoD.0040104D ;call inutil, llama instruccion siguiente
0040104D     E8 FBFFFFFF    call    KeyMeNoD.0040104D ;call imposible, se llama a si mismo generando stackoverflow
00401052     E8 F6FFFFFF    call    KeyMeNoD.0040104D
00401057     E8 F1FFFFFF    call    KeyMeNoD.0040104D
0040105C     E8 ECFFFFFF    call    KeyMeNoD.0040104D
00401061     E8 E7FFFFFF    call    KeyMeNoD.0040104D
00401066     E8 E2FFFFFF    call    KeyMeNoD.0040104D
0040106B     E8 DDFFFFFF    call    KeyMeNoD.0040104D
00401070     E8 D8FFFFFF    call    KeyMeNoD.0040104D
00401075     E8 D3FFFFFF    call    KeyMeNoD.0040104D
0040107A     E8 CEFFFFFF    call    KeyMeNoD.0040104D

Son todos llamados contiguos.
Cada llamado ocupa 5 bytes.
Casualidad que cada vez que  se genera el opcode E8 VVXXYYZZ,  VV disminuye en 5 (cada vez se acerca en 5 bytes a donde se hace el salto)

Al hacer copy past de los stolen bytes, en el lugar donde NO corresponden, las direcciones relativas de los OPCODES en los CALL NEAR no sirven, son distintas.
Es decir, CALL    miprograma._mifuncionX sigue siendo la misma intruccion (texto) pero los opcode son diferentes (binary past no sirve)



0)Del primer punto no estoy seguro, no me he puesto a desempaquetar programas, no tengo experiencia en el area,  pero por lo que pude ver, tendria que ser eso. Es la única

saludos.

[.:UND3R:.]

Me ha quedado claro, Muchas gracias por la aclaración

Saludos  _enko

[.:UND3R:.]

hablando de saltos absolutos, cambiamos a CALL NEAR. Son saltos a rutinas que se encuentran dentro del mismo segmento del codigo, por ende, su direccion es relativa a la posicion actual. Una call near repetido dos veces nunca tiene el mismo opcode.

y como se asigna el opcode? como se establece el valor que tomará?

Saludos

[_Enko]

la respuesta estaba en el ejemplo
Acordate que en la arquitectura x86 los bytes estan invertidos en las palabas y dobles palabras.

0040102F     E8 19000000    call    KeyMeNoD.0040104D saltar 25 bytes adelante
00401034     E8 14000000    call    KeyMeNoD.0040104D saltar 20 byts adelante
00401039     E8 0F000000    call    KeyMeNoD.0040104D saltar 15 bytes adelante
0040103E     E8 0A000000    call    KeyMeNoD.0040104D saltar 10 bytes adelante
00401043     E8 05000000    call    KeyMeNoD.0040104D; saltar 5b adelante
00401052     E8 F6FFFFFF    call    KeyMeNoD.0040104D ;saltar5 b atras
00401057     E8 F1FFFFFF    call    KeyMeNoD.0040104D ;saltar 10bytes atras
0040105C     E8 ECFFFFFF    call    KeyMeNoD.0040104D ;saltar 15 bytes atras
0040107A     E8 CEFFFFFF    call    KeyMeNoD.0040104D

la direccion es lo que esta despues del E8.

[.:UND3R:.]

Ahora si que está todo aclarado y entendido el porqué cambia el call dependiendo de la ubicación del CALL NEAR

Saludos y muchas gracias

[.:UND3R:.]

Me ha surgido otra duda de este tutorial haber si me la pueden aclarar cuando dumpea:

Dumpeando

Como habrán visto, no encontramos el OEP. Sin embargo,  "¡Es un buen momentaaaa!" para dumpear, como diría Mariano Closs. Lo hacemos con el plugin OllyDump, dejando sin marcar la opción "Rebuild Import". Puesto que no encontramos el OEP, vamos a dejar como EntryPoint el EntryPoint del packer, es decir, 6B010.

....

Por lo visto hay zonas de memoria a las que no puede acceder y por lo tanto no pueden ser dumpeadas. El problema está en la ImageSize del programa, que es 8570Bh, un tamaño que no es múltiplo del campo SectionAlignment del OptionalHeader, o hablando más concretamente, no es múltiplo de 1000h.
Así que volvemos a dumpear con OllyDump, dejando sin marcar la opción de "Rebuild Import", colocando como EntryPoint el EntryPoint del packer (6B010h), y colocando como Size el valor 85000h (hemos redondeado hacia abajo):

No entendí la explicación si alguien pudiera explicármela de manera sencilla y entendible se lo agradecería

Muchas gracias

[.:UND3R:.]

Ninguna respuesta?


Gracias

[MCKSys Argentina]

Preguntaste en CLS???? Porque por aca no somos muchos los que hemos hecho el curso.

Aparte, en la lista tenes otros que estan como vos. Incluso, el mismo Ricardo Narvaja lee los post y te puede contestar... (o al menos alguno que haya resuelto el concurso  )

Saludos!

[.:UND3R:.]

Eso me he estado dando cuenta, creo que llegué al punto de no respuestas 

Entonces nos veremos por allá, Saludos