Mensajes

por fin he conseguido hacer que funciona mi pequeño programa en assembler y ahora toca convertirlo en shellcode, pero todavía tengo caracteres nulos.
En este trozo por ejemplo:

Código [Seleccionar] Expandir

; ******************************************
; Buscamos la dirección base de kernel32.dll
; ******************************************
      xor eax, eax           
      mov eax, fs:[30h]
      mov eax, [eax+0Ch]
      mov eax, [eax+1Ch]
      mov eax, [eax] 
      mov eax, [eax]
      mov eax, [eax+08h]
   push eax ; guardamos en la pila la direccion base de kernel32.dll

la instrucción mov eax, fs:[30h] me la traduce en assembly como 64 A1 30 00 00 00
y el problema es claramente que el 30h lo traduce a 32 bits (en little endian) y por lo tanto rellena con ceros a la derecha.

luego las instrucciones mov eax, [eax] que se utilizan para saltar a la siguiente dirección (o algo parecido), se traducen como 8b00.

Y no se como puedo eliminar estos caracteres nulos.
¿alguna indea? ¿hay quizá algún programa que codifique la shellcode automaticamente sin caracteres nulos?


un saludo.

[sub esp, 10h]

No se si ya has arreglado tu problema, pero te traigo una posible solución. Si el problema era la dirección a WinExec, proba con ShellExecuteA. Te pongo el codigo. $ mov dword ptr[ebp],636c6163h $ mov dword ptr[ebp+4],6578652eh $ mov dword ptr[ebp+9],0 $ push 5 $ push 0 $ push 0 $ push ebp $ push 0 $ push 0 $ call ShellExecuteA $ ret . El simbolo "$" lo pongo para hacer el salto de línea porque estoy desde el celular.

lo he arreglado pero todavía no tengo claro por qué falla la dirección de winexec y de CreateProcess:

Para empezar en el código había errores:

primero yo estaba restando 9h y en realidad había que restar 10h en la pila(no entiendo el porqué pues no manejo bien lo de la pila):
sub esp, 10h
Luego la dirección que le daba a la cadena también estaba mal, tenía que ser 0fh y no 11h cómo venía poniendo yo (tampoco entiendo el porqué).

tambien sumaba despues de la cadena la longitud de esta pero en realidad no hay que hacerlo.
add esp, 9h

y finalmente, y esto sí que es extraño... la dirección de winexec no era correcta. como había dicho la obtenía con Getprocadress en un programita creado en visual Studio. El Offset de la función winexec dentro de kernel32 me dá correcto pero la dirección base que obtiene un programa hecho en visual studio no coincide con la dirección base que utiliza mi programa ejecutable.

al final he averiguado la dirección, haciendo primero un invoke winexec y mirando a qué dirección saltaba mediante el ollydbg, y luego utilizando dicha dirección en mi programa, al fin ha funcionado pero no he entendido muy bien los fallos.

de todas formas probaré el código que tú me pones a ver si me funciona también, muchas gracias!!

ah,,  se me olvidaba, el código que me funciona es este:

.386
.model flat, stdcall
option casemap:none

.data
.code
start:

push ebp
mov ebp, esp
xor dl, dl    ;con esto hacemos que dl valga 0

sub esp, 10h
mov byte ptr [ebp-0fh],63h 
mov byte ptr [ebp-0eh],61h   
mov byte ptr [ebp-0dh],6Ch
mov byte ptr [ebp-0ch],63h
mov byte ptr [ebp-0bh],2Eh
mov byte ptr [ebp-0ah],65h
mov byte ptr [ebp-09h],78h
mov byte ptr [ebp-08h],65h
mov byte ptr [ebp-07h],dl
push 5
lea eax, [ebp-0fh]   ;cargamos la direccion que apunta a nuestra cadena
push eax     
mov eax,7732e76dh   ;winexec
call eax
push 1     
mov eax,772f2aefh   ;exit process
call eax

end start

milibreia db "WinExec",0   ;debes de linkarlo con /section:.text,RWE
calculator db "calc.exe",0   ;pero tu lo adaptas como hiciste antes

no entiendo muy bien qué es /section:.text,RWE y cómo debo linkarlo etc.
La verdad es que lo de hacer la shellcode de esta forma es todavía muy avanzado para mí. Necesito hacerlo primero con las direcciones hardcodeadas y luego pasar a este método.

un saludo.

así lo he hecho pero sigue sin hacer nada. Como bien dices, he comprobado la dirección y a mí me parece que el problema es justamente ese, la dirección de la función winexec. Es cierto que varían de un sistema a otro, e incluso te puedo decir que en el caso del w7 varía cada vez que el sistema se reinicia. pero ese no es el problema ya que la modifico cada vez que la utilizo (como puedes imaginarte esta no es para una verdadera shellcode sino más bien para una introducción a como funcionan). Y la dirección la obtengo con un programa que llama a getprocadress y me imprime la dirección en la consola. Luego yo la modifico en mi programa. Pero lo he depurado con ollydbg y parece que la dirección de winexec no es correcta. No pasa lo mismo con ExitProcess que sí que lo es.

he probado con CreateProcessA en lugar de winexec y el resultado es igual. La dirección que devuelve getprocadress no es correcta. No lo entiendo.

lo he probado en visual studio y el problema parece estar en la dirección de winexec. Sin embargo el método para obtener dicha dirección es el de usar getprocadress  (en otro programa) y no me había fallado con otras funciones hasta ahora.

¿pasa algo raro con la dirección de winexec en kernel32.dll en windows7?

[.386.model flat, stdcalloption casemap:none.data.codestart:sub esp, 9hmov byte ptr [ebp-11h],63h mov byte ptr [ebp-10h],61h mov byte ptr [ebp-0fh],6Ch mov byte ptr [ebp-0eh],63h mov byte ptr [ebp-0dh],2Eh mov byte ptr [ebp-0ch],65hmov byte ptr [ebp-0bh],78h mov byte ptr [ebp-0ah],65hmov byte ptr [ebp-09h],00hpush 5 lea eax, [ebp-11h] ;cargamos la direccion que apunta a nuestra cadenapush eax mov eax,71c326d3h ;winexeccall eaxpush 1 mov eax,772e2aefh ;exit processcall eaxend start]

a ver si alguien me puede echar una mano con este programa en assembler (pensado para generar una shellcode).
Más simple no puede ser, quiero llamar a winexec para que ejecute la calculadora: (no hace nada). Cuando lo depuro con olly, por pasos, al llegar a la llamada a la dirección de winexec me dá un error de modo que esa dirección no puede ser leída.
La dirección de winexec la obtengo con el típico programa que utiliza la función getprocadress, y en principio debería ser correcta.

.386
.model flat, stdcall
option casemap:none

.data
.code
start:
sub esp, 9h
mov byte ptr [ebp-11h],63h 
mov byte ptr [ebp-10h],61h   
mov byte ptr [ebp-0fh],6Ch
mov byte ptr [ebp-0eh],63h
mov byte ptr [ebp-0dh],2Eh
mov byte ptr [ebp-0ch],65h
mov byte ptr [ebp-0bh],78h
mov byte ptr [ebp-0ah],65h
mov byte ptr [ebp-09h],00h
push 5
lea eax, [ebp-11h]   ;cargamos la direccion que apunta a nuestra cadena
push eax     
mov eax,71c326d3h   ;winexec
call eax
push 1     
mov eax,772e2aefh   ;exit process
call eax
end start

no hace nada, lo intento depurar con ollydbg pero no entiendo muy bien si hace lo correcto o no.

lo primero que hago es reservar espacio en la pila para 9 bytes. Luego inserto la cadena pero me salto unos bytes que había antes en la pila, por eso empieza en ebp-11h.

una vez insertada la cadena en la pila, "calc.exe/0", meto el parametro 5 (que equivale a SW_SHOW, y que es otro parámetro de winexec).

y finalmente llamo a winexec.

hola estoy peleandome con una shellcode basica, sólo con fines didácticos, (en windows7) y he observado que a la hora de obtener la dirección (hardcodeada) de una función de una dll hay dos formas de hacerlo (pero me dá que en realidad son cosas distintas):

- Una (que es la que utilizo yo y he comprobado que funciona) es obtentiendo la dirección de la función, con un programa que llame a getprocadress y me devuelva la dirección. Esta dirección es la que utilizo en la shellcode (y funciona, sólo que hay que volver a calcularla cada vez que se reinicia el sistema).

- La otra no la he probado sólo la he visto, y consiste en utilizar un programa que me muestre las dependencias de un ejecutable, como por ejemplo dumpbin o dependencyWalker. Con estos lo que se obtiene es la dirección base de la dll y luego la dirección de la función en dicha dll y se suman ambas para obtener la dirección absoluta de la función, y así utillizarla en la shellcode. He observado que con este método siempre dá los mismos valores, aunque se reinicie el sistema. Además me dá los mismos valores aún analizando dos programas diferentes.

entonces llegados a este punto me surge la duda de qué es lo que estoy obteniendo realmente en ambos casos ya que parece que estoy obteniendo la dirección de una función en ambos, pero obtengo resultados distintos en uno y en otro.

un saludo.

mensaje editado..

[push dword 0x9999]

Mmm, y asi?
push dword 0x9999

en masm no me ensambla, me dá error de sintaxis, tengo que ponerlo así 9999h. De todos modos yo lo estoy poniendo en decimal: 9999. Pero aún así el problema es que al ser un número de 32 bits, me rellena con ceros lo que queda. No importa demasiado ya que lo que hago es poner 99999999 y de este modo ya no rellena nada, pero era simplemente para saber cómo podía solventar lo de los ceros en este caso.

Un saludo, y muchas gracias x vuestra ayuda.