Introduction

Finding virtual offsets provides us a way to access functions in the games that we otherwise would not be able access. Using either SDKCalls, Extensions, or MM:S Plugins, we can make use of these virtual offsets to give us a massive amount of functionality that is not included with Sourcemod out of the box.
For this example, you will need a copy of IDA Disassembler. We will be using IDA Pro 5.2 but any of the more recent versions should work fine (will not work with the free version). You will also need to grab this linux_vtable_dump.idc file and install it into your IDA/idc/ directory. Lastly, you will need to get a copy of the Linux server file for the game you want to find the offsets for. This will generally be in the 'bin' directory of your game folder and the file will be named server.so (use server_i486.so for older games that do not have server.so) along with some other similar files.

Finding Offsets

Disassemble the Linux Server:
Now that your files are setup appropriately, you can start the IDA Disassembler. On the Welcome to IDA box that opens initially, you will want to click the "New" button. This will allow us to add a new file for it to disassemble. After you initially disassemble the file, you will be able to reload it without any hassle by using the 'Previous' button and selecting the file on this screen.



After you click the New Button, the application will open. It will prompt you to choose a specific type of file from a box, however you can just close this as we do not need it. The screen should now say "Drag a File Here to disassemble". Open your folder containing the server_i486.so and drag drop this file in now. This will start the disassembling process, and depending on hardware, can take anywhere from 15-30 minutes to completely finish.

Find the Virtual Table::
You will want to be in IDA View-A and make sure you can see both the IDA View-A window as well as the Names window to make this easier on yourself. For this example, we will be finding the Virtual Offset for the function CBasePlayer::ChangeTeam. Our first step is to locate this function in the Names window. (The search hotkey combination is Alt+T) Now once you find this function, in the Names window, double click it, and it should select a line in the IDA View-A window that looks something similar to this.



From here we are going to want to go to the Jump Menu up top, and select Jump to Cross Reference. (The hotkey is CTRL+X) This will find the reference files for this paticular function. You will want to make sure that you find the line with `vtable at the start of it, as this will be the Virtual Table file that contains the offsets for us.



Save the Virtual Table file::
Now double click the line that says `vtable for'CBasePlayer and you will be brought back to the IDA View-A window. This time your cursor will be on the line with the VTable information. You have now successfully located the file you need, and you are ready to get the offsets. Making sure that your cursor is still somewhere in that line, go to...
File -> IDC File
and browse to the linux_vtable_dump.idc file that we placed in the IDA directory earlier. Load this file and click OK, and it will now ask you to enter a number for VTable's entries to ingore indexing. Setting this to 0 will output a file listing the exact Linux offsets, setting this to 1 will output a file which estimates the windows offsets (general rule is windows offset = linux offset - 1 but this isn't always the case). It will run your IDC script file, and give you another dialog box. This time it wants you to choose the location for the dump file. Browse to your desktop, and enter anything for the File Name box, and click Save. You now have a text file on your desktop will all of the CBaseEntity offsets inside of it that you can use.

Conclusion

That is all there is to it. Keep in mind that even though this is the Linux server file, the offsets listed in the dump file are for windows. You will just need to add +1 to these offsets to obtain the Linux offset. Make sure that you are using the Linux server file when you disassemble as well, because the Windows server does not have symbols or readable names, and you will not be able to find the offsets with it (unless you have the .pdb files for it, which only the Developers of the Game / Mod should have).

Windows Info

[07:38pm]  dvander word it in such a way that I can copy/paste it into the wiki
[07:38pm]  lol, i dunno if i can do that in IRC.  basically, there are two tricks
[07:39pm]  the first is if you know assembly really well
[07:39pm]  you can look at the SDK for a function that calls something you are interested in
[07:39pm]  find a string in that function, or a string in a function in its cross-reference graph
[07:40pm]  for the former case, find the same string in the windows binary and use the xref graph to find the right function
[07:40pm]  for the latter case, say a function with a string in it calls the function that has what you want
[07:40pm]  you find the first function, then read through it until you get to what you want
[07:41pm]  once you have the actual function you're looking for
[07:41pm]  you use the xref graph to find its reference in the data section
[07:41pm]  it will be in a large table - the virtual table
[07:41pm]  and you can compute its offset from the base of that table
[07:42pm]  the other trick is a bit easier, sometimes
[07:42pm]  you compile the SDK on windows
[07:42pm]  turn on the MSVC feature that dumps assembly
[07:42pm]  and poke around, using educated guessing

C++: Insertar un ejecutable dentro de otro… y luego ejecutarlo

Vamos a explicar cómo tomar un ejecutable (o cualquier otro fichero binario), insertarlo dentro de un ejecutable y posteriormente cómo recuperar ese ejecutable embebido, soltarlo a disco y ejecutarlo. El escenario típico es borrar el propio ejecutable que actúa como hospedante, pero seguro que a las mentes calenturientas de mis lectores se les ocurren más aplicaciones.
El problema no existía en Windows 95 y siguientes: un programa podía borrar su propio ejecutable y terminar sin ningún problema (o casi). Pero en los núcleos NT hacer eso es harina de otro costal. Teóricamente se puede hacer mientras que el ejecutable a borrar no abra ningún handle… pero evidentemente cualquier ejecutable suele abrir no uno, sino infinidad de ellos.
La solución consiste entonces en disponer de dos ejecutables en disco. El primero hará su tarea y llamará al segundo antes de terminar, que tras unos instantes procederá a borrar el primero, quedando éste último en disco. Pero entonces tenemos que distribuir dos ficheros y colocarlos en el mismo sitio, por lo que la mejor solución es que el primero contenga al segundo en sus entrañas y lo use a voluntad. Incidentalmente el segundo podría decir a Windows que lo borre en el siguiente reinicio, pero no vamos a entrar en detalles sobre esto.
Primer paso: Insertar el ejecutable
Suponiendo que tengamos ya construido nuestro ejecutable (que vamos a llamar “borra.exe”), insertar un recurso del tipo RCDATA en un fichero ejecutable es una tarea trivial. Basta con abrir el fichero de recursos del ejecutable (el .rc) como texto e insertar la línea:

ELEXE RCDATA "..\\final\\Win32\\Release\\borra.exe"

Recompilamos y ya tenemos el ejecutable como recurso binario embebido en nuestro propio ejecutable. Evidentemente no estamos limitados a ningún tipo de archivo en concreto. Podríamos hacerlo incluso con recursos normales (mapas de bits, iconos, cadenas, etc.). La única diferencia es la forma de recuperar un recurso binario de uno almacenado como estándar.
Segundo paso: Sacar el ejecutable y ponerlo en disco
Cuando queramos volcar nuestro ejecutable a disco, debemos ejecutar algo parecido a lo siguiente:

HRSRC res=FindResource(NULL,_T("ELEXE"),RT_RCDATA);
if(res==NULL)
     return GetLastError();

int size=SizeofResource(NULL,res);
HGLOBAL hRes=LoadResource(NULL,res);
unsigned char *pRes=(unsigned char *)LockResource(hRes);

HANDLE hFile=CreateFile(szT2Path,GENERIC_WRITE,0,NULL,CREATE_ALWAYS,0,NULL);
if(hFile==INVALID_HANDLE_VALUE)
     return GetLastError();

WriteFile(hFile,pRes,size,&bytesWritten,NULL);
CloseHandle(hFile);

ShellExecute(HWND_DESKTOP,NULL,szT2Path,NULL,NULL,SW_SHOWNORMAL);

El primer paso consiste en llamar a FindResource con el nombre y el tipo de recurso. Si nuestro fichero hubiera estado almacenado en otro lugar que no fuera nuestro propio ejecutable, el primer parámetro a pasar es la instancia del fichero externo.
Tras tener un handle válido, tenemos que mirar el tamaño que ocupa el recurso almacenado, lo que hacemos con SizeofResource.
Ahora viene cargar el recurso en memoria y obtener un handle de memoria (LoadResource). Pero todavía no podemos acceder a los bytes de nuestro fichero, debemos bloquear el acceso a los mismos mediante LockResource, lo que nos devolverá un área de memoria accesible.
Aquí el autor lo ha asignado a un buffer de caracteres sin signo, pero realmente cualquier tipo de dato es perfectamente válido, aunque tenemos que tener en cuenta de no guardar ningún byte de más en el fichero final. Haciéndolo con un buffer de caracteres nos aseguramos de guardar el tamaño correcto.
Ya solo nos queda guardar el buffer a disco y hacer la llamada para ejecutar el fichero extraído.
Quizás nos preguntemos por qué no hemos liberado la memoria apuntada por pRes: está expresamente descrito en la documentación de la MSDN: no debemos hacerlo nosotros, ya lo hará el sistema cuando corresponda.
Consideraciones finales
Evidentemente una solución más sencilla sería marcar el propio ejecutable para ser borrado en el siguiente reinicio en lugar de hacer toda esta parafernalia, pero a veces puede no interesarnos que dicho fichero esté en disco hasta ese momento.
De todos modos aplicaciones para esto las hay a montones. Soltar un ejecutable que haga algo, termine y luego sea borrado por el programa principal, forzar un reinicio del programa principal, distribuir un solo exe que luego suelte todos los ficheros que necesite…

Origen: http://geeks.ms/blogs/rfog/archive/2008/09/11/c-insertar-un-ejecutable-dentro-de-otro-y-luego-ejecutarlo.aspx

What does a hero truly need?

Find out when the world's best players compete in the first ever Dota2 professional tournament August 17th - 21st at Gamescom in Cologne, Germany. Watch live streaming games and replays at Dota2.com.

Visit Steam to download the 1080p HD version of the trailer.

Las diferentes versiones de TDSS

El programa malicioso que Kaspersky Anti-Virus detecta como TDSS pertenece al grupo de los más complejos de hoy en día. TDSS usa diferentes trucos para evitar ser detectado por los métodos de firma, heurístico y proactivo; aplica métodos de cifrado durante la transmisión de datos entre el bot y el centro de administración y posee un potente componente rootkit que le permite camuflar la presencia de cualquier tipo de programas maliciosos en el sistema.
El nombre con que su autor bautizó el programa es TDL. Desde el momento de la aparición del programa malicioso en 2008, los creadores de virus lo han venido perfeccionando constantemente. En 2010 la última versión era TDL-3, cuya descripción detallada dimos en el artículo publicado en agosto de 2010.
Los autores de TDSS no pusieron el programa en venta sino hasta finales de 2010. En diciembre, al analizar uno de los especímenes, descubrimos algo extraño: el disco cifrado de TDL-3 contenía ciertos módulos de otro programa malicioso llamado SHIZ.
Entonces apareció en Internet el programa de afiliados que se dedicaba a suplantar los resultados de los sistemas de búsqueda y que pertenecía a los creadores de SHIZ, pero cuya estructura se basaba en TDL-3.
Los cambios introducidos en la configuración de TDL-3 y la aparición de un nuevo sistema de afiliados confirman que los códigos fuente de TDL-3 se vendieron a los delincuentes que antes se dedicaban al desarrollo del programa malicioso SHIZ.
Pero ¿por qué los autores de TDL decidieron vender los códigos fuente de la tercera versión? Es que para ese entonces ya había aparecido la versión TDL-4. Es probable que los cambios de esta versión les hayan parecido tan importantes a los escritores de virus que hayan dejado de temer la competencia por parte de los nuevos propietarios de TDL-3.
A finales de 2010 Viacheslav Rusakov describió el funcionamiento de la nueva versión del rootkit de TDSS desde el punto de vista de su interacción con el sistema operativo. En este artículo analizaremos TDL-4 desde el punto de vista de su funcionamiento con la red y la carga útil de la botnet que en el momento en que llevamos a cabo la investigación, contaba con más de 4,5 millones de ordenadores infectados.

De nuevo un programa de afiliados

En el funcionamiento de la nueva versión parece que quedó intacto sólo el método de propagación, por medio de los programas de afiliados. Como antes, para propagar el programa malicioso, los programas de afiliados siguen ofreciendo el descargador TDL que, después de constatar la versión del sistema operativo, descarga TDL-4 en el ordenador.
Por cada mil instalaciones, los afiliados a TDL reciben de 20 a 200 dólares americanos, dependiendo de la ubicación geográfica del equipo de la víctima. Los afiliados pueden usar cualquier método de instalación. Con más frecuencia TDL se difunde en los recursos pornográficos, los sitios piratas y los sitios de almacenamiento de vídeo y ficheros.
Los cambios en TDL-4 afectaron de alguna manera a casi todos los componentes del programa malicioso y sus actividades en la red. Los escritores de virus expandieron las funcionalidades del programa malicioso, modificaron el algoritmo de cifrado del protocolo de comunicación entre los bots y los servidores de administración de la botnet trataron de garantizarse el acceso a los equipos infectados incluso en caso de que se clausurasen los centros de administración de la botnet. Al parecer, los dueños de TDL están tratando de crear una botnet “indestructible”, protegida de las amenazas tanto de la competencia, como de las compañías antivirus.

La botnet “indestructible”

Cifrado de las conexiones de red

Uno de los cambios claves de TDL-4 en comparación con la versión anterior fue la actualización del algoritmo de cifrado del protocolo usado para la comunicación entre los equipos infectados y los servidores de administración de la botnet. Para reemplazar RC4, los delincuentes desarrollaron su propio algoritmo de cifrado, que usaba suplantaciones y operaciones XOR. Sirven de llaves de cifrado el nombre de dominio desde donde se inicia la conexión y el parámetro bsh del fichero cfg.ini.
Recordamos que la presencia de un fichero de configuración, donde se describen los principales parámetros usados por los diferentes módulos para llevar el registro de sus actividades y de la conexión con los servidores de administración es una de las peculiaridades de los programas maliciosos de la familia TDSS.
En comparación con la tercera versión, el formato del fichero de configuración ha cambiado poco. La adición clave es el parámetro “bsh”. Este parámetro es el identificador del ejemplar del programa malicioso, asignado por el servidor de administración durante la primera conexión con el bot. También sirve como una de las llaves de cifrado durante las siguientes conexiones con el servidor de administración.
Durante la inicialización del protocolo se crea una tabla de suplantación para la solicitud http inicial del bot. Esta tabla se inicia con dos llaves: el nombre del dominio del servidor de administración de la botnet y el parámetro "bsh". La solicitud inicial se cifra y se convierte al formato base64. Después, en el inicio y final del mensaje obtenido, se agregan cadenas aleatorias escogidas con anterioridad en formato base64. La solicitud completa se envía al servidor mediante el protocolo HTTPS.
El algoritmo propio de cifrado de la comunicación entre los centros de administración de la botnet y la red evita que se pueda analizar el tráfico de red y bloquea los intentos de otros delincuentes de interceptar la administración de la botnet.

Un "antivirus” propio

TDL-4, al igual que Sinowal es un bootkit, es decir, para ejecutarse automáticamente infecta el sector MBR, lo que le permite iniciarse antes que el sistema operativo. Este método, usado por los virus de inicio clásicos, les garantiza a estos programas una gran vitalidad y los oculta de la mayoría de los programas de protección.
TDL es muy hábil para ocultarse a sí mismo y a los programas maliciosos y evitar que los antivirus los detecten. Para que los demás programas maliciosos que hayan penetrado al equipo sin la venia de los dueños de TDL no llamen la atención de los usuarios hacia el equipo infectado, TDL-4 tiene la posibilidad de eliminarlos. Por supuesto, no todos, sino los más populares.
TDSS tiene códigos para eliminar unos veinte programas maliciosos, incluyendo Gbot, ZeuS, Clishmic, Optima, etc. TDSS escanea el registro, busca nombres específicos de ficheros, pone en su lista negra las direcciones de los servidores de administración de otros botnets y bloquea el acceso a éstos desde el equipo infectado.
Por una parte, este “antivirus” ayuda a TDSS a luchar contra la competencia y por otra, a apartar de sí mismo y de su “equipo” (los programas maliciosos que instaló) los inconvenientes causados por la presencia en el ordenador infectado de otros programas maliciosos.
¿Qué programas maliciosos instala TDL-4? Desde principios de este año, en la botnet se han instalado cerca de 30 programas maliciosos adicionales, incluyendo falsos antivirus, módulos publicitarios y el spambot Pushdo.
Es curioso que después de instalar otros programas maliciosos TDL-4 no se borra y puede usarse para desinstalar en cualquier momento sus programas maliciosos con la ayuda del módulo r.dll.

Acceso de la botnet a la red p2p Kad

Una de las innovaciones más brillantes de TDL-4 es el módulo kad.dll, que posibilita el acceso de la botnet TDSS a la red P2P Kad. Pero ¿por qué les hace falta a los delincuentes una red pública de intercambio de ficheros?
Hace bastante tiempo que se tiene noticias de botnets controladas mediante el protocolo P2P, pero hasta ahora se trataba de protocolos cerrados de comunicación creados por los delincuentes. TDSS, por su parte, usa una red P2P pública para enviar las instrucciones del dueño de la botnet a todos los ordenadores de la red zombi. El principio de funcionamiento del algoritmo de TDSS con esta red es el siguiente:

1. En la red pública Kad los delincuentes abren acceso a un fichero llamado ktzerules. El fichero está cifrado y contiene una lista de instrucciones para TDSS.
2. Los ordenadores infectados con TDSS reciben la instrucción de descargar e instalar el módulo kad.dll.
3. Una vez instalado, kad.dll descarga el fichero nodes.dat que contiene la lista pública de direcciones IP de los servidores y clientes de la red Kad.
4. En la red pública Kad el módulo kad.dll solicita la búsqueda del fichero ktzerules.
5. Después de descargar e instalar el fichero ktzerules, kad.dll ejecuta las instrucciones contenidas en ktzerules.

Esta es la lista de instrucciones contenidas en el fichero cifrado ktzerules.

• SearchCfg, buscar un nuevo fichero ktzerules en la red Kad
• LoadExe, descargar y ejecutar el fichero ejecutable
• ConfigWrite, escribir la entrada en cfg.ini
• Search, buscar el fichero en la red Kad
• Publish, publicar el fichero en la red Kad
• Knock, descargar desde el centro de administración el fichero nodes.dat, que contiene la lista de direcciones IP de los servidores y clientes de la red Kad, entre ellos los ordenadores infectados por TDSS.

La instrucción más interesante es Knock. Mediante esta instrucción los delincuentes crean su propia red P2P Kad, cuyos clientes son sólo los ordenadores infectados por TDSS.
En esencia, en la administración de la botnet TDSS el módulo kad.dll cumple funciones análogas a cmd.dll. Usando el fichero nodes.dat, que contienen la lista de las direcciones IP de los participantes en la red Kad y ktzerules, que contiene la instrucción de descargar un nuevo fichero nodes.dat desde los servidores de los delincuentes, los dueños de la botnet pueden dar de alta o de baja los equipos infectados en la red pública Kad. En la red pública Kad no hay más de 10 ordenadores infectados por TDSS. Esto hace que sea muy difícil suplantar el fichero ktzerules y evita que otros delincuentes intercepten la administración de la botnet. En cambio, la cantidad general de ordenadores infectados con TDSS en la red cerrada es de varias decenas de miles.
Además, el acceso a la red Kad les da a los delincuentes la posibilidad de descargar en los ordenadores de la botnet y hacer públicos para los usuarios de la red P2P cualquier tipo de ficheros, por ejemplo pornografía o bases de datos robadas.
La peligrosidad de esta botnet consiste en que, incluso si se cierran los centros de administración, los dueños de la misma no pierden el control sobre los ordenadores infectados. Sin embargo, este sistema tiene ciertas lagunas:

1. Usando la red pública Kad, los delincuentes corren el riesgo de que aparezcan instrucciones falsas para la botnet.
2. Durante el desarrollo del módulo kad.dll, para gestionar la interacción con la red Kad usaron códigos bajo licencia GPL GPL, lo que significa que los autores están infringiendo el acuerdo de licencia.

Expansión de las funcionalidades

Además de las funcionalidades publicitarias, en TDL-4 han aparecido nuevos módulos. Ya hemos escrito sobre el “antivirus” y el módulo de trabajo con redes P2P. Aparte de ellos, los dueños de TDSS incluyeron entre las funcionalidades del programa malicioso varios módulos más y ahora pueden ofrecer a sus clientes servicios de acceso anónimo a la red mediante los equipos infectados y soporte de sistemas de 64 bits.

Módulo del servidor proxy

Socks.dll es el nombre del fichero que TDSS incrusta en el proceso svchost y que sirve para abrir un servidor proxy en el equipo infectado. La presencia de este módulo permite navegar anónimamente en Internet mediante los equipos infectados.
Como cuentan con una gran cantidad de equipos con esta funcionalidad, los delincuentes han empezado a ofrecer servicios de conexión anónima a Internet. El coste del servicio es de unos 100 dólares al mes. Para ofrecer comodidad a sus usuarios, los delincuentes desarrollaron un plugin para Firefox que permite cambiar con rapidez los servidores proxy sin salir del navegador.

Soporte de sistemas de 64 bits

La aparición del driver de 64 bits en TDSS fue una de las novedades tecnológicas introducidas por los delincuentes en 2010. Para admitir el funcionamiento de los sistemas de 64 bits en régimen de usuario, TDL-4 contiene el módulo cmd64.dll, que es la versión de cmd.dll para sistemas de 64 bits. Sin embargo, debido a las limitaciones en el funcionamiento de los programas en sistemas de 64 bits, el código cmd64.dll contiene sólo las funcionalidades de comunicación con los servidores de administración de la botnet.

Trabajo con los sistemas de búsqueda

El módulo cmd.dll casi no ha sufrido cambios. Su tarea es establecer la conexión con los servidores de administración de la botnet y suplantar los resultados en los sistemas publicitarios y de búsqueda. En la lista de instrucciones para TDSS, la principal novedad es SetName, que asigna un número a cada ordenador infectado. Durante el trabajo con los sistemas de búsqueda y las redes de banners, TDSS usa la misma tecnología que otros programas maliciosos para hacer subir el rating de los resultados. Sin embargo, TDSS tiene la lista más larga de sistemas de búsqueda en los cuales suplanta los resultados de las búsquedas.

Servidores de administración de la botnet

TDSS usa varias fuentes para obtener las listas de administración de los servidores. Por defecto, la lista se toma del cuerpo de cmd.dll, pero si los servidores estuviesen fuera de alcance, el bot la toma de cfg.ini. Si por alguna razón ninguno de los servidores de administración de la lista cfg.ini está disponible, la lista se extrae del fichero cifrado bckfg.tmp, que el bot recibe la primera vez que se conecta al servidor de administración. Desde principios de este año se han registrado 60 servidores de administración de la botnet, distribuidos por todo el mundo.


Si se analiza con atención esta lista, se puede ver que las direcciones IP de los centros de administración cambian todo el tiempo y algunos dejan de funcionar. Estos cambios están condicionados por los servidores proxy que ocultan la verdadera ubicación de los centros de administración.

Estadística de los servidores de administración

A pesar de las medidas tomadas por los delincuentes para proteger los centros de administración de la botnet, conociendo el protocolo de comunicación de TDL-4 con los servidores de administración se pueden crear solicitudes especiales y recibir estadísticas de la cantidad de equipos infectados. Al analizar los datos obtenidos, se puso al descubierto tres bases de datos MySQL independientes ubicadas en Moldavia, Lituania y EEUU que admitían el funcionamiento de la botnet desde detrás de servidores proxy.
Según la información de estas bases de datos, sólo en el primer trimestre de 2011, TDL-4 infectó 4.524.488 equipos en todo el mundo.
Casi una tercera parte de los equipos infectados se encuentra en los EE.UU. A juzgar por los precios de los programas de afiliados, infectar esta cantidad de equipos en EE.UU. cuesta 250.000 dólares, suma que al parecer gastaron los creadores de TDSS. Es curioso que en la estadística no figuran usuarios de Rusia. La explicación es que los programas de afiliados no ofrecen ningún pago por infectar usuarios rusos.

Esto todavía no es el final

El subtítulo de las últimas secciones de nuestros artículos sobre TDSS ya se está haciendo una tradición. En este caso tenemos razones para suponer que TDSS continuará desarrollándose. El activo perfeccionamiento del código de TDL-4, el rootkit para sistemas de 64 bits, el inicio antes del sistema operativo, el uso de exploits del arsenal de Stuxnet, el uso de la tecnología P2P, el antivirus propio y muchas cosas más ubican al programa malicioso TDSS entre los más desarrollados desde el punto de vista tecnológico y los más difíciles de analizar. Los delincuentes usan la botnet de más de 4.500.000 bots para manipular los sistemas publicitarios y los resultados de los sistemas de búsqueda, garantiza a los delincuentes acceso anónimo a Internet y sirve de plataforma para instalar otros programas maliciosos.
TDSS y la botnet que reúne los equipos infectados causarán muchos disgustos a los usuarios y los especialistas en seguridad IT. Una botnet descentralizada y sin servidores es prácticamente indestructible y la epidemia del gusano KIDO lo ha confirmado.