[[marceloalegre]]

Ya entiendo por que DarkByte lo decia...

Aca paso una pequeña explicación del tema que saque de una pagina (esta como para tontos):

La inyección de código (o de dll) consiste, básicamente, en pedir parte del espacio de memoria y ejecución de otro proceso para ejecutar código propio. Para haceros una idea... Veamos un ejemplo.
Supongamos una reunión de cocineros, cada uno con su fogón, sus ollas y sus ingredientes. Estamos todos en un concurso y los jueces andan paseando para observar que no se hagan trampas. En un momento dado aprovechas
para, usando una olla de otro cocinero y uno de sus fogones (un fogón excelente que le ha tocado a él, en suerte, y tú no tienes), introducir los ingredientes de tu salsa. De esta forma parecerá que la salsa la está
haciendo él, ¿no? Si pasa el juez, te verá a lo tuyo y creerá que dicha salsa pertenece a tu compañero. Desde luego, si revisa lo singredientes declarados de cada uno y el objetivo del plato podría darse cuenta de que esa salsa no se corresponde con lo que se supone que ese cocinero debe estar haciendo, pero... Los jueces no "suelen" fijarse tanto. Así que te has aprovechado de otro para ocultar que estás haciendo una salsa, ganas tiempo y ahorras olla y fogón. Encima, aprovechamos un fogón de calidad "especial" que nosotros no tenemos y que dará a nuestra salsa el punto de cocción perfecto.

Ahora extrapolemos a lo que nos ocupa. Se trata de aprovecharnos de "ciertas ventajas" de que disfrutan algunos programas en el S.O. para hacer algo sin que se sepa que somos nosotros y sin las restricciones que
nosotros podamos tener.

1.- ¿Que ventajas prácticas tiene la inyección de código?
Visto lo visto ya podeis imaginar algunas. Al margen de las más legítimas, y en lo que respecta al tema de la seguridad, las consecuencias inmediatas de la inyección de código son:

a) la posibilidad de ejecutar código "de forma invisible" en el S.O. Una vez inyectado el código en el proceso "anfitrión" podemos cerrar la ejecución de nuestro programa principal (inyector) y dejar que se siga ejecutando el código inyectado en el espacio de programa del proceso "anfitrión". Un listado de las tareas en ejecución NO revelará nuestro código.

b) La posibilidad de engañar a algunos cortafuegos que trabajan a nivel de permisos a ejecutables concretos.

Si un cortafuegos permite, por ejemplo, que el iexplore o el emule salgan a Internet, podríamos inyectar un reverse shell en uno de estos dos programas y el cortafuegos, en principio, lo dejaría pasar sin "cantar".
OJO. Algunos cortafuegos, sobre todo en su versión comercial, ya detectan este tipo de prácticas.

c) Otra posibilidad es la del ejemplo que voy a poner (por ser sencillo y fácil de asimilar por todos). Dado que estamos ejecutando código en otro proceso, podemos borrar nuestro ejecutable actual. Útil, por ejemplo, para borrar rastros. Bastará con que inyecte el código necesario en el proceso que me de la gana y finalice la ejecución de mi programa... El código inyectado se ocupará de borrar el ejecutable que he usado para inyectarlo.


2.- ¿Es tan sencillo "colarse" en otro programa?
Umm... Si y no. Usando las funciones del API, y contando con que nuestro programa lo ejecute un usuario con suficientes privilegios, inyectar código es relativamente sencillo. Sin embargo, debemos tener en cuenta que, una vez estamos en ese otro programa, todas las referencias (punteros) a funciones y datos válidas en nuestro programa dejarán de serlo en el programa anfitrión.

Eso podría complicarnos algo las cosas... De hecho mucho. Si no fuese por la tendencia conservadora de Windows de cargar en la misma dirección de memoria en todos los procesos varias de las dll básicas del API. Eso nos
permitirá saber que, al menos ciertas funciones, se encontrarán casi con toda seguridad en una posición concreta del espacio de memoria de dicho programa que, además, coincidirá con la posición que ocupa esa misma función en NUESTRO propio espacio de memoria.

Por ejemplo, librerías como kernel32 o user32 se cargan en prácticamente todos los procesos que ejecuta windows. Ntdll es otro ejemplo (aunque muchas de sus funciones están mapeadas desde kernel32). Podemos pues,
por lo tanto, usar todas las funciones de esas dll sabiendo que posición ocupan en nuestro proceso y confiando en que usarán esa misma referencia en el espacio de ejecución del programa objetivo o anfitrión.

De la misma forma, tambien debemos contar con que los datos (variables, estructuras, etc) válidos en nuestro programa no lo serán en el programa objetivo. Si definimos, por ejemplo, una variable "x" en nuestro programa,
cada vez que usemos el nombre de dicha variable para realizar una operación (x = x + 2, por ejemplo) estaremos referenciando con el nombre "X" a una posición CONCRETA de memoria dentro del espacio reservado por nuestro
programa. Sin embargo, esa posición concreta, dentro del programa objetivo, puede estar ocupada por CUALQUIER otra cosa que dicho programa necesite (otras variables, una función o parte de código, etc). Incluso es posible que ni siquiera exista esa posición concreta.

Por lo tanto deberemos buscar la forma de reservar memoria en dicho programa para alojar nuestra variable "X" y conocer la posición de memoria que referenciará dentro de ese programa, con el fin de poder usarla en el
código que inyectaremos.

Por último, en caso de ser necesario usar funciones de dlls del API que NO pertenezcan a las dll básicas, no podremos asumir que el programa anfitrión cuenta con ellas, ni que están en las mismas posiciones de memoria que en el nuestro. Así que deberemos cargarlas dentro del código que inyectaremos (afortunadamente esto es posible dado que el API cuanta con la función LoadLibraryA dentro de kernel32.dll)...
----------------------

Honestamente no tenia, ni tengo interes de hacer daño, ya tengo el codigo fuente en delphi y esto es correcto, funciona perfectamente, realmente no se que filosofia tiene el foro ante estos aspectos. Como dice roman el que quiere hacer daño puede hacerlo tranquilamente hay mil lugares por donde buscar....
Asi que si quieren los moderadores y deciden que es correcto yo lo posteo en el foro...
DarkByte no lo tomes a mal!! te respeto muchisimo, aportas muchas cosas buenas al foro!, pero en el tema de liberar info de este tipo, seguramente tenemos formas distintas de pensar!!

Saludos a todos!