Nico Karman el creador de inexinferis.com y el soft iApp, plataforma de cheats para Counter-Strike 1.5 y 1.6, se retira y publica el código fuente de su proyecto.
Recordemos que Nico se inició en este mismo foro (Karman) , aún se pueden encontrar sus posts si se busca. bueno, la publicación incluye varios códigos fuente en c/c++ y entre ellos está iApp o Inexinferis Application, con la librería para tunear aplicaciones gráficas de Windows (winapi gui apps). Con esta librería se tuneó la iApp
Cómo coAdmin del sitio y único colaborador tengo el permiso de Nico Karman de publicar esto en este sitio y en otros, para desmistificar cómo se hizo el iApp y el Inexinferis Revolution tan conocido en la comunidad del cheat de Counter-Strike
Primero que nada quiero decir que voy a postear el código fuente público de un hack de karman, llamado Inexinferis FX de finales del 2010. Es un código ya publicado sólo que no se observa demasiado por internet XD
Lo posteo porque es parte de los métodos que se estaban comentando en el foro últimamente, y se trata de utilizar 'detours' pero a un nivel más profundo que el que ofrece Openg32.dll, siendo Opengl32.dll el nivel más alto y el driver de la tarjeta gráfica lo más bajo. Intermediamente se tiene otra DLL de relacionada con Opengl32 pero perteneciente a la firma de la tarjeta gráfica, pero el tema es que hay muchas marcas de tarjetas gráficas y por lo tanto muchos drivers. Por lo que cada uno sabe lo que tiene XD
En Opengl32.DLL básicamente se encuentran funciones que sólo hacen saltos hacia el nivel más bajo de Opengl, y para obtener las direcciones correctas del driver, se hace con este método del TEB.
Este es el ejemplo de glBegin
Citar
Pos: FS:[0x18] Len: 4 Ver: Win9x y NT -> Dirección lineal del TIB
con esos parámetros se consigue hacer un salto hacia el nivel bajo del que hablábamos (nvoglnt.dll en mi caso que tengo una tarjeta NVIDIA)
Luego hace otro salto hacia la función en sí. Con OllyDBG se puede observar el estado de los registros para tener una mejor idea de como se obtienen las direcciones. Mejor aún, para aquellos que prefieren leer una buena explicación les dejo este manual al respecto: http://www.mediafire.com/?kmru385gmmcik46
//MessageBox(hdHalfLife,"Couldn't Get TEB From Opengl32.dll\n\nMake Sure that you are Running the Game in OpenGl Mode...","Inexinferis FX Series - Karman",0);
//MessageBox(hdHalfLife,"Couldn't Read From Opengl32.dll Address\n\nMaybe your OpenGL driver is not compatible...","Inexinferis FX Series - Karman",0);
Para terminar de redondear el tema de interceptar Opengl32 usando detours, muestro una pequeña base para crear un WH, utiliza una función personalizada para instalar un hook del tipo DETOUR. Habíamos visto en otros tutoriales como se hace, y que se trata de una técnica intrusiva porque requiere parchear la memoria (código) del proceso víctima. http://foro.elhacker.net/programacion_cc/detours-t168884.0.html No tiene nada que ver con otros tutoriales que muestran como se modifican los valores de algunos punteros que corresponden a datos en el proceso. Ej: http://foro.elhacker.net/programacion_cc/codigo_fuente_cheat_cs_16-t387341.0.html
Dejo el código funcional y el proyecto para descargar como siempre, dejo unas imágenes..
En este caso para diferenciarnos de otros tutoriales, explico la forma en que se puede cargar esta DLL en el proceso "hl.exe" que corresponde al juego Counter-Strike.
Se trata de ir a la carpeta del juego, y buscar una DLL de las que sabemos que no son necesarias en el juego pero de todas formas son cargadas al proceso. Hay otras DLLs que son cargadas y algunas de sus funciones o todas, son utilizadas en el proceso, por lo que no se puede quitarlas, sino más bien hacer un 'wrapper' de ellas. Pero no quitarlas.
Vamos a ver una DLL que si la podemos quitar que se llama "DemoPlayer.dll". Vamos a quitarla y poner nuestra DLL con el WH en su lugar. Obviamente la tenemos que renombrar a "demoplayer.DLL" si es que no tiene ese nombre toda via.
Al final quiero decir que los sistemas de seguridad suelen escanear en la memoria, por ejemplo los primeros 5 bytes de algunas funciones para determinar si tienen 'detours'. Pero a veces hacen otras comprobaciones como CRC32 de toda una función, o quien sabe que otras comprobaciones.. el tema es que este es un método intrusivo.
Código
//
// Modifications: By 85
// Credits: gamedeception (detour function), SharkBoy999 base
otra cosa que quiero agregar, es que el 'hook' a GetProcAddress no es necesario, pero está hecho y sirve para demostrar algo importante.
cuando salimos del juego, osea del proceso, antes se descargan las DLLs entre otras cosas, pero cuando se descarga nuestra DLL la memoria del proceso continua parcheada (los hooks que instalamos), y las referencias a los hooks son inválidas ya que la DLL se ha descargado.
Esto no importa para Opengl32 porque nadie va a utilizar Opengl32 al salir, pero con GetProcAddress si pasa esto. Por eso se debería considerar restaurar los bytes parcheados en GetProcAddress, o más fácil es hacer que la DLL se descargue cuando ya no sea necesaria (cuando no se haga más referencia a los hooks). Con un ExitProcess(100) queda resuelto, en realidad no investigué acerca de este tema, sólo traté de arreglarlo de alguna forma. Pero es un detalle a considerar.
Captcha, reCaptcha as well as Question and Answer does not stop vBulletin Spam registrations and so I have come up with yet another solution to stop vBulletin Spam for Registration. This works with any kind of site and is based on Cookies for Comments Wordpress Plugin.
The idea and implementation is completely based on the plugin and so the credit completely goes to the Authors of the above plugin. I have just used it for vBulletin and shared it here so you can apply the same for your forums. It is very simple and yet so effective that it can be applied to almost any website.
Step 1 Download the above plugin and extract into a folder. Upload css.php file to your forum root directory. Browse to the css.php file in your browser and copy the link to the css.php file.
Step 2 Now add the following lines to your headinclude template in each of your vBulletin style.
Replace the SOME_RANDOM_STRING_OF_YOUR_CHOICE with anything of your choice.
If you don't want to add stylesheet declaration in your template, you can also opt for blank image. For this you have to upload the blank.gif image from the above plugin to your site and then add the following blank image code in header or footer template of each of your vBulletin style.
Remember the above rules goes right at the top. Even above the vBSEO Rules if any.
Now any user visiting your register.php file without visiting any of your pages on your forum will get a 403 forbidden error message.
There can be issues if you have multiple CMSes like may be Wordpress and vBulletin or any other static pages and genuine users can click on registration link from those pages. The solution is to make the call to the above CSS/image file from every page of your site.
I hope it helps reduce the spam registration considerably.
The above solution can even be applied to any other custom CMS of your choice as well. You have to just block your registration pages with the needed cookie and set the cookies in header or footer of your site for genuine users who visit your site.
Further Spam Prevention Options for vBulletin You can also opt for some more spam prevention options that I have mentioned on my blog here as well as opt for a Block vBulletin Spam Posts Plugin to stop spam posts in forums.
Pero si esto funciona como dice, es super importante para los que tienen vBulletin por el gran problema de los bots :/ Supuestamente sirve para cualquier sitio.
Overview Innovative systems research hinges on the ability to easily instrument and extend existing operating system and application functionality. With access to appropriate source code, it is often trivial to insert new instrumentation or extensions by rebuilding the OS or application. However, in today's world systems researchers seldom have access to all relevant source code.
Detours is a library for instrumenting arbitrary Win32 functions Windows-compatible processors. Detours intercepts Win32 functions by re-writing the in-memory code for target functions. The Detours package also contains utilities to attach arbitrary DLLs and data segments (called payloads) to any Win32 binary.
Detours preserves the un-instrumented target function (callable through a trampoline) as a subroutine for use by the instrumentation. Our trampoline design enables a large class of innovative extensions to existing binary software.
We have used Detours to create an automatic distributed partitioning system, to instrument and analyze the DCOM protocol stack, and to create a thunking layer for a COM-based OS API. Detours is used widely within Microsoft and within the industry.
Bueno, la intención no es contar toda la historia sino publicar un código fuente XD.
En síntesis, con esta librería se pueden interceptar funciones. Es una librería de MS que no es pública en su versión completa, pero si tiene una versión de prueba para el público. Se usaba desde hace años para construir los hacks de distintos juegos, por ejemplo para el Counter-Strike. En este enlace se puede encontrar una base para un hook de Opengl32 que fue muy conocida cuando salió. http://board.cheat-project.com/showthread.php?t=9232
Algunas de estas bases se hicieron primero con Detours 1.5 y después se actualizaron a Detours 2.1. Ahora está disponible la versión pública de Detours 3.0.
Lo que hice yo, fue organizar la base publicada en ese enlace que he mostrado. originalmente no compilaba, tenía errores, faltaban archivos, y tenía mucho código que no era necesario para una simple demostración. Por eso el código fue organizado y arreglado para que funcione, el proyecto es de una librería de vínculos dinámicos (DLL), que debe ser cargada en el juego Counter-Strike (En modo Opengl32). Al cargarse la DLL se instalan los hooks ('detours'), y se obtiene un "Wallhack" funcionando.
El creador de esta base es un tal Xantrax, el link ya lo he mostrado. Esto se trata de ver como se implementa esta librería. Dejo el código completo y al final un enlace de descarga. La descarga fue preparada especialmente, porque incluye los archivos de instalación de Detours 2.1, el .h y la librería estática .lib. Y se incluye también el .h y la librería estática .lib correspondiente a Detours 1.5. El tema es que estos archivos no se consiguen fácilmente porque son versiones anteriores de 'Detours'. Otra cosa es que para obtener la librería estática .lib se tiene que compilar 'Detours' para que la produzca.
justo me había acordado de una 'wrapper' muy famosa en el ambiente del hacking de juegos. Es del 2002 de un programador llamado Crusader, y durante un tiempo esto había servido para utilizar wallhacks en el Counter-Strike, aunque se debería poder usarse en otros juegos basados en Opengl32.
Lo que hice fue agregar algunas líneas para remover el cielo y para un wallhack. La DLL de reemplazo (wrapper) se debe poner en la carpeta del juego (ver imagen 1).
Esto es detectado por los sistemas antitrampas, validan los archivos y las rutas. Pero puede servir a alguien para practicar con Opengl32. Con los hacks se aprende XD
Algo que se denominaba ‘wrapper’, en este caso vamos a hacer lo mismo pero sin la necesidad de usar un archivo .DEF para los símbolos exportados. El tema es que para hacer la exportación de símbolos en este caso sin usar .DEF tenemos que utilizar en nuestras funciones de reemplazo, el nombre completo y correcto de las funciones originales.
Primero vayamos a las opciones del proyecto, y veamos que la opción de la convención de llamada esté en __cdecl, porque si bien sabíamos que PSAPI usaba __stdcall, pero lo que vamos a hacer en esta ocasión es especificarlo explícitamente en el código, para cada función. Por defecto siempre esta opción se encuentra en __cdecl, en otras palabras lo que quiero decir es que lo dejen así..
Empecemos diciendo en lo que es similar al anterior método, por ejemplo los prototipos de las funciones. Veamos una definición de tipo para la función EnumProcesses en main.cpp
Veamos como se expecifica explícitamente la convención de llamada __stdcall (WINAPI). La definición de nuestra función de reemplazo, que como habíamos visto antes, retorna el puntero a función original. En este caso a la EnumProcesses original en la DLL original que renombramos PSAPI2.DLL
El tema es que como no estamos usando un .DEF tenemos que especificar en el código, qué funciones son las que van a ser exportadas. Esto se hace con __declspec (dllexport)
Veamos una macro que al mismo tiempo también especifica que se trata de un estilo de función de C con lo cual evitamos el planchado de nombres en los símbolos exportados.
En el compilador vamos a dejar que la convención de llamada por defecto sea __cdecl, y vamos a valernos de especificar __stdcall en los prototipos o definiciones de tipos y en los punteros a función, como ya vimos. En el anterior tutorial, teníamos 2 instancias de funciones de reemplazo para cada función que íbamos a exportar. Y vimos que la segunda instancia no era necesaria antes, pero ahora si lo va a ser.
Veamos exports.cpp Esta es la segunda instancia, debe ser del tipo __cdecl para ser compatible con la directiva extern “C”, y al mismo tiempo debe ser el símbolo marcado para ser exportado, eso se hace con __declspec (dllexport) como dijimos antes. Y por último, el nombre de esta función debe ser exactamente igual al de la original.
Por eso si la convención de llamada por defecto es __cdecl entonces esta función tendría esa convención. Por eso dije antes que la dejen como estaba a la opción esa. De otra forma debería especificar __cdecl explícitamente en la definición de la función.
En teoría debería deberíamos usar el puntero a la función original a modo de una llamada a función por puntero (ya sea como return+puntero o sólo el puntero si se trata de una función de tipo void).
Esta situación no es diferente a la del enlace anterior, por lo que la solución es la misma; nuestra función de reemplazo de tipo __cdecl va a tener que restaurar el registro EBP antes de saltar a la función original. Vamos a utilizar la instrucción JMP para ir a la original y no la instrucción CALL (aunque vimos que se puede).
El fix con ensamblador en línea (inline ASM), guarda el registro EBP y lo restaura antes de saltar a la función original, también se deja la pila equilibrada con ADD ESP, X Tanto la ubicación del EBP original en la pila como la cantidad de espacios que se deben reducir para equilibrar la misma, se deben obtener de un desensamblador por ejemplo. Sino, pueden utilizar un depurador como el OllyDBG.
Veamos igualmente una imagen de como resulta el código de ensamblador:
Citar
10001000 > 55 PUSH EBP 10001001 8BEC MOV EBP,ESP 10001003 51 PUSH ECX 10001004 53 PUSH EBX 10001005 56 PUSH ESI 10001006 57 PUSH EDI 10001007 C745 FC 5500000> MOV DWORD PTR SS:[EBP-4],55 1000100E C745 FC 5500000> MOV DWORD PTR SS:[EBP-4],55 10001015 8B4424 10 MOV EAX,DWORD PTR SS:[ESP+10] 10001019 A3 D0320010 MOV DWORD PTR DS:[100032D0],EAX 1000101E 8B2D D0320010 MOV EBP,DWORD PTR DS:[100032D0] 10001024 83C4 14 ADD ESP,14 10001027 E9 64040000 JMP psapi.10001490 1000102C 5F POP EDI 1000102D 5E POP ESI 1000102E 5B POP EBX 1000102F 8BE5 MOV ESP,EBP 10001031 5D POP EBP 10001032 C3 RETN
Como ustedes pueden ver se genera al final este código:
Citar
1000102C 5F POP EDI 1000102D 5E POP ESI 1000102E 5B POP EBX 1000102F 8BE5 MOV ESP,EBP 10001031 5D POP EBP
Lo cual es una correcta liberación de pila, pero el problema es que este código no se genera sino usamos el fix.
Como ya dije, es la misma situación que la del tutorial de convención de llamada para un caso con Opengl32.
El resultado es una DLL wrapper de PSAPI.DLL que no requiere .DEF para realizar las exportaciones. Psapi.lib tampoco es requerida, recordemos que hacemos un enlazamiento dinámico con la DLL PSAPI.DLL original (que renombramos a PSAPI2.DLL).
Y los nombres de los EXPORTS no resultan cambiados.
Este tutorial te va a enseñar como crear algo conocido como ‘Wrapper’ de una DLL, cuya traducción es ‘envoltura’ pero se conoce con el término del inglés directamente. Las wrappers son versiones propias de DLL’s conocidas. En este caso vamos a hacer un wrapper de una DLL muy conocida llamada PSAPI.DLL. Si no la conocen investíguenla XD, pero se trata de una DLL bastante común encontrarla cargada en muchos procesos. La técnica de construir wrappers tiene al menos 2 objetivos: 1: Hooking. ya que nuestra propia versión de la DLL va a contener nuestras propias versiones de las funciones originales, y al mismo Tiempo necesitamos llamar a las originales dentro de las nuestras. El tema es que podemos ejecutar nuestro código antes de que se ejecute el código original. 2: Cargar una DLL. Lo que estamos haciendo al crear nuestra propia versión de una DLL conocida es hacer que al programa víctima se le cargue nuestra DLL en lugar de la original. Esta carga no la hace el programa víctima sino el sistema operativo. El SO detecta nuestra DLL en la misma ubicación que el archivo ejecutable del programa y la carga automáticamente, ya que existe una dependencia real con la DLL.
En cuanto a seguridad, es una técnica no efectiva para crear un hack para un programa que tenga seguridad. Sería muy fácil validar los archivos en disco que se cargan al proceso (con MD5 por ejemplo), o validar las rutas, etc etc Mientras no sea para nada de hacking, tiene cierto atractivo esta idea XD.
Acerca de como se crea algo así.. Bueno lo primero es conocer la DLL original que queremos reemplazar, es decir todas sus funciones o al menos las que el proceso víctima utilice (dependencias).
Esto significa que debemos conocer los prototipos de estas funciones, incluyendo su convención de llamada y demás. Teniendo eso en primer lugar, vamos a considerar que también necesitamos usar la DLL original porque dependemos de las funciones originales. Esto se resuelve cambiándole el nombre a la DLL original. En el caso de PSAPI.DLL lo podemos cambiar a PSAPI2.DLL. Luego vamos a necesitar cargar la DLL original renombrada y hacer un enlazamiento dinámico con ella, y conseguir las direcciones originales de las funciones que necesitamos. Obviamente esto lo hacemos con LoadLibrary + GetProcAddress. Luego en nuestra propia DLL ponemos las funciones de reemplazo respetando los prototipos y le ponemos las direcciones de retorno a las originales que importamos dinámicamente con GetProcAddress. Utilizamos obviamente punteros a función para los retornos en las funciones de reemplazo (hooks).
La convención de llamada usada en PSAPI.DLL para las funciones es __stdcall, por eso podemos hacer que todas las funciones en nuestro proyecto sean por defecto __stdcall para no tener que especificarlo explícitamente en cada una.
Veamos a PSAPI.DLL
Veamos sus exportaciones.
Vamos a concentrarnos en una de sus funciones sólamente, por ejemplo EnumProcesses
Necesitamos un prototipo de función, definamos un tipo de dato correspondiente a esta función.
Ahora creamos otra instancia más (no realmente necesaria en este caso), esta función va a ser la que se exporte para que pueda ser usada por el programa víctima.
Y básicamente hacer lo mismo con las demás funciones XD. Para compilar este proyecto se requiere del archivo psapi.h que contiene los tipos de datos usados en las funciones de reemplazo. No se requiere psapi.lib que es una librería de enlazamiento estático.
Vamos a necesitar un archivo .DEF que debe ser incluído en el proyecto. Hay unas reglas para usar el .DEF y estas son: 1: se debe empezar poniendo LIBRARY y seguido el nombre de la DLL. 2: se debe poner EXPORTS 3: se deben poner uno por uno, los nombres que deseamos para cada símbolo, seguido de cada Nombre debe ir el signo ‘=’ y el nombre real del símbolo, el cual obtenemos del desensamblado. 4: seguido a lo anterior se deja un espacio y se coloca un ‘arroba' y el número de índice de exportación.
Pero veamos una imagen para entender como se hace:
Veamos el código de la DLL:
En main.cpp se encuentran los prototipos de las funciones y los punteros a funciones. Para no poner todo veamos sólo el caso de EnumProcesses
Luego se muestra un código que se trata de una clase y la creación de un objeto de tipo de la clase, esto busca que se inicializen los punteros a función cuando el programa es ejecutado, ya que cuando se crea el objeto se ejecuta la rutina que inicializa los punteros a función.
En exports.cpp sólamente tenemos las funciones de exportación, son las cuales son referenciadas en el archivo .DEF. Estas funciones retornan las funciones de reemplazo. Esto de tener 2 instancias no es necesario como ya se dijo, pero si lo es si se desea utilizar otro método que después voy a exponer.
Hola, estaba probando un código para mensaje scroll, me pareció buena la idea de postearlo. Ya lo había usado mucho antes pero no para un programa de consola.
El programa va a mostrar todas las cadenas que hay en un array de cadenas o matríz de caracteres, son 13 cadenas en total, pero originalmente lo usaba con 4. La modificación que le hice fue la necesidad de crear un hilo aparte para mostrar las cadenas en scroll, y suspender el hilo principal.
El hilo principal nunca se resume y para salir del programa se sale con ExitProcess desde el hilo secundario.
El intervalo de tiempo entre las cadenas se hace con 'Sleep'.
Como ustedes ya saben, cuando se crea un hilo con CreateThread se le debe pasar un argumento que es la rutina con la cual empieza a ejecutarse el hilo. Esta rutina lleva un parámetro, que lo recibe al crearse el hilo porque dicho parámetro se pasa a CreateThread como argumento. http://msdn.microsoft.com/en-us/library/windows/desktop/ms682453(v=vs.85).aspx
El tamaño del vector de cadenas se puede sacar con sizeof, pero en este caso se hace restando las direcciones de memoria del último elemento menos el primero.
Para iniciar el 'scrolling' se presiona 1, y para salir del programa se presiona 2.