Les lumières vacillaient dans la salle des serveurs, chaque clignotement un compte à rebours silencieux. Les techniciens en combinaisons stériles se déplaçaient avec une détermination sinistre, leurs visages illuminés par la lueur froide des moniteurs affichant des lignes de code destinées à disparaître. C’était la mort numérique d’un monde, et personne ne semblait s’en soucier, […]
Après Wine, après Dolphin, après tous ces émulateurs qui se cassent le cerveau à reproduire le moindre transistor d'une console... voici TouchHLE !
Et celui-là, il a compris un truc que beaucoup oublient qui est que pour faire tourner des vieux jeux iPhone de 2008-2011, y'a pas besoin de recréer un iPhone complet dans votre PC.
Faut juste que les apps croient qu'elles tournent sur iOS. Du coup, le projet c'est de réimplémenter les frameworks Apple (UIKit, OpenGL ES, OpenAL) en natif, et seul le binaire ARM de l'app est émulé via dynarmic. Le reste, c'est du code Rust qui fait le boulot directement sur votre machine.
Bref, c'est de l'émulation "haut niveau" (HLE pour High-Level Emulation), l'approche opposée à QEMU qui simule chaque instruction du processeur. C'est la même philosophie que Dolphin pour la GameCube ou Wine pour Windows. Plus léger, plus rapide, mais ça demande de connaître intimement chaque fonction que les apps appellent.
Le logo TouchHLE : un engrenage Rust avec le bouton Home de l'iPhone, tout un symbole (
Source
)
Et le résultat c'est que sur les
667 apps testées dans leur base de compatibilité
, 153 fonctionnent parfaitement et 101 sont jouables avec des bugs mineurs. Je vous parle de pépites du gaming portable comme Super Monkey Ball, Doom, Sonic, Tetris, Pac-Man, Angry Birds ou Cut the Rope. De quoi croquer les madeleines de votre jeunesse iOS première génération.
Super Monkey Ball qui tourne dans TouchHLE, nostalgie de 2008 (
Source
)
Le projet a été lancé en décembre 2022 par Hikari_no_yume, en mode "projet passion à plein temps". Et depuis la release publique de février 2023, c'est devenu un effort communautaire avec une quarantaine de contributeurs. Et ça tourne sur Windows, macOS et même Android.
Alors oui, ça ne fait pas tourner les apps modernes 64-bit, la FAQ est claire là-dessus. Le codebase est conçu pour le 32-bit de l'époque iPhone OS 2.x et 3.0, et l'équipe assume : les jeux post-iOS 7 avec leurs modèles freemium, c'est pas leur combat. Eux, ils préservent les classiques d'avant que le mobile gaming devienne un casino déguisé.
D'ailleurs, si la
récente ouverture d'Apple aux émulateurs sur l'App Store
vous a donné des idées, sachez que TouchHLE ne peut pas tourner sur iOS lui-même... il a besoin de compilation JIT, et Apple bloque ça sur sa propre plateforme. Hop, on reste donc sur PC ou Android.
Pour l'installer, c'est dispo sur
GitHub
avec des releases pour Windows, macOS et Android. Il vous faudra vos propres fichiers .ipa (les apps iPhone de l'époque), le projet ne fournit rien pour des raisons légales évidentes. Mais si vous avez gardé des backups iTunes d'il y a 15 ans... c'est le moment de les ressortir.
Perso, je trouve l'approche pas con. Plutôt que de s'acharner à reproduire le hardware Apple bit par bit (ce qui serait un cauchemar légal et technique), ils ont choisi la voie pragmatique : faire croire aux apps qu'elles sont chez elles, sans jamais toucher au code d'Apple. Et ça c'est malin !
Soyez honnêtes, c'est quoi votre dernier message de commit ? "fix", "update", "refactor" ou les grands classiques "Ça marche, on ne touche plus" ou "azertyuiop^$" ?
Si vous vous reconnaissez, alors Lumen va peut-être vous sauver la mise.
Lumen
c'est un outil en ligne de commande écrit en Rust qui utilise l'IA pour vous aider à gérer votre workflow Git. En gros, vous stagez vos fichiers, vous lancez lumen draft et hop, l'IA analyse vos modifications pour générer un message de commit propre au format conventionnel. Fini les "fixed stuff" à 3h du mat.
Mais le truc va plus loin que ça puisque vous pouvez aussi lui demander d'expliquer un commit avec lumen explain HEAD (ou un hash, une plage de commits...). Pratique quand vous tombez sur du code écrit par vous-même il y a 6 mois et que vous n'y comprenez plus rien. D'ailleurs, y'a même une fonctionnalité de recherche interactive dans l'historique avec lumen list si vous avez fzf d'installé.
Et le plus cool, c'est la commande lumen operate. Vous lui décrivez en langage naturel ce que vous voulez faire genre "squash mes 3 derniers commits" et il vous génère la commande Git correspondante. Avec un warning si la commande est potentiellement destructrice et une demande de confirmation avant exécution, histoire de pas faire de bêtises.
Côté providers, c'est flexible... OpenAI, Anthropic Claude, Gemini, Groq, DeepSeek, Ollama pour du local, et d'autres encore... Vous configurez ça une fois avec lumen configure pour les commandes IA et c'est parti. Le diff viewer intégré est pas mal non plus (et lui fonctionne sans config), avec une vue côte à côte dans le terminal et la possibilité de naviguer entre les hunks.
L'installation se fait via Homebrew sur Mac/Linux avec brew install jnsahaj/lumen/lumen ou via Cargo si vous avez Rust. C'est open source sous licence MIT.
Perso, je trouve que c'est le genre d'outil bien pratique pour ceux qui galèrent avec leurs messages de commit ou qui passent leur temps à chercher des commandes Git obscures. Et le fait que ça tourne avec différents providers IA, y compris en local avec Ollama, c'est également un vrai plus pour ceux qui veulent pas envoyer leur code sur des serveurs externes.
Le risque interne a toujours représenté un défi pour les organisations. Sa définition a évolué au fil du temps mais sa réalité est la même. Historiquement, le terme « interne » désignait une personne physiquement présente dans l’entreprise : un employé présent au bureau ou un prestataire sur site.
Cette représentation a changé. Les utilisateurs sont désormais dispersés entre le bureau, la maison et d’autres espaces de télétravail, les données résident souvent dans le cloud, et le périmètre traditionnel s’est volatilisé. Aujourd’hui, toute personne ayant accès à cet environnement de confiance est, par définition, un interne.
Ainsi, une question se pose : si un terminal est compromis par un malware avec un accès de type commande-et-contrôle, s’agit-il d’une attaque interne ? Si l’on se réfère à la seule question de l’accès aux données, l’adversaire détient désormais les mêmes privilèges qu’un interne légitime.
Le défi de la détection
Le véritable défi réside dans le fait que les acteurs malveillants sont devenus extrêmement habiles à exploiter ce paysage en mutation. Une fois qu’ils parviennent à compromettre une identité ou un terminal, que ce soit par hameçonnage, en utilisant un malware ou en obtenant des identifiants volés, ils héritent effectivement des permissions et privilèges d’un utilisateur légitime.
À partir de ce moment-là, leurs actions, déplacements et schémas d’accès deviennent presque indiscernables de ceux du personnel de confiance de l’organisation. Plus ces adversaires s’approchent des systèmes critiques et des données sensibles, plus il devient difficile pour les mesures de sécurité traditionnelles de les distinguer des véritables employés ou opérateurs systèmes.
Lorsqu’un attaquant a pénétré dans les systèmes d’une organisation, il devient pratiquement indétectable, semblable aux personnes chargées de gérer et sécuriser ces systèmes. Cet attaquant devient alors un administrateur systèmes.
Cette approche furtive autrement appelée “exploitation des ressources locales” (Living Off The Land, LOTL) s’explique par le fait que les attaquants évitent délibérément de se faire remarquer en utilisant des outils, identifiants et processus déjà présents et approuvés dans l’environnement, plutôt que d’introduire des logiciels suspects ou des comportements inhabituels. Ils restent sous les radars, se fondent parfaitement dans les activités légitimes des utilisateurs, et imitent les opérations quotidiennes de manière à passer inaperçus.
Leur fonctionnement est alors comparable au fait d’entrer dans une entreprise vêtu d’un costume, avec assurance, en adoptant les manières et les routines des employés. Personne ne remet votre présence en question, car vous donnez l’impression d’appartenir à l’organisation et vous agissez en accord avec les habitudes établies.
Cette capacité à se fondre dans la masse représente un défi majeur pour la détection, rendant l’analyse comportementale et la surveillance continue plus cruciales que jamais.
Une défense efficace est imprévisible
Pour détecter ces attaquants, les organisations doivent se concentrer sur le comportement plutôt que sur l’identité seule. Il convient alors d’observer et d’identifier les écarts par rapport au comportement normal. Qu’il s’agisse d’un acte malveillant ou d’un compte compromis, les schémas comportementaux sont souvent similaires lorsque l’objectif est d’accéder à des ressources de grande valeur et à des données sensibles. En mettant en place des pièges pour détecter une activité inhabituelle, les équipes informatiques peuvent intercepter les menaces internes avant qu’elles ne dégénèrent en incidents majeurs.
Cependant, les pièges à eux seuls ne suffisent pas à garantir une résilience totale. Le Zero Trust reste l’élément crucial de toute stratégie de défense. Cette approche repose sur le principe que la confiance ne peut être ni statique ni implicite : elle doit être continuellement évaluée. Une authentification forte, des terminaux d’entreprise sécurisés et une surveillance continue ont rendu plus difficile la compromission des systèmes par les attaquants. Pourtant, les décideurs en matière de sécurité doivent aller plus loin en adoptant ce que l’on appelle la confiance négative (Negative Trust).
La confiance négative introduit une tromperie contrôlée et de l’imprévisibilité dans les systèmes afin de perturber les attaquants. Cette approche est efficace car la prévisibilité constitue un risque que beaucoup d’organisations négligent. Les entreprises fonctionnent souvent de manière trop standardisée, ce qui facilite le cheminement et les méthodes des adversaires. En rendant les systèmes imprévisibles, en introduisant de la variabilité et en ajoutant du bruit contrôlé dans l’environnement, il devient plus difficile pour les attaquants de se déplacer et plus facile pour les défenseurs de détecter leur présence.
En effet, lorsque les données sont chiffrées, l’entropie augmente et les données semblent aléatoires. Les adversaires détestent l’entropie. À l’intérieur d’un environnement, la prévisibilité produit le même effet. Plus les systèmes sont prévisibles, plus il est facile pour les attaquants de se déplacer sans être détectés. La confiance négative ajoute du bruit, augmente l’entropie et rend l’environnement imprévisible, forçant ainsi les attaquants à tomber dans des leurres.
Perspectives
À mesure que les adversaires utilisent des sites de confiance pour se dissimuler à la vue de tous, ils se connectent plutôt que de « pirater » leur accès aux organisations. Chaque attaque commence désormais à ressembler à une attaque interne, que l’utilisateur soit réellement employé ou non.
C’est pourquoi chaque menace doit être traitée comme une menace interne. Pour ce faire, il faut réduire les vecteurs d’attaque en suivant les principes du Zero Trust, puis en ajoutant du bruit par le biais de la confiance négative. C’est là, la voie à suivre.
Les organisations doivent nettement améliorer leur capacité à détecter les comportements malveillants, surtout à une époque où les adversaires sont prêts à payer des employés pour qu’ils divulguent des données ou remettent simplement des cookies d’authentification issus de leurs navigateurs. Alors que l’accès est le nouveau périmètre, le comportement de chaque utilisateur est le seul véritable indicateur de confiance.
*Tony Fergusson est CISO en résidence chez Zscaler
This collection of examples discussing the question of the intrinsic security characteristics of programming languages. Through illustrations and discussions, it advocates for a different vision of well-known mechanisms and is intended to provide some food for thoughts regarding languages and development tools, as well as recommendations regarding the education of developers or evaluators for secure software.
La 12ᵉ édition de Kernel Recipes s’est tenue à Paris du 22 au 24 septembre 2025, et comme chaque année, l’événement a rassemblé un bel échantillon de la communauté du noyau Linux : développeurs, mainteneurs, testeurs, contributeurs, et passionnés venus échanger autour du projet du noyau.
Trois jours intenses de présentations, de discussions informelles, de caféine et de partages d’expériences — bref, un cru encore une fois très riche. Les sujets ont couvert un large spectre : du développement des sous-systèmes du noyau à la maintenance, en passant par la sécurité ou la performance. Cette année encore quelques interventions concernant l'impact de BPF et la place grandissante de Rust dans le projet.
Les slides et enregistrements vidéo de toutes les présentations sont désormais en ligne !
Nous tenons à remercier l'ensemble des speakers qui encore une fois ont fait de cette 12e édition une réussite : Maira CANAL, Dorinda BASSEY , Matthew WILCOX, Melissa WEN, Andrea RIGHI, Greg KH, Thomas Schwinge, Thara Gopinath, SJ Park, Roman Gushchin, Leonardo Brás, Song Liu, Julia LAWALL, Boris Brezillon, Thomas Weissschuh, Indu Bhagat, Alice Ryhl, Vlastimil Babka, Lorenzo Stoakes.
Un remerciement tout particulier à Paul McKenney notre parrain cette année qui a fournit un travail énorme pour nous aider à boucler cette édition.
Un grand merci également au talent de Frank Tizzoni qui avec ses dessins est devenu incontournable à la conférence. Merci à Anisse Astier pour son live blog et sa capacité incroyable à retranscrire l'essentiel de cette conférence.
Chapeau bas à Erwan Velu pour ses lancers de micro, ses photos et son aide à l'organisation, et à Jean-Christophe Huwette pour nous permettre de proposer tous les ans un live stream impeccable et des vidéos pour tout le monde.
Enfin un grand merci à nos sponsors sans lesquels nous ne pourrions pas proposer depuis 12 ans cet événement à Paris, un événement qui reste abordable, convivial : Meta, AMD, Libre Computer, Collabora, Haproxy, Igalia, Jumptrading, Linux Foundation, Criteo R&D, Cyberzen, ANSSI, Linux Pratique.
Bonjour les gens ! Me revoilà (une fois de plus, ça n’en finit plus …) après plusieurs années d’arrêt de blogging pour tout un tas de raisons, autant personnelles que professionnelles (j’y reviendrai peut-être un de ces jours). Et histoire de bien re-commencer, rien de mieux qu’un article dithyrambique (on aime bien en général, vu […]
Le procès antitrust adtech contre Google oppose la demande de cession d’AdX à des engagements de conduite, enjeu crucial pour l’équilibre publicitaire en ligne.
Connexion
