Mensajes

Efectivamente, ya lo consegui desempacar "a mano"(gracias a ese gran tute de Solid), en realidad desisti de hacerlo con el pydbg. No lo hice a mano total por la cosa del code splicing que no se como va y el rebase de la iat, cosas que te hace el arminline aunque me gustaria saber como
Por otro lado me hice con uno que lleva nanomites y tambien los pude dumpear y arreglar los nanomites pero tambien con herramienta, porque me perdia en el codigo de las tablas de los saltos... ¿lo han cambiado? (para ello segui los tutes de ricardo)

En conclusion, que no han cambiado nada  ???, las herramientas de siempre para versiones antiguas siguen funcionando!!

O sea, que no es tan duro

Yo digo que es por el desalineamiento de pila por el push ax....... puestos a decir  jajaja pero ni idea

Oh interesante, muchas gracias por esa valiosa info, ya me hice un script en pydbg que extrae los bytes que inyecta el padre en el hijo, eso debe ser a lo que te refieres(lo sigue haciendo de 1000 en 1000), yo pensaba que era el code splicing jeje.... sin embargo la inyecta solo al principio no veo eso que dices de desencripcion on-demand por llamarlo de alguna manera

Voy avanzando, de momento estoy jugando/hackando bastante el pydbg, añadiendole funciones y tal, como hooks a apis, con logs y eso...

Lo que no me convence mucho es la performance, es muy flexible pero si ya tarda bastante en procesar este pequeño crackme ni me imagino con una app de verdad

Mi objetivo es hacer un deunpacker generico para armadillo en pydbg a ver si me sale antes de que me abandonen las fuerzas jeje

Os aconsejo mucho el pydbg, ya se que no callo con el(que si pydbg para arriba, pydbg para abajo) pero estoy aprendiendo mucho con el sobre como se depura una app en windows y solo hay que saber un poco de python!! Lo ideal fuera que fuese en un lenguaje compilado(a codigo maquina) pero no hay mucho donde escoger, quiza ocaml me hubiera gustado o haskell, el resto no tienen las facilidades de python, aunque no se como andarian de eficiencia...

Solucionado, razon aqui: http://foro.elhacker.net/ingenieria_inversa/pydbg_el_no_va_mas_que_opinais_ayuda_con_funcion_de_carga-t258419.0.html;msg1255082#msg1255082

gracias por las molestias, al final sí se puede hacer en ring3 y sin SetThreadContext! jeje ahi viene explicado

El problema de hacerlo con SetThreadContext es que *creo*(porque lo probe y no ruló) que el so coge el context_record DESPUES del retorno de la excepcion, claro, es logico, a ver si me explico, quedaria asi:

Código [Seleccionar] Expandir


<salto excepcion>
<manejador excepcion>
<mi controlador SetThreadContext>
<el so actualiza el contexto y por tanto los Debug registers con la estructura del contexto en memoria>
<Dr7 borrado>


solucion que me sirvióí:

Código [Seleccionar] Expandir


<salto excepcion>
<poner breakpoint A en rutina SEH del programa>
<vuelta al so>
<salto breakpoint A, poner breakpoint B en la dir de retorno del manejador de la excepcion, borrar bp A>
<manejador excepcion>
<salto breakpoint B, restaurar el context record con los DrX, borrar BP B>
<vuelta al so>
<victoria>


Gracias

Ummm Shaddy me dio la idea, gracias, al final despues de mucho debuggeo lo consegui, el PyDbg ya carga el UnpackmeArmadillo6  

Lo hice así, capturo todas las excepciones con un manejador, en este pongo un breakpoint en el inicio de la SEH function, y en el manejador de esta un breakpoint en el retorno(retorno al ntdll, o al so, lo que sea)( luego borro los breakpoints claro), en el manejador del break de retorno de la esxcepcion restauro los valores de los registros de depuracion y zas!! en toda la boca Armadillo!!! jajaja  

mas info: (enlace recursivo lo siento) http://foro.elhacker.net/asm/evitar_que_te_borren_los_debug_registers_en_un_debugger_ring3-t258455.0.html;msg1255085#msg1255085

He googleado bastante y nada,

Alguien sabe como hace el olly esto? estoy intentando integrarlo en pydbg y no doy con ello.
Poniendo el bit GD a 1 del Dr7 supuestamente tendria que saltar una excepcion si se hace un mov Dr7, eax pero creo que stoy confundido y solo sirve para modo privilegiado. Creo que es el SO el que se encarga de poner los debug registers despues de una excepcion pero como puedo evitar que el so haga eso desde ring3?
Espero haber sido claro, cualquier ayuda es bienvenida

Era una cosilla, dwFlags = 0x0 vaya tonteria lo que hacia funcionar raro la cosa
Por lo demas los hw bps no funcionan porque armadillo los borra! como lidiar con esto? alguna idea? se me ocurre poner un handler ante el evento de despues de procesar la excepcion pero no se como hacer esto, tal vez no este contemplado, como lo hara olly??

Estoy un poco roto.

Me estoy iniciando en esto del PyDbg que es un debugger programatico en python y me ha maravillado.

Tiene algunos bugs pero el codigo fuente es muy claro, yo ya he corregido uno (el de los bps hw) y ampliado alguna funcion.

El mayor escollo con que he topado es el de siempre, los metodos anti-debug, he conseguido limpiar algunas huellas pero llegado al metodo de las HeapFlags me he quedado estancado.

La primera solucion fue crear mi funcion de carga del proceso, myload, que crea el proceso suspendido, sustituye el entry point por un JMP EIP, lo resume, y luego attachea el debugger sustituyendo el entry point con los bytes originales. Funciona a veces, pero si lo uso no van los bps hardware, y me interesa usarlos para cargar el UnpackArmadillo6 que os adjunte el otro dia.

No se si pastearos aqui el codigo o que, bueno alla va, sera un rollo, lo he comentado algo:

Código [Seleccionar] Expandir


def myload (self, path_to_file, command_line=None, create_new_console=None, show_window = None):
        pi = PROCESS_INFORMATION()
        si = STARTUPINFO()

        si.cb = sizeof(si)

        # these flags control the main window display of the debuggee.
        if not show_window:
                si.dwFlags     = 0x1
                si.wShowWindow = 0x0

        # CreateProcess() seems to work better with command line arguments when the path_to_file is passed as NULL.
        if command_line:
                command_line = path_to_file + " " + command_line
                path_to_file = 0
           
        creation_flags = 4 # CREATE_SUSPENDED

        if create_new_console:
                creation_flags |= CREATE_NEW_CONSOLE

        success = kernel32.CreateProcessA(c_char_p(path_to_file),
                                          c_char_p(command_line),
                                          0,
                                          0,
                                          0,
                                          creation_flags,
                                          0,
                                          0,
                                          byref(si),
                                          byref(pi))

        if not success:
            raise pdx("CreateProcess()", True)

        # store the handles we need.
        self.pid       = pi.dwProcessId
        self.h_process = pi.hProcess

        # resolve the PEB address.
        selector_entry = LDT_ENTRY()
        thread_context = self.get_thread_context(pi.hThread)

        if not kernel32.GetThreadSelectorEntry(pi.hThread, thread_context.SegFs, byref(selector_entry)):
                self.win32_error("GetThreadSelectorEntry()")

        teb  = selector_entry.BaseLow
        teb += (selector_entry.HighWord.Bits.BaseMid << 16) + (selector_entry.HighWord.Bits.BaseHi << 24)

        # add this TEB to the internal dictionary.
        self.tebs[pi.dwThreadId] = teb
        self.h_thread = pi.hThread
        self.dwThreadId = pi.dwThreadId
       
        self.peb = self.read_process_memory(teb + 0x30, 4)
        self.peb = struct.unpack("<L", self.peb)[0]
       
        pef = pefile.PE(path_to_file)
        address = pef.OPTIONAL_HEADER.AddressOfEntryPoint + pef.OPTIONAL_HEADER.ImageBase
        # save the original byte at the requested breakpoint address.
        original_bytes = self.read_process_memory(address, 2)

        self.write_process_memory(address, "\xEB\xFE") #JMP EIP
        kernel32.ResumeThread(pi.hThread)
        self.attach(self.pid)
        self.write_process_memory(address, original_bytes, 2)
        kernel32.FlushInstructionCache(self.h_process, 0, 0)


he usado tambien pefile la libreria para obetner el entry point del fichero aa cargar, nada, lo dicho esta nueva herrramienta merece la pena

Hay otra forma de borrar las heapflags? que no sea la de la clave del registro(aunque me acabare rindiendo a ella), y por cierto alguien sabe que pasaria si cambiase las HeapFlags en memoria con un ReadProcessMemory??

Sludos,

Buf, he mirado un poco y no es sencilla la cosa.

No es un ejecutable de win32, es de win16(windows 3.1 etc), un new executable(NE), el olly al parecer no te sirve... 

Deberias probar con windbg, o el debugger de una version antigua de visual c que funcione para 16 bits, pero no lo he probado. Intente con el debug que trae windows y dice que no puede arrancar windows asi que nada. El IDA lo desensambla pero no me deja depurarlo.. ademas saca cosas extrañas que no encuentro con el editor hexadecimal...(lo mire poco)
Quizás tb pudieras usar un debugger de ring0, i.e. un system debugger que capte las llamadas hechas por todo el sistema, aun asi parece complicado aterrizar en su codigo

La verdad podria ser buena idea para un crackme, un NE comprimido pero no creo que tenga mucho interes, si como reto pero practico ninguno

Otra posibilidad, instalarte un MV con windows 3.1 y todo el aparataje necesario para debuggear, aunque no se nada de esto

Como ultima opcion pydbg y las apis de windows, yo me estoy iniciando en el y es interesantisimo es un debugger "programatico", GPL y con un codigo python que se lee muy bien, sin duda merece la pena, solo que tendrias que programarte de 0 casi todo pues esta preparadop para win32

Si tanto te interesa creo que estas son las opciones

Suerte y a por ellos, espero tus avances

Vale, a mi me funciona con lo que te dije, = es que no explique bien los pasos, donde tienes que poner el ret no es el lugar del "call ss:[esp+8]" sino en la funcion donde se mete, o sea, le das a F7 y luego espacio y retn. La funcion esa ha de ser la del trial, para llegar a ella tienes que esperar que pase el tiempo o hacer el hack al SetTimer, para que sea la primera en la que entra, si te intentas loguear romperas otra vez en ese call ss:[esp+8] peeero no debes parchear la funcion más veces, ya que esta cambia con el tiempo segun quien llame al procedimiento(no me refiero a que cambie el codigo, cambia solo la direccion a la que salta, recuerda que es un call [esp]).

He probado en otro ordenador y tienes razon, no encuentra esa direccion, me he dado cuenta de que es dinamica, ademas si la intentas buscar al principio de la ejecución no la encuentra tampoco, ¿horror? no tanto...

Despues de trazar un poco el programa me doy cuenta de que esa parte de codigo la carga en runtime, y para ello utiliza las funciones GlobalAlloc(para reservar el bloque de memoria donde va a escribir el codigo) y _lread, _lopen, _lseek para cargar el codigo....

No lo mire más pero parchearlo no deberia ser mas dificil que coger un numero suficientemente grande de bytes seguidos de la funcion a parchear y buscarlos en el fichero, asegurate de que no hay mas de una ocurrencia o tendras problemas.

Si quieres seguir la via honesta, descifra los parametros de _lseek y varios _lread y pista.

El lugar donde los encuentras es aqui:



Saludos.