SET 034 0x0B

eZine lover (@eZine)

Published in 

Saqueadores Edicion Tecnica

 · 5 years ago

  

-[ 0x0B ]-------------------------------------------------------------------- 
-[ e-mule - Curiosidades ]--------------------------------------------------- 
-[ by FCA00000 ]-----------------------------------------------------SET-34-- 

Este es un artículo que cuenta algunas cosas sobre el programa eMule usado para transferencia de ficheros en redes P2P. 
Incidentalmente se explica el sistema de créditos y como se le puede engañar. 
Empiezo de manera sencilla, y voy aumentando el nivel. Salta los párrafos que  
ya sepas. 

Introducción 
---------------- 
La verdad es que sospecho que no hace falta ninguna presentación para el eMule,  
pero aquí va. 
Las redes de intercambio de ficheros P2P llevan mucho tiempo establecidas, y  
existen varias de ellas. De hecho el programa eMule se puede conectar a más de  
una. El protocolo más común se denomina eDonkey. 
Existen varios programas clientes P2P pero definitivamente eMule es uno de los  
más usados. Al ser el código de licencia GPL, se puede ver el código fuente y  
modificarlo. 
Para ello sólo es necesario el compilador Visual C++ 7.10 
Aunque no te lo creas, yo no tengo conexión a Internet en casa. Si quiero mirar  
el correo o mirar alguna página web, lo hago desde el trabajo, o en casa de  
algún amigo. 
Sin embargo recientemente intenté comprar una película que no encontré en  
ninguna tienda, así que me pasé al lado oscuro y intenté conseguirla en el P2P. 
Instalé el eMule, me conecté a un servidor, la busqué, y estaba disponible en 7  
fuentes, de las cuales 2 estaban desconectadas. No es mucho, pero menos da una  
piedra. 

Datos partidos 
-------------------- 
Cuando un ordenador se conecta a un servidor de la red P2P, le dice cuales  
ficheros comparte. En realidad el nombre del fichero no es importante, sino un  
identificador único para cada fichero. Esto hace que, aunque cambies el nombre,  
el servidor sigue sabiendo que tú tienes el mismo fichero que otra persona, si  
los identificadores coinciden. 
Por tanto, el servidor almacena los siguientes datos: 
-dirección IP del cliente 
-nombre del fichero 
-identificador único del fichero 

Ahora sería útil que consiguieras el documento 'The eMule Protocol  
Specification' disponible en http://emule-project.net. Explica muchas cosas con  
gran detalle. 
Para seguir la misma notación, usaré las palabras: 
-servidor: es un ordenador conocido, disponible 24x7. Se usa para la  
 autentificación, para saber los clientes conectados, y los ficheros que éstos  
 ofrecen. 
-fuente: un ordenador que tiene un fichero 
-destino: un ordenador que desea un fichero 

Como supongo que todos sabéis, cada fuente puede tener el fichero completo, o  
sólo un trozo. En cualquier caso, el ordenador destino y el fuente intercambian  
información sobre los trozos disponibles, y el fuente decide en qué momento se  
los va a dar. 
Esta decisión depende de varias reglas: 
-número de sesiones: si el fuente tiene muchos clientes, el destino tendrá que 
 esperar hasta que esté desocupado. 
-volatilidad: supongamos que un fichero se divide en 10 trozos, y que 1 de 
 ellos sólo lo tiene 1 fuente. Con el objetivo de asegurar su supervivencia, el 
 fuente le da prioridad a este trozo. 
-ubicuidad: si un trozo está en otras 1.000 fuentes, se entiende que es fácil 
 de conseguir, por lo que no es prioritario. 
-antiguedad de la sesión: los primeros 15 minutos van más rápidos que los 
 siguientes. 
-trozos intermedios: si un cliente ha bajado muchos trozos, baja su prioridad 
 para los siguientes. 
-trozos finales: cuando te falta un único trozo para completar el fichero, 
 adquiere prioridad. Esto se hace para evitar una debilidad del protocolo, y la 
 frustración del 'fallo en el último minuto' 
-usuarios amigos: es posible promocionar a ciertos clientes, beneficiándolos 
 con más velocidad o prioridad. 
-créditos: para recompensar a los usuarios donantes, se establece un porcentaje 
 entre la cantidad de datos bajados y subidos. Si tú me das ficheros a mí, yo 
 te los doy a tí. Quid pro quo, que diría Séneca. 

Recordar que el destino le pide trozos al fuente, y éste los pone en una cola  
de la manera que mejor le parezca. Es posible que estés en la posición 200 y  
de repente saltes a la 4, o incluso vuelvas para atrás porque alguien se te  
haya colado. 

Es más, lo normal es pedirle el mismo trozo a todos los fuentes que lo tienen.  
Cuando te llega el turno, el fuente le pregunta al destino si todavía quiere el  
trozo. Si ya lo has conseguido de otro sitio, no lo necesitas. 
Pero no vuelves a final de la cola, sino que el fuente pregunta: 'Vale, no  
quieres el trozo X, pero también me has pedido el trozo Y . ¿Lo quieres? ' 

¿Qué hay de lo mío? 
-------------------------- 
En mi caso concreto, yo buscaba un fichero muy poco común: 'El hombre que no  
estaba allí', dirigida por los hermanos Cohen. 
Tras algunas deducciones, entendí que los usuarios que comparten este fichero  
son aficionados a todo tipo de cine, y por tanto tienen muchas películas, y  
además poco comunes. Esto provoca que tengan muchas peticiones, que me ponían  
en la cola para 20 días más tarde! 
La regla de volatilidad no se aplicaba en este caso: muchos de los trozos sólo  
los tenía una fuente. 

Dado que era la primera vez que me conectaba, mi puntuación es la mínima: ni  
comparto ficheros, ni nadie me conoce. Esto me pone el último de la fila. 

Lo que yo pretendía era colarme, con alguna excusa. Obviamente fue en este  
momento cuando decidí echarle una ojeada al código fuente. 

Se compone de unos 300 ficheros de programa en C++ , y como es para Windows, sé  
que el 70% del código se destina al interface gráfico. El resto está organizado  
en clases. Bueno, decir 'organizado' es mucho: todos los ficheros están en el  
mismo directorio. Yo no soy quién para criticar, pero lo podrían haber hecho  
más fácil de entender. 

Debo aclarar que tanto el programa como la documentación denominan los  
conceptos Upload y Download desde el punto de vista del fuente. Es decir: no es  
el destino el que baja un fichero, sino que es el fuente el que lo sube. 

Lo primero que miré es el sistema de créditos, que está en el fichero  
ClientCredits.cpp 
La rutina importante es 
CClientCredits::GetScoreRatio(uint32 dwForIP) 

que obviamente dice la puntuación de un cliente. Esta puntuación se guarda en  
el fuente, no en el servidor. Es decir, yo decido si tú me gustas o no. 

El programa primero mira el número de bytes que se han bajado. Es decir: si tu  
no me has dado más de 1 Mb, entonces eres un roñica, y tu puntuación es la  
mínima: 1 
En cambio si el fuente ha bajado del destino, pero no ha subido nada, entonces  
'esta ronda la pago yo' y tu puntuación es la máxima: 10 
En cualquier otro caso, se dividen la cantidad de datos bajados entre los  
subidos. Hace una interpolación lineal y otra exponencial, y toma el mejor. 

Vale, así que si quiero colarme, tengo que darle antes algo a cambio. 

?Bailas? 
------------ 
Mi objetivo es porporcionarle al fuente un fichero que sea apetitoso. En cuanto  
él empiece a bajarlo, me dará créditos y me subirá el fichero que yo quiero. 
Lo repetiré con un ejemplo: 
-yo quiero The_man_who_wasnt_there_by_Cohen.avi 
-si él quiere The_big_lebowsky_by_Cohen.avi , entonces 
-yo busco The_big_lebowsky_by_Cohen.avi en otro fuente. 
-lo bajo, y se lo ofrezco. 
-consigo puntos a mi favor 
-él sube The_man_who_wasnt_there_by_Cohen.avi hacia mí 

 
La solución lógica es ver qué ficheros tiene el fuente parcialmente, sin  
completar, esperando que algún alma caritativa los ponga a su disposición.  
Seguramente está ansioso por obtenerlos. 

Ahora tengo que saber cuales ficheros quiere el fuente. En teoría podría usar  
el comando 
6.4.21 View shared files 
pero por defecto no está habilitado, pues es un ataque a la privacidad del  
fuente. 

Mirando la documentación del eMule en el apartado 6.2.9 explica el protocolo  
para buscar un fichero, pero sólo sirve en el servidor. Además la única manera  
de buscar un fichero es mediante el nombre, o el identificador único. No se  
permite hacer una búsqueda usando el usuario como criterio. 

Dado que eMule no permite saber todos los ficheros parciales de una fuente (ni  
tampoco los completados), tengo que buscar alguna puerta trasera. 

Para saber lo que le interesa a mi fuente, he supuesto ciertas hipótesis que  
luego he ido refinando. 

Si el fuente tiene una película de los Cohen, quizás tenga más. Le digo al  
eMule que busque ficheros que incluyan la palabra 'Cohen'. Obviamente encuentra  
muchas occurrencias, de distintas fuentes. 
Lo bueno es que puedo filtrar (en mi cliente eMule) los que pertenecen a una  
cierta fuente, con su dirección IP, o el nombre de usuario. 
Esto lo hago en SearchFile.cpp 
CSearchFile::CSearchFile 
que es donde procesa el mensaje OP_SEARCHRESULT según se explica en la  
documentación 6.2.10 Search Result 
El filtro compara el campo Client ID, llamado m_nClientID en esta rutina. 

También se puede hacer en 
BaseClient.cpp 
CUpDownClient::ProcessHelloTypePacket 
pero esto es para el caso de que solicites el fichero, no para la búsqueda en  
sí. 

Para esto tengo que modificar y recompilar el eMule. Cuestión de un par de  
minutos. 

Con esto averiguo que mi futuro amigo tiene otras 2 películas de los Cohen. Las  
tiene completas, así que no está interesado en conseguir los trozos que le  
faltan. 
Usando un poquito de ingeniería social, deduzco que quizás le gusten otros  
directores similares. Le digo a eMule que busque archivos conteniendo la  
palabra Triers (por Lars von Triers, supongo que te suena) , Ingar Bergman, y  
similares. 
Consulto unas cuantas páginas de cinematografía para hallar términos  
sub-relacionados con Cohen, y en unos 20 minutos he lanzado 100 búsquedas en  
los servidores eMule, que proporcionan una lista de 30 ficheros pertenecientes  
a mi futuro amigo. 

Le pido esos 30 ficheros a mi fuente. Debido al diseño del eMule, el protocolo  
para saber cuales partes están disponibles, tiene prioridad sobre las colas  
para obtener los trozos de los ficheros. Con esto veo cuales ficheros tiene  
completos, y cuales trozos le faltan. 

Obviamente esta técnica es bastante limitada, pero felizmente resulta efectiva  
y averiguo que tiene 2 ficheros de los que le faltan 1 trozo a cada uno. Uno de  
ellos es Oh_brother_where_are_thou_by_Cohen.avi , que le falta el trozo séptimo. 

Esta es la mía: busco quién tiene ese trozo y ... nadie lo tiene. De hecho hay  
15 fuentes parciales; ninguna completa. Notar que esos 15 son a su vez destinos  
potenciales del trozo que nadie tiene. O sea, que si yo tuviera ese trozo, me  
haría amigo de todos ellos, aumentando mi crédito con todos. 

¿Pero de dónde lo saco? 
-------------------------- 
Como dice MakiNavaja: 'Lo que falta se inventa, porque en el barrio sobra  
ciencia' 
Para completar las pruebas necesito un servidor del protocolo eDonkey.  
Encuentro uno muy simple llamado eFarm cuyo código fuente ocupa 100 KB y se  
compila e instala en un plisplas. 

Hago que un ordenador Linux me funcione como servidor + fuente, y otro Windows  
hace de destino. 

Cojo una película cualquiera, la renombro como  
Oh_brother_where_are_thou_by_Cohen.avi , y ahora tengo que modificar su  
identificador único. Esto se calcula en AbstractFile.cpp 
CAbstractFile::SetFileHash 

que simplemente llama a md4cpy 
ahora hay que mirar el módulo MD4.cpp para darse cuenta de cómo hace los  
checksums. Básicamente se parte el fichero en trozos de 9.28 Mb y se hace un  
hash MD4 de cada parte. Luego se hace otro hash con todos los hash parciales.  
A partir de ahora consideramos que el fichero ocupa 9.28 Mb, por lo que  
llamaremos 'trozo' a una serie de bytes de este sub-fichero. 

Ahora hay que leer lo que dice la documentación en el apartado 
6.4.4 Request file parts: 
Pide a la fuente trozos de un fichero. Un mensaje puede pedir 3 trozos como  
máximo. 
Protocolo: 1 byte = 0xE3 
Tamaño: 4 bytes = tamaño de este mensaje 
Tipo: 1 byte = 0x47 = OP_REQUESTPARTS 
FileID: 16 bytes = identificador único del fichero (hash de los datos) 
Inicio del trozo primero : 4 bytes 
Inicio del trozo segundo : 4 bytes 
Inicio del trozo tercero : 4 bytes 
Fin del trozo primero : 4 bytes 
Fin del trozo segundo : 4 bytes 
Fin del trozo tercero : 4 bytes 

y el correspondiente 

6.4.3 Sending file part 
Este mensaje contiene un trozo de un archivo para bajar (debería decir subir).  
El tamaño del archivo especificado en la cabecera indica el tamaño del trozo,  
no el de este mensaje TCP/IP . Se compone de: 
Protocolo: 1 byte = 0xE3 
Tamaño: 4 bytes = tamaño de este trozo 
Tipo: 1 byte = 0x46 = OP_SENDINGPART 
FileID: 16 bytes = identificador único del fichero (hash de los datos) 
Posición Inicial : 4 bytes 
Posición Final : 4 bytes 
Datos: el contenido, que puede estar comprimido 

Ahora es cuando viene lo bueno: las fuentes saben que les falta un trozo del  
subfichero llamado FileID, que a su vez es el cheksum que se debería obtener.  
Pero no tienen nadie que se los proporcione. 

Entonces es muy fácil engañarlo: genero un fichero, modifico la rutina  
CAbstractFile::SetFileHash para que identifique este trozo con el nombre FileID  
que piden mis amigos, y lo pongo a disposición del servidor. 

Paso a paso: 
-busco  Oh_brother_where_are_thou_by_Cohen.avi 
-apunto su FileID, ej. 0xAAAAAAAA 0xAAAAAAAA 0xAAAAAAAA 0xAAAAAAAA 
-elijo un fuente cualquiera 
-le llamo con el mensaje 6.4.8 Part hashset request 
-me responde 6.4.9 Part hashset reply 
-esto contiene 60 sub-ficheros, o sea, 60 FileID 
-la parte séptima no la tiene nadie. Su FileID=0x77777777 0x77777777 0x77777777 0x77777777 
-creo un fichero 7.bin 
-modifico CAbstractFile::SetFileHash para que haga 
  if(m_strFileName != "7.bin") 
     pucFileHash=calcula_hash();  // rutina original, inalterada 
  else 
     strcpy(pucFileHash, "0x77777777 0x77777777 0x77777777 0x77777777"); 
-la línea anterior no es correcta, pero más o menos se entiende, ¿no? 
-le digo a eMule que recargue la lista de ficheros que yo ofrezco 
-dado que es el último fichero que le falta a los destinos, constantemente 
 están escaneando para ver si alguien lo oferta 
-en menos de 10 minutos tengo los 15 destinos rogándome que les suba el fichero 

Obviamente el checksum no es correcto, así que los destinos creen que ha habido  
un error de transmisión y lo solicitan de nuevo. Una y otra vez. 

Lo bueno es que 'oficialmente' yo les he transferido datos, por lo que mi  
puntuación ha subido. 
Esto es porque los créditos se conceden en 
CClientCredits::AddDownloaded(uint32 bytes, uint32 dwForIP) 
que es llamado por  
CUpDownClient::ProcessBlockPacket 
el cual es llamado con cada paquete OP_SENDINGPART. 

Recordar que el checksum sólo se puede calcular cuando se recibe el sub-fichero,  
no cada trozo. 

Existe también la posibilidad de mandar trozos comprimidos. Si funciona como  
espero, quizás podría mandar un paquete de 100 bytes, diciendo que en realidad  
se descomprime como 100 Kb. Esto multiplicaría rápidamente mi puntuación ! 

Mirando el código veo que hace 
nHeaderSize = sizeof(FileID) + sizeof(Posición Inicial) +  
sizeof(Posición Final) ; 
uint32 uTransferredFileDataSize = size - nHeaderSize; 
credits->AddDownloaded(uTransferredFileDataSize, GetIP()); 
... 
if (packed) 
	.... 

O sea, que los créditos se conceden en función de los datos _transmitidos_ ,  
no los datos _efectivos_ . No todo iba a ser bonito. 

El infinito, y más allá 
-------------------------- 
Notar que esta técnica se puede extender a todas las fuentes que queramos. 
Si quiero ser amigo de todos, puedo ofertar ficheros muy codiciados: 
-Invento nombres de fichero al azar, y los busco en los servidores. 
-Elijo aquellos que tienen muchas fuentes (>10) pero hay una parte que nadie 
 tiene. 
-Solicito sus checksums. Simplemente para obtener el FileID de cada trozo. 
-Modifico mi eMule para que diga que yo tengo esas partes. 
-En cuanto los otros me las pidan, los pongo en la cola a partir de la posición 1000 
-Esto no requiere una conexión rápida. El mayor esfuerzo es buscar los ficheros en el 
 servidor. 
-Si alguna vez necesito algo de esas fuentes, los pongo al principio de la cola 
-Yo les transmito datos falsificados, y ellos me dan crédito. 
-Ya puedo empezar a pedirles los ficheros que quiera. 
-Se acabaron las esperas. 

Claro que engañar no es la mejor manera de hacer amigos, así que no te aconsejo 
usar este truco. De hecho, ahora que lo pienso, esto se usa en la cola del  
médico: hay gente que pide hora a las 10, a las 11, y a las 12. Así pueden ir  
a la hora que más les convenga. Y si llegan a las 11:15 en vez de esperar, te  
intentan convencer de que les dejes pasar porque sólo han llegado tarde por 15  
minutos. 

De todas maneras sospecho que no es corriente buscar un único fichero: supongo  
que la gente baja (casi) cualquier cosa que puedan conseguir, y el problema es  
la velocidad de tu conexión, no la disponibilidad de los ficheros. 

Si has seguido el razonamiento verás que es fácil inundar las redes P2P con  
ficheros corrompidos, pues el checksum no se calcula en el momento correcto.  
?Quiere esto decir que las entidades de proteccion de derechos de autor pueden  
luchar, informáticamente hablando, contra estas redes? Yo creo que sí, aunque  
me parece que no lo han intentado lo suficiente. 

Esto me lleva a una pregunta: ¿cómo es posible que haya tantos ficheros que  
están parcialmente en la red? Cuando la primera persona lo pone a disposición,  
lo normal es que esté completo. Y cuando el segundo usuario lo baja, quiero  
suponer que lo baja completo también. 
Claro que es posible que la primera fuente desaparezca antes de que nadie tenga  
tiempo de bajarlo, pero en ese caso sólo otra persona tendrá la mitad. 
Cuando un tercero busca el fichero, ya sabe que no está completo, y no tiene  
sentido empezar a bajarlo. 

Lo único que se me ocurre es que esto es la Internet, y no tiene porqué ser  
lógico. 

 
En fin, mucho cuidado con los ficheros que bajais y lo que subís. 

*EOF*