Mensajes

La diferencia esta en que el ADODC es un control y ADODB es una lib.

El control no se ha actualizado y ya es obsoleto (http://msdn.microsoft.com/en-us/library/microsoft.visualbasic.compatibility.vb6.adodc.aspx), en cambio ADODB si lo ha hecho.

En resumen: empezaron juntos, pero el segundo sigue vigente, el otro no.

Al menos eso es lo que me queda claro luego de googlear un rato... 

Saludos!

Fijate esto: http://x86asm.net/articles/working-with-big-numbers-using-x86-instructions/

Explica como hacer operaciones de 64 bits en 32. La idea es similiar a operar numeros de 32 bits en 16...

Hi Heiko112!

I don't have much spare time, but I'll try to help you.

As soon as I get home, I will try to make a translation of this tut.

Greetings!

La idea es añadir alguna función como RaiseException o provocar un BSOD al saltar una de esas funciones en nuestros programas, para protegerlos.

Un BSOD??? No es "algo" extremo???

Bueno, ya te han dado varias respuestas a tus preguntas, pero aún asi:

Tuviste algún problema para ejecutar el crackme y debuggear? Instalé algunas protecciones básicas y quería saber si te topaste con ellas o si directamente ni las vistes.

La primera protección es mandar cerrar los procesos típicos del olly
La segunda fue ocultar la API MessageBoxA, en lugar de cargarla de forma normal, usé GetProcAddress
La tercera protección es algo más compleja: Se genera un thread adicional e inyecto un código ASM en dicho thread para ejecutarlo, dejo el source:

Por lo visto los plugins de Olly también lo protegen de los threads que generas a partir de la aplicación principal Ya que la llamada a la API IsDebuggerPresent no se genera nunca desde el propio ejecutable. Seguiré investigando

PD. El source de thread en ASM no es mio

No tuve problemas para ejecutar el crackme bajo Olly. Use Olly 1.10 con el plugin StrongOD (uno viejito que tengo por ahi).

Vi las protecciones que has puesto.

La proteccion de cerrar los procesos con "taskkill" no funciono porque strongod usa un driver para que el olly no aparezca en la lista de procesos. A esto lo puedes verificar con Process Explorer, por ej.

El ocultar el mensaje de "chico bueno" seria inconveniente si lo hubiera buscado  . Normalmente, busco otros indicadores para saber si algo salio bien o mal, aunque asumi que algo pasaria al "ingresar" los datos correctos.

El tema del thread esta bueno. Incluso mire el codigo. Aqui te hago una sugerencia: No uses strings para armar el codigo. Es muy evidente. Puedes usar un monton de cosas raras en VB, abusando de la estructura de los ejecutables (sino preguntale a Karcrack que es un monstruo en ese tema)

Por ej: Si estudias como hace VB para llamar a una API de Windows, veras que puedes definir una API inexistente en una DLL conocida (o inexistente tambien) y ejecutar codigo llamandola (esto es lo genial). Esto despista y hace que el analisis sea mas complejo.

Otra cosa: fijate que en vez de usar CreateThread. puedes usar CallWindowProc para ejecutar el codigo. Incluso, puedes cargar el code asm en un array y ejecutarlo. Esto tiene la contrariedad de que si la maquina tiene DEP activo para todos los procesos, va a fallar, por lo que podrias hacer un VirtualAlloc y despues si ejecutar.

En resumen: el desafio fue entretenido. Me he divertido analizando el codigo, asi que para mi es tarea cumplida... 

Saludos!

[EDIT:]

En una VM que tengo por acá:



Si hago tiempo, esta noche veo de hacer un keygen...

EDIT:

EXE desempacado + Keygen en VB6 + Código fuente keygen: http://www.multiupload.nl/EKLOF1CPS3

He probado el KG sólo en 2 máquinas, asi que PODRIA fallar... 

Saludos!

Personalmente, uso el Olly 1.10 original con el plugin StrongOD.

No he tenido problemas hasta ahora y no lo detectado ni Themida.

El Olly lo bajas de la web de Oleh y el plugin lo puedes bajar de tuts4you.

Saludos!

Hace un tiempo atras empece un script para ollyscript, el cual reconoce las estructuras internas de VB 5/6.

La base salio de otro script que rondaba la web en esos tiempos mas este (para IDA): http://www.hex-rays.com/products/ida/support/freefiles/vb.idc

Aunque no esta completo, me permite encontrar las cosas rapido, como la GUITable, los ObjectInformation y demas.

Saludos!

Si estas haciendo un parche, trata de ponerlo lo mas cerca posible del codigo. Si no tienes espacio, puedes agregar una sección nueva al EXE o bien, buscar una "cueva" donde meter el codigo. Por supuesto, si escribes en una sección que no es ejecutable, habra errores, por lo que deberas cambiarla.

Ese mensaje sale porque estas tratando de guardar información que no existe en el ejecutable físico.

Las secciones de un ejecutable tienen 2 tamaños: 1 "real" (raw) y 1 virtual. Cuando el EXE está en disco, cada sección ocupa lo especificado en el RAW Size de la sección.

Pero, cuando se lo mapea en memoria, el valor usado es el Virtual Size.

Si agarras cualquier EXE, verás que en la gran mayoría, Virtual Size es mayor que Raw Size.

El problema surge cuando cambias bytes que están fuera de lo abarcado por el Raw Size.

No sé si me he explicado bien, pero por las dudas lee un poco sobre el formato PE y las secciones de un ejecutable.

Saludos!