CitarIF Propiedad = "" OR Propiedad <> "www.elhacker.net" THEN
Response.Write("<h1><font color=Red>Maldito lammer no borres la propiedad de este código - <br>Propiedad www.elhacker.net - foro.elhacker.net</font></h1>")
Response.end
- Bienvenido a Test Foro de elhacker.net SMF 2.1.
Esta sección te permite ver todos los mensajes escritos por este usuario. Ten en cuenta que sólo puedes ver los mensajes escritos en zonas a las que tienes acceso en este momento.
#21
Bugs y Exploits / Re: Mi Primer ASP Shell
12 Abril 2005, 02:41 AM
#22
Ingeniería Inversa / Re: quitar limite de ejecuciones
24 Diciembre 2004, 22:09 PM
Otra solucion que se me ocurre asi a bote pronto es cambiar el EBX de la primera linea por ESI. De manera que al hacer SUB EAX, ESI reste el valor de ESI a la misma ESI, con lo cual tienes el contador siempre a 0.
No lo he probado pero en teoria deberia funcionar. Hay mil maneras de cambiar la ejecucion normal de un programa, lo dificl es localizar y sobretodo interpretar corretamente el codigo importante como ha hecho maese Mr.PoTaTo.
@ Elhackernet
Echale una leida al curso de Raton para saber de que va la ingenieria inversa.
salu2
No lo he probado pero en teoria deberia funcionar. Hay mil maneras de cambiar la ejecucion normal de un programa, lo dificl es localizar y sobretodo interpretar corretamente el codigo importante como ha hecho maese Mr.PoTaTo.
@ Elhackernet
Echale una leida al curso de Raton para saber de que va la ingenieria inversa.
salu2
#23
Ingeniería Inversa / Re: Nueva generacion de antidebuggers?
28 Julio 2004, 20:03 PM
Bueno, bueno, no hablen todos a la vez... de uno en uno, please...
¬_¬
¬_¬
#24
Ingeniería Inversa / Nueva generacion de antidebuggers?
22 Julio 2004, 22:19 PM
Me he kedado asin 
al leer lo esto:
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
al leer lo esto:Citar [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 upOR
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
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
#25
Ingeniería Inversa / Re:Que es la ingeneria inversa?
8 Junio 2004, 21:46 PMCita de: .txt en 11 Junio 2003, 12:38 PM
si meto la pata, pido disculpas a los mod´s!
la ingenieria inversa es un proceso que se hace programando (si no estoy mal en assembler), para lograr que los programas que estan "bloqueados", es decir como un shareware...
como asi bloqueado?
pos si, ya sabemos que un shareware dura en promedio 30 dias y se corta, pero aho está la idea de la ingenieria inversa: como esos datos estan en nuestro HD, pos se supone que podemos modificarlos para que el programa sirva...
creo que eso es la IV....
es algo mucho mas profundo...
bye!
Esta es una de las respuestas mas surrealistas que he leido en mi vida
#26
Ingeniería Inversa / Re: Modificacion inocua de código con Olly
28 Abril 2004, 01:17 AM
jajaja, toy en tos laos xD
No me acordaba de lo del topo del capitulo 2! voy a repasarlo pero ya! asias master...
Lo que dices de injertar código tiene mucho más sentido que lo mio, yo estaba dando mis primeros pasos (a palos de ciego xD) y 'ta claro que me complicaba demasiado la vida.
He estado comentándolo tambien con un amigo de la uni que sí estudia informática (aunke parezca mentira por estar por estos lares, mi carrera no tiene nada que ver con la informática ^^! ) y tiene más claros los conceptos teóricos de todo esto, y me ha dicho lo mismo, que lo más facil seria insertar código que no hiciera nada enmedio de la cadena detectada, nose, un NOP por ejemplo, o un CMP y luego pasar del resultado que dé, etc...
Ahora me disponía devorar el manual del Olly para ver cómo insertar código, si es que podía, pero por suerte se me ocurrió pasar por aki antes! jeje
En cuanto haga unas pruebas ya os comento el resultado...
'talueeeec
No me acordaba de lo del topo del capitulo 2! voy a repasarlo pero ya! asias master...
Lo que dices de injertar código tiene mucho más sentido que lo mio, yo estaba dando mis primeros pasos (a palos de ciego xD) y 'ta claro que me complicaba demasiado la vida.
He estado comentándolo tambien con un amigo de la uni que sí estudia informática (aunke parezca mentira por estar por estos lares, mi carrera no tiene nada que ver con la informática ^^! ) y tiene más claros los conceptos teóricos de todo esto, y me ha dicho lo mismo, que lo más facil seria insertar código que no hiciera nada enmedio de la cadena detectada, nose, un NOP por ejemplo, o un CMP y luego pasar del resultado que dé, etc...
Ahora me disponía devorar el manual del Olly para ver cómo insertar código, si es que podía, pero por suerte se me ocurrió pasar por aki antes! jeje
En cuanto haga unas pruebas ya os comento el resultado...
'talueeeec
#27
Ingeniería Inversa / Modificacion inocua de código con Olly
27 Abril 2004, 22:44 PM
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...
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...