❌

Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
Aujourd’hui — 3 mai 2026Flux principal

Un C-3PO grandeur nature transformé en assistant vocal qui répond pour de vrai

✇Korben
Par : Vincent Lautier
3 mai 2026 à 08:20

Un maker a transformé une réplique grandeur nature de C-3PO en assistant vocal interactif, et le résultat est franchement convaincant. Sa version du droïde papote, répond à vos questions, et tient même une conversation, le tout sans dépendre du moindre cloud une fois en local.

Le truc tient sur un Raspberry Pi 5 planqué dans la coque dorée du droïde. Un micro capte ce que vous racontez, un moteur de speech-to-text le transcrit, et un LLM local s'occupe de comprendre votre question pour formuler une réponse. Jusque là, rien de fou c'est même devenu même assez classique.

Le truc rigolo, c'est la couche par dessus. L'auteur a ajouté un prompt système qui force le LLM à répondre comme C-3PO le ferait : un peu anxieux, très formel, avec ce ton un brin pompeux qu'on connaît tous. Du coup, quand vous lui demandez bêtement la météo, vous pouvez vous prendre une réponse genre "Oh dear, je crains que les conditions atmosphériques ne soient guère favorables à un déplacement humain". Très C-3PO.

Pour la voix, le projet utilise un modèle synthétique entraîné sur les dialogues d'Anthony Daniels, l'acteur original. Le son passe ensuite par une chaîne d'effets audio qui ajoute la résonance métallique et le léger souffle qu'on entend dans les films. Le résultat n'est pas parfait, mais ça reste franchement bluffant pour un projet bricolé à la maison.

Tout le code est dispo en open source, ce qui veut dire que vous pouvez théoriquement le reproduire chez vous, à condition d'avoir une réplique C-3PO sous la main. Ce qui n'est pas le plus simple. Pour les budgets plus modestes, l'auteur précise que le pipeline tourne aussi très bien dans une simple enceinte connectée custom, le côté droïde doré n'étant pas indispensable au fonctionnement.

Le seul vrai bémol, c'est la latence. Entre le moment où vous parlez et la réponse vocale, comptez quelques secondes, ce qui casse un peu l'illusion d'avoir affaire à un assistant réactif. Mais bon, le vrai C-3PO du film mettait aussi trois plombes à comprendre les ordres, donc on peut presque considérer ça comme un détail de fidélité au personnage.

Source : Hackaday

Japan Airlines teste des robots humanoïdes pour charger les bagages

✇Korben
Par : Vincent Lautier
1 mai 2026 à 11:33

Japan Airlines va confier la manutention des bagages à des robots humanoïdes sur les pistes de l'aéroport Haneda. Le test démarre en mai 2026, dure deux ans, et implique pour commencer deux machines posées au milieu des bagagistes humains.

L'opération est pilotée par JAL Ground Service avec GMO AI & Robotics. Les robots viennent de Chine : un Unitree G1 d'environ 1m30 et un Walker E d'UBTECH.

Le programme est découpé en plusieurs étapes (cartographie du site, simulations en environnement reconstitué, puis tarmac réel), avec à terme l'idée de leur faire transporter les containers de fret, manipuler les leviers de verrouillage et même nettoyer les cabines une fois les avions vides. L'autonomie annoncée est de 2 à 3 heures, avant qu'il ne faille recharger la machine.

Sauf que la première démo publique a calmé tout le monde. Le G1 a tapoté un colis sur le tapis roulant et fait coucou à un humain, mais personne ne l'a vu soulever quoi que ce soit.

La presse anglo-saxonne a gentiment moqué la chose : démarche hésitante, gestes cosmétiques, et surtout aucune preuve de capacité à porter une valise standard.

Le Japon n'a pas le choix. Population vieillissante, faible immigration, et tourisme record qui sature les infrastructures : les aéroports japonais galèrent à recruter des bagagistes, et la situation ne va pas s'arranger dans les prochaines années.

Du coup, plutôt que d'investir dans des bras articulés industriels qui demandent de repenser tout le poste de travail, JAL parie sur des humanoïdes capables de s'intégrer dans un poste conçu pour des humains. 

En pratique, on est encore loin du compte. Une valise standard pèse entre 20 et 30 kg. Un humanoïde d'environ 35 kg sur deux jambes qui tient à peine debout, ce n'est pas vraiment l'outil idéal pour balancer du Samsonite à la chaîne pendant huit heures. JAL le sait.

D'où les deux ans de test prévus avant tout déploiement réel, et l'envie d'observer ce qui marche, ce qui casse, et ce qui finira aux oubliettes. Les deux fournisseurs choisis ne sont d'ailleurs pas des inconnus : Unitree et UBTECH se positionnent comme les gros chinois de l'humanoïde, face à un Tesla Optimus encore largement scénarisé.

Vous l'avez compris  on est plus dans la com' que sur de l'efficacité pure. Faire coucou à un bagage, ça ne le met toujours pas en soute.

Source : ARS Technica

Copy Fail - Une IA trouve la faille Linux que personne n'a vue

✇Korben
Par : Korben ✨
30 avril 2026 à 09:27

732 octets, c'est tout ce qu'il faut pour passer de simple utilisateur à root sur n'importe quel Linux non patché compilé depuis 2017, soit la quasi-totalité des kernels. Cette faille béante s'appelle Copy Fail (CVE-2026-31431), elle a été dénichée par Taeyang Lee de chez Theori avec leur outil d'audit IA Xint Code. Et comme elle vient d'être divulguée hier sur la liste oss-security et qu'en plus, ils ont fait un joli petit site qui explique tout comme ça fonctionne, je vais essayer de tout vous expliquer !

La faille elle-même est moche mais surtout, c'est un agent IA qui l'a sorti en une heure environ. C'est un bug que la communauté kernel a laissé passer durant près de 9 ans et qui se trouve dans le sous-système crypto.

En gros, le noyau Linux expose une interface réseau spéciale pour accéder aux opérations de chiffrement depuis un programme normal, sans droits particuliers.

Et depuis 2017, une optimisation dans ce mécanisme a créé une situation bizarre : un fichier en lecture seule sur le disque, disons un binaire système, peut se retrouver dans la zone de sortie d'une opération de chiffrement .C'est la zone que votre programme a le droit de modifier.

Il suffit alors d'enchaîner un appel système particulier (splice) pour écrire 4 octets au bon endroit, on répète ça en boucle, et on modifie progressivement un binaire système de votre choix comme par exemple /usr/bin/su.

Et voilà, vous êtes root !

Maintenant, si vous administrez un serveur, le plus propre reste de patcher le kernel via votre distro. En attendant le patch, la mitigation dépend de comment votre distro a compilé le module algif_aead, et là il y a deux situations bien distinctes.

Cas 1 - Distros où le module est chargeable dynamiquement (Ubuntu, Debian, Arch, etc.). Vous le bloquez avec :

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead

Cas 2 - Distros entreprise où le module est compilé en dur dans le kernel (RHEL, Rocky Linux, AlmaLinux, Oracle Linux, SUSE Enterprise...). Là, attention au piège : lsmod | grep algif_aead ne renvoie rien, mais ça ne signifie PAS que c'est désactivé. Le code est embarqué directement dans le vmlinuz, donc rmmod et la blacklist via /etc/modprobe.d/ sont sans effet (vous aurez "Module algif_aead is builtin"). La vraie mitigation passe par la kernel command line au boot :

sudo grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init"
sudo reboot

Ça empêche l'init_call du module de tourner au démarrage. Vous vérifiez ensuite avec cat /proc/cmdline que le paramètre est bien pris en compte. Si vous voulez aller encore plus loin, il est aussi possible de bloquer toute la surface d'attaque AF_ALG via seccomp au niveau de chaque service exposé.

Le PoC est également trouvable. C'est un script Python (Python 3.10+ obligatoire pour os.splice) capable de faire tomber Ubuntu 24.04 LTS, Amazon Linux 2023, RHEL 10.1 et SUSE 16 avec exactement le même code.

Dans une première version j'avais écrit que SELinux en mode enforcing par défaut bloquait l'exploit sur Fedora et RHEL. C'est inexact, et je remercie le lecteur qui m'a fait corriger. La policy SELinux par défaut de Fedora et RHEL autorise les contextes utilisateurs à créer des sockets AF_ALG, et l'exploit écrit directement dans le page cache kernel sans déclencher les hooks LSM file-based.

Donc SELinux enforcing ne bloque pas Copy Fail tel que livré par défaut. Le seul OS immune via SELinux est GrapheneOS , qui durcit la policy AOSP en réservant AF_ALG au seul process dumpstate. Ceux qui veulent tester sans Python peuvent aussi regarder du côté du port C indépendant , un exécutable statique de 1,7 Ko sans dépendance externe.

Les comparaisons avec Dirty COW et Dirty Pipe pleuvent, sauf que là où Dirty COW exigeait du timing précis et où Dirty Pipe demandait une manipulation spécifique du pipe-buffer, Copy Fail tape tout pareil sur 4 distribs majeures sans rien avoir à ajuster.

Et côté sévérité officielle, c'est du 7.8/10 donc c'est assez élevé !

Pour trouver cette faille, Xint Code, l'agent IA de Theori, n'a pas tâtonné à l'aveugle. Taeyang Lee lui a surtout glissé un prompt très précis qui lui demandait d'examiner tous les chemins accessibles depuis un programme utilisateur dans le sous-système crypto, en insistant sur le fait que splice() peut faire atterrir des fichiers en lecture seule dans des zones modifiables.

Une heure plus tard, Copy Fail sortait comme trouvaille critique ! Theori précise que le même scan a aussi remonté d'autres vulnérabilités encore sous embargo. Brrrrrr.... Tremblez simples mortel !

Ouais donc ouais, l'IA n'a pas remplacé l'expertise humaine, mais elle l'a démultipliée. Car Lee savait où regarder, et Xint Code a juste fait ce qu'il aurait fait mais en plus rapide ! C'est pas magique donc... Mais ça fait gagner du temps !

L'exploit est dispo ici sur le GitHub de Theori et côté impact, c'est costaud sur les hôtes multi-users et tout ce qui est environnements partagés. Je pense aux conteneurs Docker, aux clusters Kubernetes, aux pipelines CI/CD...etc.

Après si y'a que vous qui avez accès à votre serveur, c'est un peu moins critique car il faut forcément un accès local pour l'exploiter. C'est la même logique de chaînage que BlueHammer côté Windows , sauf qu'ici la marche jusqu'à root est encore plus petite.

Comment tester le PoC sur une machine de test ?

Si vous avez une VM sous Ubuntu 22.04 non patchée (kernel 5.15.x), voilà exactement ce qui se passe, testé en conditions réelles. Ne faites ça que sur une machine dont vous êtes propriétaire et où vous avez l'autorisation explicite.

Étape 1 - Cloner le PoC et vérifier le hash

manu@ubuntu:~$ git clone https://github.com/theori-io/copy-fail-CVE-2026-31431
Cloning into 'copy-fail-CVE-2026-31431'...
remote: Enumerating objects: 9, done.
Resolving deltas: 100% (1/1), done.

manu@ubuntu:~$ cd copy-fail-CVE-2026-31431 && sha256sum copy_fail_exp.py
a567d09b15f6e4440e70c9f2aa8edec8ed59f53301952df05c719aa3911687f9 copy_fail_exp.py

manu@ubuntu:~/copy-fail-CVE-2026-31431$ id
uid=1000(manu) gid=1000(manu) groups=1000(manu) ← utilisateur normal, pas root

Theori ne publie pas de hash officiel dans leur README, mais le SHA256 ci-dessus est celui du PoC tel qu'il est actuellement sur le repo. Si votre hash diffère, ne lancez pas le script.

Étape 2 - Lancer l'exploit

manu@ubuntu:~/copy-fail-CVE-2026-31431$ python3 copy_fail_exp.py

# L'exploit écrit 4 octets à la fois dans le page cache de /usr/bin/su
# via l'interface AF_ALG du kernel (authencesn + splice)
# Aucune race condition, aucun timing précis requis.

Mot de passe :

Le script utilise AF_ALG (l'interface crypto du kernel) combiné à splice() pour écrire un shellcode de 160 octets directement dans le page cache de /usr/bin/su, sans jamais toucher le disque. Il remplace ensuite le binaire patché pour exécuter un shell root.

Étape 3 - Shell root obtenu

root@ubuntu:~# id
uid=0(root) gid=1000(manu) groups=1000(manu)

root@ubuntu:~# whoami
root

root@ubuntu:~# uname -r
5.15.0-143-generic

# Kernel 5.15 vulnérable confirmé - Ubuntu 22.04 non patché

Notez le uid=0(root) alors qu'on est parti d'un uid=1000 sans aucun mot de passe, aucune race condition, aucun timing à ajuster. Brutal.

Étape 4 - Accès aux fichiers root-only

root@ubuntu:~# cat /etc/shadow | head -3
root:*:20271:0:99999:7:::
daemon:*:20271:0:99999:7:::
bin:*:20271:0:99999:7:::

root@ubuntu:~# cat /etc/passwd | grep root
root:x:0:0:root:/root:/bin/bash

/etc/shadow est normalement illisible pour un utilisateur standard. Là, avec notre PoC en Python et zéro interaction supplémentaire, on y accède comme si de rien n'était. Sur un serveur multi-utilisateurs, c'est game over pour tous les comptes présents.

Sur un système patché, le script échoue proprement à l'étape 2 avec un message d'erreur. C'est aussi simple que ça pour vérifier votre exposition.

Bref, mettez à jour vos kernels ou désactivez le module fautif rapidement !

Source

Starcraft2.ai - Le coach IA SC2

✇Korben
Par : Korben ✨
30 avril 2026 à 09:00

Starcraft2.ai débarque en force pour les joueurs de StarCraft 2 et de Brood War qui voudraient disséquer leurs replays sans bouger de leur navigateur. Le créateur de ce site, qui se présente sous le pseudo de Tomkit, a sorti un analyseur gratuit qui combine un moteur de rendu isométrique et un coach IA.

Vous balancez un fichier .SC2Replay (ou .rep pour Brood War), et chose incroyableuuuh, le site reconstruit votre partie complète en vue isométrique avec mouvement des unités, brouillard de guerre activable / désactivable et heatmaps. Comme ça plus besoin de relancer le client pour mater une partie.

Et le truc qui tue, c'est que vous pouvez aussi partager n'importe quel replay via une simple URL.

L'outil derrière ce projet, c'est sc2reader (la bibliothèque Python de référence pour Starcraft) qui parse intégralement les binaires des replays : Position détaillée des unités, séquence des ordres de construction, économie, kills, tout est extrait du fichier directement.

Le truc cool, c'est évidemment le coach IA. L'outil envoie le contexte de la partie (courbe d'éco, build order, échanges d'unités, résultat des batailles) à Claude, qui sort alors un debrief avec des conseils actionnables. Par exemple, le LLM identifie le type de stratégie déployée (timing attack, macro, all-in, cheese) et balance des recommandations basées sur les standards pro. C'est quand même bien plus utile que tous ces guides génériques qu'on retrouve en ligne.

Puis ce qui est cool avec ce logiciel, c'est aussi le support de Brood War et à où j'écris ces lignes, c'est l'un des seuls analyseurs encore maintenus pour le vieux premier StarCraft . Donc pour ceux qui parmi vous ont encore des replays archivés depuis l'ère du modem 56k, c'est carrément une bonne nouvelle !

Bref, si vous jouez encore à SC2 ou si vous voulez juste mater de beaux replays sans lancer le jeu, c'est par ici .

Forget Smarter AI, This Robot Thinks Presence Is the Point

✇Yanko Design
Par : Ida Torres
2 mai 2026 à 20:45

We keep building AI to do more. More answers, more speed, more certainty. Designer Mehrnaz Amouei looked at that trajectory and asked a fundamentally different question: what if we built AI to be more present instead? The result is POCO, a soft robotic companion that might be one of the most quietly radical design concepts to emerge in recent years. It doesn’t talk over you, doesn’t flood you with information, and it doesn’t pretend to know things it doesn’t know. POCO sits with you. Literally.

At its core, POCO is a soft, tactile object that pairs with a smartphone, which serves as its computational brain and face. A soft textile body wraps around the device, transforming rigid, glass-and-metal technology into something that moves, breathes, and gestures in response to your presence. Together, they create something that sits somewhere between object, creature, and companion, and that deliberate ambiguity is very much intentional. You’re not quite sure what to call it, and that’s entirely the point.

Designer: Mehrnaz Amouei

Amouei developed POCO through research at the University of Illinois at Chicago, grounding the project in studies on loneliness and trust. Her findings indicated that people don’t actually want AI that projects certainty or control. They want availability and responsiveness. They want something that shows up without taking over. From those findings came the concept of “constructive interdependence,” a design philosophy where POCO’s limitations aren’t bugs to be patched but features embedded directly into the interaction model itself. The robot communicates what it can and cannot do through its behavior and physical states, which is a level of honesty you don’t often get from technology that typically overpromises and underdelivers.

I think that matters more than it might initially seem. The dominant conversation around AI right now is almost entirely about expansion: more capability, more integration, more autonomy. POCO pushes back on that without being preachy about it. It reframes the question of what good AI design actually looks like, and the answer it offers isn’t “smarter,” it’s “more trustworthy.” That is a genuinely different value system, and it feels overdue.

The sustainability dimension is also worth paying attention to. Rather than introducing new hardware and generating more electronic waste, POCO repurposes a device most people already own. That decision isn’t just a nice bonus; it’s built into the concept from the start, aligning with the UN’s Sustainable Development Goals around mental well-being and responsible consumption. In product design terms, that means the project was developed with a broader cultural and environmental context in mind, not just a user persona sitting in a lab.

Physically, POCO responds to touch, movement, and environmental cues. It adapts to a user’s preferences while maintaining a consistent identity, which is a surprisingly nuanced balance to strike in any product, let alone one sitting at the intersection of soft robotics and emotional design. Because interaction happens through touch rather than voice commands or screen taps, there’s an intentional slowing down embedded in the experience. You can’t rush a tactile exchange the same way you can type faster or speak louder. That shift from speed to presence feels like a meaningful counter-proposal to how most tech is currently designed. We’ve grown so accustomed to interfaces that demand our attention that a device asking only for our company reads almost as radical.

POCO has already earned an Honorable Mention from the International Design Awards and drawn coverage from major design publications. Whether it ever moves into consumer production remains an open question. But as a design statement, it’s doing exactly what the best concept work should: prompting us to reconsider what we actually want from the technology we live with, and whether expanding capability was ever really the right goal. Maybe the most interesting AI isn’t the one that knows the most. Maybe it’s the one that knows when to just stay close.

The post Forget Smarter AI, This Robot Thinks Presence Is the Point first appeared on Yanko Design.

À partir d’avant-hierFlux principal

Microsoft partnership has "limited our ability": Leaked memo reveals OpenAI's open hostility towards one of its biggest investors

✇Windows Central - News, Forums, Reviews, Help for Windows 10 and all things Microsoft.
Par : [email protected] (Kevin Okemwa)
23 avril 2026 à 11:03
The ChatGPT maker indicated that its new partnership with Amazon will help enhance its enterprise market share while highlighting key constraints in its Microsoft tie-up.

Satya Nadella with Sam Altman at a conference

Sam Altman is apparently openly hostile towards Microsoft.

❌
❌