RE: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arriveaux USA ?
Est-ce que le scénario suivant est envisageable? 1) charger un programme dans une carte CUDA ou ATI Radeon 28XX avec une master key piratée qui termine le HDCP (cf DVDFab par exemple) 2) puis encodage à la volée du flux reçu 3) renvoi dans le host En gros une carte graphique qui se fait passer pour un écran compatible HDCP. Sinon, il y a aussi un mode dans les processeurs Intel qui s'appelle System Management Mode. Il y a une zone masquée par le chipset (maintenant le contrôleur mémoire) qui fait que l'OS ne voit pas cette zone. L'entrée dans ce mode n'est possible que par une IRQ particulière SMI. Les programmes SMM sont en 16 bits mais ont accès à TOUT. Le BIOS peut y loger un programme de gestion des ventilateurs par exemple. Le BIOS peut aussi bloquer l'ouverture de la zone, des fois que Windows veuille y mettre des choses. Mais bon cette technique ne permet que de récupérer ce que l'on veut quand on veut (attention programmation SMM pas piquée des vers et outils de compil spéciaux) mais l'attaque frontale d'un algo de crypto ne me semble jamais judicieuse. C'est juste pour partager l'info... Pour contourner il ne faut pas se focaliser sur le verrou -Message d'origine- De : owner-fr...@frnog.org [mailto:owner-fr...@frnog.org] De la part de Pierre Col Envoyé : dimanche 24 octobre 2010 07:16 À : Thomas SOETE; frnog@frnog.org Objet : Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arriveaux USA ? Thomas SOETE a écrit : Il reste donc f() l'inconne qui transforme A et B pour donner C. Tu soumet l'idée que f peut changer a chaque film, pourquoi pas, ça veut juste dire que f() doit transiter un jour ou l'autre et que donc on peut l'intercepter. Tu raisonnes mal : f() ne transite jamais. Tu nous dit que le flux MPEG4 transite quelquepart qui n'est pas récupérable par logiciel. Donc il transite possiblement dans le noyau pour atterrir dans la carte graphique pour s'y faire décoder Oui. On a donc trois axes de recherches : - un pilote falsifié de la carte graphique dumpant le flux qui lui est envoyé - un pilote noyau, celui-ci résidant dans le noyau il peut lire tout ce qui transite et donc dumper le flux mpeg4 - une machine virtuelle dans laquelle on fait tourner le windows, ce qui permet de voir toutes les E/S possible de l'OS et donc dumper le flux qui arrivera un jour ou l'autre sur la carte video Non, sur Windows un logiciel de lecture vidéo peut se prémunir de tout cela. Là encore, tu affirmes des choses sur un sujet que visiblement tu ne maîtrises pas. Essaie de commencer tes phrases par j'imagine que ou de mettre du conditionnel plutôt que il peut lire ou qui permet , ce serait plus correct si tu es un chercheur avec une démarche scientifique :-) Pour travailler dans un laboratoire de recherche d'informatique En étant chercheur ou ingénieur ? et regardant de près les problématiques de sécurité informatiques, je peux te dire qu'il n'y a _aucun_ algorithme sur à partir du moment où il tourne sur le cpu de la machine. Wow. Tu parles ausssi du CPU qui est dans ta carte bancaire, là ?? Les seuls algo qui tiennent la route sont les algo de chiffrement reposant sur des problèmes mathématiques difficiles a résoudre. On peut parler de plusieurs centaines de milliers d'années pour explorer un espace de 256 bits. Tu es gentil, le sujet de mon mémoire de fin d'étude à l'ENSEIHT en 1986 - car je suis ingénieur en informatique et maths appliquées, je suis tombé dans le marketing ensuite - c'étai la preuve de protocoles cryptographiques, alors j'ai probablement lu des papiers sur les travaux de Rivest, Shamir et Adleman bien avant toi :-) Si tu veux t'y mettre sérieusement, commence déjà par : http://fr.wikipedia.org/wiki/Rivest_Shamir_Adleman Donc si on est au milieu et qu'on a pas la clé, récupérer les données est très difficile (on a l'exemple de TrueCrypt qui a resisté à la NSA...). Mais comme là on se trouve a lextrémité du tunnel avec 100% des données, c'est raté. Si tu veux occuper ton labo, cherche à casser PUMit, mais tu y perdras un temps qui serait mieux employer à trouver des trucs trouvables :-) Avec une grande capacité de stockage, on pourrait même imaginer faire tourner le windows dans un émulateur, enregistrer 100% des instructions machines executées pour pouvoir rejouer a sa guise le film. Là tu as raison, mais je n'ai jamais dit qu'un film n'était pas rejouable. reste à construire cet émulateur et à l efaire tourner comme tu le dis :-) Comme dit dans mes précédent mails, c'est pas simple mais pas impossible. On est d'accord : et si ça prend 3 ans et coûte 1 millino d'euros, ce n'est un souci pour personne :-) La seule tentative avec les contenu HD était l'HDCP où on déportait le flux chiffré jusqu'à l'écran. Il est donc impossible au niveau de la machine de récupérer le flux non chiffré. Or l'histoire a montré certaines clés sont tombées puis la master-key rendant la protection nulle. C'est
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arriveaux USA ?
Stephane Kanschine wrote: Ou que toi, tu n'as pas regardé assez bas (système). C'est beau d'avoir des illusions, garde les :-) OK, je laisse tomber, vous êtes plus fort en décodage vidéo que les meilleurs experts mondiaux sur le sujet. Vous devriez en faire un métier, ça paye vraiment bien, surtout aux USA :-) -- Pierre --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arriveaux USA ?
On est pas plus fort que les experts mondiaux, on dit juste qu'en informatique si un logiciel sait faire A+B = C, un autre peut le faire. Ça peut prendre plusieurs mois pour étudier la routine de décodage intégrée à pumit mais ... c'est faisable. Et dans le pire des cas, si quelqu'un veut récupérer le flux pour le redistribuer, il ira au plus facile : dumper le flux DVI qui lui n'est pas protégé et le recompressera. Ça c'est faisable dans l’immédiat. Je te l'accorde que ce n'est pas à la portée du premier quidam et refaire de la compression à la volée n'est pas évident sans une certaine puissance de calcul (ou de stockage pour récupérer le flux brut DVI). Mais ça peut permettre de récupérer un fichier avec une qualité équivalente à l'original. De toute façon, si ça se déploie à grande échelle, ça subira le même sort que CSS AACS BD+ ... (j'ai l'impression de me répéter là ...). Thomas Le 23 octobre 2010 15:15, Pierre Col p...@9online.fr a écrit : Stephane Kanschine wrote: Ou que toi, tu n'as pas regardé assez bas (système). C'est beau d'avoir des illusions, garde les :-) OK, je laisse tomber, vous êtes plus fort en décodage vidéo que les meilleurs experts mondiaux sur le sujet. Vous devriez en faire un métier, ça paye vraiment bien, surtout aux USA :-) -- Pierre --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arriveaux USA ?
Thomas SOETE wrote: On est pas plus fort que les experts mondiaux, on dit juste qu'en informatique si un logiciel sait faire A+B = C, un autre peut le faire. Non. Un premier logiciel fait C = A - B. Il fait ce split de B contenat 99% du contenu et C contenant 1% du contenu selon un algo aléatoire qui, lui-même, dépend aléatoirement de A et de A seul. Un autre logiciel, à partir de ces infos aléatoires dépendant alors de B et C, sait refaire A = B + C. Pour autant, il faudraitt quelques années à n'importe quel autre logiciel pour faire A = B+C. Et de surcroît, même si au bout de quelques années un algo sachant comment faire A = B + C était trouvé, l'auteur de l'algo ne saurait ni faire A' = B' + C' ou A = B + C. Suf à y repasser quelques années pour chaque. L'intérêt du système est qu'il n'y a pas de clé dont la fuite compromettrait tout un catalogue. Ça peut prendre plusieurs mois pour étudier la routine de décodage intégrée à pumit mais ... c'est faisable. Amusez-vous : ça vaut le coup, si c'est bientôt déployé à grande échelle avec plein de films de majors... -- Pierre --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arriveaux USA ?
Tout comme BD+ (http://en.wikipedia.org/wiki/BD%2B) = owned Tu as A, la partie qui est contenue sur le disque et B qui est la partie qui est téléchargée on demand. Tu as f, la méthode qui fait f(A,B) = C. Si on a pas B, ça peut être compliqué (on peut imaginer que B soit une clé de chiffrement par exemple, comme dans le satellite). Or, on a sur d'avoir A et B (au moins sur un PC, car A est sur le disque et il est possible d'intercepter B lors de son transfert, même s'il transite de manière chiffrée vu que la machine le déchiffre un jour ou l'autre). Il reste donc f() l'inconne qui transforme A et B pour donner C. Tu soumet l'idée que f peut changer a chaque film, pourquoi pas, ça veut juste dire que f() doit transiter un jour ou l'autre et que donc on peut l'intercepter. Mais tout ceci est bien complexe et comme tu dis peut prendre des années à analyser (soit, on a bien mis 4 ans a casser la PS3...). Donc il faut trouver un moyen plus rapide. Tu nous dit que le flux MPEG4 transite quelquepart qui n'est pas récupérable par logiciel. Donc il transite possiblement dans le noyau pour atterrir dans la carte graphique pour s'y faire décoder (supposition, il y a d'autres possibilités). On a donc trois axes de recherches : - un pilote falsifié de la carte graphique dumpant le flux qui lui est envoyé - un pilote noyau, celui-ci résidant dans le noyau il peut lire tout ce qui transite et donc dumper le flux mpeg4 - une machine virtuelle dans laquelle on fait tourner le windows, ce qui permet de voir toutes les E/S possible de l'OS et donc dumper le flux qui arrivera un jour ou l'autre sur la carte video Pour travailler dans un laboratoire de recherche d'informatique et regardant de près les problématiques de sécurité informatiques, je peux te dire qu'il n'y a _aucun_ algorithme sur à partir du moment où il tourne sur le cpu de la machine. Les seuls algo qui tiennent la route sont les algo de chiffrement reposant sur des problèmes mathématiques difficiles a résoudre. On peut parler de plusieurs centaines de milliers d'années pour explorer un espace de 256 bits. Donc si on est au milieu et qu'on a pas la clé, récupérer les données est très difficile (on a l'exemple de TrueCrypt qui a resisté à la NSA...). Mais comme là on se trouve a l’extrémité du tunnel avec 100% des données, c'est raté. Avec une grande capacité de stockage, on pourrait même imaginer faire tourner le windows dans un émulateur, enregistrer 100% des instructions machines executées pour pouvoir rejouer a sa guise le film. Comme dit dans mes précédent mails, c'est pas simple mais pas impossible. La seule tentative avec les contenu HD était l'HDCP où on déportait le flux chiffré jusqu'à l'écran. Il est donc impossible au niveau de la machine de récupérer le flux non chiffré. Or l'histoire a montré certaines clés sont tombées puis la master-key rendant la protection nulle. Sur ce, j'ai encore du pain sur la planche :) Le 23 octobre 2010 18:21, Pierre Col p...@9online.fr a écrit : Thomas SOETE wrote: On est pas plus fort que les experts mondiaux, on dit juste qu'en informatique si un logiciel sait faire A+B = C, un autre peut le faire. Non. Un premier logiciel fait C = A - B. Il fait ce split de B contenat 99% du contenu et C contenant 1% du contenu selon un algo aléatoire qui, lui-même, dépend aléatoirement de A et de A seul. Un autre logiciel, à partir de ces infos aléatoires dépendant alors de B et C, sait refaire A = B + C. Pour autant, il faudraitt quelques années à n'importe quel autre logiciel pour faire A = B+C. Et de surcroît, même si au bout de quelques années un algo sachant comment faire A = B + C était trouvé, l'auteur de l'algo ne saurait ni faire A' = B' + C' ou A = B + C. Suf à y repasser quelques années pour chaque. L'intérêt du système est qu'il n'y a pas de clé dont la fuite compromettrait tout un catalogue. Ça peut prendre plusieurs mois pour étudier la routine de décodage intégrée à pumit mais ... c'est faisable. Amusez-vous : ça vaut le coup, si c'est bientôt déployé à grande échelle avec plein de films de majors... -- Pierre --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arriveaux USA ?
On 23/10/2010 21:12, Thomas SOETE wrote: Tu nous dit que le flux MPEG4 transite quelquepart qui n'est pas récupérable par logiciel. Donc il transite possiblement dans le noyau pour atterrir dans la carte graphique pour s'y faire décoder (supposition, il y a d'autres possibilités). On a donc trois axes de recherches : - un pilote falsifié de la carte graphique dumpant le flux qui lui est envoyé - un pilote noyau, celui-ci résidant dans le noyau il peut lire tout ce qui transite et donc dumper le flux mpeg4 - une machine virtuelle dans laquelle on fait tourner le windows, ce qui permet de voir toutes les E/S possible de l'OS et donc dumper le flux qui arrivera un jour ou l'autre sur la carte video D'après les propos que tient Pierre Col je pense fortement qu'il parle de la fonctionnalité PVP (Protected Video Path) incluse dans Windows et qui est notamment utilisée lors de la lecture de Blu-ray protégés. En gros, le principe est de faire transiter les flux dans des processus et des espaces mémoires protégés (le noyau étant le gardien), qu'il n'est possible d'accéder que sous réserve de remplir des conditions extrêmement strictes. Par exemple, même un administrateur avec tous les droits ne peut pas y accéder, et d'une manière générale le seul code qui peut y accéder est du code signé et vérifié par certificat (mais ce n'est pas la seule condition). Ça inclut le code s'exécutant en mode noyau. Je pense que la méthode employée consiste à empêcher un pilote non signé de tourner en même temps que le PVP est utilisé. Par ailleurs il est absolument certain que Windows refusera de remettre un flux protégé à un pilote de carte graphique non signé. Exit donc tes solutions 1 et 2. N'importe qui avec un PC sous Windows 7 peut faire l'expérience : essayez de faire joujou avec le processus « audiodg.exe », qui représente une partie du moteur audio de Windows, avec un débuggeur ou tout autre outil un peu intrusif. Impossible : audiodg.exe est un processus « protégé » car il est susceptible de transporter de l'audio provenant d'un Blu-ray chiffré (ou de toute autre application utilisant le PAP). Aussi, l'application peut exiger que le flux ne puisse quitter la machine que sous forme chiffrée par HDCP, et l'OS le garantit. Exit donc ta solution 3. Un truc qui m'a toujours sidéré c'est que ce système est une énorme usine à gaz (les schémas sur le site de Microsoft donnent le mal de crâne) qui touche énormément de composants critiques du système d'exploitation. Vu le nombre de « tuyaux » divers et variés par lequel ces données protégées doivent passer (entre l'application et la carte graphique en passant par le framework de rendu ça fait une trotte), le truc a du couter les yeux de la tête en termes de conception, test et développement. Je trouve hallucinant que Microsoft puisse dépenser une telle montagne de fric et accepter de faire des modifications aussi intrusives en plein cœur de son système d'exploitation juste pour les petits caprices des studios Hollywoodiens. Ils auraient pu monter un projet semblable pour améliorer la sécurité (la vraie) de leur système, pour améliorer les performances, ou que sais-je… mais ils ont préféré céder au chantage d'un cartel d'entreprises. Quel gâchis. Bon, évidemment, Thomas Soete a raison : même une telle forteresse n'est pas infaillible, c'est mathématiquement impossible. On peut par exemple imaginer patcher le binaire du kernel pour faire sauter des protections. Mais Microsoft ont tout fait pour que ce soit extrêmement difficile. Et en fait, je n'ai jamais entendu parler de quelqu'un qui y soit arrivé. Probablement parce qu'il n'y a jamais vraiment eu de demande : pour copier les flux contenus sur des Blu-ray il s'est avéré plus simple (et plus propre) de cracker AACS que PVP. Même chose pour HDCP. Donc au final, comme AACS et HDCP sont maintenant crackés, la seule technologie de protection encore debout est PVP/PAP. Paradoxalement, cette dernière ne sert plus à rien vu que les autres maillons de la chaine sont cassés : il suffit de copier le flux en amont ou en aval de PVP, qui au final ne protège que du vent. Encore une fois : quel gâchis. Il est évident que la technologie que défend Pierre Col ne fera que répéter l'histoire si elle se répand suffisamment pour atteindre le seuil critique qui intéressera les crackers. Je ne vois absolument pas pourquoi elle ne subirait pas le même sort que le Blu-ray. Comme l'a si justement rappelé Thomas Soete, même des technologies extrêmement compliquées et obfusquées comme BD+ ont fini par se faire cracker tôt ou tard. C'est juste inéluctable : si une machine est capable de sortir A, alors on pourra forcément lui faire copier A. C'est la loi de la nature, et c'est tant mieux ! -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 20 41 09 29 smime.p7s Description: S/MIME Cryptographic Signature
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arriveaux USA ?
Euh juste comme ça pour l'AACS on connaissait son fonctionnement un simple utilitaire comme backupdvd c'est le plus connu (ancien) http://en.wikipedia.org/wiki/BackupHDDVD permettait de décrypter un disque. Ce qui manquait c'était bien sur la ou les clefs mais ça on pouvait l'obtenir via un dump. Par contre c'était fastidieux maintenant avec la récupération de la master c'est finger in the nose. Pour revenir à tes méthodes ce que l'on a juste besoin de récupérerle flux.Un simple dump sur les I/O de win devrait normalement suffire. je ne pense pas que leur solution utilise PVP comme dit Pierre on peut l'implanter dans une box. Pour repondre à tes interrogations c'est simple microsoft a développé ça pour trois raisons. La première obliger les concepteur/distributeurs a acheter et intégrer sa solution. La deuxième verrouiller le marché comme d'hab, il vous faut un window (en plus récent vista ou 7) pour voir votre vidéo. Pas de mac et pas de linux. La troisème obliger et rassurer le marché n'oublions pas que c'est microsoft à coup de matraquage depuis des années a implanté dans la tête des distributeurs l'utilisation de DRM pour après leur vendre sa solution. Et couper l'herbe sous les pieds des constructeurs (sony le principal) qui implantaient leurs propres solutions. Mais on pollue énormément ce sujet n'oublions qu'au début on partait sur le fait que M6 n'avait pas de CDN. Donc avant de parler de solution de cryptage voyons déja comment amener correctement et dans les meilleures conditions le flux chez les clients. My 2 cents, Le Sat, 23 Oct 2010 22:06:23 +0200, e-t172 e-t...@akegroup.org a écrit: On 23/10/2010 21:12, Thomas SOETE wrote: Tu nous dit que le flux MPEG4 transite quelquepart qui n'est pas récupérable par logiciel. Donc il transite possiblement dans le noyau pour atterrir dans la carte graphique pour s'y faire décoder (supposition, il y a d'autres possibilités). On a donc trois axes de recherches : - un pilote falsifié de la carte graphique dumpant le flux qui lui est envoyé - un pilote noyau, celui-ci résidant dans le noyau il peut lire tout ce qui transite et donc dumper le flux mpeg4 - une machine virtuelle dans laquelle on fait tourner le windows, ce qui permet de voir toutes les E/S possible de l'OS et donc dumper le flux qui arrivera un jour ou l'autre sur la carte video D'après les propos que tient Pierre Col je pense fortement qu'il parle de la fonctionnalité PVP (Protected Video Path) incluse dans Windows et qui est notamment utilisée lors de la lecture de Blu-ray protégés. En gros, le principe est de faire transiter les flux dans des processus et des espaces mémoires protégés (le noyau étant le gardien), qu'il n'est possible d'accéder que sous réserve de remplir des conditions extrêmement strictes. Par exemple, même un administrateur avec tous les droits ne peut pas y accéder, et d'une manière générale le seul code qui peut y accéder est du code signé et vérifié par certificat (mais ce n'est pas la seule condition). Ça inclut le code s'exécutant en mode noyau. Je pense que la méthode employée consiste à empêcher un pilote non signé de tourner en même temps que le PVP est utilisé. Par ailleurs il est absolument certain que Windows refusera de remettre un flux protégé à un pilote de carte graphique non signé. Exit donc tes solutions 1 et 2. N'importe qui avec un PC sous Windows 7 peut faire l'expérience : essayez de faire joujou avec le processus « audiodg.exe », qui représente une partie du moteur audio de Windows, avec un débuggeur ou tout autre outil un peu intrusif. Impossible : audiodg.exe est un processus « protégé » car il est susceptible de transporter de l'audio provenant d'un Blu-ray chiffré (ou de toute autre application utilisant le PAP). Aussi, l'application peut exiger que le flux ne puisse quitter la machine que sous forme chiffrée par HDCP, et l'OS le garantit. Exit donc ta solution 3. Un truc qui m'a toujours sidéré c'est que ce système est une énorme usine à gaz (les schémas sur le site de Microsoft donnent le mal de crâne) qui touche énormément de composants critiques du système d'exploitation. Vu le nombre de « tuyaux » divers et variés par lequel ces données protégées doivent passer (entre l'application et la carte graphique en passant par le framework de rendu ça fait une trotte), le truc a du couter les yeux de la tête en termes de conception, test et développement. Je trouve hallucinant que Microsoft puisse dépenser une telle montagne de fric et accepter de faire des modifications aussi intrusives en plein cœur de son système d'exploitation juste pour les petits caprices des studios Hollywoodiens. Ils auraient pu monter un projet semblable pour améliorer la sécurité (la vraie) de leur système, pour améliorer les performances, ou que sais-je… mais ils ont préféré céder au chantage d'un cartel d'entreprises. Quel gâchis. Bon, évidemment, Thomas Soete a raison : même une telle forteresse n'est pas
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arriveaux USA ?
Thomas SOETE a écrit : Il reste donc f() l'inconne qui transforme A et B pour donner C. Tu soumet l'idée que f peut changer a chaque film, pourquoi pas, ça veut juste dire que f() doit transiter un jour ou l'autre et que donc on peut l'intercepter. Tu raisonnes mal : f() ne transite jamais. Tu nous dit que le flux MPEG4 transite quelquepart qui n'est pas récupérable par logiciel. Donc il transite possiblement dans le noyau pour atterrir dans la carte graphique pour s'y faire décoder Oui. On a donc trois axes de recherches : - un pilote falsifié de la carte graphique dumpant le flux qui lui est envoyé - un pilote noyau, celui-ci résidant dans le noyau il peut lire tout ce qui transite et donc dumper le flux mpeg4 - une machine virtuelle dans laquelle on fait tourner le windows, ce qui permet de voir toutes les E/S possible de l'OS et donc dumper le flux qui arrivera un jour ou l'autre sur la carte video Non, sur Windows un logiciel de lecture vidéo peut se prémunir de tout cela. Là encore, tu affirmes des choses sur un sujet que visiblement tu ne maîtrises pas. Essaie de commencer tes phrases par j'imagine que ou de mettre du conditionnel plutôt que il peut lire ou qui permet , ce serait plus correct si tu es un chercheur avec une démarche scientifique :-) Pour travailler dans un laboratoire de recherche d'informatique En étant chercheur ou ingénieur ? et regardant de près les problématiques de sécurité informatiques, je peux te dire qu'il n'y a _aucun_ algorithme sur à partir du moment où il tourne sur le cpu de la machine. Wow. Tu parles ausssi du CPU qui est dans ta carte bancaire, là ?? Les seuls algo qui tiennent la route sont les algo de chiffrement reposant sur des problèmes mathématiques difficiles a résoudre. On peut parler de plusieurs centaines de milliers d'années pour explorer un espace de 256 bits. Tu es gentil, le sujet de mon mémoire de fin d'étude à l'ENSEIHT en 1986 - car je suis ingénieur en informatique et maths appliquées, je suis tombé dans le marketing ensuite - c'étai la preuve de protocoles cryptographiques, alors j'ai probablement lu des papiers sur les travaux de Rivest, Shamir et Adleman bien avant toi :-) Si tu veux t'y mettre sérieusement, commence déjà par : http://fr.wikipedia.org/wiki/Rivest_Shamir_Adleman Donc si on est au milieu et qu'on a pas la clé, récupérer les données est très difficile (on a l'exemple de TrueCrypt qui a resisté à la NSA...). Mais comme là on se trouve a l’extrémité du tunnel avec 100% des données, c'est raté. Si tu veux occuper ton labo, cherche à casser PUMit, mais tu y perdras un temps qui serait mieux employer à trouver des trucs trouvables :-) Avec une grande capacité de stockage, on pourrait même imaginer faire tourner le windows dans un émulateur, enregistrer 100% des instructions machines executées pour pouvoir rejouer a sa guise le film. Là tu as raison, mais je n'ai jamais dit qu'un film n'était pas rejouable. reste à construire cet émulateur et à l efaire tourner comme tu le dis :-) Comme dit dans mes précédent mails, c'est pas simple mais pas impossible. On est d'accord : et si ça prend 3 ans et coûte 1 millino d'euros, ce n'est un souci pour personne :-) La seule tentative avec les contenu HD était l'HDCP où on déportait le flux chiffré jusqu'à l'écran. Il est donc impossible au niveau de la machine de récupérer le flux non chiffré. Or l'histoire a montré certaines clés sont tombées puis la master-key rendant la protection nulle. C'est pour cela qu'un système sans clé et à algorithme aléatoire basé seulement sur des propriétés de A, qui se retrouvent dans B, est incassable, et que son éventuel cassage pour un film n'en compromet aucun autre. -- Pierre --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] M6 replay depuis Bouygues Telecom : pourquoi on arriveaux USA ?
e-t172 a écrit : Exit donc tes solutions 1 et 2. Exit donc ta solution 3. Voilà. Un truc qui m'a toujours sidéré c'est que ce système est une énorme usine à gaz (les schémas sur le site de Microsoft donnent le mal de crâne) qui touche énormément de composants critiques du système d'exploitation. Vu le nombre de « tuyaux » divers et variés par lequel ces données protégées doivent passer (entre l'application et la carte graphique en passant par le framework de rendu ça fait une trotte), le truc a du couter les yeux de la tête en termes de conception, test et développement. J'imagine, mais Microsoft avait les moyens; maintenant cela existe. Je trouve hallucinant que Microsoft puisse dépenser une telle montagne de fric et accepter de faire des modifications aussi intrusives en plein cour de son système d'exploitation juste pour les petits caprices des studios Hollywoodiens. Vous n'ilmaginez pas l'argent que gagne Microsoft avec ses DRM et tout ce qui s'ensuit... -- Pierre --- Liste de diffusion du FRnOG http://www.frnog.org/