Temas

Hola,

Estoy trasteando con un programa que usa varios módulos. El módulo que en teoria valida el serial-requestcode-autorizecode lo he parcheado sin demasiados problemas para que llegue al punto deseado sea lo que sea que se le meta como autorizecode, de manera que saca la ventanita de codigo correcto y te dice que reinicies el programa para que funcione sin limitaciones.

El problema es que cuando lo reinicio el programa me vuelve a pedir el serial-request-autorize como si no lo hubiera metido antes.

Mientras estaba traceando he visto que los códigos que se generan a partir del serial (los de request-autorize) se van metiendo en el registro de windows en una clave concreta. Supongo que lo que pasa es que cuando se inicia el programa al cargarse alguno de los otros módulos se realiza otra vez el proceso de comprobación de las claves de registro, ahi se de cuenta de que no son legítimas y resetea el proceso de autorizacion.

Para pillar el módulo que hace esa segunda comprobación necesitaría averiguar alguna manera de decirle al Olly que meta un BP cuando se intente acceder a esa clave en concreto del registro, pero... ¿se puede hacer algo asi?


Un saludo.

Hola a todos,

A pasado mucho tiempo desde la ultima vez que me pasé por aquí...

El caso es que ando buscando información para hacer Ingeniería Inversa en sistemas de 64 bits. Agradecería cualquier información al respecto tanto en tutoriales como en herramientas.

Por cierto, he leído en algún sitio que hay una manera de usar el Olly en entornos x64. Podría ser cierto algo asi?


Un saludo.

[[FMADV] - OllyDbg Format String Bug]

Me he kedado asin al leer lo esto:

[FMADV] - OllyDbg Format String Bug

* Introduction:
There exists a format string bug in the code that handles Debugger
Messages in OllyDbg. This means any traced application can crash OllyDbg
and execute machine code.

* About (From the Webpage):
OllyDbg is a 32-bit assembler level analysing debugger for Microsoft
Windows. Emphasis on binary code analysis makes it particularly useful in
cases where source is unavailable.

OllyDbg is seen as an industry standard when it comes to analysing
vulnerabilties on win32 and it's easy to understand makes it a must for
anyone developing exploits on windows. Many people have sung the praises
of OllyDbg, including some very high profile engineers and exploit
developers.

* Technical details:
Typically OllyDbg attaches to a process and allows the user how to
customize the session; wether they trace, or they breakpoint some stuff or
whatever. The windows API is actually very debugger friendly and has many
functions to interact with debuggers (most likely built for their own
(safe) debugger WinDbg). One of these functions, OutputDebugString sends a
string directly to the debugger for interpretation, which OllyDbg displays to
the user via a status line along the bottom, sans a format specifier,
which means the user supplied string is used as the format specifier.

To reproduce this excellent bug, these steps can be taken:

1. Download Python (http://python.org) and win32com
(http://starship.python.net/crew/mhammond/win32/Downloads.html). These
two are _essential_ to any hacker's windows box.

2. Run 'python' so you get an interactive shell.

3. Attach to the 'python' process with OllyDbg, press 'F9' to continue
execution.

4. Type 'import win32api' and press enter in the python screen.

5. Type 'win32api.OutputDebugString("%s" * 50)' to crash OllyDbg.
Typically, if you have OllyDbg set as the JIT Debugger, another OllyDbg
screen will pop up OR

6. Type 'win32api.OutputDebugString("%8.8x" * 15)' to view whats on the
stack!

7. The python process will now have died since OllyDbg died, so do the
process again!

If this is all too hard, or you don't believe Then a screenshot for
your viewing pleasure is availiable at:
http://felinemenace.org/~nd/ollyfmt.png

Andrewg of FelineMenace managed to create a python script to exploit this
vulnerability, albeit with some shellcode problems

* Conclusion:
It certainly opens up the possibly for binaries to start owning their
debuggers, in an anti-reversing sense. GDB is a huge project too, with
multiple public/unpublished bugs. Because Debuggers work with the
executable in a state of execution, disassemblers such as IDA could be
vulnerable to a static attack of a malformed binary, much like the 
executable handling in the OpenBSD kernel i suppose. The possibilities are
endless! However there is a definate need for disclosure of these bugs, as
debuggers/disassembler are the first defense against the malicious.

* Greets:
TFM (Team FelineMenace), Greg + rootkit.com, people who spend their day
making sure imported beer is actually imported, peach.gotdns.org.

----
http://felinemenace.org/~nd

Origen

Desde luego si lo que dice es cierto habrá que ir con extremo cuidado a partir de ahora con los archivos que keramos examinar con el Olly.

Lo que no acabo de entender del todo como consigue el exploit que el Olly le ejecute código arbitrario....

En fin, que piensan del asunto?

Salu2

Una de las cosas que voy aprendiendo en sl curso de crack de Ratón es a entender un poco el código ensamblador (muy vagamente por ahora |-P), asi que hace poco me dió por investigar la manera de modificar un .exe para que no fuera detectado por el KAV y aprender de una vez a entender lo que estoy cambiando, no hacerlo al tún-tún como hasta ahora.

Como es fácil obtener los offsets que el KAV reconoce, es fácil localizar que cadena hay que cambiar del .exe con el Olly. Una vez localizada (y aki empiezan mis elucubraciones) en teoria se podria trasladar a otro lugar del .exe donde no estorbara, meterle un <call> al offset donde se trasladara con su <retn> correspondiente, y meter un <jmp> justo antes del call para que saltara hasta después del <retn>. O si acaso no se pudiera con un <call> (?) , pues hacerlo todo a base de <jmp>. La verdad es que no se que método es más conveniente.

El problema me viene a la hora de identificar con el Olly todas las instrucciones afectadas. No se si se puede meter un <call> en cualkier sitio, pero no creo. El <jmp> creo que tiene que ser más flexible. Y a la hora de encontrar donde meter ese código desplazado, pues supongo que los .exe deben tener su estructura, por lo que no se podra meter en cualkier sitio.

Además tambien ignoro si se puede añadir a lo bruto una serie de líneas más por ejemplo al final del .exe o si tendria que identificar código inútil del interior del .exe para sustituirlo por el que me interesa desplazar.

No se si me explico con claridad...  En resumen, mas o menos  mis preguntas serían ¿puedo interrumpir cualkier parte del código con un <jmp> o un <call> continuar el código en ese salto? ¿Donde meto ese salto (no el origen, ya que este te lo da el offset detectado por el AV, sino el destino)? ¿Cómo se identifican las partes de código inútiles (para machacarlas, si fuera necesario, con el código desplazado)?

En fin, posteo en busca de consejo y orientacion por parte de los maestros...