Esta entrada es una guia de usuario, no verificada por ningún desarrollador de eMule, pero es un añadido útil para la mayoría de los usuarios. Pueden encontrarse preguntas y comentarios sobre este un hilo dedicado a él en nuestro foro.
Autor: Tchon
Esta nota está destinada a los "newbies"
Créditos y encriptación de seguridad
I - Introducción.
El sistema de créditos fué desarollado para favorecer a los que saben compartir y funciona para todos los « clientes » ed2k (eMule, eDonkey, MlDonkey, etc.).
eMule guarda el volumen transferido (expresado en bytes) en el fichero « clients.met ».
Cada vez que un cliente pide un fichero, los valores de los bytes que le transfiere y el valor de los bytes recibidos de él se usan para calcular un modificador, el cual afecta el puesto en la cola de espera.
Hay dos modificadores diferentes calculados:* Ratio1 = Total subido x 2 / Total descargado, salvo que Total descargado sea 0, en cuyo caso Ratio1=10
* Ratio2 = Raíz Cuadrada(Total subido + 2)
Ambos ratios son comparados y el valor más bajo es usado como modificador.
También existen algunas condiciones:
* Total subido < 1.000.000 B => Modificador = 1
* El modificador no puede ser menor que 1 ni mayor que 10 Los créditos no son globales. Se intercambian entre dos clientes específicos.
Sus propios créditos son guardados por cada cliente que le debe un crédito. Esto previene la falsificación de los créditos. No pueden ver sus propios créditos.
Ver el documento original de -> Monk
II - Userash
Cada cliente que se conecta a otro de la red ed2k es conocido por su « userhash » y no por su ID ni por su IP. La clave de identificación de base o « userash » es guardada en el fichero « preferences.dat ». Se crea automáticamente en el momento de la primera utilización de la mula.
Ejemplo de « userash » : A15E9203550DF62E540CEF789A416F26
Sucedió que esta clave no fue bastante protegida contra los piratas y otro "leechers". Ciertos compartieron su « userhash » con algunos compañeros, otros que tenían pocos créditos consiguieron robar el « userhash » de cualquiera con más créditos etc.
III - La seguridad de los créditos.
En las versiones recientes de la mula, existe el segundo nivel de seguridad para evitar el robo de los créditos: secure user identification (SUI), basado en el sistema " RSA ". La clave generada entonces o clave particular de 384 bits es registrada en el fichero « cryptkey.dat ». El sistema " RSA " genera la segunda clave o clave pública codificada (o en sentido opuesto decodificada) gracias a la clave particular. Es con esta clave que serán identificados y guardados sus créditos entre sus clientes (y vice-versa). No es muy sencillo, pero eficaz.
Existe un esquema explicativo -> Identification sécurisée des utilisateurs
Exepto con las versiones recientes de eMule y los « mods » que lo utilizan siempre, este sistema debe ser activado. En "Preferencias" -> "Seguridad" -> " Opciones diversas " -> " Utilizar la identificación segura " debe estar activado √ .
Si no ...
21/02/2004 17:29:13: received signature for client without public key
... castigado, no tendrá créditos …
IV - Las otras caras.
El reparto o el pirateo del fichero « preferences.dat » implica un desdoblamiento de la identificación. Cuando dos mulas con el mismo « userash »" se presentan al mismo tiempo en un mismo cliente, son acusadas de « userashing » y rechazadas las dos.
Llegado sólo y primero, el "pirata" que tiene la misma identificación que el cliente al cual la robó va a gozar de los créditos y posiblemente agotarlos. Ahora, la mula guarda la identificación de los "piratas" y rechaza ambos clientes.
04/03/2004 09:44:52: 'pollopocxxx' has failed the secure identification, V2 State: 0
04/03/2004 09:45:17: Aviso: Se ha encontrado un cliente igual a otro ya conectado: TONI.xxxxx (80.37.240.230) y pollopocxxx (81.203.82.81)
04/03/2004 09:45:20: 'TONI.xxxxx' has failed the secure identification, V2 State: 0
04/03/2004 09:45:22: Los clientes 'TONI.xxxxx' y 'pollopocxxx' tienen el mismo hash de usuario o IP - eliminados 'Both'
En el momento del paso de la identificación simple a la identificación segura (a partir de la versión 0.29b), los antiguos créditos « no seguros » están perdidos ya que fueron identificados con el antiguo sistema.
Si el fichero « crypkey.dat » está borrado o perdido, el sistema de seguridad " RSA " no funciona más. No es posible más codificar, decodificar y administrar los créditos.
Entonces, hay que borrar el fichero " preferences.dat " y empezar de nuevo desde el principio.
V - Archivos muy importantes.
Ya vimos que los más importantes son el « preferences.dat » y el « cryptkey.dat ».
También es importante el clients.met, más que nada para respetar los créditos que tengan otros usuarios contigo. Ascenderán más rápido en tu cola, descargando antes, y por lo tanto, después tú ascenderás más rápido en las suyas.
Estos ficheros deben ser salvaguardados para una recuperación en buenas condiciones en caso de problema o en caso de cambio de versión.
Un saludo.
@+ |
