Vue lecture

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.

Un développeur fait tourner Doom dans un navigateur, avec du CSS et rien d'autre

Niels Leenheer a porté le mythique Doom de 1993 dans un navigateur web, mais sans WebGL ni Canvas. Tout le rendu 3D repose sur des div et des transformations CSS. Le résultat est jouable, open source, et un brin absurde. On adore.

Doom en div

Le principe est aussi fou qu'il en a l'air. Chaque mur, chaque sol, chaque tonneau et chaque ennemi est une balise div, positionnée dans l'espace 3D grâce aux transformations CSS. Le jeu lit les données du fichier WAD original de 1993, celui-là même qui contenait les niveaux du Doom d'id Software, et en extrait les coordonnées des murs, des secteurs et des textures.

La logique du jeu, elle, tourne en JavaScript. Mais côté affichage, c'est 100 % CSS : pas de Canvas, pas de WebGL, pas de bibliothèque graphique. Juste des div, des calculs trigonométriques en CSS et des propriétés personnalisées.

Pour simuler une caméra, le développeur a trouvé une astuce assez maline : plutôt que de déplacer le joueur dans la scène, c'est la scène entière qui bouge dans le sens inverse. Le CSS ne gère pas nativement la notion de caméra, du coup Leenheer a tout simplement inversé le problème.

Des fonctions CSS qu'on ne soupçonnait pas

Le projet exploite des fonctions CSS relativement récentes : hypot() pour le théorème de Pythagore, atan2() pour les angles de rotation, clip-path pour découper les sols en polygones complexes, et @property pour animer des propriétés personnalisées qui servent à gérer les portes, les ascenseurs et même la chute du joueur.

Les ennemis utilisent des spritesheets classiques avec un effet de billboard, c'est-à-dire qu'ils font toujours face à la caméra. Les effets de lumière passent par un filtre brightness sur chaque secteur, et le fameux ennemi invisible Spectre utilise un filtre SVG pour reproduire l'effet de distorsion du jeu original.

Leenheer a même ajouté un mode spectateur avec caméra libre, absent du Doom de 1993, et les calculs de positionnement de cette caméra reposent eux aussi sur les fonctions trigonométriques du CSS.

Les limites du CSS poussé à fond

Le jeu est jouable sur cssdoom.wtf, et le code source est disponible sur GitHub sous licence GPL 2. Par contre, les performances restent limitées. Sur Safari iOS, le jeu peut planter au bout de quelques minutes, et les gros niveaux font souffrir le navigateur.

Leenheer le reconnaît lui-même : le projet ne remplacera jamais WebGL ou WebGPU pour du rendu 3D sérieux. Le but était avant tout de montrer jusqu'où le CSS moderne peut aller, et sur ce point, la démonstration est plutôt convaincante.

C'est le genre de projet complètement absurde qui force le respect. Doom a déjà été porté sur à peu près tout ce qui contient un processeur, des calculatrices aux tests de grossesse, et voilà qu'il tourne maintenant dans une feuille de style.

L'air de rien, ça montre que le CSS de 2026 n'a plus grand-chose à voir avec celui qu'on utilisait pour centrer un div il y a dix ans.

Source : Huckster.io

DOOM over DNS - 2000 records TXT pour buter des démons

« Can it run DOOM ? » Vous connaissez tous la question je pense. En effet, depuis 1993, le FPS d'id Software a tourné sur à peu près tout ce qui contient un processeur, des calculatrices aux écouteurs en passant par des tests de grossesse. Et là, Adam Rice vient de pousser le délire encore plus loin en stockant et en lançant le jeu entier... via des enregistrements DNS.

Oui, ce bon vieux protocole de plus de 40 ans, conçu à la base pour traduire des noms de domaine en adresses IP (RFC 1035, tout ça). En fait, la magie tient dans le fait que les enregistrements TXT n'ont aucune validation de contenu. Du coup, rien n'empêche d'y coller du texte arbitraire... genre un FPS complet converti en texte via base64. En gros, le DNS devient un stockage clé-valeur distribué mondialement et mis en cache un peu partout. Pas mal comme CDN du pauvre !

Le fichier WAD (les niveaux et assets du jeu, 4 Mo) passe à 1,7 Mo après compression, les DLLs du moteur de 4,4 Mo à 1,2 Mo, et le tout est découpé en 1 966 enregistrements TXT sur une seule zone CloudFlare Pro. Un record spécial contient également les métadonnées de réassemblage (nombre de chunks, hash de vérification).

Ensuite, côté joueur, un script PowerShell de 250 lignes résout les 2 000 requêtes, reconstruit le binaire en mémoire et hop, ça tourne. Les données du jeu ne touchent ainsi jamais le disque, puisque tout reste en mémoire. Le tout chargé en 10 à 20 secondes (PowerShell 7 requis) !

Le truc rigolo, c'est que l'auteur ne connaît pas le C#. C'est Claude (oui, encore cette fichue IA, ahaha) qui s'est tapé le portage en modifiant managed-doom, un port C# du moteur original, pour remplacer les lectures fichier par des flux mémoire et virer toutes les dépendances natives au profit d'appels Win32 directs. L'audio a été sacrifié pour réduire le nombre de records mais bon, on va pas chipoter. Après si vous voulez tester, sachez que ça ne fonctionne que sous Windows car ça repose sur PowerShell, donc pas de version Linux pour l'instant.

D'ailleurs, si le concept vous rappelle quelque chose, c'est normal. Planquer des données dans les enregistrements TXT, c'est en fait une technique bien connue en sécu. J'en parlais déjà avec DNSteal pour exfiltrer des fichiers via DNS , ou avec ces malwares carrément stockés dans les records DNS . Adam Rice le dit lui-même, son projet est parti de l'exploration de techniques d'implants (staging de shellcode via TXT records) sauf qu'au lieu de planquer un trojan, il y a planqué ce FPS de +33 ans. C'est quand même plus sympa !

À vrai dire, avant d'en arriver là, il a d'abord fait un proof of concept avec une image de canard (va savoir pourquoi). Encoder la photo en base64, découper en chunks, uploader via l'API CloudFlare, reconstruire de l'autre côté avec un hash identique et ça a marché du premier coup. Par contre pour la vidéo, oubliez, un MP4 de 1 Go ferait 670 000 enregistrements.

Voilà et tout ça pour 20 dollars par mois (le prix de la zone CloudFlare Pro). Donc si DOOM sur des écouteurs vous avait déjà fait sourire, attendez qu'un taré le fasse tourner avec que des paquets ICMP. Bah quoi ??

Bref, le code est dispo sur GitHub et le DNS a clairement pas fini de nous surprendre.

Source

Il avait porté DOOM sur Super Nintendo en 1995, il revient trente ans plus tard pour corriger sa copie

Randal Linden est le développeur qui avait réussi l'exploit de faire tourner DOOM sur la Super Nintendo en 1995. Trente ans plus tard, il s’est associé à Limited Run Games pour ressortir une version améliorée sur cartouche, avec un processeur Raspberry Pi caché à l'intérieur.

Dans un long échange accordé à Kotaku, il revient sur ce projet un peu fou et sur les coulisses techniques du portage.

Reverse-engineerer son propre code, trente ans après

À l'époque, Linden bossait chez Sculptured Software, un studio basé à Salt Lake City. L'idée de départ était assez artisanale : acheter des cartouches Star Fox en magasin, les ouvrir, et remplacer la ROM par de la RAM pour tester les capacités de la puce Super FX. Le prototype a suffisamment impressionné ses supérieurs pour qu'ils aillent le présenter directement à id Software au Texas. Le feu vert a suivi.

Le portage de 1995, c'était un moteur entièrement reconstruit de zéro, sans une seule ligne de code d'id Software. Linden avait créé son propre assembleur, son propre linker et son propre débogueur. Mais les contraintes hardware de la SNES avaient imposé des sacrifices : un framerate poussif, pas de textures au sol et au plafond, des niveaux modifiés, et le quatrième épisode supprimé.

Quand Audi Sorlie, de Limited Run Games, lui a posé la question de savoir s'il referait les choses différemment, Linden a répondu qu'il avait « plein d'idées » mais que personne ne lui avait jamais demandé d'y retoucher. Jusqu'à maintenant.

Une puce Raspberry Pi qui se fait passer pour un Super FX

La solution technique est plutôt marrante. La cartouche embarque un Raspberry Pi RP2350 qui émule le processeur Super FX. Comme l'explique Linden à Kotaku, « la Super Nintendo ne sait pas qu'elle ne parle pas à un vrai Super FX ».

Le code est quasiment identique à ce qu'il écrirait pour la puce d'origine, mais avec des performances largement supérieures.

Le résultat : circle strafing, framerate amélioré, support du rumble, et les quatre épisodes complets enfin disponibles sur SNES. Linden admet aussi avoir dû reverse-engineerer son propre code vieux de trente ans. « C'était assez compliqué, une partie du code. Je me suis dit : wow, j'étais vraiment intelligent à l'époque. »

Bethesda a dit oui sans trop hésiter

Côté droits, il fallait quand même convaincre Bethesda, propriétaire de la licence DOOM. Selon Sorlie, la réaction initiale a été plutôt incrédule : « Vous voulez retourner développer pour la Super Nintendo ? Genre, pour de vrai ? » 

Mais le retour de Linden sur le projet et les premiers prototypes ont suffi à convaincre. « Ils étaient aussi enthousiastes que nous. »

C'est le genre d'histoire qui rappelle que derrière les jeux vidéo, il y a parfois des parcours assez improbables. Linden n'avait pas pu appeler id Software pour pitcher son idée en 1995, il avait dû bricoler un prototype avec des cartouches Star Fox achetées en magasin, et trente ans plus tard il se retrouve à relire du code assembleur qu'il ne comprend plus lui-même.

Le projet a un côté un peu absurde, mais c'est aussi ce qui le rend attachant. Reste à voir si les fans de retrogaming seront au rendez-vous, mais vu que l'édition collector limitée à 666 exemplaires s'est déjà envolée, on a un début de réponse.

Source : Kotaku

Il balance un stream de DOOM sur des caméras Yi pleines de failles

Vous avez une caméra de surveillance connectée chez vous ? Du genre petite caméra Yi à 15 balles achetée sur AliExpress pour surveiller le salon ou le chat quand vous n’êtes pas là ? Alors tenez-vous bien parce qu’un chercheur a réussi à faire tourner DOOM dessus. Et sans toucher au firmware s’il vous plait ! Il a juste exploité le stream vidéo et quelques bugs bien sentis de l’appareil.

Luke M a publié son projet Yihaw sur GitHub et ça fait un peu peur car si quelqu’un peut hijacker le stream de votre caméra pour y balancer un FPS des années 90, il peut aussi faire pas mal d’autres trucs beaucoup moins rigolos.

Le hack est assez cool d’ailleurs car ces caméras Yi tournent sur un petit processeur ARM sous Linux. Elles ont donc une app mobile qui vous permet de voir le stream en temps réel et Luke M a trouvé plusieurs vulnérabilités dans la stack réseau de la caméra. Je vous passe les détails mais avec ces bugs, il peut injecter du code arbitraire sans modifier le firmware.

Il peut alors créer trois threads qui tournent en parallèle. Le premier récupère les frames YUV420p directement depuis le capteur de la caméra. Le deuxième convertit ça en h264. Le troisième, au lieu d’envoyer le flux vidéo normal, envoie DOOM. Du coup, vous ouvrez l’app Yi IoT sur votre smartphone et vous voyez le Doomguy buter des demons au lieu de voir votre salon. C’est rigolo, hein ?

Ces caméras Yi, il y en a des millions installées partout dans le monde. Bureaux, maisons, magasins…etc car elles sont pas chères, elles marchent plutôt bien, elles ont une app correcte, mais leur sécurité c’est une vraie passoire. C’est bourré de bugs qu’on trouve en une après-midi avec un fuzzer basique.

Luke M liste plusieurs exploits dans son repo GitHub et c’est un vrai buffet à volonté pour quelqu’un qui veut prendre le contrôle de ces caméras. Bien sûr ce serait illégal alors personne ne le fait, surtout parce que ça demande quand même un peu de boulot pour chaque modèle de caméra. Mais les outils existent, les vulnérabilités sont connues, et si un chercheur solo peut le faire pour s’amuser avec DOOM, imaginez ce qu’un botnet bien pensé pourrait faire.

Tous ces trucs qu’on a chez nous, qui tournent sur du Linux embarqué avec des stacks réseau écrites à l’arrache par des équipes chinoises sous-payées qui doivent sortir un produit tous les trois mois.

C’est beau non ?

Source (c’est du PDF)

La fin du monde est proche !

Peut-être que vous le connaissez déjà, mais si ce n’est pas le cas, sachez qu’il existe un site qui tracke méticuleusement toutes les apocalypses ratées ! Et actuellement et le compteur affiche fièrement 201 échecs et 0 succès. Ouf, tant mieux ! Ce site c’est le Doomsday Scoreboard de March1 Studios, et c’est un peu le panneau “X jours sans accident” des usines, mais inversé puisqu’ici on célèbre le fait que les prophètes se plantent avec la régularité d’un métronome cassé.

La dernière en date c’est l’apocalypse du 23 septembre 2025. Joshua Mhlakela, un pasteur sud-africain, avait posté des vidéos expliquant que le “Rapture” (le retour de Jésus) allait se produire ce jour-là. Les vidéos sont devenues virales sur TikTok sous le hashtag #RaptureTok, parce que bien sûr, même l’apocalypse a besoin d’influenceurs maintenant et y’a même des gens qui ont quitté leur job pour se préparer ou fait des tutos à la con du genre “5 conseils pour survivre au Rapture”.

Autant vous dire que le réveil normal du 24 septembre a dû être chelou et plein de mauvaise foi.

Mais le vrai champion toutes catégories de ces apocalypses, c’est Harold Camping. Lui il a fait 12 prédictions ratées. C’est plus que le nombre de Fast and Furious ^^ et sa prédiction la plus célèbre, sortie en mai 2011, il l’a financée avec des millions de dollars en publicité : 5000 panneaux d’affichage, 20 camping-cars sillonnant les États-Unis. Il avait calculé que c’était exactement 7000 ans après le déluge biblique, donc forcément, ça devait matcher.

Puis le 22 mai, après sa prédiction ratée, il s’est déclaré complètement débousolé ! Imaginez, vous claquez des millions pour annoncer la fin du monde, et le lendemain vous devez sortir les poubelles. Du coup pour sauver la face, il a dit “Ah non en fait c’était spirituel, la vraie c’est en octobre”. Je vous rassure, ça a foiré aussi en octobre et toutes les fois d’après.

William Miller, lui aussi c’est un autre roi du pivot stratégique. En 1843, il prédit la fin du monde devant 100 000 personnes mais bien sûr, ça a foiré “Pardon les gars, j’ai refait les calculs, c’est octobre 1844”. Et le 22 octobre 1844, toujours rien. Le résultat de ce double échec s’appelle même la Grande Déception , et honnêtement, le nom est bien trouvé. Mais Miller ne s’est pas découragé : il a juste dit que ça s’était passé au paradis, donc vous n’avez rien vu. C’est d’ailleurs de là qu’est née l’Église Adventiste.

Niveau récupération de fail, chapeau ! On dirait ces gens bizarres sur les réseaux sociaux qui repoussent chaque mois depuis 2020, leur prédiction de tous ces millions de morts provoqués à cause d’un vaccin Covid qui devait normalement joncher nos rues. Ahahaha qu’est ce qu’on se marre ^^.

Les Témoins de Jéhovah ont aussi leur propre série de ratés : 1914, 1915, 1918, 1920, 1925, 1941, 1975, 1994. La prédiction de 1925 était d’ailleurs annoncée comme plus certaine que celle de 1914 selon les Écritures. Résultat ? Entre 1925 et 1928, ils ont perdu 80% de leurs membres, déçus. La réponse officielle a été que ça avait aidé à séparer les fidèles des autres. Ça c’est du marketing de crise de champions !

En 2012 (vous vous souvenez de cette apocalypse là ?), un sondage dans 20 pays montrait que 14% des gens pensaient que le monde finirait de leur vivant. Aux États-Unis, c’était même plus de 20%. Et en 2022, 39% des Américains croyaient vivre la fin des temps. Autrement dit, 4 personnes sur 10 parient sur un cheval qui a perdu ses 201 dernières courses. Les paris sportifs sont moins risqués…

Le calendrier Maya de 2012, c’était peut-être d’ailleurs la plus grosse en termes de couverture médiatique. La fin du Grand Cycle du calendrier Maya a été interprétée comme la fin du monde avec des films catastrophe, des documentaires alarmistes, des ventes de bunkers qui explosent…etc. Puis le jour J, le 22 décembre 2012, réveil normal, café normal, métro normal. Hé oui, les Mayas n’avaient jamais dit que c’était la fin, juste que leur calendrier recommençait un nouveau cycle. Mais bon, ça fait moins de clics.

On a un peu le même truc en ce moment avec la comète 3I/ATLAS. Je vois dans Google News des tas de médias merdiques nous expliquer une fois que c’est un vaisseau alien qui ralenti pour venir nous achever, et une autre fois que le machin nous arrive droit dessus pour nous atomiser…

Et dire qu’il suffit d’aller lire 2/3 articles sérieux sur le sujet pour capter qu’on ne risque rien. Le machin va juste passer, on va lui faire coucou et on ne le reverra jamais… Breeeef, la connerie et la peur n’a pas de limites malheureusement.

Et le site Doomsday Scoreboard ne se contente pas uniquement d’archiver les échecs. Il liste aussi les apocalypses en attente. En ce moment y’a 8 prédictions pour 2025-2026. Donc 8 nouvelles chances de voir le compteur passer à 209 apocalypses ratées. Ce que j’aime bien avec ce site en tout cas, c’est qu’il transforme des annonces plutôt déprimantes en performance artistique.

Le compteur qui tourne, le total des échecs qui s’incrémente, les liens vers les sources Wikipedia pour chaque prédiction…etc. C’est à la fois un joli devoir de mémoire et une bonne blague ! En tout cas, pour le moment, c’est le seul domaine où l’humanité affiche un taux de fiabilité de 100% !

Voilà… Maintenant, rendez-vous dans 249 jours pour savoir si l’apocalypse aura lieue ou si vous devrez quand même aller bosser le lendemain.

Merci à Lilian pour le lien !

L'histoire de celui qui a prédit la mort de DOOM

Et si je vous disais qu’un mec a réussi à prédire l’avenir avec la précision d’un oracle ? Et pas une vague prédiction à la Nostradamus où on peut interpréter n’importe quoi… Non, non, une vraie prédiction scientifique du style : “Ce truc devrait crasher vers septembre 2025”. Et devinez quoi ? Ça a effectivement crashé.

L’histoire commence en 2023, quand un certain Minki décide de tester une théorie complètement barrée. Le mec lit un article technique sur le moteur de DOOM et remarque un truc bizarre : une variable qui compte les démos du jeu qui s’incrémente en permanence, y compris quand une nouvelle démo commence. Cette variable se compare constamment avec sa valeur précédente, mais elle continue de grimper, encore et encore, jusqu’à… jusqu’à quoi exactement ?

Bah justement, c’est là que ça devient intéressant car Minki sort sa calculatrice et commence à faire ses petits calculs. Il sait que selon la documentation technique de DOOM , le moteur utilise des integers 16 bits pour optimiser les performances. Traduction pour les non-geeks : les nombres ont une limite, et quand on la dépasse, c’est le drame ! Un peu comme quand vous essayez de rentrer votre gros cul dans un ascenseur bondé. Sauf qu’ici, au lieu d’un ascenseur bloqué, on a un jeu qui explose.

Donc notre ami fait ses calculs et arrive à cette conclusion : DOOM devrait crasher après environ 2 ans et demi de fonctionnement continu. Et franchement, qui penserait à vérifier un truc pareil ? La plupart d’entre nous, on lance DOOM pour se défouler 30 minutes et on passe à autre chose. Mais minki, lui, il voit plus loin.

Alors il fait quoi ? Il prend un vieux PDA (si si, ces trucs qu’on utilisait avant les smartphones), il bricole une alimentation avec des batteries 18650 et un chargeur USB branché sur son routeur, et il lance DOOM. Puis il attend. Deux ans et demi. Pour de vrai.

Pendant ce temps, vous et moi, on a changé trois fois de téléphone, bingé 47 séries Netflix, survécu à François Bayrou, vu l’IA devenir mainstream… Et Minki ? Bah lui, il avait DOOM qui tournait dans un coin de son appart…

Et le plus dingue, c’est que ça a marché exactement comme prévu. Selon le post original sur LenOwO , le jeu a crashé “seulement quelques heures après avoir passé les deux ans et demi”. Boom. Prédiction confirmée. Le mec a calculé la mort de DOOM avec une précision chirurgicale.

Ici, pas besoin d’exploits sophistiqués ou d’outils de pentest dernier cri. Juste de la curiosité, des maths, et une patience de moine tibétain. Et c’est comme ça que Minki a transformé un bug théorique en prédiction concrète, puis en réalité observable.

En fait, les bugs d’overflow de DOOM sont légion . Si vous avez plus de 64 lignes défilantes, ça crash. Si une balle traverse plus de 128 objets, ça bug. Si vous construisez une zone de plus de 2500 unités de hauteur, le moteur panique. C’est un peu comme si le jeu était construit sur un château de cartes, où chaque limite non vérifiée est une catastrophe qui attend son heure.

Bref, vous l’aurez compris, cette expérience c’est bien plus qu’un simple “j’ai fait tourner DOOM pendant longtemps lol”. C’est une démonstration de la prédictibilité des systèmes informatiques. Ça montre que quand on comprend vraiment comment un programme fonctionne, on peut littéralement voir dans l’avenir…

Bien joué Minki !

Opération Sundevil - Le jour où l'Amérique a déclaré la guerre aux hackers

Cet article fait partie de ma série de l’été spécial hackers. Bonne lecture !

Phoenix, Arizona, 6 heures du mat’. Un gamin de 16 ans dort paisiblement dans sa chambre, entouré de posters de Star Wars et de boîtes de pizza vides pendant que dehors, une dizaine d’agents armés jusqu’aux dents encerclent sa baraque…

Hé oui, aujourd’hui, je vais vous raconter comment 150 agents du Secret Service ont débarqué chez des ados boutonneux en pensant sauver l’Amérique. C’était le 8 mai 1990, et c’est devenu l’Opération Sundevil, la plus grosse opération anti-hacker de l’histoire.

❌