Skip navigation.

devloop :: blog

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

Posts tagged with "cryptographie"

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.

Inforensique en vrac

, , , ...

C'est la classe : ma solution du challenge DFRWS 2008 a été citée sur le Computer Forensic Blog.

Mais ce n'est rien comparé au travail des développeurs de Volatility sur l'analyse de la mémoire des systèmes Linux.
Ils ont apporté des modifications à un outil de RedHat nommé Crash qui permet ainsi d'extraire de l'image de la mémoire la liste des processus, fichiers ouverts, connexions en cours, points de montages utilisés et bien plus encore.

Ils ont ensuite amélioré Volatility pour qu'il gère les images de mémoire physique Linux.
On retrouve les fonctionnalités qui ont été ajoutées à Crash ainsi que des possibilités supplémentaires pour extraire certains éléments de la mémoire : mémoire d'un processus particulier, paquets réseau...
Cela leur a par exemple permis de retrouver la communication FTP que je n'ai pas trouvé durant ma recherche :smile:

Volatility peut aussi être utilisé comme module dans PyFlag et au vue des captures d'écran ça a l'air impressionant ^_^


Changeons de sujet avec cet article de Dark Reading qui nous apprend que Bruce Schneier et un groupe de chercheurs auraient réussi à détecter la présence des systèmes de fichiers cachés par TrueCrypt.
Je m'attendais à lire des révélations croustillantes sur un oubli d'implémentation ou une faiblesse cryptographique, en réalité ils se sont seulement basés sur les traces d'accès laissés sur un système Windows qui montraient l'existence de fichiers sur une partition qui n'apparait pas dans la table des partitions.
Ils se sont notamment basés sur l'analyse des fichiers .lnk et des listes MRU (Most Recently Used) présentes dans le registre de Windows.

Je trouve que l'équation
présence des exécutables TrueCrypt + preuve de l'existence d'une partition qui n'y est plus = preuve de l'existence d'une partition cachée
est un peu rapide et est loin d'être fiable.
C'est ce que j'ai tendance à appeler le "principe de l'entourloupe", à savoir bien que ces outils soient utiles, leur simple présence génère la suspicion chez la personne qui analyse le système. C'est pour cela que je regarde toujours avec un peu de recul le principe du déni plausible.

C'est en particulier vrai avec des outils spécialisés comme Stegeek, 2c2, 4C ou encore Elettra paru dans le dernier Phrack.
Ca me parait moins vrai pour les partitions cachées, surtout que la technique utilisée dans l'article n'est pas liée à TrueCrypt et pourrait même déjouer une méthode faite maison. Bref la faille n'est pas dans TrueCrypt mais plus du côté de l'utilisateur qui devrait prendre différentes mesures pour dissimuler son activité (et s'il utilise TrueCrypt il doit bien être capable de le faire p: )

ThumbStego

, , , ...

Je viens de tester ThumbStego (pour "Thumbnail Steganography"), un nouvel outil permettant de dissimuler des données dans des images.
Jusque là, rien de bien nouveau, il existe un tas d'outils qui permettent de cacher de l'information dans des images. Là où ce logiciel se démarque des autres c'est que contrairement à la majorité (et pngstego dont j'avais parlé en fait partie), ThumbStego ne se base pas sur la méthode LSB qui consiste à utiliser le bit de poids faible de chaque octet.

La description du logiciel, telle que trouvée sur PacketStorm, est la suivante :

Thumbnail steganography creates a thumbnail from a source image and stores data in it by altering the color channels. To decipher the data, a new thumbnail is made from the original image and the differences between the pixels are calculated. This is intended to increase complexity of automated deciphering of images containing extra (steganographied) data. It requires both the original and the thumbnail to decipher. The original works like a key to unlock the thumbnail.

Je ne saurais pas expliquer en détail le fonctionnement de cet outil, les courageux se pencheront vers les sources en Java. Ce qu'il faut retenir c'est principalement la génération d'une image miniature de l'originale, créée de façon à ce que l'originale ait un rôle de masque pour extraire les données cachées :smile:

Pour utiliser le logiciel, vous aurez besoin d'une version récente de Java sans quoi un message d'erreur de version vous jette, ou alors vous devrez recompiler le programme. De mon côté j'ai opté pour la première solution et ait installé la version 1.6 de Java (j'avais la 1.5).
Armé d'une image et d'un fichier texte, le me suis placé dans le répertoire bin (une fois l'archive de ThumbStego décompressée) et ait tappé la commande suivante :
java -cp . tstego/TStego E sdreams.jpg out.png 17941-8.txt S

Ceci m'a généré l'image miniature out.png... à la regarder avec un éditeur hexadécimal, rien ne se laisse deviner que ce fichier cache des données à sa façon.

L'image et sa miniature :


Pour extraire les données :
java -cp . tstego/TStego D sdreams.jpg out.png secret.txt

Et on découvre alors qu'une vingtaine de fables de La Fontaine y étaient dissimulées :smile:

Pour résumer ThumbStego utilise un concept très intéressant et comble du bonheur offre un ratio qui a l'air pas mauvais du tout.
Certes je n'ai pas fait de calcul, mais l'option S permet de générer une miniature la plus petite possible en prenant en compte la quantité de données à cacher. Avec une miniature réduite de seulement 1%, il est évident que le ratio est bien plus intéressant qu'avec les outils standards.
Rien que dans mon exemple, le texte fait environ 29% de la taille de la miniature en étant loin de forcer les capacités du soft... avec d'autres outils on aurait eu un ratio de 12.5% (1/8 pour le LSB).
On regrette juste que le logiciel soit un peu lent (de grosses boucles dans le code) et un peu casse-tête à lancer (sous la forme d'un jar ce serais parfait).
Dans tous les cas, à garder sous la main :smile:

Mise à jour: les nouvelles versions sont maintenant sous la forme d'un jar avec une interface graphique :smile:

En vrac

, , , ...

User-Friendly.org a fêté ses 10 ans hier. Ce comic-strip en ligne dont j'avais déjà parlé est mis à jour quotidiennement. Donc chapeau bas et longue vie à UF :smile:

Le NIST et la NSA derrière un standard de cryptographie backdooré ? Deux cryptographes se sont penchés sur un standard de génération aléatoire de nombres qui avait été demandé par la NSA et approuvé par le NIST. Ils ont relevé la présence de constantes dans l'algorithme "Dual_EC_DRBG" auxquelles pourraient bien correspondre d'autres constantes tenues secrètes qui permettrait à l'entité les possèdant de casser la sécurité de ce standard. Bruce Schneier en parle aussi.

Le dernier album de The Hives, "The Black and White Album"... il déchire tout :headbang:

J'en ai longtemps révé... et ça va se réaliser :yes:
Tim Burton va faire une adaption ciné d'Alice in Wonderland !!!
D'après Wikipedia :

In November 2007, Burton signed a deal with Disney to direct two 3-D films. The first will be an motion capture adaptation of Alice in Wonderland, which will finish filming by May 2008.


Vous pouvez aussi retrouver devloop :: blog sur archive.org

Créez une partition cachée sous Linux

, , , ...

Les systèmes d'exploitation les plus utilisés proposent tous à l'heure actuelle des solutions pour chiffrer les partitions ou l'ensemble d'un disque.
L'inconvénient de ces systèmes est que la présence des données chiffrées est généralement bien visible, par exemple par le biais d'un fichier de montage (/etc/crypttab ou /etc/cryptotab sous openSUSE) et de la table des partitions permettant au système de savoir avec quel algorithme il doit déchiffrer les partitions chiffrées et sur quelle partie du disque.

Dans cet article je vais vous expliquer comment mettre en place une partition cachée qui ne sera visible ni dans la table des partitions ni décrite dans un fichier de configuration.
A l'heure actuelle, TrueCrypt propose un système de ce type mais nous utiliserons ici une méthode plus basique en nous servant de la commande losetup pour la gestion des périphériques de boucle (/dev/loop*) et de cryptsetup qui permet créer des volumes dm-crypt.

Le principe est le suivant : sur un disque dur nous allons créer une partition visible qui prendra la moitié de l'espace. Ensuite sur le reste de l'espace (tout l'espace libre restant) nous placerons notre partition chiffrée :smile:

Créer une partition cachée sur un disque dur

Dans l'exemple qui suit le disque fait une taille de 50Mo. La partition visible fera 20Mo, le reste sera pris par notre partition secrète. A vous d'adapter les commandes en fonction de votre disque et des systèmes de fichiers que vous désirez.

On partitionne le disque à l'aide de cfdisk pour créer notre partition de 20Mo. Il est important que cette partition soit placée au début du disque :
cfdisk /dev/hda1

On récupère l'adresse de la fin de cette partition (en octets) à l'aide de la commande parted :
parted /dev/hda unit B print

Dans mon cas, la fin de la partition est à l'offset 16450559. Nous fixerons alors le début de notre partiton cachée à 16450600 (arrondir au supérieur).
On formate la partition visible en ext2, on la monte et on crée un fichier pour tester :
mkfs.ext2 /dev/hda1
mount -t ext2 /dev/hda1 /mnt/hda1
echo abcd > /mnt/hda1/truc

Passons maintenant à notre partition chiffrée. Pour ne pas faire de bétises il faut trouver le nom d'un périphérique loop non utilisé. Ceux en cours d'utilisation peuvent être obtenus par la commande suivante :
losetup -a

Dans mon cas, loop0 est déjà utilisé donc je me rabats sur loop1 :
losetup -o 16450600 /dev/loop1 /dev/hda

On crée ensuite le "mapper" qui se chargera du chiffrement. Dans mon cas il s'appelle "toto" et utilise l'algorithme par défaut (AES128). Pour plus d'infos, lisez la page de manuel de cryptsetup. Le programme vous demandera de saisir le mot de passe pour le chiffrement.
cryptsetup create toto /dev/loop1

On vérifie que notre mapper a bien été créé à l'aide de "dmsetup ls" puis on peut créer et jouer avec notre partition :
mkfs.ext2 /dev/mapper/toto
mount /dev/mapper/toto /mnt/test
echo test > /mnt/test/truc
umount /mnt/test

Quand on a fini on démonte le mapper et le périphérique de boucle :
cryptsetup remove toto
losetup -d /dev/loop1

Si on effectue une recherche sur le disque dur, on trouve une occurence pour "abcd", 0 pour "test" et une seule pour "truc". Notre partition est bien chiffrée et invisible :smile:

Seul problème, pour ne pas à avoir à mémoriser les commandes et l'offset de la partition, il est préférable de créer un script de montage et un autre du démontage. A vous de faire marcher votre imagination pour dissimuler ces scripts :smile:

La vrai fausse backdoor dans le chiffrement des disques durs par PGP

, , ,

Il y a quelques jours, le blog Securology a publié un article traitant d'une fonctionnalité peu connue du logiciel de chiffrement de disque PGP Whole Disk Encryption (WDE) qui a provoqué quelques réactions "trollesques"... :troll:

Avant d'entrer dans le vif du sujet, il est bon de connaître à quoi sert PGP WDE et un résumé simple de son fonctionnement.
PGP Whole Disk Encryption permet, comme son nom l'indique, de chiffrer la totalité d'un disque dûr, c'est à dire : les différentes partitions, le (ou les) système(s) d'exploitation et le secteur de boot (Master Boot Record).
Quand un poste disposant de cette technologie est allumé, il boote d'abord sur du code de PGP qui va demander la saisie d'un mot de passe au clavier par l'utilisateur.
Par une suite de différents calculs cryptographiques, ce mot de passe va permettre au final le déchiffrement des données.

Dans les étapes utilisées pour arriver au lancement du système d'exploitation, la première est la déchiffrement d'une clé qui a été cryptée à l'aide du mot de passe de l'utilisateur.
Cette méthode est très utilisée, notamment pour la cryptographie à clé publique : pour éviter que la clé secrète soit compromise en cas d'intrusion et/ou de vol de données, celle-ci n'est pas stockée en clair sur le disque mais stockée chiffrée par un algorithme de chiffrement symétrique.
Ce procédé est nommé S2K / K2S (string-to-key et vice-versa), il est par exemple documenté dans la RFC 2440 : OpenPGP Message Format (chapitres 3.6.*, c'est dans la même RFC que l'on trouve une explication sur le Radix-64 :wink: )

On pourrait penser que la clé déchiffrée est celle utilisée pour le déchiffrement, mais il n'en est rien. Il y a une seconde étape qui permet à partir de cette clé d'accèder à la clé maître (master key) avec laquelle le chiffrement a été utilisé.
L'objectif de ce second procédé et de permettre à différents utilisateurs de déchiffrer le disque, chacun utilisant un mot de passe différent (si j'ai bien tout compris :wink: )

Maintenant que vous connaissez (vaguement) le fonctionnement du système, il est temps de parler de la fonctionnalité baptisée "Whole Disk Encryption (WDE) Bypass".
Le nom est celui donné par PGP et est suffisament explicite : il permet de passer oûtre la saisie d'un mot de passe pour déchiffrer les données.

A quoi sert exactement cette fonctionnalité ? Elle permet aux administrateurs de faire redémarrer les machines dont le disque est chiffré par WDE.
Partons du principe que vous êtes un administrateur d'un parc réseau avec des machines ultra-sécurisées et que vous avez besoin d'effectuer différentes taches qui seront validées lors du redémarrage de la machine.
Vous lancez l'opération et vous attendez sagement que vos machines redémarrent pour continuer à travailler. Sauf que... les machines ne redémarrent pas !
En effet le système d'exploitation ne s'est pas lancé car personne n'est devant le poste pour saisir le mot de passe de déchiffrement et par conséquent la couche réseau de l'OS n'est pas disponible. Vous voilà obligé de faire le tour des machines et de saisir chaque mot de passe de déchiffrement pour remettre votre réseau en marche :insane:

C'est là qu'intervient la fameuse fonctionnalité "bypass". Quand elle est activée, elle va stocker sur le disque une nouvelle clé de chiffrement dérivée de la master key ainsi qu'un flag disant à WDE d'utiliser cette clé automatiquement au prochain démarrage du poste. Cette clé est cryptée par le procédé S2K par un mot de passe fixe (valeur hexadécimale 0x01).

Donc :
  • l'administrateur lance ses taches sur les machines
  • il active le WDE Bypass
  • il redémarre les postes
  • WDE utilise la clé de bypass pour démarrer les postes
  • WDE supprime les données de bypass qui ont été placées sur le disque
  • les postes sont démarrés et accessibles par le réseau :smile:

Sur le principe c'est plutôt bien trouvé et c'est une fonctionnalité qui est semble très appréciée dans les entreprises (on peut comprendre). Le problème c'est que l'on baisse la sécurité du chiffrement à chaque utilisation du mode bypass : il suffit qu'un intrus subtilise une machine entre le moment de l'éteignage et celui du redémarrage pour disposer d'un disque sur lequel sont présentes toutes les informations nécessaires pour déchiffer le disque.

Le débat faire rage sur Slashdot entre ceux qui considèrent qu'il s'agit d'une backdoor et ceux qui défendent qu'il s'agit d'une fonctionnalité tout à fait normale.
En réalité quand j'essayais de comprendre le fonctionnement de tout ça, ça n'a pas été évident de trouver les commentaires de ceux qui se posaient les vrais questions sur Slashdot. Il faut dire que tout les articles sur le sujet sont en anglais et que ça ne facilite pas la tâche... heureusement c'est de l'écrit (j'ai eu l'occasion de parler anglais cet après midi et c'était l'enfer, en plus c'était une discussion avec un chinois :faint: )

Après avoir pesé le pour et le contre, mon opinion personnelle est que non, ce n'est pas une backdoor.
D'abord, bien que peu expliquée, cette fonctionnalité était citée dans la documentation. De plus PGP affiche une position claire sur cette fonctionnalité et a réagit en postant un commentaire sur le blog de l'auteur de l'article avant de donner des explications publiques.

Cependant cette fonctionnalité baisse considérablement la sécurité générale du chiffrement. Comme toujours en cryptographie, le niveau de sécurité d'un système est équivalent à celui de son mayon le plus faible. Ici on peut imaginer un malware qui active le WDE Bypass en vue d'une prochaine attaque physique, ou encore un code qui modifiera le fonctionnement du WDE... mais là on s'écarte sans doute trop du sujet.

Dans tous les cas pour activer cette fonctionnalité il faut un "cryptographic access" aux données, c'est à dire avoir des droits d'utilisateur sur la machine, c'est à dire... avoir accès aux données en clair.

En fin de compte ce qui gêne c'est que le WDE Bypass pourrait tout aussi bien être utilisé en douce, et q'une clé spéciale soit intégrée à l'installation du logiciel, chiffrée à l'aide d'une passphrase connue seulement par une certaine agence de sécurité nationnale :wink:
Bref on en revient à la confiance que l'on donne aux développeurs des logiciels que l'on utilise. Mais c'est un procédé intéressant et je comptais bien vous faire profiter de ces articles :smile:

Explication (simplifiée) de PGP WDE sur le site officiel (vidéo présente)
Un second article de Securology en réponse aux informations apportées par un représentant de PGP
Le premier article

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'
January 2009
S M T W T F S
December 2008February 2009
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31