BandaAncha

  • 🔍 en 📰 artículos ⏎
  • 🔍 en 💬 foros ⏎
  • 🔍 en 👇 este 💬 foro ⏎
  • 🔍 en 👇 este 💬 tema ⏎
Regístrate Regístrate Identifícate Identifícate

¿porque Ares no esta capado?

FroGt

Despues de buscar en el foro no e encontrado nada, con lo que lanzo la pregunta.

Que tipo de protocolo usa ese programa? porque se queda fuera del capado del protocolo de emule y Bt?

A ver si alguien sabe explicar esot con conocimientos fundados y no con el simple ''no esta capado porque no se han dao cuenta'' (que no dudo que sea asi, pero que el que lo diga que sea porque lo sabe con seguridad)

Salu2 :D

Este tema está cerrado a nuevas respuestas. Abre un nuevo tema para retomar la conversación.
HeLLKnight

Si no voy muy mal encaminado la forma de capar el tráfico que puso Ono, ¿no se llegó a la conclusión que era porque su hardware reconoce el encabezado de los paquetes TCP?

Si eso es así, tienen configurados sus dispositivos de priorizado para capar la velocidad de transferencia de esos paquetes, y deben tener introducidos todos los encabezados de los protocolos p2p que quieren filtrar. Así pues se me ocurre que o bien el Ares tiene un encabezado difícil de reconocer, o que está cifrado, o bien que símplemente Ono no ha introducido en la configuración de su hardware de priorizado...

Por eso es por lo que suelo leer en los foros de desarrollo y betas de programas p2p como utorrent o emule como la gente pide cada día que se cifren los paquetes que envía y reciben.

Espero que se me haya entendido medianamente :-D

FroGt

Cita de yomimmo

Del estudio de sus protocolos se deduce que la transferencia de ficheros esta encriptada o al menos ofuscada, si se pueden identificar la comunicaciones cliente servidor del tipo login y search, con lo que la unica manera de implementar un filtro de layer 7 para Ares es "prohibir" que los paquetes de login y searh pasen por la red, ya que mientras no se pueda identificar de forma clara la estructura del paquete de datos no se puede priorizar.

Si quieres te mando la documentacion sobre el estudio del protocolo ares hecho por los del proyecto "layer 7 filter".

Me parece muy interesante este tema, te agradeceria compañero que nos direccionaras a la documentacion de dicho proyecto, para echarle un vistazo y asi opder aprender algo mas.

Me pregunto yo ¿porque no han sacado ya una version de emule con dicho cifrado implementado? entre estos emules se ablarian cifradamente y entre estos emules y lod demas de manera normal e ir fomentando al paso a estos emules con cifrado poco a poco, asi no habria wevos de caparnos.

Nose, pero como e dicho ya en el foro si cuando termine el año esto no se ha solucionado ``adios ONO´´

🗨️ 1
Evilchan

YO expuse el tema de porque no esta capado el ARes(buscar el post que ahora esto perro y no me apetece) y efectivamente es porque la cabecera no la han incluido en el software o hardware para detectarla ya que en ese moemento el ares era aun desconocido. En el post escribir un link donde te decian como podias hacer un programa para detectar paquetes con cabecera del tipo emule,kazzaa, etc. Es mas. si quereis el codigo fuente de de como detectar pquetes emule por llamarlo de alguna manera es muy facil, vais a cualquier pagina de mods de emule y os bajais los archivos source, ahi viene el codigo que utiliza el emule para ver que version de emule u otro p2p utilizan los demas clientes cuando se conectan a ti. De este modo se saben cuantos bytes y cuales son los que delatan a cada cliente.

Edito:

community.broadcom.com/home el link consta de 3 partes y esta en ingles

🗨️ 6
braculas

l7-filter.sourceforge.net/protocols
No es por que no quieran.
(Undermatching pattern) A pattern can't be written for this protocol that matches all connections. (e.g. it may only be able to match search requests, but not file transfers in a P2P protocol.) See the comments in the pattern file for specifics.

🗨️ 5
Rod

Efectivamente. Como ya se habló en su día, los paquetes de datos que se envían los clientes están "cifrados" por lo que no existe un patrón a través del cual se pueda identificar el protocolo. Lo que sí se podría hacer sería bloquear el acceso a los servidores, con lo cual los clientes no podrían conseguir fuentes para transferirse datos. Pero claro, eso cantaría mucho y Ono no podría soltar las mentiras que suelta sobre el capado (que no priorización).

🗨️ 4
braculas

Si, asi es. Cuando dije "no es porque no quieran" me refería a que no pueden, salvando el bloqueo a los servidores que comentabas e incluso filtrando las búsquedas de contenidos que podamos hacer con el programa.
Cada vez que pienso que utilizan un desarrollo libre en contra de los usuarios, se me ponen los pelos de punta. Esto pienso que se creo para las empresas que utilizan sus propios recursos, no para un isp.

🗨️ 3
BocaDePez
BocaDePez
🗨️ 2
BocaDePez
BocaDePez
braculas
braculas
heffeque

1.3 JPC
Joltid Peer Cache (JPC) is now integrated into Azureus. For users whose ISP support this, JPC should allow faster downloads, while helping the ISP reduce its bandwidth costs. The JPC Plugin is safe in the way that your ISP won't know what you are downloading, and can't use it to spy on you. The JPC plugin can be disabled through Tools > Options > Plugins > JPC.

Lo que no sé es si los encriptados de cabeceras de azureus, bitcomet y bitspirit son compatibles entre sí. En el pando está por confirmar si lo utilizan también o no en su última versión, pero todo apunta a que también.

🗨️ 6
BocaDePez

Ahora Azureus y Bitspirit tiene encriptacion? Yo no consegui que los de bitcoment comentaran como encritpaban las cosas...

🗨️ 5
HeLLKnight

Por lo que me he enterado últimamente, los creadores de uTorrent y Azureus han llegado a un acuerdo para usar el mismo protocolo de encriptación, como podeis leer aqui:

(link roto)

"Yes, that's recent. Like, yesterday recent. ludde and a few non-Az devs made a new spec, and Parg thought it was a better spec, so now the two clients are working with a common PE spec. (not PHE, because EVERYTHING in encrypted, not just the header)"

Es de esperar que en las próximas betas de uTorrent (por cierto, mucho mejor que azureus y bitcomet para mi gusto, solo que todavía no tiene mucha fama en españa) introduzcan la encriptación, pues en Azureus acaban de hacerlo en la última beta, podeis leerlo aquí:

(link roto)

Justo donde pone:

FEATURE: Core | Encrypted peer connections [Parg,Nolar]

Al parecer bitcomet y bitlord (bitlord=bitcomet+spyware) ya tienen esta encriptación, Si bien tiene algunos "peros". No va a ser el mismo método de encriptación que he mencionado antes, por lo que no se si es compatible. No viene activada por defecto así que el 99% de la gente no sabe ni que existe ni lo utiliza. No creo que funcione si la función no está activada en ambos lados de la comunicación, además que ambos deberían usar bitcomet.

Son pruebas que no he hecho, pero a ver si entre todos llegamos al fondo de la cuestión ;-)

🗨️ 4
heffeque

En el bitcomet está activado el "auto" por defecto, no en desactivado como tu comentas.

Edit: estoy leyendo el hilo del foro ese y... más bien es alrevés de lo que tu dices. Los de Azureus pasan del creador de µTorrent, van a hacer su protocolo y quien quiera que les siga el protocolo, y quien no quiera pues que use el que le dé la gana.

Edit2: ap, nop, parece ser que hacia el final del hilo ya hablan de que están haciendo uno en común.

🗨️ 2
ronconcola

entonces eso queire decir que quiza las proximas verisones de azureus o utorrent se puedan saltar el capado?

Pero entonces si cifran esos datos, que pasara con lso que usan versiones antiguas de azureus o utorrent? no podran bajarse cosas de los nuevos clientes?