Audit des liens eD2K, FileIdentifier et collections

Périmètre : parsing/génération des liens, identité de fichier, extensions de hashset/AICH, sources embarquées, Magnet et collections. Les propositions ci-dessous sont des tests et analyses, pas des fonctions déjà retenues.

1. Sources auditées

ED2KLink.cpp / .h
FileIdentifier.cpp / .h
Collection.cpp / .h
CollectionFile.cpp / .h
SHAHashSet.cpp / .h
Opcodes.h
DownloadQueue.cpp

2. Forme minimale d’un lien fichier

CED2KFileLink::GetLink() génère :

ed2k://|file|<name>|<size>|<md4>|/

Le générateur minimal ne rajoute donc pas automatiquement hashset/AICH/sources dans cette fonction.

3. Validation du nom

Le constructeur rejette :

name empty

Le nom passe par :

URLDecode
OptUtf8ToStr
Trim

Compatibilité d’encodage = surface importante de fuzzing.

4. Validation de la taille

Le parser utilise :

_tstoi64

puis exige :

size > 0
size <= MAX_EMULE_FILE_SIZE

et vérifie la capacité du filesystem au-delà de l’ancienne limite.

5. Limites de taille

Constantes :

PARTSIZE = 9 728 000 bytes

OLD_MAX_EMULE_FILE_SIZE = 4 290 048 000
MAX_EMULE_FILE_SIZE     = 0x4000000000
                        = 2^38
                        = 256 GiB

La vieille limite ne doit pas être arrondie abusivement à 2^32.

6. Validation MD4

Le parser exige :

32 caractères

puis :

strmd4()

pour obtenir les 16 octets.

Le champ est donc strictement contrôlé.

7. p= — part hashset

Le parser tokenise :

HASH:HASH:HASH...

Chaque élément doit être un MD4 valide.

Il construit un buffer :

FileHash
uint16 HashCount
PartHashes...

compatible avec la logique de hashset.

8. Double p=

Le code considère un second hashset dans le même lien comme une erreur interne :

m_hashset != NULL
→ bError

Tester explicitement ce cas.

9. Hashset incorrect

Si un part hash ne se parse pas :

bError = true

et le hashset entier est supprimé.

Le lien fichier principal peut néanmoins rester exploitable selon la branche de parsing.

À confirmer par tests unitaires.

10. Cohérence hashset / taille

Question de robustesse :

nombre de part hashes
↔
taille théorique du fichier

Le parser du lien construit le hashset ; la validation finale peut intervenir plus tard dans FileIdentifier/PartFile.

Tester la frontière pour éviter une incohérence persistante.

11. h= — AICH

Le parser :

DecodeBase32(...)

vers la taille d’un CAICHHash.

Si la taille décodée est correcte :

m_bAICHHashValid = true

12. Double h=

Inspecter le comportement avec plusieurs h= contradictoires.

Le code visible ne montre pas la même protection explicite que p=.

Fixture à créer.

13. Sources extension après /

Le parser distingue :

paramètres avant /
extensions après /

et cherche ensuite une chaîne contenant :

sources

Le format accepte une date d’expiration optionnelle.

14. Sources IP:port

Pour chaque source :

parse IP
parse port
port != 0
port <= 65535

Les LowID sont rejetés dans cette forme car l’adresse seule ne suffit pas à les contacter correctement.

15. Hostnames

Si le texte n’est pas une IPv4 numérique :

SUnresolvedHostname

est créé.

Le nom est borné par une longueur de 512 caractères dans cette branche.

16. Source count

La boucle limite :

nCount < MAXSHORT

car le downstream utilise un count uint16.

Un lien gigantesque reste toutefois un bon cas de fuzz/performance.

17. Source expiry

Le format peut inclure :

sources@YYMMDD,...

Le parser reconstruit une date et ignore les sources si elles sont expirées.

Cas à tester :

date impossible
timezone
leap year
YY ambiguity

18. Paramètre s=

Le parser utilise InternetCrackUrl.

Il extrait :

scheme
hostname
path
username/password
extra

mais conserve principalement URL + hostname comme source.

19. Surface SSRF / fetch

Important : le simple parsing du lien ne doit pas conduire automatiquement à un fetch arbitraire non contrôlé.

Auditer tout downstream consommant :

s=URL

et les WebSources éventuelles.

But : comprendre les restrictions de schéma, redirections et réseau local.

20. Lien server

Format :

ed2k://|server|host|port|/

Port validé <= 65535.

La validation d’IP/DNS et l’IPFilter interviennent ensuite côté ServerList.

21. serverlist

Format :

ed2k://|serverlist|URL|/

Le lien transporte une adresse de téléchargement.

Les risques appartiennent ensuite au downloader HTTP et au parser server.met.

22. nodeslist

Format :

ed2k://|nodeslist|URL|/

Même séparation :

parsing du lien
≠
validation du nodes.dat

23. search

Format :

ed2k://|search|term|/

Le terme passe par URL decode / UTF-8.

Il devient ensuite une entrée vers le moteur de recherche.

24. Magnet

Le parser accepte aussi :

magnet:

Champs pris en charge :

as=
dn=
xl=
xs=
xt=

25. xt=urn:ed2k:

Transformé en :

strHash

Même chose pour :

urn:ed2khash:

26. xt=urn:aich:

Transformé en paramètre interne :

h=

puis passe dans le même parser AICH.

Bonne convergence du code.

27. xs=ed2kftp://

Le parser en extrait une source :

sources,host:port

avant le premier /.

Tester les hostnames et IPv4 atypiques.

28. as=http://

Seuls les as commençant par :

http://

sont transformés en s= dans ce code.

Ne pas inventer HTTPS support dans cette branche sans vérifier le downstream/autres versions.

29. Unknown Magnet params

Le parser ignore les paramètres inconnus.

Bonne propriété d’extensibilité, mais tester :

paramètre sans =
ordre différent
duplications
encodages

30. CFileIdentifier

Responsabilités :

MD4 master
MD4 part hashset
AICH master
AICH part hashset

Le détail d’intégrité est déjà D07 ; ici l’intérêt est l’objet d’identité commun.

31. FileIdentifier dans le protocole moderne

Utilisé par :

OP_MULTIPACKET_EXT2
OP_MULTIPACKETANSWER_EXT2
OP_HASHSETREQUEST2
OP_HASHSETANSWER2

La couche client-client n’est donc plus limitée au simple MD4 de 16 octets.

32. Collections

CCollectionFile stocke un ensemble de tags.

Pour une entrée créée depuis un fichier :

FT_FILEHASH
FT_FILESIZE
FT_FILENAME
FT_AICH_HASH éventuellement
FT_FILECOMMENT éventuellement
FT_FILERATING éventuellement

33. Collection from link

InitFromLink() exige un lien fichier valide et copie :

hash
size
name
AICH

Les sources du lien ne deviennent pas forcément une propriété persistante de la collection.

34. Trust des types de fichiers

Commentaire source intéressant :

si un type a été reçu depuis un serveur/client, il pourrait être faux.

La classe tente de combiner type déclaré et type déduit du nom selon contexte.

À relier au D16 Search Trust.

35. Auteur de collection

Tags :

FT_COLLECTIONAUTHOR
FT_COLLECTIONAUTHORKEY

Auditer Collection.cpp pour distinguer :

nom auteur
clé auteur
signature éventuelle

avant toute explication cryptographique publique plus poussée.

41. Limite de GetLink()

La fonction standard génère uniquement le lien minimal.

Si le GUI propose des liens enrichis ailleurs, trouver le constructeur exact avant de documenter leur génération.

Ne pas déduire de la capacité du parser que GetLink() les produit automatiquement.

44. MetMedic comme contexte

L’étude MetMedic montre historiquement que manipuler des fichiers .met sans préserver leur cohérence peut produire des états incompatibles.

Pour les collections et FileIdentifier, même principe :

inspection read-only d'abord
édition seulement avec invariants testés

45. Sécurité des URI handlers

Si Windows associe ed2k:// à eMule, un lien externe peut devenir une entrée réseau/application.

Auditer :

longueur totale
escaping
quotes
shell invocation
URI registration

sans supposer que le parser C++ est l’unique couche.

46. Pas de source comme autorité

Une source intégrée au lien est :

bootstrap hint

Elle ne doit pas obtenir un niveau de confiance supérieur à une source découverte par serveur/Kad/SX simplement parce qu’elle était dans le lien.

47. AICH fourni par lien

Un AICH contenu dans le lien est une information externe.

La cohérence avec le contenu reçu doit être validée par les mécanismes d’intégrité habituels.

Ne pas confondre :

hash fourni
et
hash vérifié par données

48. Hashset fourni par lien

Même principe pour p=.

Il peut accélérer le démarrage, mais toute incohérence avec le FileHash/taille doit être détectée.

50. Interop aMule

Rejouer les mêmes liens dans :

eMule
aMule

et comparer les champs acceptés.

C’est une bonne manière de distinguer :

extension eMule
vs
pratique interopérable

51. Limite publique

Le D14 SITE doit rester centré sur :

identité ≠ localisation

Les détails de parser/fuzzing restent internes.

52. Conclusion

Le lien eD2K est l’une des pièces les plus élégantes du protocole :

identité stable
+
localisation facultative

Les travaux internes intéressants sont surtout la robustesse du parser, la cohérence des extensions et l’interop, pas la création d’un nouveau format.

================================================================================================