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.