FreeToGenerate.com

Decodifica bencode y lo contrasta con las reglas que el estándar de BitTorrent enuncia de verdad, incluida la que cambia en silencio la identidad de un torrent. No se sube nada.

Pega bencode, o abre un .torrent más abajo. Los bytes que no son imprimibles se resumen, pero se conservan tal cual.

Prueba uno:

Se lee en tu navegador. El archivo no se sube nunca.

Veredicto

Incumple una regla que enuncia la especificación

Volver a codificar daría otros bytes

No son la misma pregunta. Una clave repetida incumple las reglas y aun así vuelve a codificarse en bytes idénticos, de modo que una simple comparación de ida y vuelta la daría por buena.

Qué dice la especificación sobre esto

  • Las claves del diccionario están desordenadas. La especificación exige que aparezcan ordenadas como cadenas de bytes en bruto, no alfabéticamente, así que las mayúsculas van antes que las minúsculas y una clave corta va antes que otra que la prolonga.en el byte 56

Estructura

  • { }
  • announcehttp://tracker.test
  • info { }
  • namefile.txt
  • length1024
  • piece length16384

Info-hash

Calculando...

Forma canónica

d8:announce19:http://tracker.test4:infod6:lengthi1024e4:name8:file.txt12:piece lengthi16384eee

La única codificación que la especificación admite para este valor.

Todo funciona en tu navegador. No se sube nada, y al recargar la página se olvida lo que escribiste.

También disponible en: English · Português · Français · العربية

Decodificador bencode: el formato con una única respuesta correcta

Pega bencode o abre un .torrent y verás su estructura, las reglas que incumple y su info-hash.

¿Qué es bencode?

Bencode es la codificación que BitTorrent usa para los archivos .torrent y para el tráfico con el tracker. Tiene cuatro tipos y casi ninguna puntuación: una cadena es su longitud, dos puntos y los bytes, así que 4:spam es la palabra spam; un entero es una i, los dígitos y una e; una lista es una l, su contenido y una e; un diccionario es una d, claves y valores alternados, y una e. Ese es el formato entero.

Lo llamativo es que es canónico por construcción. La especificación exige que las claves de un diccionario aparezcan ordenadas, prohíbe i-0e y prohíbe cualquier entero con un cero a la izquierda. Entre las tres, esas reglas hacen que un valor dado tenga exactamente una codificación válida: no hay espacios en blanco que varíen, ni orden que elegir, ni forma de escribir el mismo número de dos maneras.

Esa propiedad es la razón de que se eligiera bencode. Un torrent se identifica por el SHA-1 de su diccionario info, así que la codificación tiene que ser reproducible byte a byte o la identidad deja de ser estable. Esta página decodifica lo que pegues, señala cada regla que incumple y calcula ese hash como exige la especificación.

Cómo usarlo

  1. Pega bencode, o abre un .torrent. El archivo se lee en tu navegador y no se sube nunca. Los bytes que no son imprimibles se resumen en lugar de destrozarse, y nada se pierde por el camino.
  2. Lee el veredicto y los hallazgos. Son dos preguntas distintas: si la entrada incumple una regla enunciada, y si volver a codificarla devolvería los mismos bytes. Cada hallazgo dice qué regla y dónde.
  3. Compara los dos info-hash. Uno sale de los bytes originales y el otro de decodificar y volver a codificar. Si difieren, estás viendo justo el fallo del que advierte la especificación.

Por qué recodificar puede cambiar la identidad de un torrent

El info-hash no es el hash del contenido del torrent en ningún sentido abstracto. Es el SHA-1 de los bytes del diccionario info exactamente como aparecen en el archivo. Así que si un programa decodifica un torrent y lo vuelve a codificar, y el original no era perfectamente canónico, los bytes cambian y el hash cambia con ellos, y ese hash es lo que trackers y pares usan para identificar el torrent.

La especificación anticipa esto con un detalle poco habitual. Dice que el info-hash es lo que obtienes decodificando y recodificando solo si el decodificador validó del todo la entrada, y menciona por su nombre el orden de las claves y los ceros a la izquierda. Después dice que los clientes deben o rechazar los archivos inválidos o tomar la subcadena directamente, y que no deben hacer una ida y vuelta de decodificación sobre datos inválidos. Las especificaciones no suelen dedicar un párrafo a una hipótesis.

Y no es hipotético. Mientras se construía esta página se probó una biblioteca bencode muy usada contra las cinco formas que la especificación declara inválidas: claves desordenadas, una clave repetida, i-0e, i03e e i-03e. Aceptó todas, recodificó cada una a bytes distintos y produjo un SHA-1 diferente en los cinco casos. Un documento válido pasó por la misma biblioteca byte a byte con el hash intacto, que es lo que convierte a esas cinco en comportamiento de la biblioteca y no en un defecto de la prueba.

Por eso esta página calcula el hash a partir de un trozo de los bytes que le diste, nunca recodificándolos, y muestra el recodificado al lado solo para que veas cómo se separan.

Válido y canónico son preguntas distintas

Es tentador comprobar un documento bencode decodificándolo, codificándolo otra vez y viendo si los bytes coinciden. Eso pilla las claves desordenadas y los ceros a la izquierda, y es la comprobación que casi cualquier herramienta elegiría. No lo pilla todo.

Un diccionario con la misma clave dos veces incumple la regla del orden, porque un orden ordenado no deja sitio para una repetición. Pero un decodificador que conserve ambas entradas las escribirá otra vez en el mismo sitio, y los bytes vuelven idénticos. La ida y vuelta dice que el documento está bien; la especificación dice que no. Así que esta página responde las dos preguntas por separado y dice cuál es cuál.

También hay una regla que la especificación no enuncia. Prohíbe los ceros a la izquierda en los enteros y da i0e como única excepción, pero describe una cadena solo como precedida de su longitud en base diez y no dice nada de cómo puede escribirse esa longitud. Una cadena introducida como 03:abc es por tanto rara, no ilegal, y esta página la señala como observación sin contarla en el veredicto. Donde la especificación se abstiene de decidir, la página también.

Lo que esto no puede decirte

No puede decirte si un torrent es seguro, está completo o apunta a algo útil. Lee estructura, no significado: los hashes de las piezas para él son solo cadenas de bytes, y no intenta contrastarlos con nada. Un archivo puede ser bencode perfectamente canónico y aun así ser el torrent de algo que no quieres.

Tampoco afirma nada sobre ningún cliente de BitTorrent concreto. La especificación dice qué debe hacer un cliente; qué hace cualquiera de ellos en realidad no es algo que esta página pueda observar, y nada de esto se ha probado contra uno.

Por último, bencode es un formato de bytes, no de texto. Una clave o un valor pueden contener cualquier byte, incluidos algunos que no son texto válido en ninguna codificación, y los hashes de las piezas de un torrent real son exactamente eso. Esta página mantiene cada byte intacto en la ida y vuelta, y cuando un valor no puede mostrarse como texto dice cuántos bytes ocupa en lugar de inventar caracteres que no están.

¿Por qué es gratis?

Decodificar bencode es manipulación de cadenas, y el hash lo calcula tu propio navegador. No hay servidor de por medio, así que no hay nada que facturar ni cuenta que crear.

No se sube nada. Un .torrent que abras se lee localmente y no sale de la pestaña, algo que aquí importa más de lo habitual.