Esto me dió alegría ya que me dije, “bien, algo nuevo para investigar vino a mi!!”… así que me puse manos a la obra, y mientras publicaba un artículo viejo que escribí para la revista @rroba, me dediqué a mirar este bichito…

Mirando los logs de NOD

He aquí algunas líneas del log de mi AV’s…

06/06/2009 12:02:04 a.m. HTTP filter file http://174.133.147.18/p0508/2.0/w2.bin?829467 probably a variant of Win32/Adware.Coolezweb.AI application connection terminated – quarantined NT AUTHORITY\SYSTEM Threat was detected upon access to web by the application: C:\WINDOWS\system32\svchost.exe.

06/06/2009 12:01:56 a.m. HTTP filter file http://174.133.73.178/p0508/2.0/w2.bin?405861 probably a variant of Win32/Adware.Coolezweb.AI application connection terminated – quarantined NT AUTHORITY\SYSTEM Threat was detected upon access to web by the application: C:\WINDOWS\system32\svchost.exe.

06/06/2009 12:01:48 a.m. HTTP filter file http://174.133.34.178/p0612/2.0/w1.bin?413869 probably a variant of Win32/Adware.Coolezweb.AI application connection terminated – quarantined NT AUTHORITY\SYSTEM Threat was detected upon access to web by the application: C:\WINDOWS\system32\svchost.exe.

06/06/2009 12:01:40 a.m. HTTP filter file http://174.133.72.250/p0508/2.0/w1.bin?762274 probably a variant of Win32/Adware.Coolezweb.AI application connection terminated – quarantined NT AUTHORITY\SYSTEM Threat was detected upon access to web by the application: C:\WINDOWS\system32\svchost.exe.

06/06/2009 12:01:29 a.m. HTTP filter file http://174.133.147.18/p0508/2.0/w1.bin?875733 probably a variant of Win32/Adware.Coolezweb.AI application connection terminated – quarantined NT AUTHORITY\SYSTEM Threat was detected upon access to web by the application: C:\WINDOWS\system32\svchost.exe.

06/06/2009 12:01:21 a.m. HTTP filter file http://174.133.73.178/p0508/2.0/w1.bin?233033 probably a variant of Win32/Adware.Coolezweb.AI application connection terminated – quarantined NT AUTHORITY\SYSTEM Threat was detected upon access to web by the application: C:\WINDOWS\system32\svchost.exe.

06/06/2009 12:01:19 a.m. Real-time file system protection file C:\WINDOWS\system32\wtukd32.exe probably a variant of Win32/Adware.Coolezweb.AI application cleaned by deleting – quarantined NT AUTHORITY\SYSTEM Event occurred on a file modified by the application: C:\WINDOWS\system32\svchost.exe.

06/06/2009 12:01:12 a.m. HTTP filter file http://174.133.34.178/p0612/2.0/w.bin?613307 probably a variant of Win32/Adware.Coolezweb.AI application connection terminated – quarantined NT AUTHORITY\SYSTEM Threat was detected upon access to web by the application: C:\WINDOWS\system32\svchost.exe.

06/06/2009 12:01:04 a.m. HTTP filter file http://174.133.72.250/p0508/2.0/w.bin?333771 probably a variant of Win32/Adware.Coolezweb.AI application connection terminated – quarantined NT AUTHORITY\SYSTEM Threat was detected upon access to web by the application: C:\WINDOWS\system32\svchost.exe.

06/06/2009 12:00:56 a.m. HTTP filter file http://174.133.147.18/p0508/2.0/w.bin?280812 probably a variant of Win32/Adware.Coolezweb.AI application connection terminated – quarantined NT AUTHORITY\SYSTEM Threat was detected upon access to web by the application: C:\WINDOWS\system32\svchost.exe.

06/06/2009 12:00:48 a.m. HTTP filter file http://174.133.73.178/p0508/2.0/w.bin?170629 probably a variant of Win32/Adware.Coolezweb.AI application connection terminated – quarantined NT AUTHORITY\SYSTEM Threat was detected upon access to web by the application: C:\WINDOWS\system32\svchost.exe.

05/06/2009 10:15:47 p.m. HTTP filter file http://bddanhdnfl.net/ccsuper3.php Win32/Small.NEK trojan connection terminated – quarantined NOTEBOOK\Sparkrisp Threat was detected upon access to web by the application: C:\fuwtkxex.exe.

05/06/2009 10:15:46 p.m. Real-time file system protection file C:\clftq.exe Win32/TrojanDownloader.Bredolab.AA trojan cleaned by deleting – quarantined NOTEBOOK\Sparkrisp Event occurred on a new file created by the application: C:\fuwtkxex.exe.

05/06/2009 10:15:45 p.m. Real-time file system protection file C:\Documents and Settings\Sparkrisp\Configuración local\Archivos temporales de Internet\Content.IE5\K13ASQ4J\ccsuper2[1].htm Win32/TrojanDownloader.Bredolab.AA trojan cleaned by deleting – quarantined NOTEBOOK\Sparkrisp Event occurred on a new file created by the application: C:\fuwtkxex.exe.

05/06/2009 10:15:45 p.m. HTTP filter file http://bddanhdnfl.net/ccsuper2.php Win32/TrojanDownloader.Bredolab.AA trojan connection terminated – quarantined NOTEBOOK\Sparkrisp Threat was detected upon access to web by the application: C:\fuwtkxex.exe.

05/06/2009 10:15:42 p.m. HTTP filter file http://bddanhdnfl.net/ccsuper1.php Win32/Small.NEK trojan connection terminated – quarantined NOTEBOOK\Sparkrisp Threat was detected upon access to web by the application: C:\fuwtkxex.exe.

05/06/2009 10:15:41 p.m. HTTP filter file http://bddanhdnfl.net/ccsuper0.php a variant of Win32/Rustock.NIK trojan connection terminated – quarantined NOTEBOOK\Sparkrisp Threat was detected upon access to web by the application: C:\fuwtkxex.exe.

05/06/2009 10:15:18 p.m. HTTP filter file http://bddanhdnfl.net/progs/xadmaa/molivjw.php Win32/Small.NEK trojan connection terminated – quarantined NOTEBOOK\Sparkrisp Threat was detected upon access to web by the application: C:\Documents and Settings\Sparkrisp\Configuración local\Temp\136.exe.

05/06/2009 10:15:17 p.m. HTTP filter file http://bddanhdnfl.net/progs/xadmaa/djdjjnxlcp.php Win32/Small.NEK trojan connection terminated – quarantined NOTEBOOK\Sparkrisp Threat was detected upon access to web by the application: C:\Documents and Settings\Sparkrisp\Configuración local\Temp\136.exe.

Bien, nuestra pequeña bestia intentó muchas cosas al mismo tiempo prácticamente.

Aparentemente, nuestro autor, o “autor” porque no creo que lo sea de todos estos virusillos, tiene un host y seguramente hace downloaders, para los mismos, estos consultan las url’s que estamos viendo en el log, baja los troyanos, y finalmente infecta nuestra PC, para robarnos información, tomar el control, etc.

Viendo que hay detrás

Si probamos alguna de las URL’s, y la ejecutamos en un navegador (sin miedo jejeje), veremos algo por el estilo:

Exactamente, el binario de uno de los troyanos, el cual NOD lo detecta como: Win32/Small.NEK.

Con una simple mirada en el código binario, podemos ver que está hecho en VB (MSVBVM60.DLL), y otra cosa más, en que carpeta el desarrollador lo tiene al proyecto entero!

D:\Documents and Settings\Administrator\Lhb—\installscash active!!nno form wow downloader\mycc\Project1.vbp

Aparentemende NOD lo detecta como un troyano, pero es un downloader…

Luego, veremos nombres de logs, archivos de log, serán archivos generados por el downloader?

xdfbxewhrrjdzdfbcvne5gwgaabaz36.log

xdfbxewhrrjdzdfbcvne5gwgaabaz37.log

xdfbxewhrrjdzdfbcvne5gwgaabaz38.log

xdfbxewhrrjdzdfbcvne5gwgaabaz39.log

Y la lista sigue…

Así veremos también en esa misma página, la utilización de la API: urlmonURLDownloadToFile, sabemos que es utilizada para bajar archivos de una URL, muy común en los downloaders.

Si guardamos el fichero obtenido de esa URL (sugiero hacerlo con wget), y utilizan el WKT VB Debugger, podremos ir viendo lo que va a haciendo…

Algunas de las cosas que veremos es que tiene strings encriptadas, para evitar el desensamblado y la identificación sencilla del virus en cuestión.

Así que debuggearemos un poco para ver que hace…

M8C9S8H5zcX9C9z3Q9UaKbRbA4y0k9EbybPcR9LcUaYby23azcJdOcFaR9z1

M8C9UaH5C9X9Faz3ObUaIdP9w0C4naJaIcEaLaRcOby27bH8Q8EbRcz8NbHdI3b8KaOcFaPbKazcUaB52bJcJdIcD8zaVbLcJcM8z3jaLdz8PbLcN9E9w0H3cb2bibG3w2

He aquí algunas de las strings encriptadas… es simple pensar que utiliza XOR, para encriptarlas, ya que no se necesita mucho más para estas tareas víricas…

AddService = zgtkg3jrsyzdb6wtgw3rh3wahhrjkae80,,My_AddService_Name

Quiere decir que este bichito debe instalar un servicio en nuestro sistema… pero que pícaro…

FStStr -> ‘sc config   wscsvc start= DISABLED’

FStStrNoPop -> ‘C:\DOCUME~1\SPARKR~1\CONFIG~1\Temp\zgtkg3jrsyzdb6wtgw3rh3wahhrjkae35.log’

FStStrNoPop -> ‘C:\DOCUME~1\SPARKR~1\CONFIG~1\Temp\zgtkg3jrsyzdb6wtgw3rh3wahhrjkae43.exe’

FStStrNoPop -> ‘zgtkg3jrsyzdb6wtgw3rh3wahhrjkae81.exe’

Dije antes, que utiliza la famosa API para bajar un archivo de una URL en particular… hay trucos para evitar que los antivirus detecten que se está utilizando, generalmente la heurística detecta todo y está sonado..

loc_40401D: LitStr “U”

loc_404020: LitStr “R”

loc_404023: ConcatStr

loc_404024: FStStrNoPop var_A0

loc_404027: LitStr “L”

loc_40402A: ConcatStr

loc_40402B: FStStrNoPop var_A4

loc_40402E: LitStr “D”

loc_404031: ConcatStr

loc_404032: FStStrNoPop var_A8

loc_404035: LitStr “o”

loc_404038: ConcatStr

loc_404039: FStStrNoPop var_AC

loc_40403C: LitStr “w”

loc_40403F: ConcatStr

loc_404040: FStStrNoPop var_B0

loc_404043: LitStr “n”

loc_404046: ConcatStr

loc_404047: FStStrNoPop var_B4

Luego si miramos más el proyecto veremos que tiene una función para ejecutar las API’s de alguna manera especial.. no entraremos tanto en detalle, vamos a seguir mirando que mas nos ofrece…

Siguiendo el rastro

Si dejamos a este bichito ejecutarse un par de días, seguirá bajando copias y variantes de sí mismo. Parece que los programadores de estos downloaders, son muy activos, en dos días he bajado como 3 o 4 versiones del mismo downloader, con algunas diferencias…

Tenemos otro que modifica el registro de windows, instalándose en el inicio, para hacer las conecciones remotas, cada vez que arranca el sistema operativo.

Por ejemplo existe otra variante, la que se instala al inicio, que no instala el servicio…

En la segunda imagen de inicio, marco otros sospechosos que encontré, no sé si son de este virus o de otro que tengo xDDD, si es de otro, quizás tengamos más diversión xD…

Al ver que instala servicios, se me ocurre correr la utilidad GMER, muy utilizada. Y me avisa de una instalación de un servicio oculto…

Podemos desinstalarlo y borrarlo con GMER, sin problemas, al próximo reinicio no estará más. Si queremos analizarlo un poco más con IDA no veremos mucho, así que o Softice o Syser Debugger, que es bastante bueno también.

Bien, como dije cada uno de los “hijos” tiene sus características, la idea principal calculo que será infectarnos y hacernos zombies de alguna manera, o robarnos información, a su vez con una rápida actualización de los downloaders, los cuales no fueron detectados por NOD 4.0, sino que éste detectó las conecciones hacia el host.

Los dos ficheros de inicio, que tenía yo en mi PC, aparentemente están empaquetados, veremos con una pequeña sesión de Olly que sale…en la segunda parte.. xD

Veremos varias cosas más, otros archivos ocultos especialmente en las carpetas system32 de nuestro windows…. pero eso será como dije en la próxima…

Espero que les esté gustando.

Un saludo.

convert this post to pdf.

Empezaremos por el principio, como siempre debemos empezar, mirando la víctima, ejecutemoslo… listo? ¿Que tenemos?, una hermosa ventanita con un menú file, con la opción exit, y otro menú help con la opción register y about.

Experimentando con la bestia

Bueno, que sucede si hacemos click en la opción register del menú help?, nos aparece una ventanita que nos dice “Kill the nagscreen”, estas ventanitas, con esos iconos característicos son generalmente llamadas con una API llamada MessageBox o MessageBoxA, dependiendo si la aplicación es de 16 o 32 bits respectivamente.

Aquí ya tenemos una pista, estas eran las “pistas” que yo les mencioné anteriormente, que sirven para guíarnos a través del código.

Otra cosa interesante, es que aparece una ventanita aleatoriamente diciendo algunas cosas sin sentido e incitándonos a crackearlo. Destruyámosla.

Si hacemos click en la opción About, nos da datos sobre el autor del crackme, y demás cosas, que no tienen mucha importancia.

Reglas de juego

Ahora veamos que nos pide el autor del crackme, y seamos chicos aplicados cumpliendo con todo lo que él dice, al pie de la letra, ¿están listos? ¡¡Adelante!!

Bueno, dice que saquemos el messagebox que aparece cuando hacemos click en register, lo haremos, y luego debemos matar la ventanita chiquita que nos incita a crackearlo.

Sobre las “pistas”, API’s, y reconociendo patrones de código

Tenemos siempre, que tratar, debido al gran caos del código desensamblado de un programa, tener referencias y entender lo útil y principal, lo que verdaderamente está sucediendo en partes o en la totalidad del programa, para poder “descifrar” el funcionamiento del programa, encontrar la protección y poder anularla.

Otras veces, deberemos entender, varias cosas antes de desensamblar un programa, cuando veamos ejercicios del tipo reverseme’s, ya verán de lo que les hablo.

Las pistas que debemos encontrar, son las API’s, debemos conocer las más comunes , sus parámetros, sus valores de retorno, su función principal, aquí les detallo algunas:

MessageBox SystemTime Hmemcpy
OpenFile GetLocalTime
DialogBoxParamA createwindow
GetDlgItemText createwindowexa
WriteFile showwindow

Bueno, la mayoría de estos nombres de API’s se explican por sí solos, así que no hay que preocuparse mucho, lo que sí, les mostraré ahora algunos que he estado descubriendo, por ejemplo en este crackme, encontré uno que me sirvió y me dio la pista para poder matar la nagscreen que nos incita a crackear el crackme.

La API que me guió hasta esa ventana es, CreateThread , en breve les mostraré porqué y como razoné para deducir que esa API era la responsable.

Los patrones de código son reconocibles, con la práctica, el ojo humano al principio debe acostumbrarse a leer ensamblador, como dije antes, todo código sea ensamblador, c++, basic, pascal, es caótico, tiende a ser caótico.

Cuando programamos un sistema por ejemplo, un programa muy grande, debemos documentar debidamente cada función, cada proceso creado, que valores retorna, porque, y como funciona, para futuros arreglos o implementaciones, debemos organizar, e identar todas las instrucciones correctamente, sino sería ilegible, o muy difícil de entender, y aunque ustedes no lo crean, se hacen concursos de “ofuscados” son programas que hacen algo, como un cálculo o alguna cosa simple, pero que el ganador es aquel que lo hace “menos entendible”, sin querer decir que programe “suciamente”, simplemente hacerlo lo mas ilegible posible. Pero no nos meteremos en esos campos extraños de la informática.

Un programa desensamblado, es lo mas terrorífico que un programador se puede encontrar, el algo verdaderamente ilegible, si no se tiene el conocimiento real de la situación a bajo nivel, y cierta práctica como para reconocer los patrones de código de los cuales les hablo.

Cuando usamos Vc++, VB, Delphi, o algún otro RAD, el código generado por estos compiladores, se repite muchísimas veces en distintos programas programados bajo el mismo lenguaje, permitiéndonos, con la práctica ( o un buen tutorial a mano sobre el tema ) poder reconocer por ejemplo, cuando el programa chequea si las opciones de los menúes fueron clickeadas, etc.

¡¡Al Ataque!!

Muy bien, aclaradas algunas cosas antes, vayamos a nuestro pequeño ejercicio, haber si podemos calentar un poco nuestras neuronas…

Veamos de que se trata, a mí me gusta saber en que lenguaje está programada mi víctima, para saber con quien estoy “hablando”, es como una presentación…… bueno dejenme, son mañas.

Corramos el programa Language 2000, arrastremos la víctima hacia language 2000, y que nos dice…. Que está programado en Visual C++, ohps! muy bien, y ¿ahora que?, bien respiremos profundamente, porque cuando los programas están programados en Vc++, en C++ o en C, significa, que su código desensamblado, será más entendible (eso no significa más fácil). ¿Por qué digo esto?, porque cuando trabajamos con programas programados en VB, por ejemplo , este lenguaje es interpretado, y necesita runtimes, utiliza funciones propias del lenguaje, las cuales debemos analizar para que sirve cada una, porque raramente llama a una API, salvo que sea una llamada directa hecha por el programador.

Programas hechos en VB o en Delphi por ejemplo, tienen patrones de código bien reconocibles, y llamadas a rutinas, que realizan el trabajo “sucio”, entonces, el código desensamblado es mayor, mucho más caótico y difícil de descifrar si no tenemos la suficiente paciencia, pero no es imposible, no se me desanimen.

Ahora, tomemos un desensamblador, como por ejemplo el IDA, muy bueno a mi parecer, hace el código muy entendible, y tiene las librerías llamadas FLIRT, que si sabes en que está programada la víctima, puedes cargar una FLIRT para reconocer rutinas propias de los programas generados con X lenguaje, entonces de esa manera se entiende mucho más fácil, y puedes ir al punto directamente sin dar muchas vueltas.

Bueno, empecemos por lo más sencillo, buscar strings references, esto es lo más sencillo, porque nos lleva al punto directo, de cuando el mesagebox o X componente fue creado con X texto que busquemos, que no estará muy lejos de la llamada API correspondiente, les muestro que sucede en nuestro crackme:

Buscamos el texto “Kill the nagscreen.”, y lo encontramos, ahora hagamos doble click en él y nos lleva hasta aquí :

push offset aCanTRegister ; “Can’t register”
push offset aKillTheNagscreen_ ; “Kill the nagscreen.”
call ds:MessageBoxA

por problemas de espacio he dejado las instrucciones más importantes, a continuación explico cada una:
el primer, push es un parámetro al igual que el segundo push, debemos saber por eso que parámetros necesita la API MessageBoxA, para poder saber que esos son los parámetros usados para mostrar nuestra ventanita, que debemos anular.

Miremos un poco mas arriba en esa rutina y encontramos esto:

_text:00401355 loc_0_401355: ; CODE XREF: _text:0040132D j

hagamos click en la parte resaltada con amarillo y nos llevará al lugar desde donde es llamada esta rutina para mostrar la ventanita.

Aquí nos lleva:
jz short loc_0_401355

Ok, este es el salto que produce la ventana, matémoslo bruscamente, para eso usemos la instrucción NOP (No OPeration), para anular ese salto, el código de operación de esta instrucción es 90, ¿Qué es código de operación? Simplemente, el valor que toma la instrucción cuando es compilada por la computadora, entonces para entendernos con ella crudamente, debemos hablar su mismo idioma, esto quiere decir, tomar un editor hexadecimal, como hex workshop por ejemplo e ir al offset, de esta instrucción el cual nos dice IDA debajo de todo en el cuarto campo, este es 132D.

Como estos saltos ocupan dos posiciones compilados debemos poner dos NOP’s, o sea dos 90, en esa posición y en la que sigue.

Ejecutemos la víctima, hagamos click en la opcion Register…… ¡Bingo!

Ahora, vamos por la otra ventanita, esta ventana es creada debes en cuando, no tome el tiempo, pero estimo que si no es por tiempo fijo, es aleatoria, eso mucho no interesa, ya que lo que queremos es anularla, entonces, lo que me guió a mí como ya les comenté es la API CreateThread la cual sirve para crear un nuevo hilo de proceso, mientras la aplicación principal se ejecuta en otro proceso distinto, entonces, los mensajes de una ventana no traba a la otra, permitiendo el efecto “multitarea”, la teoría de programación multihilo es muy interesante pero no profundizaremos en esto más que por la definición que acabo de dar.

Busquemos el string “Kill the nagsreen.” De nuevo, miremos un poco más debajo de esa rutina y aparece nuestra querida API CreateThread, de esta manera: call ds:CreateThread

Ok, hagamos doble click la referencia de que hace al principio de la rutina, como la rutina analizada anteriormente, esto nos dice desde donde es llamada la rutina, viendo directamente el salto que debemos NOPear en nuestro caso.

Nos lleva aquí: jz short loc_0_401374

El cual debemos topear igual que el otro salto, para que ya no tenga más efecto esa rutina, y la asquerosa ventanita aleatoria no aparezca más.

Como verán, existen muchísimas formas de proteger un programa, y yo en particular pienso que deben existir cientos de otras formas, mezclas de protecciones, como por ejemplo la que acabamos de ver, en la que se implementa muy bien la API CreateThread, para crear una ventana nueva, y además una nag screen en la opción register.

Más adelante veremos, protecciones CD-Check, y quizás vayamos mas arriba aun, código automodificable, encriptación, key-files, etc.

Cada una, tiene su pro y su contra, en algún momento quizás también nos topemos, con programas que verdaderamente son DEMOS, y les falta implementar la opción “Save as…”, por ejemplo, en estos casos, usaremos las técnicas de reversing, en la que deberemos saber Win32Asm (ensamblador de 32bits para Windows), hacer injertos de código, conocer la estructura de los archivos PE, y demás cosas muy interesantes.

También, en esta carrera nos toparemos con los “loaders”, programas que parchean en memoria, y desprotegen “runtime” a los programas, veremos como funcionan, como hacer uno propio, en un lenguaje fácil (VB, Delphi), cuando y como usarlos.

Quizás lleguemos a ver mas adelante, protecciones llamadas dongles, las famosas “mochilas”, esta es una protección por hardware, que necesita de un determinado hardware conectado a uno de los puertos de la pc, para que el programa funcione.

El cracker, debe tener una mente abierta, analizar un programa protegido, es toda una aventura, es conocer, aprender, desafiarnos, y crecer, en conocimiento, y sobre todo en paciencia.

Ok, hasta aquí hemos llegado, para la próxima veremos opciones desactivadas y/o cd-checks.

¡Suerte!
¡Happy Cracking!

SparK

convert this post to pdf.

CuTedEvil CrackMe #1

Análisis y Parcheo.

Buenas, a todos los lectores de @rroba, soy SparK, del team DisidentS, y les ofrezco mis nobles y humildes conocimientos en este arte de la Ingeniería Inversa.

Espero que se diviertan tanto como yo lo he hecho con este crackme, en realidad no es nada difícil, pero a veces es lindo acorralar fácilmente a una víctima o no?

Quizás algunos de ustedes sean avezados Reverser’s y piensen al leerme, ¿pero que es esto? ¿El abecedario una y otra vez?, quizás otros novatos newbies, o simplemente lectores interesados en este arte digan: “mmmm, interesante”, quiero que sepan todos ustedes, intentaré darles siempre pensamientos frescos e ideas nuevas, por eso es bello este arte, es muy diverso.

Pero, vamos por partes, dijo Jack el Destripador, ¿Qué es un Crackme?

Ok, para los que no lo saben, un crackme es un programita que sirve para ejecitarse en el arte de la ingeniería inversa, en pocas palabras, es un “ejercicio de aplicación”.

¿ Que lograremos crackeando un crackme?

Pues, muchísimas cosas, primero, hay crackmes con las mas diversas protecciones y ocurrencias, en síntesis sirve para poder aprender, concentrarse en ese código difícil de aprender e interpretar a simple vista llamado Ensamblador, para poder memorizar técnicas, rutinas, y luego, en otro momento cuando miremos otro código digamos, “ah!, es mas o menos parecido a…” , en fin, ejercitas, la lógica, la memoria, y a la vez si no sabes o no entiendes ni medio de lo que pasa en ese maldito crackme, aprendes, que es lo más importante que te puede suceder aquí.

Les daré mas pistas, existen muchos tipos de ejercicios de aplicación, algunos de ellos son los Reverse me’s, los Tool me’s y demás, los primeros debes conocer ensamblador a fondo, y reprogramar la aplicación, o inclusive agregar código faltante, ¿ interesante no ? , ya veremos algunos, no desesperéis….

Este Crackme, lo he bajado de www.crackmes.de , y hasta hoy no tenía solución.

El crackme, tiene un aspecto como una caja de registro típica de cualquier programa, deberemos ingresar Nombre de Usuario, Serial, y luego click en Check.

Si hacemos click en Read the Rulez!, nos dirá que debemos programar un keygen, ok, ¿que es eso? Un programa que genere seriales aceptables para el crackme, ingresandole cualquier nombre de usuario, para poder hacer esto debemos conocer y entender que sucede dentro del crackme y como se calcula el serial a partir de un nombre de usuario dado.

Ok, empecemos parcheándolo, ¿porque? , pues porque no tenemos que analizar mucho para parchearlo, aunque no este permitido en las reglas del juego, lo haré para explicarles a los más novatillos como se debe hacer.

Les comento algo a todos, parchear es nocivo para la mente del cracker, se dice que es un sucio crack, aquel que pudiendo aplicar técnicas mas “finas”, parchea, ¿ porque ?, porque aquí queremos aprender, y el facilismo nos lleva a la mediocridad, entonces, si parcheamos, es fácil crackearlo, como verán solo cambiando uno o dos bytes, pero si hacemos un serial fishing, y aún muchísimo mejor , programamos una keygen, estamos demostrandonos sobre todo, que sabemos bien lo que sucede en nuestra querida pc, y que podemos entender tarde o temprano, lo que sea. Aunque si no está a nuestros alcances hacer un keygen aún, paciencia, parchear es divertido

Carguemos el Olly, (¿que porque olly?, porque me anda muy bien en mi win xp), y ejecutemoslo, presionando F9, ¿que sucede?, aparece nuestro programilla, ponemos un nombre de usuario, SparK, ahora un serial, 0123456, y click en Check, que sucede?……… NADA!

Ok, se dice en el Zen Cracking, que todo cracker necesita una referencia para penetrar en el código de un programa, los seres humanos, tenemos referencias, los objetos los identificamos con los sentidos, son distintos, son reconocibles, en el cracking sucede lo mismo, el cracker necesita un punto de referencia, al principio los novatos necesitan puntos de referencia mas “humanos”, pero luego, te acostumbras al lenguaje interno de las máquinas y empiezas a encontrar referencias que antes no veías, esto , se llama práctica.

Nuestro punto de referencia, aquí sería un cartel, llamado messagebox que diga “Incorrect Serial” o algo por el estilo, entonces, nosotros desensamblaríamos el programa, y buscaríamos donde se llama a ese messagebox y un poco antes encontraríamos el salto que nos lleva al cartel exitoso o al fracaso, simplemente invertirlo y PUM!, “You are registered”.

Pero no, no soñemos mas, enfrentemos la realidad, no hay messagebox, no nos dice nada, pero tampoco nos registra y eso nos pone mal, muy mal.

Ok, busquemos en el Olly, por alguna referencia de strings, miremos un poquito más abajo y encontramos algo como esto:

Perfecto!, algunas referencias hemos encontrado, miren esta, “Congratulations, you cracked this program ”, miremos mas arriba de esta referencia, y encontramos este salto:

004012E8 |. 74 0F |JE SHORT CuTedEvi.004012F9

Bien, si invertimos ese salto, tendríamos que estar registrados, probemos cambiar el 74 por un 75 (JNE), hagamos click sobre la instrucción de salto, presionemos la tecla espaciadora, y ahora, cambiemos el JE por un JNE, y listo, apretemos F9, ¿¿que pasa?? nada, sigue haciendo lo mismo, ¿pero que pasa aqui?

Seguramente existe lo que se llama, mirror check, es un chequeo primario o secundario, que se hace en otra parte del código, que seguramente chequea longitud del nombre de usuario, del serial ingresado, o algun cálculo con ellos posterior, miremos un poco más, ¿ven porque no es bueno parchear a lo bruto?, si no conoces el código y lo haces mecánicamente, puedes quedar mal parado ante una demostración ;oD

¿Pero, como encontrar el otro chequeo?, miremos, observermos, debugiemos el código, una y otra vez, pongamos breakpoints, haber, ¿ que sucede generalmente en estas rutinas a nivel interno para obtener los textos introducidos por el usuario?, una pista, referencia, aparentemente oculta, pero existe, generalmente se llama a la API GetDlgItemText, o GetDlgItemTextA, para obtener el texto, pues ¿que hace?, obtiene el texto del editbox del nombre de usuario por ejemplo, y pone en el registro EAX la longitud del texto introducido.

Busquemos la/las llamadas a esta hermosa API…..

Aquí hay algo interesante:

Ok, tenemos en 0040115B que carga el ID de uno de los editbox, seguramente el del nombre de usuario, y en

0040117E, el ID del serial, ahora 00401166 y en 00401191 es llamada la API mencionada.

Fijense algo curioso, luego de llamarlas a las APIs encontramos lo siguiente:

0040118E CMP EAX,0

00401191 JE CuTedEvi.0040132B

Recuerden que les conté en secreto que GetDlgItemTextA, devuelve en EAX la longitud del texto extraído de una editbox, entonces, aquí compara la longitud con 0 y si es 0, salta a otro lado, con lo que no iría por buen camino, ya que nosotros debemos ingresar un serial y un nombre de usuario, sino no chequeará nada y seguirá su rumbo…..

Existe otra API llamada lstrlenA, que justamente obtiene la longitud de una string. ¿ pero porque esta llamada aquí ?, si ya sabemos cuanto tiene cada string… quiere decir, que debe necesitarlo, miremos:

PUSH CuTedEvi.0040332B ; /String = “”

CALL <JMP.&KERNEL32.lstrlenA> ; \lstrlenA

CMP EAX,0

JE SHORT CuTedEvi.004012F7

De nuevo un chequeo por 0, y salta a donde el otro chequeo lo hace, 004012F7, como podemos ver, ese salto, es por donde NO debemos ir.

Bien, pensemos ahora, que sucede, ¿si no salta a 004012F7?, algo hace, algo debe hacer, y de hecho lo hace…

ROL es una instrucción de cálculo, rota los bits hacia la izquierda, hagamos de cuenta que multiplicamos por 5 (en decimal) un valor.

SUB resta 123 (en hexadecimal).

ADD suma 321 (en hexa también)

CMP compara con un valor, en este caso 2FE.

Luego si, no es EAX ese valor esperado, salta al famoso salto del fracaso.

Apliquemos Ingeniería Inversa:

el valor esperado en eax como resultado de los cálculos es 2FE (33 en decimal), en EAX, tenemos la longitud de la cadena serial luego de llamar a lstrlenA, entonces, hagamos el cálculo inverso para ver, que longitud necesitamos tener en el editbox serial.

Tomemos 2FE, restemosle 321, esto nos da un número negativo FFFFFFFFFFFFFFDD, ahora sumemos 123, y nos da 100 (siempre en hexadecimal, no se confundan), ahora ROL multiplica por 5, ahora DIVIDAMOS por 5, ¿¿ y que obtenemos ?? un lindo y hermoso 33.

Esa, esa cifra señores, es la longitud que el programa necesita que tenga el serial, para poder seguir chequeando.

Ahora , modifiquemos el valor del serial, y miremos, que pasa: 012345678901234567890123456789012 , ese serial introduje yo, 33 valores cualquiera ni más, ni menos…

Ahora miremos que estamos muy cerca de los cartelitos de antes, ¿se acuerdan?, ok, les muestro que pasa antes:

Ok, tenemos el salto que habíamos parcheado hoy, pero, con la diferencia que sabemos que pasa antes, ahora solamente lo que podemos hacer son dos cosas, o introducir un número cualquiera de 33 caracteres, y luego parchear ese salto, o sino, parchear los dos saltos:

Primero: CMP EAX,2FE

JNZ SHORT CuTedEvi.004012F7

Segundo: CMP BL,0

JE SHORT CuTedEvi.004012F9

y Listo!, felicidades lo has logrado.

convert this post to pdf.

Lo bajo de la web de thinkcore: http://www.thinkcore.com/utilities/networking/NetSS-v1.0.zip

Lo abro… y nada :O no había código, un EXE y un readme.txt…. ¿es justo?

Este programita, es muy simple, envía mensajes anónimos por net send, el famoso mensajero de windows XP… el truco, es muy fácil y simple, por eso no me gustó que no pusieran el código fuente, de algo tan simple, para mostrar a la gente como se puede hacer…

Me dije, ¿ es necesario debuggear y analizar lo que hace ? me dije, si… y aquí estamos

Abrí el ejecutable y me encontré con esto en Olly:

Como veremos para ojos entrenados, esta empacado… es simple de ver… no es un entrypoint “normal”. Si corremos el Peid no nos dará nada, y el rdg tampoco dará nada, así que no importa, lo cargamos en el Olly como vemos y debuggeamos un poco….

Dará vueltas, miles, armando todo nuestro ejecutable final… al final, damos F9 y lo ejecutamos del todo… lo veremos abierto….

Pondremos un breakpoint de acceso en la sección de código de nuestro proceso netss.exe de esta forma:

Ahora hacemos un click en la aplicación y Olly saltará, permitiéndonos volver al proceso principal, y mirar nuestro desempacado en memoria 100% libre de ataduras.

Veremos el código así:

Veremos que necesitamos sacar el análisis ya que Olly no lo interpretó bien….

Ahora si nuestro “EP” tiene más color ¿no amigos?, ahora haremos el volcado con el ollydump, si lo ejecutamos se romperá… ¿ qué está mal?

Si hacemos scroll veremos algo más que puede ser un entrypoint más posible que ese…

Nuestro dump se rompe porque hace un cmp con un valor específico… calculo que lo hace para ver que botón se ha presionado en el formulario, típico de aplicaciones en win32asm, como dicen los autores que lo hicieron.

He aquí más arriba algo más normal del principio de un programa en win32asm, todo definido, el querido GetModuleHandleA, hasta ExitProccess, está todo listo.

¿Cuál es la definición final? Deberemos modificar el Entrypoint, ya que si cargamos el dump con Olly, empezará en la dirección 40102B y no en 401000 que es donde debería empezar…

Para eso abrimos un editor PE cualquiera, probé uno nuevo llamado PEiT (Pe Insight, desde rusia).

Modificamos el valor del Entrypoint y quedará así finalmente:

Finalmente el EP quedará apuntando a 401000, grabamos los cambios, lo probamos y voilá! lo hemos hecho.

Bien, pero el tema era ver como enviamos esos mensajes anónimos, y si miramos un poco el código fuente, nos daremos cuenta que una de las API’s usadas son para enviar con a través del servicio mensajero.

NetMessageBufferSend

Ahora veamos como carga los parámetros cuales son cada uno, y listo, ya sabemos el secreto…

Está todo dicho amigos, la magia, el misterio se terminó… ya sabemos que parámetros y que API del sistema deberemos llamar….

La información debe conocerse, coincido que NO toda a veces, pero este tipo de información ocultarla no tiene sentido amigos… tarde o temprano… se sabe.

Google nos da pocos resultados sobre esta API, encima eso… it’s is a must dar a conocerlo a la gente…

Gracias a todos por leerme, saludos a z0mbie, GriYo, kaze, la gente de indetectables, al hispano #crackers, #Disidents, #hackers, #virus, la gente de crackslatinos, y muchos más, aún seguimos vivos.

Saludos,

SparK.-

convert this post to pdf.