Temas

Quiero procesar con un script para analizar propiedades y ciertas cosas, y necesito una guía con las siguientes características:
- Evidentemente un formato que pueda ser procesado automáticamente, PDF complica las cosas.
- Que indique en que versión se incorporó la instrucción(286, 386, etc)
- Que indique su codificación hexadecimal(opcode, ModRM, Immediate operands, etc)
- A ser posible que indique sus número de ciclos, pipe de ejecución, tiempos de espera, etc.
- A ser posible excepciones que produce
- Sintaxis en ensamblador
- Que esté actualizado! no he encontrado lo que busco en intel  

Básicamente esto, no me interesa la descripción o algoritmo con lo que hace... todas las guias de intel son en PDF? se me está haciendo difícil de procesar, además no trae los procesadores en que funciona, ni los ciclos...

Me autorespondo, lo siento por haber buscado tan poco, estaba obcecado en procesar las guias de intel en Perl
http://ref.x86asm.net/

Quisiera saber alternativas y pros y contras, si es que alguien se ha dedicado a explorar este tema y así me ahorra un poco de trabajo. También acepto opiniones de quien lo haya usado, pero recientemente.
Conozco:
Swing - +puro java, -poco eficiente?, +incluído en el runtime, -abandonado?
AWT - -pocos componentes
SWT - ? -librería externa
QT Jambi - ? -librería externa

A ver que opinan de esta idea,
no sé si alguno ha programado algo en Smalltalk, bueno pues ese estilo de programacion diferente al clásico editar-probar-corregir-loop, es algo así como un evaluar-print-loop.

Por ahí existen los vulgarmente conocidos intérpretes, como el de python(o consola), que mejor dicho se llaman REPL's(read-eval-print-loop).

Bueno mi idea es mejorarlo como Smalltalk pero juntando lo de ambos, ya que el estilo de ST es imposible aplicarlo a lenguajes típicos orientados a ficheros de código fuente. O es difcil de hacer, son muy incompatibles. (el problema de los REPLs es que no guardan tu trabajo(salvo Smalltalk y parecidos), y por ello los REPL son relegados a simples programas de prueba y experimentación)

Mi idea es tener un REPL pero con 3 ventanas, la que va ejecutando, la que va editando y la del historial. Todas con múltiples pestañas para más de un source. Con simples key-bindings tenemos diferentes comandos.
<TAB> para autocompletar símbolo
.t para tipo de un símbolo
.d para documentación de una función en una API
<CTRL-CURSOR> para reasignar una línea
etc.
Puedo mejorarlo, copiando cosas de emacs, (en vez de .t, por ejemplo CTRL-T y saldría en una ventana más de minibuffer)
Creo que se pueden obtener los beneficios de ambas aproximaciones, traer a la rapidez y sencillez de edición de los REPL, la persistencia necesaria para programar dado que casi todos los lenguajes se basan en el primer modelo.

Para acabar: sólo imaginad, mientras escribís esa función C que recibe no se cuantos parámetros, estás viendo cómo se modifican los datos de los parámetros, como un debugger, un análisis vivo, pero es la primera vez que los escribes!! todo se compila segun lo escribes(y das al ENTER); esos datos de prueba que vas escribiendo se podrían ir guardando a su vez en una batería de pruebas.

¿Qué tal lo véis? (últimamente estoy algo atareado, no sé si me llevaría mucho tiempo hacer uno para C, el problema es hacerlo wapo, con colores y tal :S)

Es esto normal?

Tengo como 30 pestañas abiertas en firefox 
Ese es mi modo de guardar marcadores 
Tengo 500 GB de los cuales menos de 800 MB libres 
Estamos ante un nuevo tipo de "síndrome" adaptado a la era digital
Alguno más en mi situación?
Necesito ayuda profesional?   

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

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,

Buenas,

He usado el Software Passport(ultima version) para comprimir un ejecutable muy simple para estudiar la proteccion Armadillo 6.60 y nada, aun siguiendo varios tutos por la red no puedo con el...

Lo unico que no lleva son nanomites

Esta aqui: http://rapidshare.com/files/244632303/UnpackmeArmadillo6.exe.bz2.html

Me gustaria poder dumpearlo y extraer el nucleo del programa para poder parchearlo etc., pero a mano. No he tenido muchos avances, a ver si alguien puede darme alguna pista.
He probado bastantes cosas y no consigo aun asi entender bien como funciona.

El intento mas cercano de conseguir algo fue de esta manera:

(Uso el plugin phantom para ocultar el olly)

Rompemos en el segundo WriteProcessMemory(hardware bp), que escribe 2 bytes en el proceso hijo, anteriormente escribio un salto jmp eip y ahora reestablece los bytes, nosotros cambiamos el buffer por EB FE, o sea, jmp eip.

Ahora deseariamos attachear olly al proceso hijo pero este esta siendo depurado por el padre asi que ponemos en el padre un bp WaitForDebugEvent, al final cuando eax == 0 (conditional) (esto no se bien por que pero lo lei) retornamos y ensamblamos
push <pid proceso hijo>
call DebugActiveProcessStop

Ejecutamos las 2 instrucciones y ya podemos atachaear un segundo olly al proceso hijo, ahora si ejecutamos el programa normal casca..... ¿que hago mal? ¿que detecta el programa diferente?

Como veis estoy muy lejos de poder dumpear el programa, reconstruir la IAT, etc...

Cualquier ayuda sera bienvenida
Saludos