showmycode.com --> Online Decoder / Decompiler.

Buenos días.

Como dice el título hoy vengo a compartirles un sitio muy funcional e importante llamado showmycode donde podremos decodificar php, JAVA class, Adobe Flash swf, .NET (DotNet) and QR bar codes.

Link: http://www.showmycode.com/

Saludos roboticos.

URLQuery

Con el auge de las infecciones de malware van surgiendo servicios online que proporcionan escaneos diferente índole algunos de estos servicios pueden ser Virus Total, Anubis ISecLAB y el que voy a explicar hoy, que es URLQuery.

Este servicio es la caña y la verdad es que se ha echo muy popular para el análisis de los Exploits Kits.

Vamos a ver un ejemplo de como funciona:

Como veis, abajo podemos ver los últimos análisis que se han ido haciendo, tenemos un cuadro de búsqueda desde donde podremos buscar dominios que hayan sido infectados con malware u otras amenazas.

Si queremos analizar una nueva URL, solo deberemos de introducirla y lanzar la URL a escanear.

Lanzamos el análisis y URLQuery analizará la web.

Podremos ver detalles como la IP. el location y exactamente con que User Agent se lanzará el análisis.

En este caso, la URL que he mandado a analizar no contenía ningún rastro de malware.

En un análisis, URLQuery ofrece varios apuntes en los report. URLQuery tiene por detrás productos IDS como Snort o Suricata, por lo tanto si hay algo en la página que se está analizando que tenga que saltar por alguna regla de IDS lo veremos reflejado.

También podremos ver cosas como, si en el mismo ASN, se han encontrado o se encontraron dominios que estaban infectados pues saldrán en el report.De esta manera podemos sacar mas información.

En el caso de que hubiera javascripts que cargaron algo del tipo malicioso en la página saldrían en el report.

Este es un ejemplo de cuando la web ha echo una petición en la que ha saltado una alerta en los sistemas de análisis de URLQuery

Podremos ver el detalle de la alerta. Además de que nos saldrá el código para que podamos analizarlo.

Hay una cosa muy interesante que tiene URLQuery y es que podemos cambiar cosas como el UserAgent o Referer por si el Exploit Kit o web maliciosa espera algo en concreto para poder infectar la usuario.

Vamos a ver algunas de las estadísticas de URLQuery

Estas son las URL que se han procesado en URLQuery y cuantas de ellas se han marcado como maliciosas.

Esta parte va muy bien para ver el tipo de tendencias en explotación que están habiendo.

Del tipo de alertas que saltan en URLQuery el top 5

URLQuery  es un buen servicio para analizar webs maliciosas, podremos ver estadísticas de Exploits Kits, alertas etc…

[+]URLQuery => https://urlquery.net/index.php

Fuente: http://www.dragonjar.org/urlquery.xhtml

Anubis: Analyzing Unknown Binaries

Este servicio también es ampliamente conocido por los investigadores de seguridad  a continuación paso a mostraros.

La web es muy sencilla de usar, vamos a ver primero que aspecto tiene:

Ahora lo que haremos será subir un binario al interfaz para que lo analice con su sistema interno.

Una vez que haceos examinar y metemos el captcha anubis hará upload hacia el servidor.

Anubis nos informa de que se ha echo upload en su sistema y que cuando se analice nos redireccionará hacia la página de resultados.

Esto es el resumen del análisis que ha hecho Anubis, podemos descargar el report de muchas maneras diferentes.

Vamos a ver el report en HTML.

Aquí tenemos unos indicadores que nos darán una información de primera mano del binario

Abajo de los indicadores tenemos información sobre el binario en si, primero de todo, datos sobre la integridad, versión del binario etc..

Nos mostrará las DLL que se van a cargar e incluso las DLL en runtime.

Otra parte importante que podremos ver es la información relacionada con el registro.

Es plausible que haya información, como claves almacenadas en entrada, que el troyano se inicie con el sistema etc..

Igual que es importante mirar el registro es muy importante ver los cambios de archivos que se producen en los análisis.

Es posible que a veces el binario haga una copia de si mismo por lo tanto podríamos pillarlo en el análisis.

Anubis ISEC Lab, es una herramienta que nos facilitará analizar un binario y ver como se comporta y que es lo que hace.

Fuente: http://www.dragonjar.org/anubis-analyzing-unknown-binaries.xhtml

Ingeniería inversa en aplicaciones de Android II

Se puede definir que el código generado para las aplicaciones Android no es exactamente “Java Bytecode”, por eso los ejecutables para Android no contienen ficheros .class si no .dex que significa Dalvik Executable. De igual forma estos ficheros .dex se pueden “decompilar” y lo que veremos posteriormente será un lenguaje de bajo nivel (Dalvik Bytecode).

Aunque como tal con algunas aplicaciones específicas podemos ver en un lenguaje de alto nivel estos códigos (aplicaciones como Dex2Jar posteriormente decompilando con JD-GUI). Algunos enlaces interesantes sobre Dalvik y los OPCodes:

http://www.dalvikvm.com/
http://pallergabor.uw.hu/androidblog/da ... codes.html
http://developer.android.com/reference/ ... codes.html

[size=18pt][b]Herramientas a utilizar y preparación del entorno[/b][/size]

Para la preparación del entorno tendremos en cuenta todo lo necesario para empezar casi “desde cero”, los requisitos como siempre son saber la lógica de un lenguaje de programación (mejor si es Java) y bueno, lo demás se explicará poco a poco.

Como trabajaremos con Android necesitaremos usar la plataforma Java, ojo, no basta con el entorno de ejecución (JRE) necesitaremos todas las herramientas para desarrolladores (JDK – Java Development Kit) y un IDE cualquiera, puede ser Eclipse. http://www.oracle.com/technetwork/java/ ... index.html

También necesitaremos las herramientas de desarrollo de Android o SDK, en el portal oficial hay una guía de instalación http://developer.android.com/sdk/installing.html también debemos configurar un emulador o el AVD, que nos permitirá ejecutar una “máquina virtual” de Android en nuestros ordenadores (ver aquí http://developer.android.com/sdk/adding-components.html).

Smali/Baksmali: se trata de un ensamblador/desemsamblador de ficheros apk que nos servirá para generar los fuentes en lenguaje de bajo nivel (aunque como tal no lo usaremos en esta guía). Se puede descargar de aquí: http://code.google.com/p/smali/

APKTool: Esta herramienta sustituirá el Smali/Baksmali ya que los integra dentro de su paquete. Como su nombre lo indica es un kit de herramientas para trabajar con ficheros APK.http://code.google.com/p/android-apktool/ con el generaremos el código de bajo nivel y luego recompilaremos.

Testsign.jar: Es una herramienta de terceros desarrollada para “firmar” o generar certificados aleatorios para indicarle al sistema que el fichero que hemos modificado se trata de una aplicación Android. Se descarga de aquí http://code.google.com/p/zen-droid/downloads/list (buscar el fichero testsign.jar).

zipalign: se trata de una herramienta que viene incluida en el SDK (PATH\android-sdk-windows\tools\zipalign.exe), que está hecha para preparar nuestro apk para el sistema Android, es decir, para que su rendimiento sea tal cual para dicho sistema ya que si no está “comprimida” con esta herramienta podría afectar el rendimiento de la misma en el dispositivo.

[size=18pt]Instalar aplicaciones APK en el emulador de Android[/size]

El AVD Manager Tool es la herramienta que nos permite gestionar distintas “máquinas virtuales” de un sistema Android configuradas para un api específica (es decir, para distintas versiones del sistema operativo Android). Supondré que ya tienen instalado el Android SDK que viene con el SDK Manager pero aún falta configurar dicho “emulador” o máquina virtual. Por lo que aquí explicaré como crear una. Lo que necesitaremos es ir al directorio en donde hemos instalado el Android SDK, allí veremos el ícono del logo o mascota de Android llamado SDK Manager, desde allí podremos instalar diversas apis y claro, configurar nuestra nueva máquina virtual.

Allí hacemos clic en la opción “Virtual Devices” y si es la primera vez que lo usamos de seguro no habrá ninguna máquina virtual configurada, por lo que hacemos clic en el botón de la derecha que dice “New…”.





Luego tendremos que configurarla. Los parámetros son:

Name: El nombre de la máquina virtual. Esta no puede contener espacios.

Target: Es el api que utilizaremos para ejecutar la máquina virtual es decir, como si fuera la versión de Android. Recomiendo de momento la “API Level 8″ o Android 2.2 que es lo mismo

Lo demás ya se configura una vez hemos seleccionado el api, pero si queremos parámetros adicionales podemos explorar la herramienta. Por último le damos a Create AVD.





Listo ahora la seccionamos en el listado y en la parte derecha le damos “Start” y “Launch”. Se empezará a cargar la nueva unidad virtual lo que puede tardar varios minutos así que debemos ser pacientes en este paso. Cuando arranque veremos una pantalla como si fuese un móvil Android, con el sistema operativo completamente funcional. Pero como lo que vamos a hacer es un proceso de ingeniería inversa necesitaremos probar la aplicación, por lo que surge la necesidad de instalar aplicaciones APK en esta nueva unidad virtual.

Lo base para esto será saber que las aplicaciones Android se deben copiar a la carpeta “platform-tools” por ejemplo, la mía está en C:\Android SDK\android-sdk-windows\platform-tools, esto porque allí hay una herramienta llamada ADB (Android Debug Bridge) la cual es una herramienta que funciona por línea de comandos y que también sirve de conexión de nuestro móvil al ordenador y realizar tareas desde allí

En esta ocasión la utilizaremos para instalar APKs, por lo que una vez copiado el APK al directorio “Platform-tools” debemos ejecutar (con el emulador abierto):

adb install fichero.apk o para desinstalar adb uninstall fichero





Ahora si todo ha salido bien veremos la aplicación instalada en el emulador. Por cierto, algo importante a tener en cuenta es que el emulador o unidad virtual debe estar ejecutándose al momento de realizar este proceso de instalación del APK.

[size=18pt]Instalar y usar ApkTool[/size]

Con el proceso anterior aprendimos a probar los APK. Bien, olvidemos por un rato eso y ahora iniciemos con el proceso de “ingeniería inversa” como tal. En esta ocasión usaremos APKTool, que básicamente sirve para cambiar algunas cosas de las aplicaciones Android pero además de ensamblar y desensamblarlas, que es nuestro uso principal en esta ocasión.

Para instalar APKTool deberemos bajar tanto el fichero apktool.jar (el principal) y si estamos en Windows debemos bajar las dependencias, veamos el proceso paso a paso mejor:

Descargar APKTool y dependencias (apktool1.4.1.tar.bz2 y apktool-install-windows-r04-brut1.tar.bz2).
Descomprimir todo en una sola carpeta.
Copiar estos ficheros al directorio principal de Windows, es decir, C:\Windows.

Listo ahora podemos ejecutar desde la consola de Windows el APKTool (Tecla Windows + R > cmd > Tecleamos apktool para ver todos sus parámetros). Para continuar con dicho proceso deberemos generar nuestro bytecode o fuentes en código de bajo nivel. Para “decompilar” nos ubicamos en la carpeta del APK y tecleamos en la consola:

apktool d fichero.apk nombre_nuevo_sin_extension

En la consola sería algo como esto:





Ya “desensamblamos” todo por lo que si revisamos la carpeta de nuestro APK hay un nuevo directorio el cual tiene el mismo nombre que le especificamos en la línea de comandos hace un momento. Lo que contiene son los ficheros fuente, el AndroidManifest.xml, entre otros recursos Lo que nos interesa es la carpeta smali, donde están los fuentes.

Si revisamos dicha carpeta y los ficheros generados, veremos unos archivos con extensión .smali, y lo primero que noto es un archivo llamado “main.smali“, pues sí, el código en lenguaje de bajo nivel.

En el tomo nº 1 de esta guía básica compartí un “crackme” o una aplicación Android que pedia un usuario y contraseña, no era más que una comparación de strings. Supongamos ahora que estamos revisando dicha aplicación y nos ponemos a buscar el mensaje de error que muestra cuando el usuario y contraseña son incorrectos.





Usaré ahora un editor de textos, de forma intuitiva uso el buscador para encontrar este mensaje y revisando un poco el código encuentro una comparación de strings, que no representan más que dicha comparación de usuario y contraseña. Pero estos string están declarados en un OPCode llamado const-string, por lo que ya sabemos la importancia de reconocerlos y que para buscar cadenas está el OPCode const-string.

Ahora, esto quiere decir que si cambio el const-string y la cadena encontrada en la comparación podré modificar los datos de acceso a la aplicación, si pongo por ejemplo “123” como contraseña podremos ver que pasa (sabiendo que la contraseña actual es “2014″ y el nombre de usuario como se puede ver es “ricadmin”):





Una vez modificado el siguiente paso será empaquetar nuevamente nuestro fichero APK, por lo que abrimos una consola de comandos, nos ubicamos en la carpeta donde estábamos trabajando y tecleamos:

apktool b carpeta_de_trabajo ficherocompilado.apk

Nótese que anteriormente yo había “desensamblado” y le llamé a mi carpeta “debug-crackmetest”. Tengan muy en cuenta los espacios que hay entre colocar el nombre de la carpeta y el del nuevo fichero compilado.

Y listo, con eso habremos generado un nuevo fichero APK con el nombre que le hemos acabado de poner (aparece en la misma carpeta de trabajo).





[size=18pt]Firmando la aplicación o “generando certificados”[/size]

Es importante decirle a Android que nuestro APK en realidad si se trata de una aplicación para Android, pues estos tienen ciertas características que el sistema lee antes de su ejecución como tal.

Para esta tarea usaremos el “testsign.jar” una utilidad escrita para dicha finalidad y que podemos bajar en para empezar a usarla debemos colocarla en la misma carpeta de nuestro APK recién compilado y en la consola escribimos:

java -classpath testsign.jar testsign compilado-firmado.apk

Tener en cuenta que esto se le aplica a nuestro APK recién compilado. Si todo sale bien no saldrá nada por pantalla:





[size=18pt]Generar un APK apto para Android[/size]

Listo, con el paso anterior “firmamos” la aplicación, ahora debemos optimizar el nuevo APK con una herramienta llamada “zipalign” que se encuentra en la carpeta “tools” de donde tenemos instalado el Android SDK.

El siguiente paso será copiar nuestro APK recién firmado a la carpeta “tools” que es donde se encuentra la aplicación “zipalign”, abrimos una consola, nos ubicamos en el directorio donde está la aplicación y nuestro fichero recién copiado y tecleamos:

zipalign -f 4 fichero-compilado.apk fichero-final.pak





Si todo sale bien tampoco saldrá nada. Ahora solo nos queda probar la aplicación y que los cambios se hayan realizado funcionen. Por lo que nuestro “fichero-final.apk” lo copiamos a “platform-tools” para instalarlo en nuestra unidad virtual que debe estar ejecutándose (por lo que en la consola escribimos “adb install fichero-final.apk”). Y el resultado es:

Fuente: http://www.indetectables.net/viewtopic.php?f=79&t=47407

Ingeniería inversa en aplicaciones de Android I

Formatos de archivo .DEX y .JAR

Como sabemos la mayoría de aplicaciones para Android están programadas en Java, los ejecutables de este sistema operativo tienen una extensión de tipo .APK, hasta aquí todo bien, pero debemos saber que esta extensión no es más que una variación de la extensión .JAR, por lo que si alguna vez hemos programado en Java sabemos que los .JAR funcionan como una especie de contenedor con varios archivos adentro, por lo que con cualquier compresor podemos extraer su contenido y ver una serie de archivos que son los que componen la aplicación.

Por lo tanto, si a una aplicación Android (.APK) le extraemos los ficheros con un compresor cualquiera podremos ver todos los ficheros que componen la aplicación:



Uno de estos archivos es classes.dex que será uno de los más importantes pues este es el que contiene las clases y todo el código en general de la aplicación.
Herramientas necesarias

Como mencionábamos más arriba, en Windows para poder ver el código en ensamblador de un archivo con extensión .exe usábamos el OllyDB, en esta ocasión haremos uso de una serie de herramientas que harán lo mismo y con esto podremos ver el código Java.

El proceso será sencillo, pasaremos el archivo .dex a .jar y luego descompilaremos este último. Para esto necesitaremos:

JD-GUI: Es una aplicación con interfaz gráfica muy intuitiva con la que podremos ver el código fuente de los archivos .class (básicamente .jar de Java). Con esta herramienta podremos ver clases, métodos y otros componentes del programa. Web oficial: http://java.decompiler.free.fr/?q=jdgui

Dex2Jar: Como su nombre nos lo dice, permite pasar de .dex a .jar, podemos usarlo individualmente o en conjunto con las herramientas que nombraremos aquí. Web oficial:http://code.google.com/p/dex2jar/

Eclipse: Es un IDE de desarrollo para varias plataformas y que funciona con java. Web oficial: http://www.eclipse.org/downloads/

Configurar .Dex2Jar en Eclipse

Lo primero será configurar un nuevo proyecto, por lo que vamos a File > New > Java Proyect, le ponemos un nombre al proyecto y damos a finalizar.



Seleccionamos nuestro proyecto en explorador de paquetes, luego estando seleccionado vamos al menú Project > Properties > Java Build Path. Allí en la pestaña “Libraries” damos click en “Add external Jars”, allí en la ventana que sale ubicamos la carpeta de Dex2Jar y añadimos todos los .Jar de la carpeta a nuestro proyecto y seleccionamos Ok.



Ahora añadimos nuestro fichero .APK al proyecto, es decir, lo arrastramos hasta el explorador de paquetes. 



Ahora hacemos click derecho en la carpeta de nuestro proyecto, seleccionamos Run As > Run Configurations y hacemos doble click en “Java application”, por lo que se añadirá una especie de página en la cual podemos pasar argumentos.

Aquí en la pestaña “Main“añadimos el nombre de la clase Main de Dex2Jar, la cual es posible encontrarla haciendo click en el botón “search” de la misma pestaña, en mi caso tiene una estructura así: com.googlecode.dex2jar.v3.Main



Luego vamos a la pestaña arguments y en la primera caja de texto colocamos el nombre de nuestro fichero APK con la extensión:



Damos click en Aplicar (Apply) y luego en “Run”, para ver un resultado de este tipo:



Ahora actualizamos nuestro explorador de proyectos (Click derecho y luego le damos “Refresh”) y veremos un nuevo fichero con extensión .Jar, es el que necesitábamos.



Descompilar archivos .JAR

Con el proceso anterior obtuvimos un .JAR limpio, ahora debemos “decompilarlo” para así poder ver su código fuente, por lo que abrimos el JD-GUI y allí abrimos nuestro .JAR generado, lo primero que observo son los métodos y en especial uno que dice button1_click(), ya que de seguro allí habrá algo.

Pero bueno, ya a partir de aquí podemos seguir e investigar todo el código, obviamente los conocimientos de programación nunca están demás para entender los algoritmos implicados en la aplicación.

Crackme

http://www.mediafire.com/download/tbdy9 ... metest.apk

Fuente: http://www.indetectables.net/viewtopic.php?f=79&t=47406

CrackMe - Nivel básico (Entendiendo un poco los binarios)

Buenos días.

Ahora estaba buscando nuevas comunidades de seguridad informática y encontré http://masters-hackers.info/ y con ellos un reto lo mas de curioso:

Coder: Bloc

Lenguaje: C#

Dificultad: 1/10(Facil)

Proteccion: No

Objetivo: Obtener datos e ingresar

Download: http://www.sendspace.com/file/st1w9p

Pass: Bloc

Para enfrentarnos al reto lo primero que pensamos es hacer ingeniería inversa (debugger) usando en mi gusto ollydbg, lo que aveces olvidamos son los "metadatados" de los binarios.

Los que están acostumbrados ha realizar retos de estenografía estarán familiarizados con el uso de editores hexadecimales, en mi caso uso WinEx.

Abrimos WinEx y cargamos nuestro  Crackme, a este paso podemos empezar a usar palabras claves para la búsqueda de algún dato importante, podríamos empezar con palabras como Textbox, Label, button y mensajes de validación que muestra el aplicativo.

Creo que la mas fácil es la ultima opción  pues es una cadena string así que buscaremos por la palabra "e" de error y con varios F3 encontramos lo siguiente:

"b.u.t.t.o.n.1...E.n.t.e.r...t.e.x.t.B.o.x.1...t.e.x.t.B.o.x.2...l.a.b.e.l.1...U.s.e.r...l.a.b.e.l.2...P.a.s.s...F.o.r.m.1..-S.i.m.p.l.e. .C.r.a.c.k.M.e. .#.1.-.B.l.o.c...|.U.s.u.a.r.i.o.|..'|.J.5.L.2.C.-.K.4.B.8.L.-.D.2.K.9.S.|..+C.r.a.c.k.e.d. .C.o.r.r.e.c.t.a.m.e.n.t.e..-S.i.m.p.l.e.-.C.r.a.c.k.M.e. .#.1.-.B.l.o.c...E.r.r.o.r...S.i.m.p.l.e. .C.r.a.c.k.M.e..KS.i.m.p.l.e._.C.r.a.c.k.M.e._.1...P.r.o.p.e.r.t.i.e.s...R.e.s.o.u.r.c.e.s"

Uniendo palabras (quitando puntos) nos queda algo asi:

|Usuario|..'|J5L2C-K4B8L-D2K9S|

Introducimos como usuario |Usuario| y Contraseña |J5L2C-K4B8L-D2K9S| y lo hemos logrado :O, personalmente pensé en quitar los | | xD.

En todo caso ha sido un reto interesante y demostrativo de que algunas veces complicamos los retos.

Cordial saludo al creador del reto.

Saludos roboticos.

Fuente: http://masters-hackers.info/showthread.php?t=25476
Links: https://docs.marklogic.com/guide/search-dev/binary-document-metadata

Estructura interna de los binarios.

Estructura Interna de los Ficheros Binarios (7 Excelentes Pósters)



Corkami

para esta navidad a realizado 7 Pósters excelentes sobre la estructura interna de diferentes tipos de ficheros binarios:
PE (Portable Executable, binarios ejecutables de Windows)
COM (binarios ejecutables de Microsoft creado en 1981
ELF (binarios ejecutables en sistemas *NIX)
Mach-O (binarios de OS X)
Clase Java (ficheros compilados Java)
PDF
ZIP
Los 7 pósters vienen acompañados además de algunos ejemplos de como crear dichos ficheros en ensamblador.

Descargar Pósters Estructura Interna de los Ficheros Binarios
Contraseña ZIP:123456

Fuente: http://www.cyberhades.com/

Fuente: http://www.blackploit.com/2013/12/estructura-interna-de-los-ficheros.html

ARE: VM para el análisis de malware de Android

ARE (Android Reverse Engineering) es una máquina virtual con un interesante set de herramientas para analizar distintos artefactos de malware de Android en un entorno seguro.

La imágen desarrollada por un grupo francés del Honeynet Project corre en VirtualBox y comprende 10 herramientas, incluyendo Androguard y el SDK de Android:

• Androguard
• Android sdk/ndk
• APKInspector
• Apktool
• Axmlprinter
• Ded
• Dex2jar
• DroidBox
• Jad
• Smali/Baksmali

Web del proyecto: http://redmine.honeynet.org/projects/are/wiki

Fuente:http://www.hackplayers.com/2011/11/are-vm-para-el-analisis-de-malware-de.html

..cantor.dust.., una herramienta visual de ingeniería visual

..cantor.dust.. es una herramienta interactiva de visualización binaria, una evolución radical del editor hexadecimal tradicional. Al traducir la información binaria a una abstracción visual, los analistas forenses y de ingeniería inversa pueden examinar montañas de datos arbitrarios en cuestión de segundos. Incluso conjuntos de instrucciones nunca antes vistas y formatos de datos pueden ser fácilmente localizados y comprendidos a través de su huella digital visual. Ha sido incluida en el arsenal de la Blackhat 2012 y ya estamos deseando probarla...

 

 

Fuente:http://www.hackplayers.com/2012/08/cantordust-visual-RE.html.html

Hacking Website Using Flasm

Flasm es un ensamblador/desensamblador de código de bytes de ActionScript para Flash. Usando Flasm, autores de scripts pueden aprender actionscript compilador y Flash Player.

Flasm desmonta el SWF completo, incluyendo todas las líneas de tiempo y eventos. En cuanto a desmontaje, a aprender cómo funciona el compilador de Flash, lo que mejora sus habilidades de ActionScript. Usted también puede hacer algunas optimizaciones en el código desmontados a mano o ajustar el código que desee. Flasm a continuación, aplica los cambios en el SWF original, en sustitución de las acciones originales. También es posible integrar las acciones Flasm en el código ActionScript.

Ubicacion:

Aplicaciones - Backtrack - Reverse-Engineering - Flasm

Abriendo desde la Terminal:

root@TioSam:~# cd /pentest/reverse-engineering
root@TioSam:/pentest/reverse-engineering# ls
flasm ida-pro-free ollydbg rec-studio
root@TioSam:/pentest/reverse-engineering# cd flasm
root@TioSam:/pentest/reverse-engineering/flasm# ls
CHANGES.TXT classic.css flasm flasm.html flasm.ini LICENSE.TXT logo.gif
root@TioSam:/pentest/reverse-engineering/flasm# ./flasm

Demostracion:

Descargar:

http://sourceforge.net/projects/flasm/

Fuente:

http://underc0de.org/foro/hacking-basico/hacking-website-using-flasm/

Inyección de código en procesos

0×01 | Intro
0×02 | API’s
0×03 | Inyectando con DLL
0×04 | Inyectando sin DLL

0×01 | Intro

Voy a explicar mas o menos como inyectar nuestro propio código en otro proceso. Primero inyectaremos una dll, después lo haremos a pelo.

0×02 | API’s

Primero necesitamos conocer algunas APIs de windows:
OpenProcess

1. HANDLE WINAPI OpenProcess(

2. __in  DWORD dwDesiredAccess,

3. __in  BOOL bInheritHandle,

4. __in  DWORD dwProcessId

5. );

Abre el proceso especificando su PID en dwProcessId, con los privilegios deseados. Retorna un manejador
al proceso, o NULL en caso de error.
VirtualAllocEx:

1. LPVOID WINAPI VirtualAllocEx(

2. __in      HANDLE hProcess,

3. __in_opt  LPVOID lpAddress,

4. __in      SIZE_T dwSize,

5. __in      DWORD flAllocationType,

6. __in      DWORD flProtect

7. );

Reserva memoria en el espacio de otro proceso, comenzando en lpAddress (si se le pasa NULL el sistema elige por nosotros), con el tamaño dwSize y con los permisos que le asignemos (usaremos PAGE_EXECUTE_READWRITE).
Devuelve un puntero a esa memoriam o NULL en caso de error.
WriteProcessMemory:

1. BOOL WINAPI WriteProcessMemory(

2. __in   HANDLE hProcess,

3. __in   LPVOID lpBaseAddress,

4. __in   LPCVOID lpBuffer,

5. __in   SIZE_T nSize,

6. __out  SIZE_T *lpNumberOfBytesWritten

7. );

Escribe en la memoria dada por lpBaseAddress el contenido apuntado por lpBuffer, hasta nSize bytes. Devuelve FALSE en caso de error.
CreateRemoteThread:

1. HANDLE WINAPI CreateRemoteThread(

2. __in   HANDLE hProcess,

3. __in   LPSECURITY_ATTRIBUTES lpThreadAttributes,

4. __in   SIZE_T dwStackSize,

5. __in   LPTHREAD_START_ROUTINE lpStartAddress,

6. __in   LPVOID lpParameter,

7. __in   DWORD dwCreationFlags,

8. __out  LPDWORD lpThreadId

9. );

Lanza un hilo en el proceso hProcess (abierto con OpenProcess), estando en ese hilo la funcion apuntada por lpStartAddress con los argumentos apuntados por lpParameter.
También usaremos Tlhelp32.h para obtener el PID de un proceso sabiendo su nombre.

1. HANDLE processList=CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);

2. PROCESSENTRY32 pInfo;

3. BOOL st=TRUE;

4. pInfo.dwSize=sizeof(PROCESSENTRY32);

5. Process32First(processList, &pInfo);

6. int myPid=0;

7. do

8. {

9. if(strcmp(pInfo.szExeFile, "test.exe")==0)

10. {

11. myPid=pInfo.th32ProcessID;

12. break;

13. }

14. Process32Next(lista, &pInfo);

15. }

16. while(st!=FALSE);

Ver MSDN para mas info.

0×03 | Inyectando con DLL

Primero necesitamos una DLL que inyectar, la cual al ser programada por nosotros hará lo que queramos.

1. #include ;

2. #include ;

3. BOOL APIENTRY DllMain (HINSTANCE hInst,

4. DWORD reason,

5. LPVOID reserved)

6. {

7. switch (reason)

8. {

9. case DLL_PROCESS_ATTACH:

10. MessageBoxA(NULL, "Hi!", "Hey!", 0);

11. break;

12. }

13. return TRUE;

14. }

Ahora tenemos que hacer al proceso cargar esa DLL. Para ello:

• Abrimos el proceso, reservamos memoria en él, y escribimos en esa memoria la ruta de la DLL.

• Obtener la dirección de LoadLibrary con GetProcAddress. LoadLibrary se encuentra en kernel32.dll, y su dirección es compartida, por lo que podemos cargarla desde el inyector y usarla desde el inyectado.

• Lanzar un hilo en el proceso abierto, dando como punto de entrada la dirección de LoadLibrary y como argumento la dirección del nombre de la DLL previamente escrito.

Todo junto queda así:

1. #include ;

2. #include ;

3. #include ;

5. void error(char *err);

7. HANDLE myProc=NULL;

9. int main(int argc, char *argv[])

10. {

12. HANDLE processList=CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);

13. PROCESSENTRY32 pInfo;

14. BOOL st=TRUE;

15. pInfo.dwSize=sizeof(PROCESSENTRY32);

16. Process32First(processList, &pInfo);

17. int myPid=0;

18. do

19. {

20. if(strcmp(pInfo.szExeFile, "test.exe")==0)

21. {

22. myPid=pInfo.th32ProcessID;

23. break;

24. }

25. Process32Next(processList, &pInfo);

26. }

27. while(st!=FALSE);

29. // Abrir el proceso

30. printf("[+] Opening process %i\n", myPid);

31. myProc=OpenProcess(PROCESS_ALL_ACCESS, FALSE, myPid);

32. if(myProc==NULL) error("[-] Error abriendo proceso.\n");

33. else printf("[+] Proceso abierto.\n");

35. // Reservar memoria para el argumento (ruta de la DLL)

36. char thData[]="dll.dll";

37. LPVOID dirToArg=VirtualAllocEx(myProc, NULL, strlen(thData), MEM_COMMIT|MEM_RESERVE, PAGE_EXECUTE_READWRITE);

38. if(dirToArg==NULL) error("[-] Error reservando memoria para argumento.\n");

39. else printf("[+] Memoria reservada para argumento (%i bytes).\n", strlen(thData));

40. // Escribir la ruta de la DLL en la memoria reservada

41. SIZE_T written=0;

42. if(WriteProcessMemory(myProc, dirToArg, (LPVOID)&thData, strlen(thData), &written)==0) error("[-] Error escribiendo memoria.\n");

43. else printf("[+] Memoria escrita (arg %i bytes).\n", written);

45. // Lanzar un hilo con LoadLibrary

46. HANDLE rThread=CreateRemoteThread(myProc, NULL, 0, (LPTHREAD_START_ROUTINE)GetProcAddress(LoadLibrary("Kernel32.dll"), "LoadLibraryA"), dirToArg, 0, NULL);

47. if(rThread==NULL) error("[-] Error creando el hilo.\n");

48. else printf("[+] Hilo creado.\n");

50. CloseHandle(myProc);

51. }

53. void error(char *err)

54. {

55. if(myProc!=NULL) CloseHandle(myProc);

56. printf("%s", err);

57. exit(0);

58. }

0×04 | Inyectando sin DLL

Aquí la cosa se complica. Las diferencias entre un método y otro son:

• Ahora no podemos utilizar cadenas de texto directamente como argumentos a funciones. Ya veremos por qué.

• No podemos llamar a ninguna función que no carguemos previamente con LoadLibrary + GetProcAddress. Esas dos están cargadas en todos los ejecutables de Windows desde kernel32, así que podemos usar un puntero a ellas.

• Tenemos que escribir todo el código de nuestras funciones en el espacio de memoria del proceso.

• Necesitaremos estructuras mas complejas como argumento de nuestros hilos remotos.

Así que el proceso de inyección quedaría así:

• Crear una estructura de datos con TODAS las cadenas de texto que vayamos a usar en el código inyectado, y con un puntero a LoadLibrary y GetProcAddress.

• Abrir el proceso.

• Reservar memoria para la estructura de datos. Escribirla.

• Reservar memoria para nuestro código. Escribirlo.

• Lanzar el hilo remoto, dando como punto de entrada el puntero a neustro código y como argumento el puntero a nuestra estructura de datos.

Y el código quedaría así:

1. #include 

2. #include ;

3. #include ;

5. void error(char *err);

6. static DWORD WINAPI myFunc(LPVOID data);

8. HANDLE myProc=NULL;

10. // Con esto cargaremos punteros a LoadLibrary y GetProcAddress en nuestra estrucura de datos

11. typedef int (WINAPI *datLoadLibrary)(LPCTSTR);

12. typedef int (WINAPI *datGetProcAddress)(HMODULE, LPCSTR);

14. int main(int argc, char *argv[])

15. {

16. if(argc<2) error("Uso: hook.exe PROCESO\n");     // Esta es nuestra estructura de argumentos

17. struct {

18. char lnUser32[50];                                 // ->; "User32.dll"

19. char fnMessageBoxA[50];                       // -> "MessageBoxA"

20. datLoadLibrary apiLoadLibrary;               // Puntero a LoadLibrary

21. datGetProcAddress apiGetProcAddress;  // Puntero a GetProcAddress

22. char Msg[50];                                  // Texto que usaremos en MessageBoxA

23. } thData;

24. strcpy(thData.lnUser32, "User32.dll");

25. strcpy(thData.fnMessageBoxA, "MessageBoxA");

26. strcpy(thData.Msg, "Hola!");

27. thData.apiLoadLibrary=GetProcAddress(GetModuleHandle("kernel32.dll"), "LoadLibraryA");

28. thData.apiGetProcAddress=GetProcAddress(GetModuleHandle("kernel32.dll"), "GetProcAddress");

30. int funcSize=600; // El tamaño de nuestra función. Podria calcularse de forma exacta, pero como ejemplo

31. // exagerado nos vale .

33. HANDLE processList=CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);

34. PROCESSENTRY32 pInfo;

35. BOOL st=TRUE;

36. pInfo.dwSize=sizeof(PROCESSENTRY32);

37. Process32First(processList, &pInfo);

38. int myPid=0;

39. do

40. {

41. if(strcmp(pInfo.szExeFile, argv[1])==0)

42. {

43. myPid=pInfo.th32ProcessID;

44. break;

45. }

46. Process32Next(processList, &pInfo);

47. }

48. while(st!=FALSE);

50. // Abrir proceso

51. printf("[+] Abriendo proceso %i\n", myPid);

52. myProc=OpenProcess(PROCESS_ALL_ACCESS, FALSE, myPid);

53. if(myProc==NULL) error("[-] Error abriendo proceso.\n");

54. else printf("[+] Proceso abierto.\n");

56. // Reservar memoria para argumentos

57. LPVOID dirToArg=VirtualAllocEx(myProc, NULL, sizeof(thData), MEM_COMMIT|MEM_RESERVE, PAGE_EXECUTE_READWRITE);

58. if(dirToArg==NULL) error("[-] Error reservando memoria para arg.\n");

59. else printf("[+] Memoria reservada para arg (%i bytes).\n", sizeof(thData));

60. // Escribir argumentos

61. SIZE_T written=0;

62. if(WriteProcessMemory(myProc, dirToArg, (LPVOID)&thData, sizeof(thData), &written)==0) error("[-] Error escribiendo la estructura de datos.\n");

63. else printf("[+] Memoria escrita (arg %i bytes).\n", written);

65. // Reservar memoria para la funcion

66. LPVOID dirToWrite=VirtualAllocEx(myProc, NULL, funcSize, MEM_COMMIT|MEM_RESERVE, PAGE_EXECUTE_READWRITE);

67. if(dirToWrite==NULL) error("[-] Error rreservando memoria para codigo.\n");

68. else printf("[+] Memoria reservada para codigo (%i bytes).\n", funcSize);

69. // Escribimos el codigo de nuestra funcion

70. if(WriteProcessMemory(myProc, dirToWrite, (LPVOID)myFunc, funcSize, &written) == 0) error("[-]Error escribiendo memoria.\n");

71. else printf("[+] Memoria escrita (codigo).\n");

73. // Lanzamos el hilo

74. HANDLE rThread=CreateRemoteThread(myProc, NULL, 0, (LPTHREAD_START_ROUTINE)dirToWrite, dirToArg, 0, NULL);

75. if(rThread==NULL) error("[-] Error lanzando hilo.\n");

76. else printf("[+] Hilo lanzado.\n");

77. CloseHandle(myProc);

79. return 0;

80. }

82. void error(char *err)

83. {

84. if(myProc!=NULL) CloseHandle(myProc);

85. printf("%s", err);

86. exit(0);

87. }

89. static DWORD WINAPI myFunc(LPVOID data)

90. {

91. // Cargamos nuestros datos en una estructura como la que hicimos

92. struct {

93. char lnUser32[50];

94. char fnMessageBoxA[50];

95. datLoadLibrary apiLoadLibrary;

96. datGetProcAddress apiGetProcAddress;

97. char MSG[50];

98. } *thData;

99. thData=data;

100. // Podemos conseguir cualquier API con estas dos, siempre que tengamos su nombre en la estructura

101. void *apiDir=(void *)thData->apiGetProcAddress((HANDLE)thData->apiLoadLibrary(thData->lnUser32), thData->fnMessageBoxA);

102. // Puntero a funcion similar a MessageBoxA

103. INT WINAPI (*myMessageBox)(HWND, LPCSTR, LPCSTR, UINT);

104. myMessageBox=apiDir;

105. myMessageBox(NULL, thData->MSG, thData->MSG, 0);

106. return;

107. }

Creo que todo está mas o menos bien explicado. Yo tampoco soy un experto en ésto así que puede que se me haya colado algún gazapo, cualquier cosa avisadme. Bytez.

AGRADECIMIENTOS TOTALES A:

http://blog.ka0labs.org