Mensajes

Que tal. Disculpen, alguien sabe cómo se pueden agregar bots en el half-life? (no el counter-strike)

Gracias

El error está en otra parte del código, lo podrías postear.

Una pregunta ¿vos entendés lo que hace el código? o ¿simplemente intentas compilarlo sin saber nada de C?

Otra cosa ¿Revisaste que el Dev-C++ soporte las aplicaciones en C ANSI Estandar y los Preprocesadores tradicionales de C?

[Pequeño detalle:]

¿Qué versión del IDE Dev-C++ usás (acordate que no es un compilador, sino que simplemente un IDE simplemente del mingw32: /Dev-Cpp/mingw32/ puedes mirar los directorios /lib y /bin para informarte un poco)?

Al menos en la versión Dev-C++ 4.9.8.0 puedes probar lo siguiente:

Herramientas/Opciones del Compilador: vas a la siguiente:

--> Generación/Optimización de Código
    -->Compilador C:

                    --> Soportar todos los programas en C ANSI Estandar [Yes]
                    --> Soportar Preprocesadores Tradicionales de C [Yes]
                    --> Desactivar todos los Mensajes de Aviso (Warnings) [No]

Probá dejando ésas opciones de ésa forma.
Zheo escribió un texto sobre el Dev-C++ (ó Dev-Cpp) el cual está en la web de este foro o en el foro de programación general (leete la ayuda de la aplicación, siempre es útil).

Pequeño detalle:

Si bien la función "printf()":

Código [Seleccionar] Expandir


#include <stdio.h>
int printf(const char *format...);


Uso:

Código [Seleccionar] Expandir


#include <stdio.h>
printf("Cadena de texto");


Está declarada en el fichero de cabecera stdio.h, no ocurre lo mismo con "exit()":

Código [Seleccionar] Expandir


#include <stdlib.h>
exit();


Está declarada en stdlib.h, y en los argumentos toma diversos valores (numéricos). Ejemplo:

Código [Seleccionar] Expandir


exit(0); // termina el programa de modo normal.


Código [Seleccionar] Expandir


exit(1); /* termina el programa de forma anormal (se usa generalmente cuando hacés una comprobación, y ésta da NULL o cero). */


Código [Seleccionar] Expandir


exit(3); /* termina el programa abortandolo. */


Ésta última es abort():

Código [Seleccionar] Expandir


#include <stdlib.h>
void abort(void);


Uso:

Código [Seleccionar] Expandir


#include <stdlib.h>
abort(); // Te imprime en la salida estándar: "abnormal program termination"


Un saludo.

PD: podrías copiar y pegar en una cita el error específico que te el compilador.

En el sitio http://www.cplusplus.com/src/ hay una aplicación, en código fuente, programada en justamente en C++. Es un programa para controlar la impresora (por consiguiente el puerto paralelo), te decía este sitio porque casualmente ayer en la noche yo estuve vajando algunos códigos.

Griph

PD: no te pego acá el código fuente porque es muy extenso, mejor bajálo vos (esta un fichero comprimido bajo el algoritmo zip).

Edito el post y te pego el código fuente:

Código [Seleccionar] Expandir


/*********************************************************************
*
* hwprint.cpp by Tom Lee
*
* Example program to demonstrate printing using the Win32 API/GDI.
* I'm new to printing with the Win32 GDI myself (although I've
* used the GDI heaps before for gfx etc.) - I've been
* trying for a long time to find useful info on the Internet
* about this very thing, but came across next to nothing.
* I thought it'd be a disservice to the Internet not to get
* something about printing with Win32/GDI out the door ASAP!
*
* -------------------------------------------------------------------
*
* Libraries to link in:
*
* kernel32.lib, user32.lib, gdi32.lib, comdlg32.lib
*
********************************************************************/

#include <windows.h>

int WINAPI WinMain( HINSTANCE hInst, HINSTANCE hPrev, LPSTR lpCmdLine, int nCmdShow )
{
PRINTDLG pd;

memset( &pd, 0, sizeof( pd ) );

pd.lStructSize = sizeof( pd );

/*
* get rid of PD_RETURNDEFAULT on the line below if you'd like to
* see the "Printer Settings" dialog!
*
*/
pd.Flags = PD_RETURNDEFAULT | PD_RETURNDC;

// try to retrieve the printer DC
if( !PrintDlg( &pd ) )
{
MessageBox( NULL, "PrintDlg( &pd ) failed!", "Fatal Error", MB_OK | MB_ICONERROR );

return -1;
}

DOCINFO di;
HDC hPrinter = pd.hDC;

// initialization of the printing!
memset( &di, 0, sizeof( di ) );
di.cbSize = sizeof( di );
StartDoc( hPrinter, &di );

// start the first and only page
StartPage( hPrinter );

// uncomment the following line to print in colour! :)
// SetTextColor( hPrinter, 0x0000FF );

// write "Hello, World!" to the printer's DC
TextOut( hPrinter, 100, 100, "Hello, World!", 13 );

// finish the first page
EndPage( hPrinter );

// end this document and release the printer's DC
EndDoc( hPrinter );
DeleteDC( hPrinter );

return 0;
}


El texto está bien. Sobre todo el método de didáctica que usaste, lo digo por explicar unas cuantas cosas con el debugger a mano, me parece que es una buena forma de fundamentar la teoría y práctica.

A pesar de que el texto está muy explicado, yo le recomendaría a cualquiera que
quiera comenzar con el tema de los exploits y las shellcodes que aprenda bien
ensamblador (fundamentalmente este lenguaje) y C; de otra forma a pesar de que
una persona con conocimientos nulos de programación ensamblador lea textos muy
explicados como éste, se le dificultará bastante la comprensión (hay que aprender a programar bien primero).

Para quien quiera saber más o menos de que se trata este texto, aquí le dejo un mini índice (me parece que te olvidaste de esa parte Rojodos, lo podrías agregar así organizas un poco mejor tu texto ).

-== Introducción. ==-
- C/C++
- Ensamblador (ASM)
- Debugger (Depurador)
- Dissasembler (Desamblador)
- Hex Editor (Editor Hexadecimal)
- La CPU (microprocesador)
- Registros de la CPU.
- ¿Que es una vulnerabilidad?
- ¿Que es un exploit?
- ¿Que es una shellcode?
- ¿Que es un overflow?
- ¿Porque se le llama Stack Overflow?
-== EJEMPLO CODIGO VULNERABLE A STACK OVERFLOW ==-
-== ¿PARA QUE NOS SIRVE UN STACK OVERFLOW? ==-
-== COMO HACER UNA SHELLCODE BASICA ==-
-== CREANDO EL EXPLOIT ==-
-== DOCUMENTACION ==-
-== AGRADECIMIENTOS ==-

Saludos,

Griph.

Estaba leyendo un texto sobre ensamblador y vi una parte interesante que habla sobre la Pila (Stack) del Procesador. Dado que es un concepto que hay que tener claro a la hora de diseñar una shellcode para un exploit, etc. aquí les dejo el texto:

     - La pila del procesador:
     -------------------------
     La pila es una característica interna del 8086. Es una estructura de
     datos situada en la RAM. Proporciona a los programas un lugar donde
     almacenar datos de forma segura, pudiendo compartirlos con otros
     procedimientos o programas de forma cómoda y práctica.

     La función más importante de la pila es la de mantener las direcciones
     de retorno en las llamadas a procedimientos e interrupciones, así como
     guardar los parámetros pasados a estos procedimientos.
     La pila también se utiliza para almacenamiento temporal de datos dentro
     de un programa, y para muchas cosas más que se aprenden con la práctica.

     La pila tiene su nombre por analogía con los montones de platos apilados
     (pilas de platos). Cuando un dato nuevo es introducido en la pila, se dice
     que es apilado (push) debido a que se sitúa por encima de los demás, es
     decir se sitúa en la CIMA de la pila.

     Una pila opera en el orden  último-en-entrar - primero-en-salir:
     LIFO (LAST IN FIRST OUT) o lo que es lo mismo, el último en entrar es
     el primero en salir.

     Esto significa que cuando la pila se utiliza para seguir la pista de los
     retornos de las subrutinas, la primera llamada a subrutina que se hizo,
     es la última que se devuelve. De esta manera, la pila mantiene ordenado el
     funcionamiento del programa, las subrutinas y rutinas de tratamiento de
     interrupción, sin importar la complejidad de la operación.

     La pila crece en orden inverso. Es decir, a medida que se añaden nuevos
     datos, la cima de la pila se acerca más a posiciones más bajas de memoria.

     Existen 3 registros destinados a gestionar la pila.
     Registro de segmento de pila (SS): que indica la dirección base del
     segmento de pila
     Puntero de pila (SP): que apunta a la cima de la pila.
     Puntero base de pila (BP): que se usa para moverse a través de la pila
     sin cambiar la cima. Se suele utilizar para acceder a los distintos
     parámetros al llamar a una función.

     Los elementos que se almacenan en la pila son del tipo palabra (2 bytes).
     Esto quiere decir, entre otras cosas, que el puntero de pila (SP), así como
     el puntero base de pila (BP), incrementan/decrementan en 2 su valor para
     apuntar a un nuevo elemento dentro de la pila, fruto de apilar o desapilar
     un elemento.

     También conlleva el que si queremos almacenar un byte en la pila, primero
     lo debemos convertir en palabra (2 bytes), y luego almacenar esa palabra.
     Esto es muy sencillo, sólo hay que meter ese byte o registro de 8 bits
     en un registro de 16 bits y almacenar este registro.

     Las instrucciones para manejar la pila son:
     PUSH ---> Guarda un dato en la pila. Decrementando SP en 2 unidades, para
               que apunte al nuevo elemento a introducir.
               Ejemplo: PUSH AX --> Apila el contenido de AX en la cima de la
                        pila.

     POP ----> Obtiene un dato de la pila. Incrementando SP en 2 unidades, para
               que apunte al nuevo elemento a introducir.
               Ejemplo: POP AX --> Desapila el contenido de la cima de la pila
                        en el registro AX. Es decir, AX contendrá el valor
                        que hubiera en la cima de la pila, y el puntero de pila
                        se actualiza incrementándolo en 2.

     PUSHF --> Guarda el contenido del registro de estado (FLAGS) en la pila.
               Decrementando SP en 2 unidades, para que apunte al nuevo elemento
               a introducir.
               No es necesario indicar sobre qué actúa esta instrucción, lo
               lleva implícito en su nombre PUSHF (PUSH FLAGS).

     POPF ---> Introduce en el registro FLAGS el contenido de la cima de la
               pila. Incrementando SP en 2 unidades, para que apunte al nuevo
               elemento a introducir.
               Al igual que con la instrucción anterior, no es necesario indicar
               sobre qué actúa esta instrucción POPF (POP FLAGS).



     Conviene recordar el hecho de que la pila crece en orden inverso al
     normal, es decir de direcciones de memoria altas a direcciones bajas.
     Por lo tanto es necesario tener en cuenta el uso que se va a hacer de
     la pila en el programa, debido a que si reservamos espacio en nuestro
     programa para una pila pequeña, en caso de sobrepasarla haciendo muchos
     push seguidos, machacaría nuestro programa.

     Hay que tener en cuenta que no sólo es nuestro programa el que utiliza
     la pila mediante la instrucción PUSH y mediante llamadas a procedimientos,
     interrupciones, etc. Sino que mientras nuestro programa corre se están
     sucediendo numerosas interrupciones que conllevan muchos PUSH.
     Por ejemplo, 18'2 veces por segundo se produce la interrupción de reloj,
     con lo cual, todas estas veces se está apilando y posteriormente
     quitando información de la pila.

     Por regla general, basta con tener una pila de unos 2 KS, es decir, espacio
     para almacenar 1024 elementos. Es muy difícil que se sobrepase este tamaño.

Que les sirva.

Griph

El Desbordamiento del Buffer: Buffer OverFlow (desbordamiento de la memoria).

Los desbordamientos de buffer se basan en introducir el código en el espacio reservado para las variables locales (los argumentos de un método/función) y después modificar la dirección de retorno/regreso (RET), en donde regresa la información, para que apunte a un offset en donde hemos introducido nuestro código fuente. Este código puede ser - por ejemplo - una ShellCode, es decir, instrucciones para llevar a cabo la ejecución de un intéprete de comandos como puede ser: bash, sh, entre otros.

Una forma de aprovechar los desbordamientos del buffer (en el caso del Lenguaje de Programación C) es la función strcpy(), con la cual se sobreescribe una posición en la memoria (es decir, se sobreescribe un offset) "parecido a las funciones de las shell codes". El string origen (la cadena de caracteres) de la función "strcpy" contiene nuestro código al principio y después la nueva dirección de retorno (RET) repetida tantas veces como sea necesario para llegar a sobreescribir la antigua.

El desbordamiento del buffer se produce cuando un usuario o un proceso intenta introducir en el buffer una cantidad de datos superior para lo cual estaba preparado el buffer. Algunas funciones útiles para llevar a cabo el desbordamiento del buffer son, las siguientes:

Código [Seleccionar] Expandir


* strcpy();
* strcat();
* sprintf();

Entre otras (nada es perfecto y por consiguiente es más que probable que hayan otras funciones que ayuden a la hora de desbordar un buffer).

Lo que provoca el desbordamiento de un buffer es una violación de la segmentación de memoria. El objetivo de esto es saltar a otra dirección offset, y por consiguiente caer en la librería que tiene el intérprete de comandos. Es decir la Shell para ejecutar los comandos, que para esto estaremos dentro del sistema del cual se está testeando.

De una forma un poco más detallada se puede explicar qué causa el fallos de la siguiente manera:

En realidad el fallo en sí no se provoca al desbordar el buffer o sobrepasar el valor para el cual está preparada la variable local, sino que al escribir más de lo que se había reservado se puede llegar a escribir la RET (la dirección de retorno). Luego el sistema operativo llevará a cabo la función a la cual se le ha desbordado buffer y se dirige a la pila. Después buscará el offset en el cual se encuentra la RET y encontrará en ésta una violación de segmento.

Existen dos tipos de desbordamientos: "Locales" y "Remotos".

Un buffer de longitud fija de 128 bytes, define la cantidad de datos que pueden almacenarse como entrada al mandato SendMail que puede servir para identificar usuarios (es decir que a tal fin está preparada para recibir 128 bytes, de lo contrario desbordará).

Entonces si envíaramos un bloque de 1000 caracteres (lo cual equivale a 1000 bytes) en lugar de un bloque de 128 caracteres (128 bytes) lo que sucede es que el buffer de SendMail se desborda; y por consiguiente se puede producir una denegación de servicio (es decir los ataques conocidos comúnmente como DoS, Denial of Service) y podría ejecutarse el comando /bin/sh. Lo grave es que si esto sucede un intruso puede tener privilegios de root (administrador):

Código [Seleccionar] Expandir

Echo ?sendmail 'perl -e 'print ?a? x 1000' ' ? |nc www.victima.com 25

Por suerte no todos los programas responden de igual manera que SendMail. El código que se usó es EGG Assembly (Assembly, sinónimo de ensamblador).

De todos modos el código fuente en ensamblador depende del Sistema Operativo, uno para GNU/Linux es el siguiente:

Código [Seleccionar] Expandir


char shellcode [] =
? \xeb\x1f\x5e\x89\x76\x08\x31\xc0\x88\x46\x07\x89\x46\x0c\xb0\x0b?
? \x89\xf3\x8d\x4e\x08\x8d\x56\x0c\xcd\x80\x31\xdb\x89\xd8\x40\xcd?
? \x80\xe8\xdc\xff\xff\xff\bin\sh ? ;


¿Cómo se Usan los Exploits?

Los exploits son formas de explotar los bugs/vulnerabilidades que presenta un software  determinado, lo cual se puede llevar a cabo mediante una aplicación que fue programada especialmente para explotar una vulnerabilidad específica (un bug). En el transcurso de diseñar el exploit se lo puede programar para que explote la vulnerabilidad de forma remota o local.
Forma Local (exploit local): es el caso en el que tienes un entorno interactivo (una shell,  por ejemplo). Para ejecutar un exploit de forma local hay que tenerlo en la máquina y luego subirlo.

Forma Remota (exploit remoto): se ejecuta de la máquina en la cual se esta probando el  bug/vulnerabilidad que existe en otra máquina remota, aprovechando algún servicio que tenga conexión a la red y por consiguiente que tenga la vulnerabilidad que se está estudiando (pueden ser muchas, así como también una sola). De esta forma generalmente lo que se intenta es tener acceso a una shell. Tanto mediante un puerto privilegiado (los que son menores a 1024, los cuales están reservados para el sistema operativo y para el usuario root) o a un puerto no privilegiado (los que son mayores a 1024 en adelante). Respecto de los puertos privilegiados puede ser que con el "nc" puedes mandar una rootshell bin/bash (por ejemplo) y luego telnetear y tener la shell ahí lista para tipear comandos. Esto se puede ver en aquellos  exploit que envían la shell al puerto 80, por ejemplo (y cabe decir que el objetivo es el de saltarse los firewalls). De una u otra forma esto se consigue si el exploit logra tomar el privilegio de usuario root o ejecutarse en el espacio GDT del  kernel (de esta forma se puede abrir un puerto privilegiado). Referente a los puertos no privilegiados son puertos más "grandes" y por consiguiente tienen  una probabilidad de colapsar menor que un puerto privilegiado. Además es una forma de que el admin (sysop) no se de cuenta  de que hay un intruso en el sistema. Por otro lado cabe decir que un exploit puede programarse en cualquier lenguaje (siempre y  cuando tenga la suficiente capacidad para llevar a cabo un desarrollo de este tipo, generalmente en se encuentran  escritos en C; dado que se ha convertido en un estándar en la red.
Este es un ejemplo de código en Java que puede producir un exploit (esto es simplemente un  trozo de de código hecho en Java, y es precisamente un método o función):

Code:

public void processX(int i) {
int a = 10;
int result;
result = i / a;     // esta es la línea que puede causar un exploit
}

Este es el código de un método normal que espera una reducida cantidad de datos enteros (int) y lo procesa de acorde a algún valor definido dentro del mismo programa o su base de datos.
Podria no ser un valor cero, y esto haría un crash al sistema, el problema mayor de los  códigos es que no rechequean o válidan ninguna entrada de sus procesos, entonces un exploits puede hacer lo que desee, desde una tonteria hasta un serio programa de seguridad en flaws. En fin... los exploit son provocados por algún mínimo error que pueda tener un determinado software.



* Proceso de Compilación:

¿Qué es Compilar un Código Fuente?

Es un proceso realizado por un programa compilador, que consiste en la traducción del código  fuente escrito por el programador en alguno de los lenguajes de programación existentes (BASIC, C,C++,Java, Cobol, Pascal, Phyton, Perl, Delphi, Ada, Ensamblador, etc.) en código ejecutable (un programa) en un determinado sistema informático (UNIX, GNu/Linux, Windows,
Solaris, etc.).

Más información en: http://www.hispabyte.com/glosario/index.php?letra=c

• Compilar un exploit escrito en lenguaje C desde GNU/Linux sería:
  
  *_* Compilación:
  
  #gcc exploit.c -o exploit
  
  *_* Ejecución:
  
  #./exploit <parametros><parametros2> etc.
  
  En caso de no tener acceso a un sistema GNU/Linux, se puede compilar desde windows. Mediante compiladores como: LCCWIN32, Dev C++, etc. Aunque cabe decir que muy pocos (esto se ve reflejado en el tema de los sockets, es decir en rigor de verdad por las librerías las cuales son distintas para cada sistema operativo y el exploit tendría que estar escrito especialmente para windows). De una u otra forma se puede leer el código fuente: cat  exploit.c , more exploit.c, etc. para ver el código fuente y leer las especificaciones que podría traer; tanto para la correcta compilación como para su posterior uso.
  
  Puede ocurrir que en la compilación de las fuentes con DevCpp (comúnmente conocido como Dev- C++) surgan errores referentes a los archivos de encabezado (headers), los cuales se deben a que se quiere  utilizar un fichero ***.h que no es estándar (porque son creados por otros programadores, para otros compiladores o bien para  otros sistemas operativos). Es
  decir este compilador trabaja con dos tipos de ficheros headers: Los ANSI (que son estandar) y los que trae de forma predeterminada windows (que también son ANSI pero sólo sirven para este sistema operativo, un ejemplo de estos ficheros es por ejemplo winsock.h que sirve para trabajar con wsockets en windows). Para evitar estos  problemas un compilador como
  CYGWIN con el paquete GCC instalado.
  
  
  
• Un exploit en Perl (estos funcionan tanto para GNU/Linux como para MS-DOS, aunque para  este último hay que llevar a cabo algunos pasos anteriores antes de comenzar a compilar códigos):
  
  perl exploit.pl <parametros> <parametros>
  
  Luego se ejecuta el fichero exploit.pl. El intérprete de Perl lo va compilando línea por  línea (al exploit) y luego lo ejecuta secuencialmente. Para ejecutar estos exploit en windows se puede bajar el ACTIVE PERL, y luego se pueden  ejecutar los exploits escritos en
  Perl desde una consola MS-DOS: C:\perl exploit.pl <parametros>
  
  
  
• Compilar un exploit en shellscript (éstos sólo funcionan en GNU/Linux):
  
  ./sh exploit.sh parametros
  
  En fin así como se puede compilar o programar un exploit con estos lenguajes, se puede hacer  también con cualquier lenguaje del cual se tenga un buen dominio (que se lo sepa usar bien).
  
  
  
  Para más información:
  
  * www.securityfocus.com
  * www.packetstorm.com
  * www.securiteam.com
  * Las e-zines de NetSearch.
  * www.decowar.com
  * www.cyruxnet.org (tiene muy buenos textos)
  * www.zine-store.com.ar
  * www.hackemate.com.ar (se las han ingeniado muy bien para recopilar tantos e-zines, son verdaderamente muchos)
  * www.cyervonet.com.ar
  * www.prehackers.com
  * www.hackxcrack.com (hay información muy útil sobre seguridad avanzada en general, viene muy bien darle una mirada)
  * http://www.cygwin.com/ (compilar y ejecutar exploits en windows, es una emulador de la shell para windows)
  * http://cygwin.com/faq/
  * http://cygwin.com/cgi-bin2/package-cat.cgi?file=gcc/gcc-3.2-3&grep=gcc (el compilador gcc)
  * http://gcc.gnu.org/
  * http://cygwin.com/cgi-bin2/package-grep.cgi?grep=gcc (paquetes para gcc)
  * En caso de que falte la DLL CYGWIN.dll (hay que ubicarla en el directorio system32 o system):
  http://www.cs.washington.edu/homes/kautz/blackbox/cygwin1.dll
  * http://cyruxnet.org/rpcxploit.htm (Cómo usar un xploit)
  * http://www.hackxcrack.com/phpBB2/viewtopic.php?t=14605 (son servidores para hacer poner en prueba los testeos de seguridad, cabe decir que es para prácticar cómo podría alguien atacar nuestro servidor u ordenador personal).

Nota: las direcciones offset de las cuales se habla en este texto son fictisias, simplemente se dan esos números para
proceder a la ejemplificación. No deben ser tomados en cuenta.

Un offset es un desplazamiento respecto de a una dirección de memoria. Por ejemplo, kernel32.dll se carga en memoria
a partir de la dirección (la siguiente es una fictisia) 0x76890000. Es decir, la dirección 0x76890000 empieza la
"DLL" (la cual recibe el nombre de dirección base). Bien, ahora, si por ejemplo usted quiere usar la función
LoadLibraryA (la cual se haya contenida en la DLL kernel32.dll), tendrá que informarse del offset de esa
función, le cual es: 0x7C. Lo cual quiere decir que la función la encuentra aquí:

Dir. Base + Offset = Dirección de la Función
0x76890000 + 0x7C = 0x7689007C

Entonces cuando quiere llamar a LoadLibraryA en ASM, tienes que mandar sus arguementos a la pila
(push eax/ebx/ecx o datos a mano..., teniendo en esos registros los argumentos, mandándolos en orden inverso).
Lo cual es de la siguiente forma:

push eax;  // Argumento 2º
push ebx;  // Argumento 1º
call 0x7689007C;  // Llamada a LoadLibraryA

Ese código ejecutará:

LoadLibraryA (argumento1, argumento2);

En el caso de los sistemas operativos de la empresa micro$oft las direcciones base de las DLL y los offset
de las diversas funciones cambian según la versión del sistema, los service packs instalados, parches y demás cuestiones.


Es decir:


Win 98 --> Dir Base kernel32.dll = 0x78960000

Win 2k --> Dir Base kernel32.dll = 0x79990000

Win 2k SP1 --> Dir Base kernel32.dll = 0x80000000

Win 2k SP4 --> Dir Base kernel32.dll = 0x79880000

Win XP --> Dir Base kernel32.dll = 0x80600000

Win XP SP1 --> Dir Base kernel32.dll = 0x80500000


Como puede ver, si durante la ShellCode deseamos llamar a LoadLibraryA simplemente tenemos que cambiar la dirección
de memoria del kernel32.dll y luego la de su offset, lo cual recibe el nombre de harcodear direcciones de memoria
o direcciones offsets). Por consiguiente nos damos cuenta que para cada shellcode que programemos tendremos que
desarrollar una para cada sistema operativo diferente. Aunque en realidad cabe decir que hay formas de lograr
una shellcode que se ocupe de buscar la dirección base y el offset de la función a utilizar de forma automática
(para que no la tengamos que cambiar y a la vez se pueda emplear en diferentes sistemas operativos).

Con la Pila (Stack) ocurre la misma situación: varía según el sistema operativo, service packs (SPs)
instalados, etc. Por eso puede que la dirección de memoria RET funcione en nuestro ordenador y no en otro.
De todos modos hay algoritmos que aplican la técnica de fuerza bruta (brute force) a la RET Address, hasta
que logran encontrar la dirección correcta a la que apunta la shellcode.

La Shellcode generalmente va como argumento del programa. Este arguemento se copia a un buffer mal construido, el
cual (dicho en palabras simples) peta. Luego se puede llamar a la shellcode a ese buffer que ha petado o en
donde estaba antiguamente, es decir en los argumentos (en ARGV, exactamente).

Una Shell code es una serie de ordenes en ensamblador que hace algo a lo cual sacamos provecho; ejecutar /bin/sh para obtener una shell, por ejemplo copiar una shell y setearla con suid root, etc. Tiene características de programación un tanto especiales.

Se usa para conseguir ejecutar un código después de haber sobreescrito la dirección de retorno de un programa/función mediante un overflow, o mediante cualquier otro método válido. Es decir, el valor de la dirección de retorno que se sobre-escribirá será la de nuestra shellcode. Cuando se programa una ShellCode simplemente cabe decir que cuando se produzca el desbordamiento y el salto se ejecutará nuestra ShellCode.

Nota: Lo de ejecutar bin/bash, setuid(0), etc. es en GNU/Linux o UNIX. Las ShellCodes para Windows (se construyen, obviamente, de distinta forma) hacen "otras cosas" como ejecutar cmd.exe (la shell del MSDOS), descargar y ejecutar algo silenciosamente (como un troyano), añadir un usuario definido como administrador del sistema, etc.

Cuando se programa una ShellCode a veces es necesario harcodearla, lo cual significa que hay que meter en el código en assembler (ASM) la dirección exacta del RET, de los strings, de las llamadas a funciones, etc. El problema es que la dirección del RET así como las llamadas a las funciones en una shellcode, varían según se ejecute en un Sistema Operativo (SO) o en otro (es decir que varía si se ejecuta en un sistema Windows, GNU/Linux, UNIX, Solaris,
BSD, etc. Esto pasa sobre todo con el software de Micro$oft, por eso los exploits para productos de esta empresa traen un mini menú para elegir el SO (win NT, win 2k, win XP, wink3...) así como los SPs (Service Packs) instalados.

Por tanto, es posible que los testeos que hagas en tu servidor no funcionen en otros que tengan un sistema operativo diferente (o incluso iguales).

Algunas aclaraciones:

* ASM: Assambler Programming Languaje, es decir Lenguaje de Programación Ensamblador. Es el lenguaje de nivel más bajo y por consiguiente el que interactúa de forma más directa con el hardware del ordenador.

* RET: Return Address, es decir Dirección de Retorno. Ésta contiene la dirección de memoria que ejecutará cuando termine la función, o hacia dónde tiene que regresar y ejecutar. Cabe decir que el RET se almacena en la Pila.

* String: Es una cadena de Texto. Ejemplos:
_ "Hola"
_ "\xcd\x80"
_ {'h','o','l','a','\0'}
Son todos Strings.


Más información:

www.shellcode.com.ar
www.google.com