Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierinformatique général
  • ✇Korben
  • Il fait tourner DOOM avec des expressions régulières, et il faut trois minutes par image
    Un développeur du nom d' Artem Lytkin a réussi à faire tourner DOOM sur une machine dont la seule et unique opération est un chercher-remplacer, le même que celui de votre traitement de texte, appliqué en boucle sur un énorme fichier texte. Le projet s'appelle doom-regex et son code est public depuis quelques jours. Une expression régulière, c'est un motif de recherche un peu évolué, capable de repérer par exemple tous les groupes de chiffres suivis d'une virgule dans un texte pou

Il fait tourner DOOM avec des expressions régulières, et il faut trois minutes par image

30 juillet 2026 à 11:43

Un développeur du nom d' Artem Lytkin a réussi à faire tourner DOOM sur une machine dont la seule et unique opération est un chercher-remplacer, le même que celui de votre traitement de texte, appliqué en boucle sur un énorme fichier texte. Le projet s'appelle doom-regex et son code est public depuis quelques jours.

Une expression régulière, c'est un motif de recherche un peu évolué, capable de repérer par exemple tous les groupes de chiffres suivis d'une virgule dans un texte pour les remplacer par autre chose. Les développeurs s'en servent tous les jours pour nettoyer des fichiers ou valider des adresses mail, jamais pour lancer un jeu vidéo.

Ici, tout l'ordinateur vit dans une seule chaîne de caractères d'environ 96 Mo, dans laquelle les registres du processeur, la mémoire, l'image affichée à l'écran, le moteur du jeu et ses données sont posés sous forme de texte. Un jeu de 544 règles de remplacement, toujours appliquées dans le même ordre, simule un petit processeur 32 bits maison baptisé RVM-1.

Il n'y a aucun interpréteur ni aucun calcul en dehors de ces règles. Quand le jeu additionne deux nombres, c'est une substitution qui réécrit des caractères au bon endroit dans la chaîne, et rien d'autre.

Le prix à payer est quand même salé, puisqu'il faut près de 14 millions de substitutions pour produire une seule image du premier niveau, à un rythme d'environ 80 000 remplacements par seconde. Trois minutes par image. Une petite séquence de 100 images représente du coup plus d'un milliard d'opérations.

Le résultat n'est pourtant pas une vague approximation, car les images produites sont identiques à l'octet près à celles du vrai DOOM compilé normalement, vérification par empreinte cryptographique à l'appui.

Tom's Hardware, le média spécialisé qui a relayé la trouvaille, résume bien l'expérience : y jouer tient plus "des échecs par correspondance avec un fusil à pompe" que du jeu de tir nerveux. Une démo pour Windows est malgré tout téléchargeable pour les plus patients.

DOOM a déjà tourné sur des tests de grossesse et des tracteurs, mais on est ici un cran au-dessus, avec la preuve qu'un outil de bureautique détourné suffit à construire un ordinateur qui marche. Hackaday, le site des bidouilleurs, reconnaît d'ailleurs que la valeur pratique du truc est à peu près nulle.

Totalement inutile, et c'est exactement pour ça qu'on adore : ce genre de bidouille obsessionnelle et gratuite vaut tous les produits à abonnement du moment.

Source : Tom's Hardware

  • ✇Korben
  • La Neo Geo fait enfin tourner DOOM
    DOOM tourne aujourd'hui sur presque tout, d'un frigo connecté à une calculatrice, et chaque année quelqu'un ajoute une machine encore plus improbable à la liste. Il restait pourtant une exception qui résistait, la Neo Geo, la console d'arcade de SNK des années 90. Elle coûtait le prix d'un petit salaire à l'époque, et elle passait quand même pour incapable de faire tourner le jeu de tir culte de id Software. Le plus curieux, c'est que ce n'était pas une question de puissance. Son

La Neo Geo fait enfin tourner DOOM

15 juillet 2026 à 17:43

DOOM tourne aujourd'hui sur presque tout, d'un frigo connecté à une calculatrice, et chaque année quelqu'un ajoute une machine encore plus improbable à la liste. Il restait pourtant une exception qui résistait, la Neo Geo, la console d'arcade de SNK des années 90. Elle coûtait le prix d'un petit salaire à l'époque, et elle passait quand même pour incapable de faire tourner le jeu de tir culte de id Software.

Le plus curieux, c'est que ce n'était pas une question de puissance. Son processeur et sa puce graphique étaient très corrects pour leur temps. Le problème venait de sa mémoire, à peine 64 kilo-octets, alors qu'une simple photo de téléphone en réclame des milliers de fois plus aujourd'hui.

DOOM, dans sa version d'origine, a besoin de beaucoup de mémoire pour dessiner son image point par point avant de l'afficher. La Neo Geo n'a tout simplement pas cette place. C'est pour cette raison qu'une figure connue du rétro-gaming sur YouTube, Modern Vintage Gamer, avait affirmé il y a quelque temps que le jeu ne tournerait jamais dessus.

Un développeur qui se fait appeler Sabino a fini par prouver le contraire. Son projet s'appelle DoomGeo. Au lieu de forcer la console à faire ce qu'elle déteste, il utilise ce qu'elle sait faire de mieux, c'est-à-dire afficher des petits dessins tout prêts à grande vitesse.

Concrètement, il découpe l'image en fines bandes verticales que la console étire en hauteur selon la distance des murs. Le processeur se contente de calculer les distances et d'indiquer quoi afficher, il ne dessine plus chaque point lui-même. Des outils préparent aussi les cartes et les décors du jeu à l'avance, pour que la console n'ait plus qu'à les afficher.

Le résultat n'est pas une simple démonstration technique. On y trouve des murs, des armes, des ennemis, des objets à ramasser, des portes et un vrai système de combat qui fonctionne. Le projet n'est pas encore complet, mais il tourne déjà sur une vraie console, pas seulement sur un émulateur.

Voir tomber la dernière console qui résistait au fameux "ça ne fait pas tourner DOOM", ça montre bien qu'avec assez d'astuce, aucune machine ne tient très longtemps.

Source : Hackaday

  • ✇Korben
  • Doom tourne désormais sur un bracelet Xiaomi Mi Band 10
    Il y a des gens qui se détendent en regardant une petite série. Aaron Christophel, lui, se détend en désossant des bracelets connectés Xiaomi pour leur faire cracher du code qu'aucun ingénieur de la marque n'avait prévu. Ce bidouilleur allemand, plus connu sous le pseudo atc1441, vient de s'attaquer au Mi Band 10, et il en a tiré ce que la communauté du hack matériel considère comme le sacre suprême depuis trente ans : un portage de Doom, le jeu de tir sorti en 1993. Le jeu n'était pourtant

Doom tourne désormais sur un bracelet Xiaomi Mi Band 10

22 juin 2026 à 15:06

Il y a des gens qui se détendent en regardant une petite série. Aaron Christophel, lui, se détend en désossant des bracelets connectés Xiaomi pour leur faire cracher du code qu'aucun ingénieur de la marque n'avait prévu.

Ce bidouilleur allemand, plus connu sous le pseudo atc1441, vient de s'attaquer au Mi Band 10, et il en a tiré ce que la communauté du hack matériel considère comme le sacre suprême depuis trente ans : un portage de Doom, le jeu de tir sorti en 1993.

Le jeu n'était pourtant pas le problème. La puce, si.

Le Mi Band 10 utilise un BES2700iMP, un composant fabriqué par Bestechnic, un fondeur chinois qu'on croise surtout dans des écouteurs sans fil parce qu'il est taillé pour la basse consommation. Petite subtilité qui complique tout : chez Bestechnic, cette même puce répond aussi au nom de code BEST1503.

Or pour programmer un composant pareil, il faut son SDK, autrement dit le kit fourni par le fabricant avec la documentation et les outils pour développer dessus. Et là, surprise : pour ce modèle, aucun SDK public. Rien du tout. Christophel s'est donc retrouvé face à une puce muette, sans plan ni notice.

Sa porte d'entrée, il l'a trouvée du côté d'une cousine quasi jumelle. Le BEST1306, un autre composant Bestechnic, partage la même architecture, et lui possède un SDK qui a fuité par le biais de kits de développement audio. En recoupant patiemment les deux, il a reconstitué par rétro-ingénierie, ce travail qui consiste à remonter le fonctionnement interne d'un appareil sans en avoir les plans, un SDK compatible avec le BES2700iMP.

Le reste a suivi. Firmware maison, c'est-à-dire le logiciel bas niveau qui pilote directement le matériel, puis portage de Doom via le projet GBADoom. Tout n'est pas nickel pour autant : l'écran fonctionne en SPI un seul bit au lieu du quad-SPI dont il est capable, deux manières d'envoyer les pixels dont la seconde va nettement plus vite, ce qui plombe ici la fluidité et écrase les couleurs.

Screenshot

Bref, ça se joue, mais c'est moche. Et sur une dalle large de quelques centimètres, on reste évidemment dans l'exploit pour l'exploit plus que dans la séance de jeu.

Le détail qui fait un peu marrer vu le contexte actuel, c'est l'aveu de Christophel sur l'intelligence artificielle : elle ne lui a quasiment servi à rien. Les données techniques de ces puces propriétaires n'existent nulle part dans les corpus d'entraînement des modèles, du coup les assistants brassaient du vide.

Et ce n'est pas fini. Le Mi Band 9 embarque exactement le même matériel, ce qui signifie que le SDK reconstitué devrait y tourner tel quel, sans toucher une ligne. Tout est documenté et publié sur GitHub, à la disposition de quiconque veut prolonger cette bien belle aventure.

Bref, faire tourner un jeu de 1993 sur un bracelet de sport ne sert objectivement à rien, et c'est précisément pour ça que c'est toujours très cool.

Source : Hackaday

  • ✇Korben
  • Un clone de DOOM en COBOL ça vous dit ?
    Un développeur connu sous le pseudonyme icitry s'est posé une question que personne de sensé ne formule jamais, peut-on coder un jeu de tir à la première personne en COBOL ? La réponse, contre toute attente, est oui, et le résultat est même tout à fait jouable. Pour ceux que ce nom laisse de marbre, COBOL, pour Common Business Oriented Language, est un langage né en 1959 qui fait encore tourner aujourd'hui une partie des mainframes chargés de vos virements bancaires et de la paie. C'est l'outil

Un clone de DOOM en COBOL ça vous dit ?

8 juin 2026 à 18:17

Un développeur connu sous le pseudonyme icitry s'est posé une question que personne de sensé ne formule jamais, peut-on coder un jeu de tir à la première personne en COBOL ? La réponse, contre toute attente, est oui, et le résultat est même tout à fait jouable.

Pour ceux que ce nom laisse de marbre, COBOL, pour Common Business Oriented Language, est un langage né en 1959 qui fait encore tourner aujourd'hui une partie des mainframes chargés de vos virements bancaires et de la paie. C'est l'outil de la gestion et des relevés de compte, à peu près l'inverse de ce qu'on imagine pour un jeu vidéo.

Le moteur du jeu repose sur le raycasting, cette technique qui a propulsé Wolfenstein 3D au début des années 90. Le programme projette une rangée de rayons depuis le point de vue du joueur, regarde où chacun vient percuter un mur, et en déduit colonne par colonne la hauteur à dessiner. De la fausse 3D reconstruite à partir d'un simple plan vu de dessus.

Le vrai casse-tête, c'est que COBOL n'embarque aucune bibliothèque graphique, pas la moindre fonction pour allumer un pixel ou ouvrir une fenêtre. La parade est astucieuse. Le programme calcule lui-même chaque image, en recrache les pixels bruts sur la sortie standard du terminal, puis laisse un petit utilitaire nommé ffplay récupérer ce flux pour l'afficher comme une vidéo animée.

Même esprit de débrouille pour les commandes. Le terminal bascule en mode brut afin d'intercepter chaque touche sans attendre que vous validiez, pendant que le programme lit en continu ce qui arrive sur son entrée standard.

Et le rendu ne se limite pas à trois murs gris qui clignotent. On y trouve des sprites, des ennemis qui se baladent et vous tirent dessus, et même des secteurs de hauteur variable qui rapprochent l'ensemble du DOOM de 1993 plutôt que de son aîné Wolfenstein.

Le code complet est publié sur GitHub sous licence Apache, libre à chacun d'aller en fouiller les coulisses. Un internaute a d'ailleurs relevé que GnuCOBOL, le compilateur libre utilisé ici, sait parfaitement appeler du code écrit en langage C, ce qui ouvrirait l'accès à tout son arsenal de bibliothèques.

Toute la démonstration sert à rappeler que COBOL est Turing-complet, c'est-à-dire capable en théorie de calculer exactement la même chose que n'importe quel langage moderne, et à le prouver sur le terrain le plus hostile qu'on puisse lui opposer.

Bref, c'est rigoureusement inutile, et c'est très exactement pour ça que c'est cool.

Source : Hackaday

  • ✇Korben
  • 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 strea

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

Par : Korben
20 octobre 2025 à 08:24

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)

  • ✇Korben
  • 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

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

Par : Korben
14 juillet 2025 à 13:37

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.

  • ✇Korben
  • Legion of Doom - Les hackers qui ont inventé les règles
    Cet article fait partie de ma série de l’été spécial hackers. Bonne lecture ! En 1987, télécharger un fichier de 150 Ko sur un vieux BBS à 2400 bauds, ça prenait 2 heures. Et encore, si personne ne décrochait le téléphone chez vous durant ce temps. Et si vous étiez déjà dans la culture hacker, ce fichier, c’était peut-être le Legion of Doom Technical Journal.

Legion of Doom - Les hackers qui ont inventé les règles

Par : Korben
9 juillet 2025 à 13:37

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

En 1987, télécharger un fichier de 150 Ko sur un vieux BBS à 2400 bauds, ça prenait 2 heures. Et encore, si personne ne décrochait le téléphone chez vous durant ce temps. Et si vous étiez déjà dans la culture hacker, ce fichier, c’était peut-être le Legion of Doom Technical Journal.

❌
❌