Skip navigation.

devloop :: blog

Blog sur la sécurité informatique, la programmation, Linux et le Web

Posts tagged with "drm"

It's fun to play with the D.M.C.A.

, , ,

Ca fait quelques mois que mes outils pour lire directement sa musique sur le site Imeem ne fonctionnent plus. On tombe à la place sur une espèce de message de répondeur où quatre voix féminines nous informent qu'il faut passer par le site Internet.

J'avais étudié quelques captures réseau pour comprendre ce qu'il cloche sans jamais voir d'où ça pouvait venir, j'ai essayé différentes clés d'API sans meilleur résultat.
En fin de compte il s'avère que Imeem a quelque peu modifié sa fonction non documentée mediaGetStreamInfo. Auparavant un paramêtre "referrer" était passé et pouvait contenir plusieurs valeurs possibles, celle habituelle étant la chaine de caractères "web".

Ce paramêtre a été modifié : à l'ancienne valeur est maintenant accolé un pipe "|" puis une longue chaine de caractères (118 caractères) formatée (à priori) selon l'algorithme utilisé pour les urls des flux.

D'après le code décompilé, Imeem a rajouté une fonction baptisée "authenticateRequest" qui génère un hash MD5 qui sera envoyé au serveur comme variable de referrer.

Les codes Flash décompilés étant généralement à la limite du compréhensible p: j'ai fait le lien grâce au fait que cette fonction utilise une constante nommée "REFERRER_ENCRYPTION_KEY" de type string et de valeur "faad2ae444233f97367cc35da6de80b51767f182".

Dans le code il reste tout de même deux variables dont l'identité reste mystérieuse... l'une semble liée au temps, l'autre est probablement un caractère de délimitation (voire rien du tout).
On remarque si on joue plusieurs titres à la suite, ce referrer "magique" ne change pas même après 10 minutes passées. On trouve dans le code des références à l'heure courante, ce qui laisse supposer qu'un indicatif d'heure (arondi) est utilisé.
Enfin une autre variable constante fait référence au temps : "REFERRER_TIMESTAMP_THRESHOLD" de valeur 30000 (secondes ?)

Pour le moment je n'ai fait que quelques tests rapides. Il faut tout de même que ces deux variables soient assez longues pour que la forme encodée atteigne 118 octets... L'hypothèse qu'un "vrai" referrer (http://bidule...) soit utilisé n'est donc pas exclue :smile:

Une spécification non-officielle du protocole RTMPE d'Adobe sur Internet

, , , ...

J'ai déjà parlé du protocole RTMPE, protocole de streaming propriétaire de chez Adobe, dans un billet sur M6 Replay ainsi qu'une façon de passer outre les sécurités du protocole en utilisant un logiciel spécifique.

J'avais aussi connaissance de "rtmpdump", petit logiciel en ligne de commande qui permet de télécharger les flux RTMP sur différents sites. Pendant un moment je suivais son développement de près puis m'en était petit à petit éloigné en me disant que si un jour le RTMPE, la version chiffrée du RTMP, était implémentée, j'en entendrais forcément parler d'une manière quelconque.

Et c'est arrivé :D
Un lisant cet article de Slashdot, on apprend qu'une spécification non-officielle a été créée en se basant sur le code source de rtmpdump.
La réaction d'Adobe a consisté à utiliser le DMCA (loi sur le droit d'auteur) pour forcer SourceForge à retirer de ses pages le projet rtmpdump qui y était hébergé.

L'implémentation de RTMPE dans rtmpdump n'est pourtant pas si récente. Si on regarde dans le ChangeLog du logiciel, on voit que le code a été rendu publique le 27 avril de cette année par la version 1.5.
On comprend l'agacement d'Adobe qui tenait secret les spécifications de RTMPE et vend ses solutions (serveurs de streaming) à un certain prix faisant tout pour que des solutions libres comme le serveur Red5 ou le player Gnash ne parlent que le RTMP qui est "non protégé".

Toutefois je n'ai pas encore jeté un oeil sérieux au support du RTMPE dans rtmpdump ainsi qu'à la spécification (qui commencent tous deux à se répliquer sur Internet dans un mouvement d'anti-censure avec en plus SF qui est montré du doigt) pour déterminer s'il est possible de télécharger facilement les vidéos sur des sites de streaming basés sur les technos Flash ou si cela requiert des connaissances particulières...

Bref un buzz à suivre de très près et qui montre une fois de plus que les DRMs sont voués à l'échec.

Enregistrer les vidéos de M6Replay Béta sous Windows c'est possible

, , , ...

J'étais désespéremment à la recherche d'une spécification qui aurait pû m'en apprendre sur le protocole RTMPE utilisé par la Béta de M6Replay, en particulier sur la couche de cryptage, quand je suis finalement tombé sur un blog parlant d'un logiciel qui avait réussi à casser cette protection.

Ca m'a finalement amené à cette discussion sur le forum d'Adobe, puis au fameux logiciel ainsi qu'à un article sur le sujet sur Slashdot.

Après essai de Replay Media Catcher, il s'avère que effectivement ça fonctionne, entre autres sur M6Replay Béta.
Bien sûr, aucune information n'est disponible sur le fonctionnement du logiciel mais il doit utiliser à priori une attaque de type MITM, se faisant passer auprès du plugin Flash comme le serveur de streaming avant de renvoyer le flux réencodé par ses soins vers le véritable serveur. Bref il doit agir comme un proxy.
Le logiciel ne se sert pas de modules Internet Explorer, ni de la librairie pcap. Il n'y a donc pas, à la différence des logiciels concurrents, de sniffing. Le protocole RTMPE n'est donc pas "cassé", ce sont juste les développeurs de Replay Media Catcher qui ont trouvé puis implémenté la bonne astuce :smile:

Face à tout ça, Adobe a rajouté une clarification dans un document sur son Flash Media Server (pdf).

Et moi je n'ai trouvé aucune information intéressante sur le RTMPE... la magie des logiciels propriétaires :frown:


Ci-dessus, le fameux logiciel en action.

M6Replay Béta et Linux

, , , ...

Vous êtes peut-être au courant de l'existence d'une version béta de M6Replay qui permet aux utilisateurs de Linux et Mac de profiter des vidéos du site de M6.

Je m'étais déjà penché il y a quelques temps sur la version initiale (pour le moment toujours la version officielle) histoire de voir si il était possible de bricoler une "zapette" comme celle pour les émissions en clair de Canal+.
Après avoir pas mal fouillé, et trouvé assez facilement les urls des flux, il s'avérait que le protocole utilisait était du "RTSP-over-HTTP" (ou du moins quelque chose dans ces eaux là :D ), qu'on pouvait normalement le lire en bidouillant les options de VLC ou en passant un simple "mms://" au lieu du protocole dit officiel.
On final on avait bien de l'image et du son mais pas vraiment ce qu'on désirait. J'ai quand même cru discerner durant un dixième de seconde une paire d'yeux au milieu d'un artistique nuage jaune fluo et de taches oranges... à moins que ce soit l'effet du hazard p:
En fait il semblerait qu'un codec propiétaire (DRM-powered) soit utilisé en plus, rendant impossible la lecture sur les systèmes libres :frown:

Avec la version béta les vidéos sont bien lisibles sous Linux, mais M6 s'est visiblement cresé la tête pour trouver une solution tout aussi imbuvable.
Ca fonctionne donc avec le lecteur Flash (qui rappelons le est propriétaire)... mais pas autre chose.

On a bien un flux XML dans lequel on retrouve des urls du style
mp4:production/live/DIFF_28072008/H264_UN_DINER_PRESQ__UN_DINER_PRESQ__280720080615__LIVE.mp4
et en observant le traffic réseau on sait que le flux vidéo est lu depuis le serveur fcds98.lon.llnw.net (le nom de machine n'est probablement pas fixe) mais à part ça difficile de retrouver un lien direct pour y pointer son lecteur multimédia préféré.

Après recherches le flux vidéo utiliserait le protocole RTMP (Real Time Messaging Protocol), un protocole (bien évidemment) propriétaire développé par Macromédia (avant rachat par Adobe).
Il existe différents outils closed-source pour capturer les vidéos des flux RTMP, la majorité se basant sur le même principe que cette source C++ à savoir utiliser la librairie pcap et surveiller tout ce qui communique avec le port TCP 1935.

Le protocole RTMP a aussi été analysé et est utilisé par le projet "Open Source Flash" par le biais du serveur Red5.
Comble du bonheur, les versions béta de VLC (>= 0.9.*) supportent le RTMP :smile:

Petit problème : M6Replay utilise à priori le RTMPE ("RTMPE is a version of RTMP which is an 128-bit encrypted protocol"), ce qui fait que ces outils se montrent inefficaces.

Bref pour le moment seulement le lecteur Flash peut lire ces vidéos sous Linux. Il reste à trouver les adresses exactes des flux et attendre que le RTMPE soit supporté par un logiciel libre pour pouvoir en profiter "pleinement".

45-5F-E1-04-22-CA-29-C4-93-3F-95-05-2B-79-2A-B2

, , , ...

C'est reparti !!! p:

Freedom to Tinker avait mis en ligne un billet humouristique qui générait une suite de valeurs hexadécimales aléatoires pour parodier la célèbre "processing key" qui permet de déchiffrer les disques protégés par AACS.
Seulement dans les commentaires, un certain BtCB s'est amusé à poster une nouvelle Processing Key valide.

Bien sûr il n'aura pas fallu longtemps pour qu'elle apparaîsse sur Digg.

Comme toujours on a une discussion très intéressante sur cette découverte sur le forum de Doom9 (essentiellement les 3 premières pages de la discussion).
On en apprend un peu plus sur la structure de la MKB et les "Subset-Difference Set" (lire par exemple par ici pour plus d'explications) mais je n'irai pas jusqu'à vous donner une explication détaillée p:

La prochaine mise à jour de AACS déjà dans les choux

, , , ...

L'AACSLA continue d'utiliser son système de révocation des clés pour empécher la lecture de nouveaux disques haute définition sur des lecteurs dont les clés ont été rendues publiques.
La mise à jour vers ce que l'on appelle l'"AACS version 3" devrait être déployée dans ce but d'ici quelques jours, le 22 mai 2007, et être mise en place sur tous les supports HD-DVD et BluRay qui seront disponibles à la vente.

Mais c'était sans compter sur les développeurs du logiciel de déchiffrement AnyDVD qui proposent une version mise à jour de leur logiciel permettant d'effectuer une copie des médias protégés par AACS v3.
La nouvelle publiée sur Ars Technica nous informe que l'exploit est déjà "visible" par le biais des HD-DVD de Matrix 2 et 3 sortis en avance dans les rayons.

L'article de Ars Technica parle d'une nouvelle clé de volume trouvée par SlySoft, l'éditeur de AnyDVD, mais techniquement ça ne colle pas avec ce que l'on a vu jusqu'à présent.

Pour que SlySoft dévoile sa mise à jour à un tel moment, il fallait, comme le fait remarquer Freedom to Tinker, que l'éditeur ait gardé secrétement cette clé sous la main depuis un bon moment.
Je pense (et je ne suis pas le seul) que la clé en question doit plus correspondre à une Device Key, une clé qui est spécifique à (par exemple) une version d'un logiciel de lecture donnée. Les anciennes versions de AnyDVD se basaient apparemment sur des clés de PowerDVD. Evidemment, AnyDVD ne peut pas explicitement utiliser les clés d'un logiciel tiers. C'est pour cela que les clés qu'il utilise doivent être le résultat d'une opération combinant plusieurs clés à l'un des moment de l'algorithme AACS (l'AACS ce n'est pas seulement le jeu du chat et de la souris, c'est aussi jouer avec le feu sans jamais se bruler p: )

Le fonctionnement de AnyDVD est encore un mystère à l'heure actuelle mais déjà discuté sur Doom9. On en saura peut-être plus d'ici peu.

Quoiqu'il en soit, les pirates sont tellement en avance sur l'AACSLA qu'ils en sont à attendre les révocations pour pouvoir publier aussitôt les clés toujours fonctionnelles :D
L'AACSLA quand à lui continue inlassablement de révoquer ses clés et à menacer de poursuites judicaires puisqu'il n'a plus que ce moyen pour essayer de garder la "machine" en fonctionnement (et ses clients par la même occasion).

Autres articles relatifs à l'AACS :
devloop :: AACS cassé
devloop :: Informatique en vrac
devloop :: AACS de nouveau ridiculisé
devloop :: 09F911029D74E35BD84156C5635688C0
Certains ont trouvé une façon de réprésenter graphiquement la Processing Key en RGB :
http://en.wikipedia.org/wiki/Image:Free-speech-flag.svg :smile:
09 f9: A Legal Primer (EFF)
AnyDVD method of operation (date un peu)

09F911029D74E35BD84156C5635688C0

, , , ...

Hier, le 1er mai 2007, le blog Freedom to Tinker nous apprenait que l'AACSLA (Advanced Access Content System Licensing Administrator) envoyait depuis quelques jours une lettre type à tous les webmasters ayant publié sur leur site Internet la fameuse Processing Key (utilisée pour le chiffrement des disques HD-DVD) découverte par arnezami il y a maintenant presque 3 mois de celà !!

Avec un tel retard et alors que des milliers de pages avaient déjà publié le fameux code, l'AACSLA aurait dû se douter que c'était perdu d'avance. Pourtant ils se sont tout de même lancés dans la bataille (sans doute se sont-il dis "On sait jamais, sur un malentendu, ca peut marcher") et s'en sont notamment pris au site communautaire Digg.com.
Les administrateurs du site ont d'abord décidé de la jouer profil bas et de retirer les occurences de la fameuse clé dans leurs pages. Mais c'était sans compter sur les visiteurs qui, en s'en rendant compte, l'ont immédiatement réenvoyé un nombre incalculable de fois, transformant la page d'acceuil du site en une suite de valeurs hexadécimales :D

L'équipe de Digg a très vite compris que ça ne servait à rien d'aller plus loin et a préféré jeter l'éponge quitte à se facher avec l'AACSLA.
Quelqu'un a posté une vidéo qui montre l'évolution de Digg au moment des faits. C'est assez impressionant p:

Depuis, cette suite d'octets que certains qualifient de magique, est devenu un nouveau symbole geek. Ainsi on trouve des t-shirts portant la combinaison d'octets, des sites Internet, des vidéos de gens qui chantent les numéros, les lisent ou les font défiler.
Ne soyez pas surpris si vous croisez dans quelques jours une personne avec un tatouage énigmatique :D

AACS de nouveau ridiculisé

, , , ...

En février dernier, un certain ATARI Vampire du forum Doom9 est parvenu à récupérer une (sub) Device Key du logiciel WinDVD.
C'est aussi par ce logiciel que plusieurs bidouilleurs se sont fait les dents sur la protection AACS et sont parvenus à la casser à plusieurs reprises.

Comme on pouvait s'y attendre, le groupe AACS Licensing Administrator a finalement eu recours au système de révocation de AACS en obligeant l'éditeur de WinDVD (InterVideo, filiale de Corel) à mettre à jour son logiciel qui incluera de nouvelles clés ainsi que de nouvelles protections anti rétro-ingénierie.

Le système de révocation est tel que les nouveaux disques HD-DVD ou BluRay seront illisibles sur l'ancienne version du logiciel WinDVD. Les utilisateurs se voient donc obligés d'effectuer une mise à jour de leur logiciels s'ils souhaitent continuer à regarder des films.
On se demande qui est le plus à plaindre dans cette histoire. Ce qui est sûr c'est que malgré toutes les protections qui pourront être ajoutées, ce ne sera qu'une question de temps avant que les nouvelles clés soient trouvées.
Ca n'a pas forcément d'utilité mais si les clés sont divulguées puis mises à jour sans cesse, les consommateurs vont probablement aller voir ailleurs et la société perdra vite sa crédibilité. Les pirates ont par conséquent en bon moyen de pression sur les éditeurs de logiciels.
Sans compter (et j'y reviens juste après) que les clés révoquées doivent être stockées sur les nouveaux disques et risqueraient de s'entasser, augmentant ainsi l'espace disque nécessaire pour placer un média protégé.

Bref c'est le jeu du chat et de la souris mais on se garde bien de la dire sur le site du AACSLA.

Quelques petites 24 heures plus tard, c'est le système de révocation en question qui est mis à mal par Geremia et arnezami sur le forum Doom9 et XBoxHacker BBS.

Geremia a effectué ses tests sur le lecteur HD-DVD de la Xbox. Il a d'abord cherché à identifier le firmware utilisé en comparant le chipset avec ceux existant puis en le désassemblant.
Après quelques heures d'analyse de code assembleur bizarre (FR30, kezako ?), il est parvenu à patcher le firmware pour retirer la procédure de vérification des clés révoquées.

Un peu plus tard, un certain xt5 a mis à disposition un programme qui va modifier le code en mémoire pour bypasser la vérification, ce qui évite la désagréable tâche d'avoir à flasher le disque.

Difficile de savoir qu'elle va être la réponse de l'AACSLA et de Microsoft. S'il faut obliger les utilisateurs à mettre à jour leur firmware ça peut être problématique p:

Clubic : Une nouvelle protection HD-DVD contournée
RegHardware : Hack exposes AACS 'hole'

Linux, accessibilité et DRM

, , , ...

En octobre dernier, on nous apprenait que le site VirginMega proposait un morceau sans DRM, ces protections qui sont loin de faciliter l'accès à la musique.

Cette fois on nous apprend qu'une major serait intéressée pour vendre toute sa musique dans DRMs !

Curieux, je me rends sur le site de VirginMega, avec mon beau navigateur Opera sur mon super système d'exploitation openSUSE (10.2) Linux et j'obtiens le message d'accueil suivant :

Les navigateurs adaptés au surf sur ce site ne sont pas encore disponible pour le système d'exploitation que vous utilisez.
Voici la liste des plate-formes permettant d'accéder à toutes les fonctionnalités du site :
- Plateforme Windows (98 SE et supérieur)


Il arrive que les sites ne reconnaissent pas Opera car le développeur web n'a pas forcément connaissance de l'existence du navigateur et le bloque pour cette raison. Pourtant le navigateur est l'un de ceux qui respecte le plus les standards.
Mais si je teste avec Firefox (plus utilisé qu'IE dans certaines contrées) j'obtiens exactement le même résultat awww

Je fais donc un click-droit sur le site et vais dans "Edit site preferences" qui m'ouvre une fenêtre avec plusieurs onglets.
Je vais dans l'onglet "Network" et à "Browser identification" je choisi "Mark as Internet Explorer" qui fait passer Opera pour un navigateur Internet Explorer 6 sous Windows XP.
Je recharge la page et là : miracle ! Le navigateur fonctionne parfaitement avec Opera. Les animations Flash, les liens Javascript et même les bandes annonces, aucun problème.

Seulement si on désire écouter un extrait audio on obtient le message suivant :

Bloquer la totalité d'un site aux utilisateurs de Linux pour l'unique raison que ceux-ci sont considérés comme des "pirates écoutant de la musique dans des formats ouverts" alors que l'on prétends s'orienter vers le sans-DRM, il fallait oser :furious:

C'est drôle

, , , ...

quoique tout est relatif :smile:

FnacMusic met en vente deux morceaux sans DRM
Les DRM énervent tellement les consommateurs que l'absence de DRM devient un argument de vente.
Fnac musique sans DRM pub

Google plie et collabore avec les éditeurs belges
Cette nouvelle fait suite à une précédente affaire.

En outre, Copiepresse demande à Google de référencer de nouveau les journaux belges francophones tels que Le Soir, L'Echo ou La Libre Belgique sur son moteur de recherche. Mais le californien n'a pas encore répondu à ce jour.


Les principaux éditeurs d'antivirus dénoncent l'attitude de Microsoft
En effet Microsoft fait tout pour ne pas dévoiler le fonctionnement interne de son futur système d'exploitation, ce qui est nécessaire aux firmes d'antivirus pour développer des logiciels compatibles Vista...
On pourrait penser que Microsoft a honte du code de Vista, surtout qu'on en a entendu beaucoup de mal. La vérité serait que Vista intègre tout un tas de protections qui pourraient être jugées comme anti-concurentielles (à l'ouest rien de nouveau)

Windows XP SP3 désormais attendu pour 2008
Ou comment Microsoft incite ses consommateurs à passer à Vista au lieu d'attendre le prochain service pack XP :whistle:

La citation du mois :

IE7 est la 'victime' de cette faille mais pas la cause


-+- Bernard Ourghanlian, Chief Technology & Security Officer de Microsoft France à propos d'une faille touchant IE7 -+-
(un vrai guide de la mauvaise foi)

Faut avouer que je me marre rarement autant en lisant les news :D