FreeToGenerate.com

Décode le bencode et le confronte aux règles que la spécification BitTorrent énonce réellement, dont celle qui change en silence l’identité d’un torrent. Rien n’est envoyé.

Collez du bencode, ou ouvrez un .torrent ci-dessous. Les octets non imprimables sont résumés, mais conservés tels quels.

Essayez :

Lu dans votre navigateur. Le fichier n’est jamais envoyé.

Verdict

Enfreint une règle énoncée par la spécification

Réencoder donnerait d’autres octets

Ce ne sont pas la même question. Une clé en double enfreint les règles et se réencode pourtant en octets identiques : une simple comparaison aller-retour la déclarerait saine.

Ce que la spécification en dit

  • Les clés du dictionnaire sont dans le désordre. La spécification exige qu’elles apparaissent triées comme des chaînes d’octets bruts, non par ordre alphabétique : les majuscules précèdent donc les minuscules, et une clé courte précède celle qui la prolonge.à l’octet 56

Structure

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

Info-hash

Calcul en cours...

Forme canonique

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

Le seul encodage que la spécification admette pour cette valeur.

Tout fonctionne dans votre navigateur. Rien n’est envoyé, et recharger la page efface ce que vous avez saisi.

Aussi disponible en : English · Español · Português · العربية

Décodeur bencode : le format à réponse unique

Collez du bencode ou ouvrez un .torrent, et voyez sa structure, les règles qu’il enfreint et son info-hash.

Qu’est-ce que le bencode ?

Le bencode est l’encodage que BitTorrent utilise pour les fichiers .torrent et les échanges avec le tracker. Il compte quatre types et presque aucune ponctuation : une chaîne, c’est sa longueur, un deux-points et les octets, si bien que 4:spam est le mot spam ; un entier, c’est un i, les chiffres et un e ; une liste, un l, son contenu et un e ; un dictionnaire, un d, des clés et des valeurs en alternance, et un e. Voilà tout le format.

Ce qui le rend singulier, c’est qu’il est canonique par construction. La spécification exige que les clés d’un dictionnaire apparaissent triées, interdit i-0e et interdit tout entier commençant par un zéro. Ensemble, ces règles font qu’une valeur donnée a exactement un encodage valide : aucune espace qui puisse varier, aucun ordre à choisir, aucune façon d’écrire le même nombre de deux manières.

C’est cette propriété qui a fait choisir le bencode. Un torrent est identifié par le SHA-1 de son dictionnaire info : l’encodage doit donc être reproductible octet pour octet, sinon l’identité cesse d’être stable. Cette page décode ce que vous collez, signale chaque règle enfreinte et calcule ce condensé comme la spécification l’exige.

Comment l’utiliser

  1. Collez du bencode, ou ouvrez un .torrent. Le fichier est lu dans votre navigateur et n’est jamais envoyé. Les octets non imprimables sont résumés plutôt que dénaturés, et rien ne se perd en chemin.
  2. Lisez le verdict et les constats. Ce sont deux questions distinctes : l’entrée enfreint-elle une règle énoncée, et un réencodage rendrait-il les mêmes octets. Chaque constat dit quelle règle et où.
  3. Comparez les deux info-hash. L’un vient des octets d’origine, l’autre d’un décodage suivi d’un réencodage. S’ils diffèrent, vous avez sous les yeux précisément le défaut contre lequel la spécification met en garde.

Pourquoi un réencodage peut changer l’identité d’un torrent

L’info-hash n’est pas le condensé du contenu du torrent en un sens abstrait. C’est le SHA-1 des octets du dictionnaire info exactement tels qu’ils figurent dans le fichier. Si un programme décode un torrent puis le réencode, et que l’original n’était pas parfaitement canonique, les octets changent et le condensé avec eux — or c’est ce condensé que trackers et pairs utilisent pour identifier le torrent.

La spécification anticipe cela avec un luxe de détails inhabituel. Elle précise que l’info-hash est ce qu’on obtient en décodant puis réencodant seulement si le décodeur a pleinement validé l’entrée, en citant nommément l’ordre des clés et les zéros initiaux. Elle ajoute que les clients doivent soit rejeter les fichiers invalides, soit extraire directement la sous-chaîne, et qu’ils ne doivent pas faire d’aller-retour de décodage sur des données invalides. Les spécifications ne consacrent pas d’ordinaire un paragraphe à une hypothèse.

Et ce n’est pas une hypothèse. Pendant la construction de cette page, une bibliothèque bencode très répandue a été confrontée aux cinq formes que la spécification déclare invalides : clés dans le désordre, clé en double, i-0e, i03e et i-03e. Elle les a toutes acceptées, a réencodé chacune vers des octets différents et a produit un SHA-1 différent dans les cinq cas. Un document valide a traversé la même bibliothèque octet pour octet, condensé inchangé, ce qui fait de ces cinq cas un comportement de la bibliothèque et non un défaut du test.

Cette page calcule donc le condensé à partir d’une tranche des octets que vous avez fournis, jamais en les réencodant, et n’affiche le réencodé à côté que pour vous laisser voir les deux se séparer.

Valide et canonique sont deux questions

Il est tentant de tester un document bencode en le décodant, en le réencodant et en vérifiant que les octets concordent. Cela attrape les clés dans le désordre et les zéros initiaux, et c’est la vérification vers laquelle presque tout outil se tournerait. Elle n’attrape pas tout.

Un dictionnaire portant deux fois la même clé enfreint la règle de tri, puisqu’un ordre trié ne laisse pas de place à une répétition. Mais un décodeur qui conserve les deux entrées les réécrira aux mêmes endroits, et les octets reviennent identiques. L’aller-retour dit que le document va bien ; la spécification dit que non. Cette page répond donc aux deux questions séparément et précise laquelle est laquelle.

Il y a aussi une règle que la spécification n’énonce pas. Elle interdit les zéros initiaux dans les entiers et donne i0e comme seule exception, mais elle décrit une chaîne uniquement comme précédée de sa longueur en base dix et ne dit rien de la façon dont cette longueur peut s’écrire. Une chaîne introduite par 03:abc est donc insolite et non illégale, et cette page la signale comme une observation sans la compter dans le verdict. Là où la spécification s’abstient de trancher, la page aussi.

Ce que cela ne peut pas vous dire

Cela ne vous dit pas si un torrent est sûr, complet, ou s’il pointe vers quoi que ce soit d’utile. Il lit une structure, pas un sens : les condensés de morceaux ne sont pour lui que des chaînes d’octets, et il ne tente de les confronter à rien. Un fichier peut être du bencode parfaitement canonique et rester le torrent de quelque chose dont vous ne voulez pas.

Cela n’avance rien non plus sur tel ou tel client BitTorrent. La spécification dit ce qu’un client doit faire ; ce que l’un d’eux fait réellement n’est pas observable depuis cette page, et rien ici n’a été éprouvé face à un client.

Enfin, le bencode est un format d’octets et non de texte. Une clé ou une valeur peut contenir n’importe quel octet, y compris des octets qui ne forment de texte valide dans aucun encodage, et les condensés de morceaux d’un vrai torrent sont exactement cela. Cette page conserve chaque octet intact à l’aller comme au retour, et lorsqu’une valeur ne peut pas s’afficher en texte, elle en indique la taille en octets plutôt que d’inventer des caractères absents.

Pourquoi est-ce gratuit ?

Décoder du bencode relève de la manipulation de chaînes, et le condensé est calculé par votre navigateur lui-même. Aucun serveur n’intervient, il n’y a donc rien à facturer ni de compte à créer.

Rien n’est envoyé. Un .torrent que vous ouvrez est lu localement et ne quitte pas l’onglet, ce qui compte ici plus qu’ailleurs.