Antes de comenzar recordemos que la versión “Trial” que ofrecen en la página oficial es una versión incompleta aunque tiene limitación de uso por días, pero además no puedes usar el software con todas sus opciones, por lo tanto viene incompleto… sinceramente ya había terminado un escrito para burlar la limitación por días, pero pensé que si hare algo debo hacerlo bien, así que reinicie mi tutorial y apenas siendo las 2 am busque por la red su versión 9 completa y me han facilitado un enlace, así que comencemos de nuevo.

Para los que me conocen saben que siempre intento hacerlo de la mejor forma o la mas completa, me saltare las partes básicas y que he explicado en otros tutoriales, pero si tienen alguna duda respecto a llevarlo a la práctica, por ejemplo si su olly es detectado o no lo tienen bien configurado,etc, al final del escrito dejare medios de contacto y me daré un tiempo para resolver sus dudas.

Continuamos con las herramientas que usaremos:

-Ollydebugger
-PID
-Topo

adjunto el link para descargar el acunetix (sin parchear) para que hagan las pruebas:
http://uppit.com/lcymxxea9jow/webvulnscan9.rar

tambien adjunto el codigo ASM que usaremos, para que hagan pruebas, el codigo esta muy comentado y en caso de tener dudas puedes revisar el tutorial del cual les platicare adelante (continuen leyendo)
http://uppit.com/4r8bnmh4fxrc/OBTENER-DLL.rar


Como les explicaba, una de las cosas que debemos hacer antes de ponernos a jugar con algún binario es necesario saber contra que vamos a luchar, abrimos el scanner y veamos:

Como verán no hay mucho que explicar, es un binario cifrado con Themida en su posible versión 2.0.1.0 – 2.1.6.0  o mas reciente, cuando tratamos con packers comerciales de este tipo sabemos que no dormiremos pronto…  así que dejare de lamentarme y me pondré con ello.


Les cuento;  tengo en mente 3 formas de atacar esta protección:
1: la primera consiste en armarnos un loader a mano como explique en “elladodelmal”  (blog de Chema Alonso) e ir viendo al paso que cambios haremos.
2: como segunda opción podría tomar algún script para desempaquetar “themida” de los ya creados por otro reverser e intentar acomodarlo para desempaquetar el binario o bien hacerlo a mano como he hecho algunas ocasiones (resulta agotador).
3: parchear directamente el binario cifrado armándonos un ataque mejor conocido como “inline patching”  el cual solo lo he hecho un par de veces (por lo largo que resulta).

Pero vamos me iré por la mas larga y es algo que me apoyare en algo que ya les explique en la tercer parte del curso de desarrollo de malware que vengo escribiendo…  Tomaremos una rutina complementada de otro poco de código que explicare adelante, lo incluiremos en una sección nueva que crearemos dentro del binario y nos armaremos un ataque bonito.

Lo primero que haremos será crear una sección nueva y vacía donde podamos incluir código que básicamente será el código de un loader, para mayor información de que es un loader, podrían leer :
http://www.elladodelmal.com/2014/02/loader-simple-acceder-al-binario.html

Seguimos, abrimos nuestra herramienta “Topo” que básicamente nos sirve para crear nuevas secciones, abrimos:


“open” seleccionamos el ejecutable “wvs.exe” dentro de la carpeta donde se instaló y listo, una vez seleccionado veremos estas opciones, lo cual seleccionaremos:


Lo que está preguntando aquí es si queremos crear una nueva sección o usar un espacio vacío dentro del binario sin afectar su tamaño original, pero no me interesa y quiero crear una nueva sección así que selecciono “Create new section” y ahora vamos a llevar las opciones, donde primero ubicaremos la cantidad de bytes a agregar que en este caso puse “2000” y tildamos la opción para que nos redirija como punto de entrada a la sección nueva y que nos haga un backup en caso de cometer algún error :


Presionamos “Do IT” :
Al parecer todo ha quedado perfecto, pero ahora es necesario ejecutar acunetix a ver si el protector o el software no ha detectado algún cambio de tamaño del binario que es una de la protecciones que incluye este packer, que esperemos no la hayan activado, crucemos los dedos y veamos:
Es grande la decepción, pero no porque haya detectado el cambio, si no porque el mensaje ya es conocido y estoy seguro que el cambio es detectado directamente del código de acunetix tal como explique en la versión anterior y es sencillo burlarla (ya lo verán), puesto que si hubiera sido del packer el chequeo seria otro tema, pero vayamos a confirmar esto, abrimos nuestro debugger y veamos que iniciamos en la sección creada:
Si presionamos la letra “M” (botones azules) veríamos el mapa de memoria y fácilmente identificamos la zona creada por topo:


Presionamos “f9” o run hasta ver el mensaje y una vez que nos aparezca el mensaje que el archivo esta corrupto, presionamos pause o “f12”
Este metodo es simple al presionar pause cuando sale el mensaje, en el logueo de llamadas “call stack” (letra K de los botones azules) podremos observar esto:

Lo cual es la llamada al “MessageBoxExA” y podríamos seguirla fácilmente para saber quién es el responsable de mandarnos este mensaje, damos click derecho “Follow Address in stack” y veremos en el stack las direcciones de retorno.
Podemos observar en el stack o pila que la primer línea es una dirección de retorno pero estaríamos dentro de la emulación de la API o fuera la sección .code que es donde ejecuta código del programa, por lo tanto me voy un poco mas abajo y observo la segunda dirección de retorno que al parecer está dentro del rango de la sección .code 0040100, selecciono esa dirección y presiono la tecla “enter” y llegamos a esta zona:
Claramente pueden observar (agregue comentarios para mejor comprensión) estamos debajo de la llamada responsable del mensaje y no hay mucha ciencia, mas arriba tenemos un salto condicional (JE) que evade todo este meollo supongo que hace el mismo chequeo que la versión anterior por lo tanto no explicare, claro que es algo diferente porque las API’s  ahora están emuladas por el protector pero ese es otro tema, seleccionemos ese salto condicional y presionamos click derecho y ubiquemos un “Hardware BreakPoint on execution” :
Reiniciamos nuestro debugger y corremos de nuevo el proceso, solo que en esta ocasión se detendrá justo en el punto de ruptura que ya pusimos, antes de mostrarnos el mensaje:

Como verán la línea indicadora del salto se marca en gris, que significa que el salto no será tomado, que pasa si hago este salto un salto incondicional, ósea que salte siempre sin importar lo que pase, para seleccionamos y presionamos barra espaciadora y cambiamos de esta forma:

Que alegria! , pues hemos burlado el primer chequeo y como verán el proceso se cerró dentro del debugger pero nos ha mostrado una ventana pidiéndonos activación, para los que leyeron mi escrito de la versión anterior sabrán que es parte de la verificación de licencia, si no la encuentra este llama a otro ejecutable llamado “activation.exe”  así que bueno lo primero que haremos será empezar a meter código para bypassear esta primer limitación ya que como vimos hicimos únicamente cambios en memoria, pues cuando un software está cifrado este se va descifrando en memoria hasta mostrar el código real pero hay un método para poder cazar el código cuando está siendo descifrado..  lo demás es cosa sencilla.

Empecemos, para los que leyeron la tercer parte del curso de desarrollo de malware, ya sabran de lo que hablare si no pues los que quieran les dejo enlace:
http://www.hackingmexico.mx/desarrollo-de-malware-desde-cero-3/

Verán que explique cómo obtener a mano nuestras API’s  ya que no podemos solo programar código dentro de un binario ya compilado ya que este usa su propia tabla de importación, por lo tanto usaremos el código que explique anteriormente para poder encontrar la API “GetProcAddress” en base a eso podremos hacer mil cosas mas,  el enlace del codigo que usaremos esta al iniciar este tutorial (deje enlaces descarga del codigo arriba), aunque si quieren entender el “porque” entres  al curso de desarrollo de malware parte 3 donde explico el codigo adjunto, así que comencemos, abrimos el proyecto en radasm y ya compilado el ejecutable lo abrimos dentro de olly para copiar el código desde el inicio hasta terminar y los únicos cambios que deberemos hacer son agregar este código antes de compilarlo y cambiar la dirección donde se encuentra el string “GetProcAddress” como muestro adelante:
Los cambios, el primero es para guardar los registro en la pila y volver a recuperarlos al terminar todo el meollo, como si nada hubiese pasado, es por eso que debemos sumarle +20 a ESP porque se desacomodo un poco la pila con el pushad. Ya compilado con esos pequeños cambios ahora lo abrimos dentro de olly para copiar el código:
Copiamos el código, ahora vamos a abrir acunetix en otro ollydebugger y pegamos el código en la zona creada anteriormente:
Bajamos y casi al final del codigo injertado podremos ver el jmp que nos agrego topo para redirigir a la zona donde estaba el punto de entrada y como no usaremos esa parte metemos el string en esa direccion y modificamos muestra la imagen de arriba.
Solo son dos parámetros, el primero es la dirección de la dll que contiene a la API que en este caso es kernel32.dll lo cual esa dirección ya la tengo por algún lado del stack guardada, el segundo parámetro es el nombre de la API que esa la ubicaremos cerca de donde ubicamos el nombre de “GetProcAddress” veamos cómo quedaría:
Vaya ahora bien en código les explico los parámetros que debemos meter como lo hicimos anteriormente pero ahora para cargar nuestro hilo:
Todo es “NULL” o “0” y lo único que debe importarnos es ubicar en algún registro la dirección donde queremos poner nuestro hilo y quedaría algo así en el código injertado:

Como verán meti en el registro ECX un offset que será donde ubicaremos nuestro loop para buscar código y será nuestro hilo… (ignoren el ultimo “JMP” lo ubique para probar si el hilo era tomado) por lo tanto con esto avanzado podríamos recuperar los valores de la pila a como estaban con la instrucción POPAD (recuerden que al inicio colocamos un pushad para salvar los registro en la pila) y regresar a donde originalmente iniciaba el programa y tendríamos un hilo corriendo en paralelo buscando los bytes a parchear que adelante mostrare, mientras pongamos el código restante para devolver la ejecución al inicio del programa como normalmente comenzaría:
Salvamos los registros y ponemos un salto a donde iniciaba el programa antes de agregar la sección con topo, antes de guardar los cambios que ya hemos hecho, pasemos al offset donde se encontraría el hilo y metamos el código, pero antes recordemos algo en qué dirección se ubicaba el salto que queríamos cambiar, pero quiero mostrarles como luce cuando aún no es ejecutado el programa y el código está cifrado:
Cifrado:
Descifrado:

Ahora bien, los bytes descifrados son los siguientes y por lo tanto los que deberiamos buscar en nuestro loop son los siguientes:
Y cambiarlos por lo que muestro a continuación:
Como verán se marcan en rojo los cambios que hice cambie el salto JE (condicional) por un JMP para que salte siempre sin excepción, solo cambia un byte (EB) con el parche que queremos colocar, por lo tanto una vez encontrado en memoria cuando se ha descifrado el programa parchearemos ese byte y colocaremos “EB” y listo.
Ahora escribamos el código siguiente:

Como vimos hace una búsqueda de los bytes y sigue repitiéndose el loop hasta que los encuentra y pasa guardar lo bytes nuevos en esa dirección que como verán solo cambia el “EB” y mas abajo coloque un loop infinito (solo para probar lo que ya hemos hecho) porque aún no hemos terminado de romper todas las limitaciones, solo estamos intentando con la primera recuerden que ya tenemos toda la maquina!!!  En casi de parchear mas cosas ya tenemos todo armado solo harían falta algunas 3 o líneas de código mas, probemos lo que llevamos hasta ahora. Así que guardemos y corremos acunetix, crucemos los dedos y probamos:

PAWW!!!  Ya no detecto los cambios y ha corrido como si nada 3:) , vencer las demás limitaciones es sencillo pues ya tenemos toda la máquina de nuestro inline patching, solo basta con hacer otras dos o tres comparaciones (4 líneas de código) y podríamos burlar el resto, pues la maquina ya está hecha que era lo complicado, ahora solo buscaremos que otros bytes cambiar… así que ya no se estresen.
Así que hemos hecho un inline patching a acunetix protegido con uno de los packers más potentes “Themida” creo que es momento de dividir este escrito, me gustaría probaran ustedes con las ultimas limitaciones pues ya hicimos la parte dura del “inline patching” ya logramos bypassear el chequeo que hace par a ver si ha cambiado el tamaño o ha sido parcheado… el resto es sencillo y si has leído mi tutorial anterior de la versión 8 podrás hacerlo si no, en un rato escribo el resto que prácticamente es muy simple,  en unas horas subo la segunda parte pero me gustaría empezaran con esto que ya les he mostrado que prácticamente es sencillo..

Saludos!

Alejandro Torres (TorresCrack)
Twitter: https://twitter.com/TorresCrack248

Fuente: http://www.hackingmexico.mx/crackeando-acunetix-v9-themidainline-patching-l/