Foro de elhacker.net

Hola

Estaba haciendo un ejemplo de como usar los opcodes para ejecutarlos en un C, por ejemplo

Este codigo es el clasico en esamblador de exit(0), y usando objdump quedo asi

#include <stdio.h>
 
char exits[] = "\xbb\x14\x00\x00\x00"
                   "\xb8\x01\x00\x00\x00"
                   "\xcd\x80";
 
int main(){
 
    int *ret;
    ret = (int *)&ret +2;
    (*ret) = (int)exits;
}

el programa lo compilo de esta forma ya que lo estoy analizando como 32 bits y mi sistema es de 64bits

gcc -m32 -ggdb -mpreferred-stack-boundary=2 -o salida salida.c

pero cuando lo ejecuto me sale una violacion de segmento, me imagino que falla exit(0) y no sale correctamente el programa

Alguien me podria decir porque falla el codigo?

es raro por que lo compile sin querer usando y una vez compilado abri el programa y no hubo error, luego como tu lo compilaste si, supongo que es el compilador

luego probe y me da error si pongo para que sirve esa opción? con los valores 2 y 3 me da error pero con el 4 ya no...

Es para alinear el stack


lo que no entiendo, es porque el codigo en ensamblador que compile en 32 bits si funciona cuando lo ejecuto, pero el archivo en C hay una violacion de segmento, solo como tu dices, si lo compilo de forma normal, no sale ningun error, pero acaba compilado como 64 bits, con opcodes de 32 bits

Supongo que la clave es que exits esta en una sección de datos y no en una de codigo, al menos en Windows muere ahi al depurarlo...

cierto, ya lo movi a la sección de código y se ejecuto bien... ya funciona, gracias

solo una ultima pregunta, en el archivo asm puse a ebx con 20, no es necesario pero es de practica

mov ebx, 20
mov eax, 1
int 0x80

cuando lo ejecuto, funciona bien y obtengo el registro de ebx

[linux]$echo $?
20

pero con el archivo hecho en C, me aparece un numero aleatorio

[linux]$echo $?
28
[linux]$echo $?
146
[linux]$echo $?
44

es normal?

salu2

De nadas, no se, fijate si depuras el programa y ejecuta exactamente el codigo correcto, de ser asi no tengo ni idea ...

Si intentas ejecutar la interrupcion al vector 0x80 en un sistema de 64 bits, tendras problemas tienes que usar la instruccion syscall, es mas rapida que la interrupcion al vector asi que no se porque estas en 32 bits.

Te dejo un codigo, devuelve el valor correcto y esta mucho mas optimizado, ya que solo me limito a saltar a la direccion de la shellcode, y esa misma es menos pesada pero no mas rapida.

char shell[] = "\x6a\x01\x58\x6a\x14\x5b\xcd\x80";
 
int main () {
 
asm ("jmp shell");
 
}

Compilado sin ninguna opcion.

Un saludo.

gracias cpu2, tendre en cuenta el codigo que me diste... y tienes razon por lo de 64 bits, por eso tenia la duda de hacerlo funcionar como 32 bits para evitar esos problemas  ;D

y lo otro si era normal, habia olvidado desactivar randomize del kernel  :silbar:

Tambien hay que quitar la proteccion de stack

-fno-stack-protector -z execstack

Y con eso, ya funciona con char en los datos

char exits[] = "\xbb\x14\x00\x00\x00"
                   "\xb8\x01\x00\x00\x00"
                   "\xcd\x80";
 
int main()

salu2

¿Eso quiere decir que los programas de 32 bits tienen que ser recompilados? En Windows hay una emulacion que da soporte al codigo legacy :silbar:

No, si tu sistema es multilibreria te permite ejecutar binarios de x86 en una amd64. Me acuerdo cuando utilizaba Gentoo en la instalacion te daba ha escojer un perfil si lo querias multilibreria o un amd64 puro, es decir nada de emulacion de binarios x86 y como ejecutes una interrupcion al vector 0x80 un core dumped.

Pero no se ya hace tiempo que no toco Linux, solo Backtrack. Pero es lo que me sucede con OpenBSD ya que es un sistema de 64 bits puro, es por eso que le dije lo de la interrupcion al vector 0x80.

Un saludo.

Ah, debe tener habilitado el soporte para 32 bits entonces.