neonet

Bonsoir,

Je me suis inscrit sur ce forum pour ce problème assez particulier.
J'ai modifié des playlists M3U8 issues d'un protocole flash. Seulement la lecture des fichiers vidéo liés à ces playlists n'est possible qu'après décryptage via une clé que je possède. Cette clé varie pour chaque playlist. Jusqu'ici, les clés consistaient en des chaînes de 16 caractères ; exemple : >Yf)
ým.Ns¨­.k8
Oui oui il y a là 16 caractères, incluant l'espace et un caractère invisible dont je découvre l'existence en déplaçant mon curseur pas à pas.

VLC lisait jusque-là ces playlists, même chiffrées de façon aussi originale. Seulement et tout récemment, le format des clés a changé, passant à 48 caractères ; exemple : c9f47ed5a2e8bea9ddad599a92438454bc341ebeaa45014c
que VLC n'arrive pas à utiliser pour déchiffrer les flux vidéo. Pourtant, la référence (dans le M3U8) au fichier contenant la clé est inchangée : un possible cryptage de la clé elle-même vers le résultat à 48 caractères (cf. exemple) est donc exclu.

Comment donc puis-je lire cette playlist ? Pourquoi ce format de clé n'est-il pas accepté dans VLC (le lecteur ne plante pas mais reste inactif) ? Peut-être un paramètre à modifier ?
Merci d'avance.

Bonjour,

un possible cryptage de la clé elle-même vers le résultat à 48 caractères (cf. exemple) est donc exclu.

Je ne pratique pas les playlists mais d'un point de vue purement informatique, je ne comprends pas ta phrase ci-dessus.
Il existe de nombreuses fonctions de hachage qui pourraient convertir cette clef de 16 caractères en une séquence d'autres caractères.
Par exemple, la fonction md5 fournit ceci :
md5(0123456789abcdef) = 4032AF8D61035123906E58E067140CC5 soit 128 bits.

Pour tomber sur 192 bits, il ne semble y en avoir qu'une dans les standards mais une fonction générant 160 bits auxquels ont ajoute un 32 bits apportant une indication supplémentaire est aussi envisageable.

Cordialement
Pulsar33

Il est vrai. Cependant, aucun appel vers une fonction de hachage n'est effectué, car le protocole est strictement le même que pour les playlists appelant mes clés de 16 caractères. Aucune conversion autre qu'une conversion logicielle (qui devrait alors être effectuée par le logiciel de lecture vidéo, ou par les codecs) n'est effectuée. Si la clé est bel et bien chiffrée, il devrait y avoir une ligne supplémentaire dans les commandes gérant la playlist, or il n'y a rien d'autre que :
#EXT-X-KEY:METHOD=AES-128,URI="ma_clé.key",IV=0x143A1ED31BE056375342A70A15CA91FD
indiquant un chiffrement AES géré via flash, déjà présente pour mes clés précédentes qui ne concordent pas avec le format de la nouvelle.

Remarquons que mon problème sera également réglé si quelqu'un est en mesure de m'expliquer comment convertir une liste de fichiers ".ts" chiffrés par AES et gérée par M3U8.

Mes recherches m'ont apprises qu'il pouvait exister différents formats de clés ; ce format peut être précisé dans la playlist (bien que ce ne soit pas le cas dans les miennes). Pour un format non précisé, la valeur retenue est "identity" et la clé est alors une chaîne de 16 octets au format binaire (exactement le format de mes clés précédentes !). Source : http://tools.ietf.org/html/draft-pantos ... #section-5

J'ai donc considérablement réduit mon problème à : quels formats de clé existe-t-il pour le chiffrement AES, et comment préciser ce format dans la playlist M3U8 ?
(je connais la commande à ajouter qui est "KEYFORMAT=" sur la ligne "#EXT-X-KEY:METHOD=AES-128", mais que mettre après ce égal ?)

salut, envoi moi un message pour qu'on discute !

On peut discuter en privé si tu veux CereFR

Entendu, je vous ai envoyé un premier message privé. Merci.