28/3/11

Sorteando maleficios

Esta vez he cumplido, me he entretenido mucho y he sufrido muchos dolores de cabeza, por culpa del AntiRunPE. ¿Alguien se imagina lo complicado que puede ser escribir en memoria sin tener WriteProcessMemory? ¿Alguien se imagina lo complicado que puede llegar a ser, una vez que tras 20 pruebas, encuentras una que escribe en memoria, utilizar otra diferente a OpenProcess? Pues nuestro amigo, tal y como vimos, nos deja inutilizadas, tanto una como otra, y os puedo asegurar que he rozado la locura, pero... Todo esfuerzo tiene recompensa... ¡Y lo he conseguido! Un programa que tras ser ejecutado en el AntiRunPe, ejecute sus acciones maléficas. Muahahahha

Siempre que he leído a los grandes de CracksLatinos, una de las cosas que más me molestaba, era... ¿Por que son todos mejores que yo? Saben siempre donde pinchar, y aciertan... Por lo que contaré la aventura real, y para aquellos que no quieren tochaco, al final tienen el módulo en VB, que saltea al Anti RunPE.

Primero de todo sabía que tenía que restaurar lo que modificaba el programa de physmera, así que debía comenzar luchando para restaurar el orden de: OpenProcess y WriteProcessMemory. Los 2 apis que utiliza un runpe normal y corriente.

El primer golpe, fue hacerlo todo estupendo de la muerte, para WriteProcessMemory, horas después de estar escribiendo un código funcional, me daría cuenta de que OBVIAMENTE al estar hookeadas, no me funcionarían. ¡PALMFACE! Sí, no estuve muy lucido.

Mi siguiente idea fue... Si puedo cargar una DLL en memoria, ¿la podré descargar? ¿La podré Recargar? Como idea es maravilloso, me hookean el código, recargo la librería y tengo todo de nuevo funcional y todo mi anterior trabajo, podía reutilizarlo. Vale... No encontré ninguna formula mágica para hacer eso xDD.

Recordando algún tuto, sabía que GetProcAddress, y LoadLibraryA, me podrían permitir cargar una librería en memoria, con ayuda de Ollydgb (mi fiel compañero sancho en esta batalla), pude comprobar que es correcto, carga una Liberia en memoria, de dicha Liberia saca la parte donde está WriteProcessMemory, ¿y sabéis que? :D, ¡No sirve! Me lleva directo a la zona hookeada!! Si ya está en memoria, lo reutiliza...

Ahora ya sí que sí, no puedo fallar... ¡La api RtlMoveMemory! Sí, hace justo lo que necesito, sólo tengo que cambiar un poco la idea inicial, no pasa nada, reescribo todo el código para esta api, lo ejecuto, ¡ostión!, ¿pero que!!?, ale a estudiar por que me falla, con una búsqueda normal, nada, con una búsqueda de un ratito largo, alguien hace la indicación de que la escritura a la librería tiene una protección, que ha de saltarse dándole permisos de "lectura, escritura y ejecución", miro con olly.. Y curiosamente tiene estos permisos... Me estudio como aplicar el api VirtualProtect, para darle los permisos... y... ¡Funciona! (por cierto, con WriteProcessMemory esto no es necesario y me enfado mucho :P)

Para comprobar si alguien está usando el programa de physmera, leo en memoria el primer byte de Write..., esto es así, por que desde el primero ya lo modifica, para ello sólo necesito llamar a OpenProcess, ReadProcessMEmory, y recibir el valor, comparar y proceder a la acción requerida.

Ya tenemos, la zona de memoria con los permisos buenos, ya tenemos una forma de restaurar la api, y de comprobar si nos han hookeado, lo probamos todo y.. ¡Funciona! ¡Funciona perfectamente! (esto, el sábado por la tarde). Por fin, puedo añadir el modulo a un RunPE normal, y probar su correcta ejecución. Perfecto, desde mí modulo de VB, todo correcto. Esto al final está tirado...

Creo un stub funcional con mi amada y cariñosa calculadora de Windows, y con mi modulo perfectamente funcional, lo ejecuto y!! Mi programa no detecta nada, y el de pysmera, funciona como si tal cosa... A buscar que esta fallando... De alguna vez trastear con cracking, recordaba que OpenProcess, no puede ser llamado 2 veces, por distintos programas... ¿sabéis quien necesita el handle de OpenProcess? ¡¡ReadProcessMemory!! ¡Estoy como al comienzo! Esto no funciona, por que no detecta si me hookearon o no, y ante la duda funciona sin modificar nada...

De nuevo, toca estudiar, como cerrarle un handle a otro proceso... Vueltas y más vueltas, prueba aquí, prueba allá... No encuentro nada que me permita esta forma de intrusión en otro proceso, por lo que toca estudiar sobre OpenProcess, y descubro, que se puede duplicar, sólo necesito tener... ¡EL HANDLE ORIGINAL! Sí, duplicateHandle, me pide el original, fantástico... Otro api, que no me sirve... De veras, todo esto en ASM, me hubiese llevado mucho menos rato xD.

Buceando, descubro que puedo conseguir un handle funcional con GetCurrentProcess :D, probamos y desde código, funciona perfectamente, cumple con lo que necesito... Ahora sólo nos queda probarlo con el AntiRunPE, lo ejecuto y por fin... por fin... Hace el baile en la memoria, y se ejecuta mi calculadora... Eso sí, recibiendo un error en el programa que realiza el unpack, lo pasamos a olly, y veo que la rutina del error, se decide si el fichero que busca "existe". Le hago una copia del solitario (por que es muy inofensivo). Y ¡Tachan! Aplicación engañada en apenas.. ¿3 días? XD

Resumen:
-Cargamos librería
-Cargamos dirección del procedimiento
-Leemos en memoria
-Comparamos si esta hookeado seguimos
-Harcodeamos (winXP sp3). Los datos de WriteProcessMemory
-Lo pasamos a un array de bytes (Esto es por mi comodidad)
-Desprotegemos las zonas de memoria afectadas
-Copiamos a memoria los datos buenos
-Liberamos la librería de memoria
-Copiamos el solitario pa tocar las narices.
-¡Fin!

¿Ahora a que parece fácil?
Aquí, adjunto tanto el Carbon Crypter, con el que hice las pruebas, como el módulo de VB, válido para Windows XP SP 3. Ya que las direcciones estan hardcodeadas.


Link de descarga

21/3/11

Sexo con crypters

Algunos ya saben que me gusta mantener mis relaciones sexuales con un alto contenido en binario, tras un par de noches de insomnio, me recorria una duda... ¿Cómo funcionaría el Runpe Killer de Psymera? Lo que conozco de dumpear un proceso, requiere que se encuentre ya en memoria, para poder acceder al mismo. Con esta premisa, ¿Podría saltar desde algún sitio hasta mi bicho? Es decir, quien lo quisiera analizar, estaría obligado a infectarse, y si se realiza bien, no se daría cuenta de que ocurrió.

Nota: El destino del tutorial, no es ir infectando, ni haciendo mal. Es demostrar que con una utilidad, "segura", en este caso, una aplicación de defensa, que bien podría ser un antivirus, un firewall, o cualquier otra herramineta. Se tiene tambien que tener siempre cuidado. Por este motivo, es útil, trabajar en máquinas virtuales.

Por lo que aquí, comienza mi aventura analizando algo que no sea un serial.

Probando puntos clave, decido poner un BP (Break Point), en sitios que se me ocurre tendrán que cargar, los bp son:
-GetThreadContext
-CreateProcessA
-SetThreadContext
-WriteProcessMemory
-VirtualAllocEx
-ReadProcessMemory

Si alguien pregunta ¿Por que? Creo que yo, utilizaría esos, para realizar una aplicación de este tipo, sí, SetThreadContext, quizá es un poco abusivo, pero yo el sexo con binarios lo hago duro.

La primera en la frente, bajé un crypter público de indetectables, precisamente algunos de los que nombra el killer, no tenía ganas de codearme uno, y así hacia el reto más complicado, desconocia los vicios programando de ambos bichos.

Primera parada; Puerta de Arganda, lo siento. CreateProcess, me dice que hemos llegado, me llama la atención un punto, el flag del programa está en Deatached_process ¿Por qué? ¿Qué es esto? No me queda muy claro en la especificación de win32 sdk, viene a ser para el correcto funcionamiento de aplicativos de consola. Personalmente creo que no sería necesario pero...

Si me quedo haciendo el bobo, el programa sale directamente en memoria, y tenemos la infección completada, aquí tengo una pista, al salir del ret, descubro que es lo que ocurre... Un SuspendThread, justo antes un push eax, que contiene la dirección del proceso que ha creado recientemente.

De nuevo, si tardo, no sólo lo ejecuta 1 vez, si no que pueden llegar a ser hasta 4 (aumentando en 5 segundos cada vez el tiempo de pausa en sleep). Supongo que busca algo en el proceso creado, al no encontrarlo, lo llama de nuevo. Todo esto, es opinión, aun no lo he analizado.

Traceando veo que realiza una busqueda de EAX = 1, cuando intenta escribir en el proceso, si ha fallado, vuelve a intentarlo una y otra vez, por este motivo se me estaba ejecutando tantas veces; Para solucionarlo con un editor hexadecimal, cambié el EP, por EB FE, un salto sobre si mismo, así dejo el proceso loopeando, y puedo tardar cuanto tiempo quiera, simplente debo recordar restaurar el valor correcto una vez finalizado.

La aplicación realiza:
-Abre la aplicación
-Espera 20 milisegundos ¿? No tengo muy claro, el por que... Supongo que da cuartel para que abra. De ahí que si en 20 milisegundos, no controló la aplicación, la vuelva a llamar (esto es malo, significa INFECTADOS). Personalmente, sin animo de molestar al programador, yo, la hubiese ejecutado directamente pausada. Me evito el trabajo de dormir mi aplicación, y puedo asegurarme que no me infecto. De todos modos, el programador, ya avisa de esta posibilidad.
-Crea una nueva sección donde meterá la ruta del ejecutable, es decir la que utilizará despues, cuando modifica WriteProcessMemory.
-Escribe en la nueva sección creada en el ejecutable,
-GetProcessAddress; Ahora empieza lo divertido
-Localiza: OpenProcess
-Parchea OpenProcess, con 12 bytes, que sólo hacen mover 0 a EAX, para indicar que todo fué bien.
-Localiza: WriteProcessMemory
-Parchea WriteProcessMemory con 127 bytes, guarda los registros, y procede a copiar todo lo que entra en la api, directamente sobre un fichero, cuya ruta está indicada en la sección nueva que crea el programa.
-Finalmente al pulsar el botón, unpack, nos reanuda el proceso, con todas las modificaciones que se han realizado anteriormente.

Mi reto ahora consiste en A) Parchear de forma que el programa realize la carga en suspendido, y no como lo hace actualmente, (por seguridad), B) añadir un código, haré un modulo que exportaré para que lo use quien quiera, que nos permita saltar el actual Runpe Killer; tambien el parcheado por mi.

Pero tanto para obtener el programa como para obtener el modulo tendreis que esperar al próximo post, que con una poca suerte, no será dentro de 3 o 4 meses.

Pd: Por último y no menos importante, agradecer el trabajo a psymera, espero que no se ofenda por algún comentario que hago, de verdad, no son con maldad, lo que has programado está genial. Simplemente aporto una visión diferente.

Un saludo,
WiNSoCk.