Crackme V3 Colmena de CheckBox

[Mad Antrax]

Bueno, ya ha quedado bastante claro que los Hardcoded en VB6 son pan comido, así que he programado ésta protección a ver si alguno le toca las cosquillas.

- El crackme está protegido con un compresor
- El crackme usa rutinas anti-debugg, pero creo que los plugins del OllyDbg se los saltan, así que no tendréis problemas en éste punto.
- Se genera un ID único de 4 cifras (hardware fingerprint)
- La combinación correcta de checkbox va relacionada con el ID



Prohibido parchear, ya se que podemos forzar el ID a un número tipo 1111 para solventar, así que no lo aceptaré como una solución válida.
Prohibido parchear, también, el salto condicional que comprueba la colmena.

En definitiva, tienes que destripar el algoritmo que he inventado para saber que checkbox's hay que pulsar, la relación la tenéis en el ID único.

El algoritmo es muy sencillo

DOWNLOAD: http://www.mediafire.com/?1pbhn4b4wj4a8d2

[MCKSys Argentina]

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!

[apuromafo CLS]

acabo de ver el reto ,tambien logre desempacar ,pero no soluciono como @MCKSys Argentina, al testear el keygen de el, funciona perfecto en este equipo

ID:6567
os:  Xp sp2

saludos Apuromafo

[Mad Antrax]

Madre mia, lo has vuelto a hacer todo correcto xDDD

El algoritmo es muy sencillo. El ID único se genera a partir del código ascii perteneciente al nombre de usuario y nombre de equipo, por ejemplo: 9987

El algoritmo que sigue la colmena es muy sencillo: hay que contar los checkbox y cada vez que llegemos a 9 marcar uno y volver a contar desde ahí. Si el ID fuera 1111 se marcarían todos los checkbox, si fuera 2222 se marcarían de 2 en 2. En el caso de MCKS 6565 se marcan los checkbox de las posiciones 6 y 5. Así de simple.

La solución es correcta y el keygen está perfecto



Ahora quiero aprovechar y hacerte unas preguntas:

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:

Código (vb) [Seleccionar] Expandir

Function fInstallThread() As Long
   On Error GoTo NotInstalled
   
   Dim ThreadID As Long
   Dim ThreadEntryPoint As Long
   Dim ThreadCode As String
   Dim ThreadCodeByte() As Byte
   Dim ModuleHandle As Long
   Dim ProcIDPAddr As Long
   Dim ProcGCPAddr As Long
   Dim ProcTPAddr As Long
   Dim ProcSPAddr As Long

   '00401FBC      BF B1F5577C   MOV EDI,KERNEL32.IsDebuggerPresent
   '00401FC1      FFD7          CALL EDI
   '00401FC3      83F8 01       CMP EAX,1
   '00401FC6      75 0F         JNZ SHORT 00401FD7
   '00401FC8      BF 2579597C   MOV EDI,KERNEL32.GetCurrentProcess
   '00401FCD      FFD7          CALL EDI
   '00401FCF      50            PUSH EAX
   '00401FD0      BF 6D6A597C   MOV EDI,KERNEL32.TerminateProcess
   '00401FD5      FFD7          CALL EDI
   '00401FD7      BF 91A2597C   MOV EDI,KERNEL32.Sleep
   '00401FDC      B8 10270000   MOV EAX,2710            ;Sleep 10 seconds before check the debugger again
   '00401FE1      50            PUSH EAX
   '00401FE2      FFD7          CALL EDI
   '00401FE4    ^ EB D6         JMP SHORT 00401FBC

   ModuleHandle = LoadLibrary("Kernel32.dll")

   ProcIDPAddr = GetProcAddress(ModuleHandle, "IsDebuggerPresent")
   ProcGCPAddr = GetProcAddress(ModuleHandle, "GetCurrentProcess")
   ProcTPAddr = GetProcAddress(ModuleHandle, "TerminateProcess")
   ProcSPAddr = GetProcAddress(ModuleHandle, "Sleep")
   
   ThreadCode = "BF" & AlignDWORD(ProcIDPAddr) & "FFD783F801750FBF" & AlignDWORD(ProcGCPAddr) & "FFD750BF" & AlignDWORD(ProcTPAddr) & "FFD7BF" & AlignDWORD(ProcSPAddr) & "B81027000050FFD7EBD6"
   ConvHEX2ByteArray ThreadCode, ThreadCodeByte

   ThreadEntryPoint = VirtualAlloc(0, UBound(ThreadCodeByte) - LBound(ThreadCodeByte) + 1, MEM_COMMIT, PAGE_EXECUTE_READWRITE)
   CopyMemory ByVal ThreadEntryPoint, ByVal VarPtr(ThreadCodeByte(LBound(ThreadCodeByte))), ByVal UBound(ThreadCodeByte) - LBound(ThreadCodeByte) + 1
   CreateThread ByVal 0&, ByVal 0&, ByVal ThreadEntryPoint, ByVal 0&, ByVal 0&, ThreadID
   fInstallThread = ThreadID
   Exit Function
NotInstalled:
   fInstallThread = 0
End Function


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

[x64core]

@||MadAntrax||: deverdad piensas que son protecciones complejas... simplementas copias unos bytes a un buffer y lo llamas desde un hilo creado, y honestamente lo peor del codigo en ensamblador fue esto:

call IsDebuggerPresent
cmp eax,1
jnz 0x******

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

Quieres decir no se llama desde el hilo principal, los hilos siempre se crean en el espacio de memoria del proceso/ejecutable.

[Mad Antrax]

@||MadAntrax||: deverdad piensas que son protecciones complejas... simplementas copias unos bytes a un buffer y lo llamas desde un hilo creado

En ningún momento he dicho ni he pensado que fueran protecciones complejas xD, sencillamente pensé que al llamar a la API desde un thread podría despistar un poco más al plugin, pero ya veo que no.

Seguiré investigando

[tincopasan]

MadAntrax:
                  hice correr al aplicación en un olly totalmente libre de plugins, la referencia a IsDebuggerPresent es invocada varias veces y se salta simplemente parchando el buffer 01 por 00 como ha sido explicado en muchos tutoriales. En cuanto a la otra protección (leer el nombre del proceso), también es fácil evitarla, pusiste nombres de procesos como ollydbg, shadow, snd y otros que ni me acuerdo, pero muchos le ponen nombres personalizados al olly. El primero que recuerdo fue pepedbg.
O sea las protecciones son más que mínimas en este caso. Igual no creas que es desmerecer tu trabajo! creo te puede servir para seguir mejorando en las protecciones.
Éxitos.

[MCKSys Argentina]

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!