Hola!,
este pequeño post es para comentarles que acabo de subir a la web del proyecto aadp una versión del plugin aadp4immdbg para ImmunityDebugger >= 1.80. La versión que se encontraba en la web hasta el día de hoy era para la versión 1.73.
Debo advertirles que no tuve demasiado tiempo para probar esta "nueva" versión así que si encuentran algún bug, por favor, envienme un mail así puedo corregirlo a la brevedad.
Esta versión no incorpora ningún cambio significativo con respecto a la anterior, de hecho, la he versionado igual que la anterior porque la única diferencia radica en el nombre de las funciones exportadas.
Pueden bajarse esta versión desde la web del proyecto http://code.google.com/p/aadp
Hasta pronto!.
Mostrando entradas con la etiqueta Plugins. Mostrar todas las entradas
Mostrando entradas con la etiqueta Plugins. Mostrar todas las entradas
domingo, 19 de febrero de 2012
viernes, 18 de febrero de 2011
Nuevo Plugin para FUU - dePFE
crosspost de: http://pastafr0la.wordpress.com/2011/02/18/probando/
Gracias a "El Tio Pastafrola" por la colaboracion y por prenderse con el proyecto FUU!.
--
Hola amigos, hoy les traigo una pequeña reseña sobre el packer PFE CX v0.1 con el cual hice mis primeros pinitos en TitanEngine y FUU
primero echemos una mirada a la GUI del protector
haremos una muestra con el maximo nivel de compresion y todas las opciones activadas, en mi caso usare calc.exe para probarlo.
Este protector corre en dos procesos como podemos ver en la imagen
asi que lo cargamos con OllyDBG y buscamos las llamadas a CreateProcessA para caer en la zona caliente del packer
aca estamos en la zona caliente, vemos como crea el proceso hijo en modo suspendido, alloca memoria y despues le escribe algunas cosas en memoria :)
Pongamos un bp en el WriteProcessMemory que le sigue al VirtualAllocEx y miremos que tiene el buffer
ese MZ corresponde a la cabezera de nuestro protegido, en mi caso calc.exe. Esto significa que no tendremos que trabajar con el segundo proceso porque el primero ya nos da el programa en bandeja de plata.
Lo unico que tenemos que hacer ahora es alinear y dumpear
Para alinearlo, cambiamos el RawOffset y RawSize de cada seccion por su VirtualOffset y VirtualSize respectivamente.
y hacemos un dumpeado de memoria con por ejemplo, el dumper del plugin IsDebuggerPresent
Obteniendo un PE valido y funcional.
Automatizarlo con TitanEngine es bastante sencillo, los pasos a seguir serian:
- Setear un BP en WriteProcessMemory con la funcion SetAPIBreakPoint.
- El callback encargado de procesar ese breakpoint, alineara y dumpeara la imagen :)
Para dumpear regiones de memoria tampoco nos tenemos que complicar mucho, ya que TitanEngine nos provee de la funcion DumpMemory.
Eso es todo amigos, un packer facilito siempre y cuando ataquemos el primer proceso. En las primeras pruebas arranque trabajando con el segundo proceso y la verdad es que cuesta mucho trabajar con los 2 procesos a la vez debido a que el SDK aun no nos provee de dichas funciones y lo tenemos que hacer a mano.
Todo este proceso fue automatizado en el siguiente plugin: bin src
p.d. Para los que estan interesados en crear algun plugin para FUU, les paso la buena noticia que ya no es necesario el uso de la funcion _DoUnpack para elegir setear nuestro primer callback.
Ahora directamente trabajamos con InitDebugEx que como ultimo argumento nos permite definir un bp que se ejecutara cuando llegue al callback del debuggee.
Tengan bien presente esto, ya que si tratan de definir bp en API's sin haber iniciado el DebugLoop, esta funcion no procesara el LOAD_DLL (CodeException 06) y por lo tanto no podran setear los bp debido a que no estan cargadas las dll's.
lunes, 29 de noviembre de 2010
aadp4olly v0.2 & aadp4immdbg
Hola!,
queria hacerles saber que una nueva version de aadp4olly ha sido releseada. Entre las mejoras, podemos citar las siguientes:
v0.2 (29/11/2010)
--
- added Anti-Antidebugging features for the following tricks:
* BlockInput
* SuspendThread
* UnhandledExceptionFilter
* Process32Next
* Module32Next
* ZwQuerySystemInformation
* ZwQueryObject
* TerminateProcess
* ZwOPenProcess
* FindWindow
- now, the plugin should support XP (ALL), Windows Vista (ALL) and Windows 7 (ALL) OS.
Quedan algunos bugs de la version v0.1.3, en especial los reportados por Peter Ferrie que tienen que ver con una falta de comprobacion sobre algunos punteros, pero van a ser fixeados en la proxima version (v0.3) en la cual ya estoy trabajando!.
Como nota final, les puedo adelantar que con la proxima version de aadp4olly voy a liberar los sources de aadlib, la libreria anti-anti-dbg en la cual se basa el plugin.
La ultima version de aadp4olly la pueden conseguir en la web del proyecto: aadp
Junto con esta nueva version de aadp4olly, he releseado aadp4immdbg, que seria basicamente el mismo plugin pero para ser utilizado con ImmunityDebugger.
Saludos!,
Hasta la proxima!.
UPDATE (02/12/2010): fue agregada una nueva modificacion del plugin aadp4olly, aadp4ollysnd es una version de aadp4olly pero ajustada para trabajar con el OllySND. Gracias a Guan de Dio por esta modificacion.
sábado, 13 de noviembre de 2010
Nuevo plugin para Ollydbg - aadp4olly v0.1
Hola!,esta vez queria presentarles un nuevo proyecto en el cual he estado trabajando estas ultimas tres o 4 semanas en mis ratos libres. Se trata de un nuevo plugin para Ollydbg, aadp4olly o Anti-Anti-Debugger Plugin for Ollydbg.
Este nuevo plugin sirve para ocultar a Ollydbg de los trucos anti-dbg mas comunes como IsDebuggerPresent, NtGlobalFlags, etc; si bien ya hay plugins de este estilo para Ollydbg desde hace mucho tiempo, queria hacer mi propia version para incluir todos los trucos que necesito en mis sesiones de debugging con packers.
En esta primera version pueden encontrar trucos anti IsDebuggerPresent, NtGlobalFlags, HeapFlags, ZwSetInformationThread, OutputDebugString, ZwQueryInformationProcess y GetTickCount, por el momento, todos desde ring3.
En proximas versiones voy a continuar agregando mas trucos y posiblemente no solo en ring3 sino en ring0.
Cualquier comentario, sugerencia, pedido para agregar algo, etc, no duden en comentar aqui o escribirme directamente.
Obviamente, el proyecto es Open Source, como todo lo que he hecho hasta ahora.
Sin mucho mas que decirles, les dejo la pagina del proyecto: aadp
La descarga directa del plugin es: aadp4olly
Espero que les sea util!.
Aca les dejo un screenshot:
Hasta pronto!.
UPDATE (14/11/2010): aadp4olly ha sido actualizado a la version 0.1.1. Se fixeo un pequeño bug cuando se cerraba la ventana del plugin (reportado por marciano).
UPDATE (18/11/2010): aadp4olly ha sido actualizado a la version 0.1.2. Se incluye un fix para XP SP0 que permite que las opciones para hookear las funciones "Zw" funcionen en dicho OS (reportado por LCF-AT).
UPDATE (21/11/2010): aadp4olly ha sido actualizado a la version 0.1.3. Se incluye un nuevo fix para las funciones Zw reportado por LCF-AT.
martes, 12 de octubre de 2010
Nuevo plugin para FUU - dePeX
Hola!,despues de un tiempo sin ningun post queria decirles que en el blog de FUU hay un nuevo post anunciando un nuevo update para FUU.
Además, hay una pequeña reseña del packer.
Acá pueden verlo!.
Saludos.
viernes, 16 de julio de 2010
New FUU Plugin - deExeFog!
Hola!,
quienes me conocen, saben que continuamente estoy intentando hacer algo, escribiendo algun tutorial, programando alguna toolcita, etc; ahora, quiero hacer una cosa: por cada nuevo plugin de FUU que haga voy a escribir un post comentando un poco los trucos que utiliza el packer para poder facilmente identificar las zonas importantes a la hora de desempacar.
En este primer post, vamos a hablar de un packer sencillo, exeFog, mas particularmente, nos centraremos en exeFog v1.x, desconozco si existe alguna version 2.x, si alguno tiene un exe, dll, ocx o lo que sea packeado con alguna otra version de exeFog, no tiene mas que enviarla para que la pueda estudiarla y agregarle soporte al correspondiente plugin.
La idea de este y los siguientes post no es la de realizar un analisis detallado sobre el packer como suelo realizar en los tutoriales, sino que veremos las partes importantes nada mas como para vencerlo y que son utilizadas luego en el plugin.
Voy a basarme en este crackme: http://www.tuts4you.com/request.php?1093
Por ejemplo, si cargamos el programa packeado en Olly (sin plugins) y le damos a F9 (Run), veremos que Olly se detiene en una exception, mas especificamente, un DIVISION_BY_ZERO:
Esto se debe a un viejo y conocido truco anti-debug conocido como IsDebuggerPresent pero en este caso, el truco no invocando explicitamente a la API IsDebuggerPresent, sino realizando un inline de esta funcion.
Si comenzamos a tracear, veremos que primeramente, llegamos a un loop en el cual se desexorea codigo, este codigo no es mas que otra parte del stub de desempacado del programa:
Como vemos, primero coloca en EBX un puntero a una zona un poco mas abajo de la instruccion "loopd", coloca en ECX un offset, en este caso "0x3c8" y en AL la key para xorear, en este caso "0x8c", luego, solo va indexando en EBX+ECX y xoreando cada byte, luego, vuelve a tomar otro byte en AL y a repetir la operacion.
Una vez que pasamos esto, si llegamos a la zona del inline IsDebuggerPresent:
Como pueden observar, solo esta accediendo al flag "BeingDebugged" que se encuentra en la PEB:
Como vemos, a ese byte, primero le aplica un NOT y luego un AND con 1, con lo cual, si ese byte esta en 1 (quiere decir que el proceso esta siendo debuggeado), el resultado de esas dos operaciones sera 0 y si el byte esta en 0 (quiere decir que el proceso no esta siendo debuggeado) pues el resultado de esas dos operaciones dara 1.
Cual es el truco en todo esto? pues que este valor es utilizado como divisor y dividendo en una division un poco mas adelante:
Como vimos, el resultado del NOT y AND lo colocaba en EBX pero a su vez quedaba en EAX tambien, con lo cual si el resultado del NOT y AND es 0 pues sera 0 / 0 = ERROR!!!.
Para solucionar esto, simplemente debemos de setear ese byte a 0 para que el resultado del NOT y AND sea 1. Podemos hacerlo de varias maneras, la mas rapida es: cuando estemos en el EP (EntryPoint) del packer, simplemente hacemos CTRL+G y ponemos "EBX" y cambiamos el valor del segundo byte a 0. Por que asi? pues porque EBX siempre apunta a la PEB cuando estamos parados en el EP:
Luego, tenemos dos partes importantes mas:
1) Donde resuelve los imports.
2) Donde salta al OEP (Original Entry Point)
Ambas zonas son facil de encontrar, miremos un poco el codigo y vamos a ver que aqui resuelve las dlls importadas por el programa:
Si miramos los registros en este momento, podremos ver que EBX contiene un puntero al string de la dll importada:
Luego, en esta zona, veremos que resuelve las funciones importadas por cada dll:
y si miramos los registros, veremos que EAX contiene el puntero al string de la funcion importada y EDI el puntero al lugar en la IAT donde esa funcion deberia de encontrarse en el programa original:
Ah, antes de continuar, queria comentarles que ademas, exeFog, realiza comprobaciones en los primeros bytes de las APIs a las cuales va a llamar para ver si hay un breakpoint colocado ahi:
Ahi pueden ver un ejemplo de como, luego de resolver la funcion y colocar el puntero en EAX, verifica que el primer byte de esa funcion no contenga un breakpoint (0xCC). Con colocar hardware breakpoints o colocar los breakpoints por software en la segunda instruccion de la API (o en el RET) bastara para bypassear la comprobacion.
Bien, finalmente, el lugar en el cual se salta al OEP es este:
Llegado al "ADD", ESP contiene el offset al EP y EBP la ImageBase del programa, con lo cual, al sumarlo dara como resultado el OEP y al tomar el RET quedaremos parados ahi:
Para realizar el plugin, los pasos que realice fueron los siguientes:
1) Buscar el patron del loop que desexorea el codigo.
2) Pasar el loop anterior y realizar una busqueda de los patrones de codigo que resuelven la IAT, nos dan el salto al OEP y realizan la verificacion de BeingDebugged. Esto lo hago seteando callbacks para cada una de las tareas.
3) Cuando salta el callback en el truco anti-dbg lo unico que hago es colocar EAX en 1 luego el AND y antes del MOV EBX, EAX, con eso me aseguro de que EAX siempre es 1.
2) Cuando salta el callback de LoadLibraryA solo tomo el valor de EAX y lo voy agregando a la IAT.
4) Cuando salta el callback de GetProcAddress simplemente tomo los valores de EAX y EDI y los agrego en la IAT.
La el plugin (dll) lo pueden conseguir aca: http://tinyurl.com/2arrnct
El source code del plugin lo pueden conseguir aca: http://tinyurl.com/2wz5bty
Hasta el proximo post!.
quienes me conocen, saben que continuamente estoy intentando hacer algo, escribiendo algun tutorial, programando alguna toolcita, etc; ahora, quiero hacer una cosa: por cada nuevo plugin de FUU que haga voy a escribir un post comentando un poco los trucos que utiliza el packer para poder facilmente identificar las zonas importantes a la hora de desempacar.
En este primer post, vamos a hablar de un packer sencillo, exeFog, mas particularmente, nos centraremos en exeFog v1.x, desconozco si existe alguna version 2.x, si alguno tiene un exe, dll, ocx o lo que sea packeado con alguna otra version de exeFog, no tiene mas que enviarla para que la pueda estudiarla y agregarle soporte al correspondiente plugin.
La idea de este y los siguientes post no es la de realizar un analisis detallado sobre el packer como suelo realizar en los tutoriales, sino que veremos las partes importantes nada mas como para vencerlo y que son utilizadas luego en el plugin.
Voy a basarme en este crackme: http://www.tuts4you.com/request.php?1093
Por ejemplo, si cargamos el programa packeado en Olly (sin plugins) y le damos a F9 (Run), veremos que Olly se detiene en una exception, mas especificamente, un DIVISION_BY_ZERO:
Esto se debe a un viejo y conocido truco anti-debug conocido como IsDebuggerPresent pero en este caso, el truco no invocando explicitamente a la API IsDebuggerPresent, sino realizando un inline de esta funcion.
Si comenzamos a tracear, veremos que primeramente, llegamos a un loop en el cual se desexorea codigo, este codigo no es mas que otra parte del stub de desempacado del programa:
Como vemos, primero coloca en EBX un puntero a una zona un poco mas abajo de la instruccion "loopd", coloca en ECX un offset, en este caso "0x3c8" y en AL la key para xorear, en este caso "0x8c", luego, solo va indexando en EBX+ECX y xoreando cada byte, luego, vuelve a tomar otro byte en AL y a repetir la operacion.
Una vez que pasamos esto, si llegamos a la zona del inline IsDebuggerPresent:
Como pueden observar, solo esta accediendo al flag "BeingDebugged" que se encuentra en la PEB:
typedef struct _PEB {
BYTE Reserved1[2];
BYTE BeingDebugged;
BYTE Reserved2[1];
PVOID Reserved3[2];
PPEB_LDR_DATA Ldr;
PRTL_USER_PROCESS_PARAMETERS ProcessParameters;
BYTE Reserved4[104];
PVOID Reserved5[52];
PPS_POST_PROCESS_INIT_ROUTINE PostProcessInitRoutine;
BYTE Reserved6[128];
PVOID Reserved7[1];
ULONG SessionId;
} PEB, *PPEB;
Se encuentra en el campo [2] de la PEB del proceso (movzx eax, byte ptr ds:[eax+2]).Como vemos, a ese byte, primero le aplica un NOT y luego un AND con 1, con lo cual, si ese byte esta en 1 (quiere decir que el proceso esta siendo debuggeado), el resultado de esas dos operaciones sera 0 y si el byte esta en 0 (quiere decir que el proceso no esta siendo debuggeado) pues el resultado de esas dos operaciones dara 1.
Cual es el truco en todo esto? pues que este valor es utilizado como divisor y dividendo en una division un poco mas adelante:
Como vimos, el resultado del NOT y AND lo colocaba en EBX pero a su vez quedaba en EAX tambien, con lo cual si el resultado del NOT y AND es 0 pues sera 0 / 0 = ERROR!!!.
Para solucionar esto, simplemente debemos de setear ese byte a 0 para que el resultado del NOT y AND sea 1. Podemos hacerlo de varias maneras, la mas rapida es: cuando estemos en el EP (EntryPoint) del packer, simplemente hacemos CTRL+G y ponemos "EBX" y cambiamos el valor del segundo byte a 0. Por que asi? pues porque EBX siempre apunta a la PEB cuando estamos parados en el EP:
Luego, tenemos dos partes importantes mas:
1) Donde resuelve los imports.
2) Donde salta al OEP (Original Entry Point)
Ambas zonas son facil de encontrar, miremos un poco el codigo y vamos a ver que aqui resuelve las dlls importadas por el programa:
Si miramos los registros en este momento, podremos ver que EBX contiene un puntero al string de la dll importada:
Luego, en esta zona, veremos que resuelve las funciones importadas por cada dll:
y si miramos los registros, veremos que EAX contiene el puntero al string de la funcion importada y EDI el puntero al lugar en la IAT donde esa funcion deberia de encontrarse en el programa original:
Ah, antes de continuar, queria comentarles que ademas, exeFog, realiza comprobaciones en los primeros bytes de las APIs a las cuales va a llamar para ver si hay un breakpoint colocado ahi:
Ahi pueden ver un ejemplo de como, luego de resolver la funcion y colocar el puntero en EAX, verifica que el primer byte de esa funcion no contenga un breakpoint (0xCC). Con colocar hardware breakpoints o colocar los breakpoints por software en la segunda instruccion de la API (o en el RET) bastara para bypassear la comprobacion.
Bien, finalmente, el lugar en el cual se salta al OEP es este:
Llegado al "ADD", ESP contiene el offset al EP y EBP la ImageBase del programa, con lo cual, al sumarlo dara como resultado el OEP y al tomar el RET quedaremos parados ahi:
Para realizar el plugin, los pasos que realice fueron los siguientes:
1) Buscar el patron del loop que desexorea el codigo.
2) Pasar el loop anterior y realizar una busqueda de los patrones de codigo que resuelven la IAT, nos dan el salto al OEP y realizan la verificacion de BeingDebugged. Esto lo hago seteando callbacks para cada una de las tareas.
3) Cuando salta el callback en el truco anti-dbg lo unico que hago es colocar EAX en 1 luego el AND y antes del MOV EBX, EAX, con eso me aseguro de que EAX siempre es 1.
2) Cuando salta el callback de LoadLibraryA solo tomo el valor de EAX y lo voy agregando a la IAT.
4) Cuando salta el callback de GetProcAddress simplemente tomo los valores de EAX y EDI y los agrego en la IAT.
La el plugin (dll) lo pueden conseguir aca: http://tinyurl.com/2arrnct
El source code del plugin lo pueden conseguir aca: http://tinyurl.com/2wz5bty
Hasta el proximo post!.
miércoles, 7 de julio de 2010
FUU v0.1.1 Beta - Minor Release
Hola!,
bueno, luego de un tiempo sin actualizaciones al final sacamos una nueva version de FUU. Esta nueva version es mas que nada un minor release para corregir un par de cosas que habian quedado muy feas en la primera version.
Alguna de las cosas que se corrigieron son la funcion de "Refresh" en la GUI y un par de errores logicos en el codigo, tanto de la GUI como de los plugins. Ademas, se agrego la posibilidad de poder guardar el dumpeado resultante del proceso de unpacking en el lugar que uno elija.
Tengo que agradecer a toda la gente que se acerco a darme una mano con el proyecto, como GUAN, Eddy, Marciano, Mario Vilas y Erisoft. Todos ellos estuvieron ayudandome tanto para testear la herramienta y reportar bugs, como para colaborar con codigo e ideas para futuras versiones como con samples para poder realizar pruebas "particulares".
Un amigo, GUAN de Dio, se ha sumado al proyecto como colaborador migrando la version de 32 bits a 64 bits. Lamentablemente, en este release no pudimos incluirla porque estamos teniendo problemas con el SDK TitanEngine y su soporte para 64 bits con MASM y VS (Visual Studio), pero esperamos prontamente poder solucionar esto y lanzar finalmente una version de 64 bits.
Quisiera ademas aprovechar un poco para aclarar algunas cosas. He visto por al red algunos comentarios de algunas personas diciendo cosas del estilo: "Para que usar FUU si PEiD con plugins va mejor". Bueno, primero que nada quisiera aclarar que la idea principal de FUU es la de un proyecto OpenSource donde todo el mundo pueda colaborar. PEiD en cambio es un proyecto No-OpenSource. Ademas, agregar que la palabra "Universal" en FUU no significa un unpacker generico sino que con esa palabra intentamos describir lo que en un futuro FUU puede llegar a ser: al ser un proyecto OpenSource en el cual todo el mundo interesado puede colaborar con sus plugins y unpackers, entonces, podriamos desarrollar un unpacker para cada proteccion conocida hasta el momento, eso es lo que quiero decir cuando digo que FUU es "Universal Unpacker".
En fin, cualquier sugerencia, reporte de bugs, aporte para el proyecto es bienvenido y solo tienen que sumarse a nuestra lista de correo o enviarme un mail (en el caso de respoderle a una persona en particular de manera privada hace que el proyecto deje de tener sentido, la idea es que todos discutamos en la lista las ideas y aportes para FUU).
Nuevamente, agradecer a todos aquellos que colaboraron con el proyecto!!!.
Las ideas aportadas fueron muy buenas y sin dudas las vamos a ir agregando de a poco en los posteriores releases.
Ah, antes de que me olvide, prometo actualizar de manera algo mas periodica que hasta ahora la seccion de plugins, subiendo nuevos sources de nuevos plugins (siempre y cuando el tiempo me lo permita).
Web del proyecto: FUU
FUU v0.1.1 Beta Download link: FUUv0.1.1b
Disfruten!.
Hasta el proximo release!.
martes, 27 de abril de 2010
Tool - FUU - [F]aster [U]niversal [U]npacker
Hola a todos!,
Si, si, no estoy muerto! sigo aca!. Durante este tiempo estuve haciendo algunas cositas, entre ellas, una nueva tool, llamada FUU, Faster Universal Unpacker.
Primero que nada quiero comentarles que esta tool nacio por la curiosidad de saber de que se trataba TitanEngine. TitanEngine es un SDK desarrollado por la gente de ReversingLabs. Se trata de una libreria llena de funciones listas para ser usadas y que tienen como finalidad la creacion de tooles del estilo de unpackers, decrypters, decompressors, etc. TitanEngine fue presentado en BlackHat en 2009 y fue ahi donde lo conoci.
Ahora bien ... que es FUU? FUU es basicamente una GUI mediante la cual se puede acceder a diferentes tipos de tools. La mision principal de FUU es la de darnos una manera facil de poder desempacar programas empacados, comprimidos o encryptados con los packers/compressors y crypters mas conocidos como UPX, ASPack, etc; Ademas, cuenta con algunos plugins extras como "Generic OEP Finder", "Crypto Signatures Detector" y "Generic Unpacker"; estos plugins fueron diseñados por la misma gente que hizo PEiD.
La tool esta creada (tanto la GUI como los plugins) estan hechos en ASM. Particularmente, la GUI, esta armada con RadASM.
Por que "Universal"?. El termino, en este caso, no esta usado de la manera que uno puede llegar a pensar, es decir, en un algoritmo que engloba la comportamiento general en varios packers y permite con una sola funcion, desempacar varios clases de packers/crypters/compressors; sino que cuando le puse "Universal" pense en que podriamos agregar cuantos plugins quisieramos para poder analizar y desempacar tantos packers como queramos, hasta llegar al punto que abarquemos todos (o al menos la gran mayoria) los existentes.
En este primer release pueden encontrar, entre muchos bugs, 4 plugins para desempacar UPX, ASPack, BeRoExePacker y FSG y ademas, los plugins mencionados anteriormente. En proximas versiones se continuaran agregando plugins para diferentes packers/crypters/compressors y alguna que otra tool extra, ademas de fixear bugs :)
El proyecto esta hosteado en googlecode:
http://code.google.com/p/fuu/
Si quieren, pueden mirar el source code aqui: http://code.google.com/p/fuu/source/browse/
Ademas, he creado un grupo en Google Groups por si alguien quiere sumarse para discutir algun tema particular, reportar bugs, pedir algun feature o algun plugin especial. El grupo lo pueden encontrar aqui: http://groups.google.com/group/faster-universal-unpacker
La GUI esta distribuida bajo licencia GPL y cada plugin (menos los extra) estan distribuidos bajo LGPL.
La primer release la puede bajar directamente desde aqui:
http://fuu.googlecode.com/files/FUU%20v0.1%20Beta.rar
En breve publicare un tutorial explicando como fue que cree esta tool y ademas como se crea un plugin con TitanEngine.
Espero que les guste y les sea util. Comentarios, sugerencias y bugs son bienvenidos siempre!.
Antes de finalizar, quisiera agradecer a Guan De Dio y marciano por aguantarme y responder todas las preguntas que siempre estoy haciendoles, por ayudarme con los problemas que suelo encontrarme y que no se como afrontar y a InDuLgEo por diseñar el main logo de la tool :P Gracias a los tres!.
Un abrazo!
Hasta la proxima!.
jueves, 15 de octubre de 2009
Nuevo differ - TurboDiff
Hola a todos!,hoy queria comentarles un poco acerca de un nueo differ que se ha publicado en la internet :P
Se trata de un nuevo differ (un programa para comparar .exe, .dll, etc en busca de diferencias) escrito por Nicolas Economou (CORE Security Technologies) y presentado en la Ekoparty 2009 en Argentina.
Basicamente, la mayor diferencia con el resto de los differs actuales (Bindiff, Patchdiff, DarumGrim) es que este differ esta pensado para la busqueda de vulnerabilidades, esta especialmente pensado y programado para que no se le pase el mas minimo detalle a la hora de identificar un minimo cambio como un JA por un JB, cosa que al resto de los differs suele pasarsele por alto en ocasiones, incluso detecta diferencias en funciones que no son analizadas correctamente por IDA (si, me falto decir que es un plugin de IDA :).
Yo lo he utilizado un poco y me parecio bastante mejor que bindiff, el unico punto debil son los graficos puesto que no se comparan con los de bindiff pero el punto fuerte es que es mucho mas preciso que bindiff y el resto de differs a la hora de buscar vulnerabilidades.
Un buen post al respecto lo pueden enconrar aqui.
El source code y el plugin compilado lo pueden encontrar en la web de Corelabs, aqui.
update1: para ser imparciales y no ejercer favoritismos :P debo de decir que hace unos dias estuve probando Bindiff 3.0 y he tenido los mismos resultados que con turbodiff en cuanto a funciones cambiadas, sin embargo, turbodiff sigue siendo un poco mas rapido en el analisis que bindiff pero sin duda este ultimo mejoro bastante desde la version 2.0.
Hasta la proxima!.
miércoles, 14 de octubre de 2009
CollaboREate & IPython for IDAPython
Hola!,Queria comentarles acerca de dos plugins interesantes para IDA.
Creo que todos conocen IDAPython (el plugin para IDA que permite interactuar con la API de IDA a traves de Python y que ademas nos provee de todas las bondades de python en IDA), bueno resulta que hasta ahora, los que no contamos con las nuevas versiones de IDA (hablo de la > 5.2) a no ser que hayamos comprado una de las caras licencias o tener acceso a alguna distro en nuestro trabajo, debiamos de editar el script de IDAPython en un simple textbox y ademas utilizar el menu o algun atajo de teclado para correr el script, bueno ahora hay una posibilidad mas.
Mediante el script que se encuentra aqui, podemos utilizar el tan conocido interactive shell, IPython, en IDA.
Post original en OpenRCE aqui.
Gracias sagar por el script!.
El segundo plugin sobre el cual queria hablar un poco es CollaboREate.
Se trata de un plugin que permite realizar trabajos de ingenieria inversa con IDA sobre un IDB pero de manera comunitaria. Como es esto? pues dos personas trabajando en un mismo idb, pueden compartir, en tiempo real, todos los cambios que vayan realizando sobre el idb, como renombrar variables, nombres de funciones, parametros, structs, unions, etc etc etc. Solo hace falta montar un server que sea el que envia los datos a todos los que se conecten a el.
Esto quiere decir que el usuario X y el usuario Y que trabajan sobre el mismo idb van a poder trabajar de una manera mas coordinada e instantanea que si tuvieramos que enviar los idbs por mail o subirlos a algun lado en internet, etc. Muy bueno sin duda para trabajos en conjunto.
Homepage de CollaboREate aqui.
Aca un paper sobre el plugin.
Bueno, eso!.
Saludos!.
