Hello les amis,

un petit édito rapido pour vous dire que tout roule mais que j’enchaine réunion sur réunion en cette fin de semaine. Du coup j’ai loupé plein de trucs dont la keynote d’Apple et je n’ai pas encore pu invoquer le Dieu du random pour le Nas. J’ai aussi un paquet de mails à la bourre donc si vous comptiez m’écrire ou que vous l’avez fait, soyez patients ou attendez la semaine prochaine.

En mon abscence, soyez fort ahahaha et prenez soin de vous !

Si vous avez encore une Nintendo NES dans un coin, c’est le moment de la dépoussierer car Raph a listé sur son site, toutes les explications nécessaires pour modifier « un peu » sa NES afin de lui donner une seconde jeunesse.

Au programme, vous apprendrez à

• Faire un reset de la console à distance
• Avoir du son en stéréo
• Reprogrammer une cartouche
• Désactiver la puce de blocage
• Mettre une jolie petite diode bleue bien tendance
• A changer l’alimentation
• A nettoyer vos cartouches
• A réparer des connecteurs de cartouche abimés
• A fabriquer une manette style arcade
• A jouer à des jeux d’arcade sur votre NES

Ça vous branche ? Alors sortez le fer à souder et rendez vous ici.

[photo]

Pour parodier la tante de John dans HeroCorp, je vais vous détendre un peu la quiche avec une petite vidéo bien sympatoche réalisée par Joe Marvelly ! Ce fan de Zelda y joue quelques hits de Ocarina of Time, en assemblant lui même les instruments. Il y joue de la guitare, de la basse, du stylophone et un peu de percussion…

Et c’est beaaaaaauuuu ! Mon dieu que c’est beauuuuuuuuuu

Je vous en parlais la semaine dernière, le hacker GeoHot annonçait sur son blog qu’il avait cracké la Playstation3 … Et bien il vient tout juste de publier l’exploit en question pour le plus grand bonheur de tous les autres hackers qui vont ainsi prendre le relai…

Il a demandé à la communauté qu’elle documente toutes ses trouvailles dans le Wiki psDev. L’exploit en question est téléchargeable ici avec les instructions.

geohot: well actually it's pretty simple
geohot: i allocate a piece of memory
geohot: using map_htab and write_htab, you can figure out the real address
of the memory
geohot: which is a big win, and something the hv shouldn't allow
geohot: i fill the htab with tons of entries pointing to that piece of
memory
geohot: and since i allocated it, i can map it read/write
geohot: then, i deallocate the memory
geohot: all those entries are set to invalid
geohot: well while it's setting entries invalid, i glitch the memory control
bus
geohot: the cache writeback misses the memory 
geohot: and i have entries allowing r/w to a piece of memory the hypervisor
thinks is deallocated
geohot: then i create a virtual segment with the htab overlapping that piece
of memory i have
geohot: write an entry into the virtual segment htab allowing r/w to the main
segment htab
geohot: switch to virtual segment
geohot: write to main segment htab a r/w mapping of itself
geohot: switch back
geohot: PWNED
geohot: and would work if memory were encrypted or had ECC
geohot: the way i actually glitch the memory bus is really funny
geohot: i have a button on my FPGA board
geohot: that pulses low for 40ns
geohot: i set up the htab with the tons of entries
geohot: and spam press the button
geohot: right after i send the deallocate call

J’ai hâte de voir tout ce petit monde s’enflammer et inventer des centaines de choses à partir de ce hack, y compris des petites bidouilles ou des homebrews.

Si vous voulez plus d’infos, rendez vous sur le blog de GeoHot !

Encore merci à Prototux pour l’info

Jusqu’en 1999, la RFC 1035 (manuel de référence) qui documente le protocole DNS, stipulait que la taille des paquets DNS ne pouvait dépasser 512 octets… Mais après cette date (1999 pour ceux qui suivent), la RFC 2671 a permis de supprimer cette limite, autorisant ainsi les paquets DNS plus volumineux.

La plupart des équipement réseaux ont donc suivi le mouvement et permettent actuellement le passage de paquets DNS supérieurs à 512 octets… Mais « la plupart » ne veux pas dire « tous ». Et c’est là qu’il risque d’y avoir du grabuge. En effet, à partir de demain (je sais, je vous préviens tard), une migration des serveurs DNS racines débutera afin de pouvoir diffuser les zones en les signants avec DNSSEC. DNSSEC permet de chiffrer les transactions DNS d’un bout à l’autre de la chaine, afin d’éviter qu’un serveur DNS parasite modifie la requête et transmette une résolution DNS vérolée au client. Je ne vais pas m’étendre sur le sujet car le DNSSEC c’est pas non plus mon coeur de métier mais allez jeter un oeil ici.

Du coup, d’ici juillet, les 13 serveurs DNS racines auront été migrés et diffuseront tous des paquets DNSSEC… Ce qui signifie vous l’aurez compris, des paquets supérieurs à 512 octets, que dis-je, supérieurs à 1500 octets ! Et c’est là que ça coince. Car il existe encore pas mal de vieux routeurs, firewalls et équipements réseaux divers et variés qui trainent un peu partout sur cette planète et que personne n’a mis à jour. Ces derniers n’acceptent donc pas les paquets DNS > 512 octet ou même si ils les acceptent, ne sont pas capables de les fragmenter correctement, privant le réseau derrière cet appareil, à un accès internet. Il risque donc d’y avoir quelques surprises.

Pour tester si votre réseau est impacté par ce problème, j’ai trouvé un série de tests expliqués ici. Il suffit de faire un dig sur ce serveur de test (ça se fait très bien dans une console sous linux) :

dig +short rs.dns-oarc.net txt

Et pour les windowsiens (Merci Dju) :

nslookup -q=txt rs.dns-oarc.net

Et voici la réponse que vous devez avoir :

rst.x4001.rs.dns-oarc.net.

rst.x3985.x4001.rs.dns-oarc.net.

rst.x4023.x3985.x4001.rs.dns-oarc.net.

« 192.168.1.1 sent EDNS buffer size 4096″

« 192.168.1.1 DNS reply size limit is at least 4023 bytes »

Les 2 dernières lignes indiquent que l’équipement réseau supporte des paquets de plus de 4000 octets. C’est super cool, ça veut dire que vous n’aurez pas de soucis. Si vous êtes en dessous des 4000, ça risque de poser des petits soucis. Voici ce que moi j’ai eu via ma freebox :

rst.x476.rs.dns-oarc.net.

rst.x485.x476.rs.dns-oarc.net.

rst.x490.x485.x476.rs.dns-oarc.net.

« 208.69.xxx.xxx DNS reply size limit is at least 490″

« 208.69.xxx.xxx lacks EDNS, defaults to 512″

« Tested at 2010-01-26 20:40:36 UTC »

On voit bien que par défaut le routeur auquel je suis connecté n’accepte pas de paquets supérieur à 512 … gloups. Mais en lisant cet article, j’ai complété mes tests avec cette requête DNS en forçant le DNSSEC. Et j’ai bien reçu la réponse (!!), ce qui semblerait indiquer que ma situation n’est pas si gloups que ça. (Mais au final, je n’en sais foutre rien !)

dig +dnssec @192.134.0.49 DNSKEY ripe.net

Je pense de toute façon que Free et les FAI en général ont bien fait leur boulot. Mais qu’en est il des petits réseaux d’entreprises ou d’université ? On le saura entre demain et juillet 2010. Mais si vous n’avez plus internet pour une raison inexpliquée, pensez à vérifier le MTU de vos machines sur le réseau (pare-feu, middlebox, routeur and co…)

En attendant, si vous souhaitez plus de matière à ce sujet, je vous recommande d’aller lire :

• System-Linux (ma source ! Merci Jeremy pour l’info !)
• Le plan d’action de cette migration en PDF
• Le site officiel du passage au DNSSEC
• La petite appli java pour tester la taille de vos paquets
• La liste des tests cités précédemment
• Et les explications de Bortzmeyer, le gourou français du DNS !

Allez, au boulot les gars !

Et voilà, on connait enfin le nom de la milice privée qui travaillera pour les majors (SCPP et ALPA), afin de balancer vos IP à Hadopi. Il s’agit de TMG (Trident Media Guard ancienement Mediaguard) dont j’avais déjà évoqué le nom ici. Cette petite boite implantée à Saint-Sébastien-sur-Loire près de Nantes a été crée en 2002 par Alain Guislain et Bastien Casalta, sera capable d’espionner 4 réseaux p2p très utilisés (Bittorrent, eMule..et ??) et se limitera à la surveillance d’un catalogue précis de film et de musique. Par exemple pour la musique, ils surveilleront 10 000 titres, relevant ainsi 25 000 ip par jours maximum rien que pour ça. w00t, ils ont l’air d’avoir de l’expérience.

Bon, rien de très sorcier sur le fonctionnement de la chose. A partir de leurs catalogues de titres, ils génèrent des empreintes des fichiers circulants sur le p2p, et s’amusent à les télécharger tout au long de la journée (je télécharge, je supprime le fichier et je recommence) en prenant soin d’enregistrer toutes les adresses IP qui se connectent à leurs faux clients p2p. Oui, ils sont bien obligé d’être des pirates eux-même pour vous choper. Je ne sais pas si ils ont une astuce au niveau de leur propre adresse IP mais en général, les sociétés ont une seule adresse IP (ou une plage d’IP) qui ne change pas et qui pourrait très bien se retrouver dans les blacklists (ipfilter) par défaut des logiciels de peer2peer traqués.

Votre IP enregistrée par TMG partira ensuite entre les mains de la SCPP et de l’ALPA (leurs clients), histoire de rajouter encore plus de risques d’erreurs au process, avant de finir son voyage chez Hadopi où cette dernière contactera les fournisseurs d’accès délateurs afin d’avoir votre adresse physique.

Bon pour le moment, ils ne peuvent pas faire grand chose car ils doivent avoir l’autorisation de la CNIL mais je parie qu’ils l’auront sans souci, menant la date d’envoi des premiers courrier hadopiste à Avril.

Thierry Lhermitte est d’ailleurs investisseur dans cette société à hauteur de 50 000 €. Le malin ! Moi je serai lui, j’aurai plutôt investi dans les sociétés proposant des VPN et rendant la solution de repérage de TMG complétement inutile. hahaha !

[Source et photo]