Gracias Shaddy, esa info es muy interesante...

He avanzado un poco más, he hecho un loader en C suplantador del proceso padre, sin embargo me di cuenta de una cosa: como bien dice Shaddy(aunque en otro sentido) hay partes del programa que no estan aun "listas", no se como explicarlo, quiero decir que hay partes de codigo que el proceso padre inyecta en el hijo. Esto lo hace a traves(por suerte) de una llamada a WriteProcessMemory. Y lo hace ante una la aparición de una excepción concreta (0x80000001) o eso creo... deberia copiar estas 2 paginas de codigo del proceso padre y hacer que las inyecte mi suplantador no obstante tope con otra cosa.
La primera pagina que escribe es a la que saltara el proceso al ejecutarse, la escribe en 401000(una direccion susculenta eh?), sustituyendo los 2 primeros bytes por un buble infinito y atacheando olly al proceso hijo como describi antes aparecemos directamente sobre el codigo del programa.

Pero hay peros, las llamadas a las API's han sido sustituidas por jmp's ¿? a stubs posiblemente, de momento no he analizado mas, pero estoy mas cerca de dumpearlo...

Una cosa más, tengo que repetir todo el rato el mismo proceso para llegar a ciertos estados de un programa, hay alguna manera de automatizar esto??... con un plugin de olly o algo, que me recomendáis que use?, el immunity no me vale porque no le funcionan los plugins del olly... al menos no el phantom.

edit: Corrijo, he encontrado el phantom para el immunity, creo que me voy a pasar a este debugger

Saludos.

Buenas,

He usado el Software Passport(ultima version) para comprimir un ejecutable muy simple para estudiar la proteccion Armadillo 6.60 y nada, aun siguiendo varios tutos por la red no puedo con el...

Lo unico que no lleva son nanomites

Esta aqui: http://rapidshare.com/files/244632303/UnpackmeArmadillo6.exe.bz2.html

 Me gustaria poder dumpearlo y extraer el nucleo del programa para poder parchearlo etc., pero a mano. No he tenido muchos avances, a ver si alguien puede darme alguna pista.
He probado bastantes cosas y no consigo aun asi entender bien como funciona.

El intento mas cercano de conseguir algo fue de esta manera:

(Uso el plugin phantom para ocultar el olly)

Rompemos en el segundo WriteProcessMemory(hardware bp), que escribe 2 bytes en el proceso hijo, anteriormente escribio un salto jmp eip y ahora reestablece los bytes, nosotros cambiamos el buffer por EB FE, o sea, jmp eip.

Ahora deseariamos attachear olly al proceso hijo pero este esta siendo depurado por el padre asi que ponemos en el padre un bp WaitForDebugEvent, al final cuando eax == 0 (conditional) (esto no se bien por que pero lo lei) retornamos y ensamblamos
push <pid proceso hijo>
call DebugActiveProcessStop

Ejecutamos las 2 instrucciones y ya podemos atachaear un segundo olly al proceso hijo, ahora si ejecutamos el programa normal casca..... ¿que hago mal? ¿que detecta el programa diferente?

Como veis estoy muy lejos de poder dumpear el programa, reconstruir la IAT, etc...

Cualquier ayuda sera bienvenida
Saludos

Hola
He encontrado otra forma mas facil... es un programa realmente sencillo
Lo comentaré por pasos:
1. Primero ponemos un break en SetTimer al arrancar, continuamos con F9
2. Rompemos en SetTimer, vemos que el tiempo es de 90000 ms. o sea, el minuto y medio de trial, cambiamos ese param por uno pequeño, con CTRL+E 90 00 00 00
3. Ponemos un bp tambien en la rutina a la que llamará cuando cumpla el tiempo(TimerProc) o sea, en 4725c0 y le damos a F9
4. Caemos en la rutina a la que llama el timer, sin embargo no la podemos bypasear porque es llamada por otros timers del programa, como puede ser esto? el codigo luce tal que así:

004725C0     PUSH EBX
004725C1     PUSH ESI
004725C2     PUSH EDI
004725C3   . PUSH EBP
004725C4   . SUB ESP,8
004725C7   . MOV EBX,DWORD PTR SS:[ESP+24]
004725CB   . PUSH EBX                                 ; /TimerID
004725CC   . PUSH DWORD PTR SS:[ESP+20]               ; |hWnd
004725D0   . CALL DWORD PTR DS:[<&USER32.KillTimer>]  ; \KillTimer
004725D6   . MOV EAX,DWORD PTR DS:[4CC234]
004725DB   . PUSH EAX
004725DC   . PUSH EBX
004725DD   .CALL Tap_It_I.004457D0
004725E2   . POP ECX
004725E3   . POP ECX
004725E4   . MOV DWORD PTR SS:[ESP+4],EAX
004725E8   . CMP WORD PTR DS:[EBX+1C],2
004725ED   . JE SHORT Tap_It_I.00472610
004725EF   . C743 28 000000>MOV DWORD PTR DS:[EBX+28],0
004725F6   .>MOV WORD PTR DS:[EBX+1C],0
004725FC   . TEST EAX,EAX
004725FE   . JE Tap_It_I.004726D1
00472604   . PUSH EBX
00472605   . CALL DWORD PTR SS:[ESP+8] <------------------OJO depende del parametro
00472609   . POP ECX
0047260A    JMP Tap_It_I.004726D1

bien pues parece que está escrito en un lenguaje OO de estos que tiene virtual table donde se almacenan las direcciones de los métodos (como dijo tena anteriormente esta posiblemente escrito en RealBasic el cual es orientado a objetos), por eso la primera llamada que salta a la vista es un call ss:[esp+8] en 472605, de hecho es la única que puiede ser dinámica, he rastreado la anterior y no parece que se use el valor del identificador del timer que podía ser otra posibilidad no?

Si no tocamos nada en el programa...(y poniendo 90 de tiempo al SetTimer no nos dara tiempo), el primer timer que saltara sera el del trial...

5. Nos metemos con F7 dentro de la llamada sospechosa esa, y ponemos un hardware break al principio(por alguna razon olly me desactiva el bp software quizas por estar fuera de la sección de codigo). Ahora si ejecutamos desde el comienzo el programa vemos que esa zona no se ejecuta cuando salta el timer por otras razones que no sean las del trial. Por tanto podemos deducir que esa es el corazon estatico culpable de la ventanita de trial y por ello vamos a eliminarla.

6. Si has reiniciado olly sigue de nuevo los pasos 1-4, y cuando entres en esa funcion, ensamblamos un retn (en 1843ed), y parece que funciona...

NOTA: no he podido probar el programa bien porque no me funciona el sonido en la máquina virtual, supongo que suena 

Saludos, es mi primer post, espero no haber metido mucho la gamba jejejee