Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierFlux principal

Bambu Lab épinglé pour violation de licence open source depuis quatre ans

26 mai 2026 à 15:03

C'est la Software Freedom Conservancy (SFC), l'ONG américaine qui défend les licences libres, qui a sorti l'affaire. Bambu Lab, l'un des plus gros fabricants d'imprimantes 3D grand public du moment, viole l'AGPLv3 depuis environ quatre ans selon l'organisation. Pas qu'un peu donc.

Pour comprendre l'histoire, il faut savoir que Bambu Studio, le slicer maison de la marque (c'est le logiciel qui transforme un modèle 3D en instructions de découpage pour l'imprimante), est en réalité un dérivé de PrusaSlicer, lui-même basé sur Slic3r.

Les deux sont sous licence AGPLv3, ce qui oblige toute boîte qui distribue un logiciel dérivé à publier son code source dans la même licence. Du coup, Bambu Studio aurait dû suivre les mêmes règles depuis le début.

Sauf que voilà, le SFC pointe deux violations très claires. D'abord, une bibliothèque maison appelée libbambu_networking, qui gère toute la communication entre le slicer et les serveurs cloud de Bambu, n'a jamais vu son code publié. La marque reconnaît même son existence dans son propre README sur GitHub. Pire encore, quand le développeur Paweł Jarczak a sorti une version modifiée d'OrcaSlicer (un fork concurrent, c'est-à-dire une copie communautaire améliorée) qui restaurait certaines fonctions cloud bloquées par Bambu, l'entreprise lui a envoyé une mise en demeure pour faire retirer son projet.

C'est la deuxième violation selon le SFC, parce que l'AGPLv3 interdit explicitement d'ajouter des restrictions supplémentaires à ce que la licence autorise. En clair, Bambu n'a pas le droit d'invoquer ses conditions d'utilisation pour empêcher quelqu'un d'exercer les droits que la licence donne. 

Côté riposte, le SFC a lancé un projet baptisé baltobu. Trois objectifs : refaire la fameuse bibliothèque à partir de zéro par reverse-engineering (démonter le code propriétaire pour le réécrire proprement), maintenir le fork OrcaSlicer de Jarczak, et créer un remplaçant complet de Bambu Studio. Une levée de fonds visant 250 007 dollars, ouverte jusqu'au 17 juillet, a déjà atteint son premier objectif pour financer des employés à ce travail sur le long terme. Si la cagnotte va au bout, de nouveaux employés pourront rejoindre le projet.

Bambu Lab a réagi du bout des lèvres. L'entreprise a publié un message reconnaissant que sa référence à des conditions d'utilisation et à une potentielle mise en demeure ait pu être perçue comme une menace légale, ce qu'elle regrette. Pas de modification réelle de la pratique pour autant. La bibliothèque reste fermée, et les pratiques cloud restent les mêmes.

Bref, une marque grand public qui surfe sur les briques open source sans en respecter les règles, ça finit toujours par se voir.

Source : Itsfoss

Tunarr - Recréer la télévision qu'on aime zapper dans Plex

Par : Korben ✨
1 mai 2026 à 07:08

Vous vous souvenez de l'époque où on s'écroulait comme des merdes dans notre canapé après une grosse journée de boulot et où on regardait juste ce que la télé nous balançait ? Pas de choix à faire sur Netflix, ni de recommandation sur l'Apple TV. On zappait juste en mode no-brain jusqu'à ce qu'on tombe sur une connerie qui réveille notre cerveau reptilien.

Eh bah le dev Chris Benincasa a créé Tunarr , un soft open source qui ressuscite ce truc-là en transformant votre Plex ou Jellyfin en chaîne de TV en continue.

Grâce à Tunarr, vous configurez vos chaînes dans une interface web (en glisser-déposer...), le soft émule un tuner HDHomeRun (le standard de la TV réseau aux US), que Plex, Jellyfin ou Emby reconnaissent ensuite comme une vraie source TV. Et voilà comment vous avez maintenant votre propre antenne maison.

Ou alors vous exportez en M3U pour des players IPTV comme Tivimate ou UHF, le tout avec un EPG intégré (c'est le guide des programmes), des bumpers (vous savez ces petites séquences Tchii Tchaaa ou M6 Mhmmmh des chaînes TV), des pubs vintage entre les programmes et même des clips musicaux pour faire authentique.

Bref, du déjà-vu, mais avec votre catalogue d'émissions à vous.

L'histoire de ce projet est d'ailleurs assez marrante car c'est un fork de dizqueTV (de vexorian), lui-même fork de pseudotv-plex (de DEFENDORe) et chacun de ces devs contribuent à Tunarr. 3 générations de mainteneurs qui collaborent sur le même projet, ça fait plaisir à voir car dans l'open source et la tech en général, ce genre de filiation c'est souvent rare tant les egos sont groooos.

Et côté fonctionnalités, c'est plutôt pas mal. Vous programmez vos chaînes par créneaux horaires (comme une vraie grille TV), par shuffle aléatoire ou par blocs cycliques. Vous balancez alors du contenu de remplissage entre les épisodes, vous personnalisez les profils de transcodage par chaîne, et vous regardez ça directement dans votre navigateur web ou via votre client Plex préféré.

De son côté, le hardware transcoding gère NVENC, VAAPI, Intel QuickSync et VideoToolbox sur macOS, donc votre GPU ne bosse pas pour rien.

Pour ma part, je me ferais bien une ambiance "C'est dimanche" qui balance des séries TV + vidéo gag et des docs sur la nature toute la journée, ou une "chaîne minuit" uniquement pour les vieux films d'horreur et les clips MTV de ma jeunesse ^^. Aaaah, nostalgie quand tu nous tiens ! Et je mettrais des vrais bumpers vintage entre les programmes, comme ça, ça donnerait l'illusion qu'on est sur une vraie programmation TF1 des années 90. Ce serait chouette non ?

Pour faire tourner ça, un Docker compose suffit (port 8000), avec un FFmpeg 6.1 minimum (7.1.1 recommandé). Vous lancez simplement :

docker run -d -p 8000:8000 -v ./tunarr-data:/config/tunarr chrisbenincasa/tunarr:latest

et c'est en ligne !

Maintenant sauf si votre Pi 3 a 2 Go de RAM, le transcoding 4K ne marchera pas mais sur du x86 récent ou un Pi 5, ça envoie carrément bien.

Et si vous préférez la méthode à l'ancienne, y'a également des binaires Linux, macOS, Windows, et même une image ARM pour Raspberry Pi . Le code est en TypeScript à 99,6%, sous license zlib (très permissive) et y'a des nouvelles releases régulières.

Voilà, ce projet n'a aucun sens dans le monde du streaming à la demande et c'est précisément pour ça que je vous en parle ! Si vous voulez retrouver l'ambiance zapping, c'est par ici ou sur le GitHub .

Et un GRAND merci à Johnny pour l'info !!

KULA - Le monitoring serveur Linux qui tient dans un seul binaire

Par : Korben ✨
1 mai 2026 à 06:53

Ouais, je sais, on est le 1er mai, et je suis pas censé bosser mais que voulez-vous on ne se refait pas ^^. Et si j'ai ouvert l'ordi ce matin, c'est pour vous parler de KULA !

KULA est un binaire tout simple qui permet de monitorer très facilement votre serveur Linux en temps réel, sans aucune dépendance. c0m4r , le dev derrière le projet, l'a codé en Go avec une obsession claire : Que ça marche partout sans rien installer à côté !

C'est vrai que les outils de monitoring temps réel sur Linux ont tendance à grossir avec le temps. Netdata est passé par exemple d'un script léger à une plateforme SaaS.

KULA veut faire exactement l'inverse ! Parce que si vous avez un VPS à 5 balles, un Raspberry Pi ou trois homelabs qui ronronnent dans le placard, c'est pas la peine de sortir un bazooka quand il y a ce petit binaire qui fait tout aussi bien.

Vous le posez sur la machine, vous lancez ./kula, et c'est plié ! Il y a même un installeur guidé en une commande (nia nia nia lisez le contenu du .sh avant de le lancer, nia nia nia, je me répète, je sais):

bash -c "$(curl -fsSL https://raw.githubusercontent.com/c0m4r/kula/refs/heads/main/addons/install.sh)"

Côté technique, le projet va chercher ses infos directement dans /proc et /sys toutes les secondes. Comme ça y'a pas besoin d'un programme "agent" séparé à installer, ni besoin de vous lancer dans du scraping HTTP. C'est juste KULA qui tourne en daemon et qui lit ce qui se passe au niveau du kernel.

Les données passent ensuite dans un moteur de stockage maison : un ring-buffer avec trois niveaux (1 seconde brut, 1 minute agrégé, 5 minutes agrégé), chacun ayant une taille max fixe (250 Mo, 150 Mo, 50 Mo par défaut). Et quand la limite est atteinte, les nouvelles données écrasent les vieilles. Comme ça l'usage disque est maîtrisé, et y'a pas besoin de faire de ménage.

Niveau métriques, c'est plutôt complet je trouve... CPU, GPU (VRAM, charge, conso), mémoire, swap, load average, processus par état, températures CPU/GPU/disque, batteries, entropie système, sync horloge. Le réseau remonte les débits par interface, les paquets par seconde, les erreurs, les drops, les retransmissions TCP, les connexions établies...etc.

Et côté disque c'est par composant : IOPS, lectures/écritures par seconde, octets/s, plus l'usage des systèmes de fichiers. Et bien sûr tout ce qui est containers Docker, podman, et même ces cgroups bruts dont vous êtes si fiers ^^, pour ceux qui font tourner des trucs sans Docker.

Et le truc auquel je ne m'attendais pas mais que j'aurais pu anticiper parce que c'est à la modeuuuuh, c'est l'assistant IA via Ollama. Vous configurez une instance Ollama locale, et le dashboard vous laisse causer à un modèle de votre choix qui peut analyser les courbes en cours, exporter du CSV par graphique, et même faire appel à une fonction get_metrics pour interroger les données en mode agent.

Tout ça en local bien sûr. C'est plutôt sympa pour debugger par exemple un pic de CPU récurrent à 3h du matin sans devoir vous taper des heures de graphes !

Le déploiement Docker c'est comme ça :

docker run -d --name kula --pid host --network host
 -v /proc:/proc:ro -v kula_data:/app/data c0m4r/kula:latest

Notez le paramètre --pid host et /proc:/proc:ro : car KULA a besoin de voir l'hôte et pas le container.

Bah ouais, c'est logique, sinon il va monitorer juste son propre container, ce qui n'a aucun intérêt, hein...

Notez que si vous êtes sur un VPS LXC mutualisé bas de gamme, certains hébergeurs restreignent l'accès à /proc du host... et là, malheureusement, KULA ne pourra remonter que ce qu'il voit ce qui est souvent pas grand-chose... sniiif.

Pour les puristes, y'a aussi des paquets .deb, .rpm, AUR pour Arch, et du multi-arch (amd64, ARM, RISC-V). Ça couvre à peu près tout ce qui se croise sur un homelab !

Et côté auth, c'est désactivé par défaut (le port par défaut est le 27960, pas le 80), mais quand vous l'activerez vous tomberez sur de l'Argon2id avec des jetons de session hashés en base.

Par contre, même si y'a quelques alertes internes (clock sync, low entropy, overload), vous n'aurez pas de notifications natives (pas de mail, ni Slack, ni webhook...etc). Et pas de support multi-node non plus puisque KULA monitore une machine à la fois.

Donc si vous avez 30 serveurs, faudra vous farcir 30 instances et 30 dashboards séparés. Pas glop ! Et bien sûr, c'est Linux only parce que tout repose sur /proc et /sys.

C'est encore un projet un peu jeune, donc à voir comment ça vieillit mais pour votre petit VPS perso d'amour ou une machine dans un setup d'auto-hébergement , c'est top pour esquiver à la fois htop qui est trop minimaliste et Grafana qui est trop usine à gaz.

Si vous voulez voir la démo, y'en a une ici : demo.kula.ovh !

Source

Eonvelope - Vos emails méritent aussi un backup local

Par : Korben
16 mars 2026 à 09:26

On archive nos photos avec Immich , nos documents avec Readur , nos mots de passe avec Vaultwarden ... mais nos emails ? Ah bah non, ça on les laisse chez Google en croisant les doigts pour que tout se passe bien jusqu'à la fin de nos jours. C'est quand même un peu dinguo quand on y réfléchit sérieusement.

Et pourtant, y'a des années de conversations là-dedans ! Des factures en pièce jointe, des confirmations de commande, des échanges pro avec votre comptable, des mots de passe envoyés en clair (oui, hélas, ça arrive encore). Du coup, quand un hébergeur mail décide de changer ses conditions générales ou de fermer boutique, tout part à la poubelle si vous n'y faites pas attention.

Eonvelope , c'est un outil open source en Python qui permet de sauvegarder automatiquement tout ça sur votre propre serveur et qui se lance avec un simple docker compose up.

Le truc, c'est que des outils comme Gmvault font déjà le boulot via cron, mais uniquement pour Gmail et en ligne de commande alors qu'Eonvelope, lui, un peu à la manière de Bichon , tourne en arrière-plan avec une interface web et archive en continu tous vos comptes. Franchement, c'est pas le même délire. Vous branchez vos comptes IMAP, POP3, Exchange, et même JMAP (le protocole poussé par Fastmail qui commence tout juste à se démocratiser), vous réglez la fréquence, et hop, vos mails atterrissent dans votre instance sans que vous ayez à y penser.

Attention par contre, c'est de l'archivage, pas un client mail... vous ne répondrez pas à vos mails depuis l'interface.

Côté installation, c'est du Docker avec seulement 2 conteneurs, le serveur web et la base de données. En fait, comptez 5 minutes chrono si vous avez déjà un serveur dédié ou un VPS, le fichier docker-compose.yml est fourni et les variables d'environnement sont bien documentées sur ReadTheDocs . Y'a même un mode basse consommation pour ceux qui font tourner ça sur un Raspberry Pi 4 avec 2 Go de RAM ou un petit Synology ! SSL et HTTPS sont inclus par défaut, et l'authentification multifacteur aussi.

Mais le vrai point fort, c'est les intégrations avec le reste de l'écosystème self-hosted. Concrètement, vous pouvez envoyer vos pièces jointes PDF vers Paperless-ngx pour l'OCR, les photos vers Immich, et exporter vos contacts vers votre carnet d'adresses Nextcloud. Y'a aussi un endpoint Prometheus pour brancher Grafana et suivre vos stats d'archivage. En gros, si vous avez déjà un homelab qui tourne, ça vient se brancher dessus comme une pièce de Lego.

L'interface web est en PWA (donc utilisable sur votre téléphone), avec un moteur de recherche, du filtrage par date et par expéditeur, des fils de conversation reconstitués et de l'import/export en EML et MBOX. Franchement, c'est propre. Y'a aussi une API REST pour ceux qui préfèrent scripter par-dessus plutôt que de passer par l'interface.

Le projet est sous licence AGPLv3 et son dev déclare l'utiliser lui-même au quotidien, ce qui est souvent bon signe. Notez que la migration depuis un backup existant n'est pas forcément fluide mais qui ne tente rien n'a rien !

Bref, ça comble un vrai manque dans la stack de nos machins auto-hébergés mais je trouve que l'approche est clairement plus intégrée que ce qui existe (genre MailPiler ou un combo fetchmail+dovecot). À surveiller donc !

Source

Scanopy - Quand votre réseau se documente tout seul

Par : Korben
16 mars 2026 à 06:34

Faut le reconnaitre, la doc et qui plus est, la doc réseau, c'est un peu le parent pauvre du homelab. Tout le monde sait qu'il faudrait la tenir à jour sur un petit wiki tout mignon mais personne le fait parce qu'on n'est pas cinglé et qu'on aime trop la vie pour ça. Heureusement, pour nous aider, y'a maintenant Scanopy qui est un outil open source qui scanne automatiquement votre réseau pour générer une topologie interactive incroyable qui se met à jour toute seule !

Pour l'installer, deux lignes suffisent :

curl -O https://raw.githubusercontent.com/scanopy/scanopy/refs/heads/main/docker-compose.yml
docker compose up -d

Et hop, l'interface est dispo sur le port 60072 de votre serveur ! Pas de config.

Concrètement, le truc balance du scan ARP pour trouver tous les hôtes (même ceux qui n'ont aucun port ouvert), puis il enchaîne avec un scan des 65 000 ports sur chaque machine qui répond. Comme ça, en quelques minutes sur un /24 classique, vous avez la cartographie complète de votre sous-réseau avec les services qui tournent dessus. Et quand je dis services, c'est pas juste "port 80 ouvert" puisque cet outil de zinzin reconnaît plus de 200 applis self-hosted comme Home Assistant, Plex, Jellyfin, PostgreSQL ou nginx. Par contre, attention, un scan de 65 000 ports sur tout un sous-réseau, ça peut chatouiller un peu votre IDS (système de détection d'intrusion) si vous en avez un.

D'ailleurs, si vous avez des équipements réseau un peu sérieux (switches manageables, routeurs), Scanopy sait aussi causer SNMP v2c et récupérer les données LLDP/CDP pour reconstituer les liens physiques entre vos appareils.

Et pour ceux qui font tourner pas mal de containers, il se branche directement sur le socket Docker pour détecter tout ce qui tourne là-dedans. En fait, c'est surtout cette combo "scan réseau + détection Docker" qui le rend utile, parce que la plupart des outils du genre font l'un ou l'autre mais jamais les deux.

L'interface de visualisation est plutôt classe comme vous pouvez le voir. Vous avez une vue topologique interactive où chaque hôte est cliquable, avec un système de branches et de versioning pour suivre l'évolution de votre réseau dans le temps (un peu comme Git, mais pour votre infra). Et y'a même de l'export en CSV, PNG et SVG. Et surtout la possibilité de partager des liens publics vers vos schémas... C'est franchement pratique quand vous bossez en équipe ou que vous devez montrer à votre boss pourquoi le NAS de votre PME rame sa mère.

Côté tambouille technique, c'est du Rust pour le moteur de scan et du Svelte pour l'interface, le tout sous licence AGPL-3.0. En gros, vous avez un serveur qui héberge l'UI et stocke les données, et des daemons qui font le boulot de scan à proprement parler. Tout est containerisé, comme ça pas besoin d'installer un agent sur vos machines côté réseau... c'est complètement agentless quoi. D'ailleurs, si vous aviez l'habitude de balancer des scans nmap à la main pour savoir ce qui traîne sur votre réseau, Scanopy automatise tout ça et rajoute la couche visu par-dessus.

Le projet est hébergé sur GitHub et y'a aussi un déploiement possible via Proxmox ou Unraid pour ceux qui préfèrent. Seul prérequis, il vous faudra Docker et Docker Compose sur votre machine. Et n'oubliez pas que le projet est encore jeune, du coup ça bouge pas mal d'une version à l'autre. Et ça casse parfois. Mais c'est plutôt bon signe parce que ça veut dire que ça progresse !

Bref, si vous en avez marre de dessiner vos schémas réseau à la main, c'est par là !

Source

This Air Purifier Concept Looks Like Scandinavian Audio Gear

Par : JC Torres
18 février 2026 à 17:20

Air purifiers tend to look like medical equipment and come with apps you didn’t ask for. They arrive with dashboards, push notifications, and Wi-Fi setup rituals that turn “cleaner air” into another thing to manage on a phone. Most of them sit in corners behind plants because they look clinical, and no one wants to acknowledge the white plastic box while having guests over for dinner.

The Beolab Air 1 is a concept air purifier designed to sit in a room without announcing itself. It was developed as a student project and draws inspiration from the calm, material-driven design language of Bang & Olufsen’s Beolab line, though it’s not affiliated with the company in any way. The goal was to see what happens when you apply that kind of sculptural thinking to clean air, instead of just adding another screen to the wellness toolkit.

Designers: Ahaan Varma, Malhar Gadnis, Michelle Sequeira, Sharanya Karkera

The most refreshing part of the concept is the interaction model. A single button press is all it takes to start, with no app pairing, no IoT setup, and no onboarding routine. The project frames this as “digital detox,” which is a reasonable description when most purifiers try to sell you sensor graphs and weekly air quality reports. You turn it on the way you’d turn on a lamp or a speaker, then leave it to work.

The materials do a lot of the talking. Angled teak wooden ridges wrap the body and function as vents for filtered air, so the aesthetic choice also serves a purpose. Textured aluminum handles the rest of the exterior. The project’s own critique of the category is blunt: plastic yellows and looks cheap over time, while wood and metal age better. A purifier built to look like a piece of considered furniture has a better chance of earning a spot on a sideboard than one that resembles a hospital accessory.

Under the surface, there’s a plausible engineering stack. A high-efficiency BLDC fan delivers strong airflow while staying quiet, a HEPA filter handles particulate capture, and an MQ135 gas sensor pairs with PM2.5 sensing to monitor air quality without forcing anyone into an app. The concept keeps the monitoring internal and the feedback subtle, a soft ambient light band that changes gently rather than a display demanding attention.

Of course, that ambient feedback is the whole point. Clean air is invisible and usually silent, and a purifier that communicates the same way feels more appropriate than one with a scrolling PM2.5 count on a bright panel. You can check in when you feel like it, and the rest of the time it just works.

The concept calls out a genuine gap in the category: people want wellness that integrates quietly into a room, not hospital aesthetics, and yet another app. Whether or not Beolab Air 1 ever gets built, asking what a purifier looks like when treated with the same care as a premium speaker is a question the category probably needed someone to ask.

The post This Air Purifier Concept Looks Like Scandinavian Audio Gear first appeared on Yanko Design.

Ludus - Pour monter un lab de cybersécurité en une commande

Par : Korben
9 octobre 2025 à 15:21

Vous faites du pentest, de la recherche en sécu ou vous êtes juste un curieux qui aime bidouiller des environnements de test ? Dans ce cas, il faut absolument que vous vous montiez un lab cybersécurité ! Mais c’est vai que c’est souvent la galère… Y’a Active Directory à configurer, des VMs Windows à déployer, des réseaux isolés à créer, tout ça manuellement… Ça prend des heures, voire des jours. Heureusement, Ludus règle le problème ! Vous décrivez ce que vous voulez dans un fichier YAML, vous tapez une commande, et hop, votre lab est prêt.

Ludus , c’est donc un système d’automatisation open-source qui tourne sur Proxmox. Vous définissez votre environnement de test (ce qu’ils appellent un “range”) dans un fichier de config, et Ludus s’occupe de tout déployer. Active Directory, machines Windows avec Office et Chocolatey, réseaux isolés, firewall rules personnalisées, DNS interne… Tout ce qu’il faut pour un lab de red team, blue team ou purple team.

Le truc cool, c’est que Ludus utilise Packer et Ansible en arrière-plan. Les templates sont construits à partir d’ISOs vérifiées, et tout est déployé de manière reproductible. Comme ça si vous voulez 255 VLANs, pas de souci. Si vous avez besoin de règles firewall custom ou de définir rôles Ansible pour configurer vos machines, c’est fastoche. Bref, Ludus vous laisse faire du high-level en YAML tout en gérant la complexité technique pour vous.

L’isolation est également bien pensée. Vous pouvez couper vos VMs d’internet, prendre des snapshots avant de leur autoriser l’accès, et ne whitelister que les domaines ou IPs spécifiques dont vous avez besoin. Du coup, pas de télémétrie qui fuit, pas de mises à jour Windows qui cassent votre environnement de test. Vous contrôlez tout !

Pour l’accès, Ludus intègre un serveur WireGuard ce qui vous permettra de vous connecter depuis n’importe où via SSH, RDP, VNC ou KasmVNC. Pratique si vous voulez accéder à votre lab depuis l’extérieur sans exposer vos machines de test sur internet.

Techniquement, ça tourne uniquement sur Debian 12/13 avec Proxmox 8/9. Il vous faudra au minimum 32GB de RAM par range (environnement de test), 200GB de stockage initial plus 50GB par range supplémentaire, et un CPU x86_64 avec un score Passmark au-dessus de 6000. C’est des specs correctes, mais pas non plus délirant si vous montez un serveur dédié pour ça.

Après une fois que c’est en place, le workflow pour les utilisateurs est assez simple. Vous récupérez une clé API et une config WireGuard auprès de l’admin du serveur Ludus, vous installez le client Ludus, vous importez votre VPN, et vous pouvez gérer votre range via la ligne de commande.

Le projet est sous licence AGPLv3, donc full open-source et comme d’hab, le code est sur GitHub . C’est en train de devenir un outil de référence dans la communauté sécu pour qui veut des environnements de test reproductibles.

Bref, si vous en avez marre de passer des heures à configurer vos labs à la main, pensez à Ludus ! Un fichier YAML, une commande vite fait, et votre infrastructure de test est toute prête ! Après, vous pouvez toujours aller bidouiller manuellement dans Proxmox si besoin, Ludus ne vous en empêchera pas, mais pour le gros du boulot chiant, il automatisera tout.

Ah et la documentation est ici !

L'histoire de deux ados britanniques qui ont failli déclencher la 3e Guerre mondiale en cherchant des OVNIS

Par : Korben
25 juillet 2025 à 11:37

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

Aujourd’hui dans ma série “les ados qui ont failli déclencher la Troisième Guerre mondiale”, je vous présente l’histoire complètement dingue de Mathew et Richard, respectivement 21 ans de Cardiff et 16 ans de la banlieue londonienne, qui ont réussi l’exploit de faire trembler le Pentagone armés d’un simple modem 56k et d’une obsession maladive pour les petits hommes verts.

Le Pentagone, cette forteresse imprenable… sauf pour deux ados obsédés par X-Files

Si comme moi, vous êtes fans de X-Files, vous allez kiffer cette histoire. Mathew Bevan, alias “Kuji”, et Richard Pryce, surnommé “Datastream Cowboy” (déjà rien que les pseudos, c’est tout un programme) ont piraté pendant des mois les systèmes les plus secrets de l’armée américaine. Et leur but étaint encore plus fou : Prouver que le gouvernement américain cache l’existence des extraterrestres. Cheh !

Et ils ont effectivement réussi à s’introduire dans ces systèmes ultra-sensibles. Pire encore, ils ont failli créer un incident diplomatique majeur. Un agent du Pentagone a même qualifié Kuji de “plus grande menace pour la paix mondiale depuis Adolf Hitler”. Rien que ça ! C’est beau, j’en suis ému.

L’histoire commence donc dans les bureaux du Rome Laboratory à Griffiss Air Force Base, dans l’État de New York. Les administrateurs système découvrent qu’un programme espion, un “sniffer”, a été installé clandestinement sur leur réseau et le machin avait collecté tellement de mots de passe et d’informations qu’il avait saturé le disque dur et fait crasher le système. Breeeef, imaginez la tronche des admins : le laboratoire de recherche le plus secret de l’US Air Force, celui qui développe l’intelligence artificielle militaire et les systèmes de guidage radar, venait de se faire trouer comme un emmental.

Rome Laboratory, le cerveau technologique de l’US Air Force… infiltré par deux ados

Le 28 mars 1994, Jim Christy, chef des investigations cybercriminelles de l’Air Force Office of Special Investigations (AFOSI) de l’époque, reçoit l’appel qui va bouleverser sa vie.

On a un problème”, lui annonce son équipe. Ancien de la NSA reconverti dans la lutte contre la cybercriminalité militaire, Christy comprend immédiatement l’ampleur du désastre. Rome Lab, c’est pas n’importe quoi, c’est l’endroit où se développent les armes du futur de l’armée américaine.

L’équipe de Christy découvre alors rapidement que les intrus utilisent deux pseudonymes : “Datastream” et “Kuji”. Deux hackers fantômes qui se baladent dans les systèmes militaires américains comme dans leur salon mais le pire reste à venir puisqu’ils utilisent les serveurs compromis de Rome Lab comme tremplin pour attaquer d’autres cibles : La NASA, Wright-Patterson Air Force Base (vous savez, là où sont censés être planqués les aliens), Hanscom Air Force Base, et même des contractants de défense en Californie et au Texas.

Pendant 26 jours, Christy et ses équipes surveillent les deux pirates sans intervenir. Ils veulent comprendre l’ampleur de l’attaque et remonter jusqu’aux coupables. Ce qu’ils découvrent les fait flipper grave : plus de 150 intrusions sur Rome Lab, des téraoctets de données sensibles copiées, des emails d’officiers lus et effacés, et des programmes de simulation de champ de bataille téléchargés. Hé oui, c’est qu’ont découvert les enquêteurs.

Jim Christy quelques années avant la traque des cyber-intrus

Mais le véritable moment de panique arrive quand les agents voient Datastream tenter d’accéder à un ordinateur dans un laboratoire nucléaire en Corée.

Holy shit”, se dit Christy. On est en 1994, les États-Unis sont en pleine négociation tendue avec la Corée du Nord sur son programme nucléaire alors si les Nord-Coréens détectent une attaque sur leur installation nucléaire venant d’une base aérienne américaine, ils vont croire à un acte de guerre.

Les agents retiennent leur souffle. Heureusement, ils découvrent par la suite que la cible était en Corée du Sud, pas au Nord. Mais Datastream a quand même téléchargé les données du Korean Atomic Energy Research Institute et les a transférées sur les serveurs de l’US Air Force. Et si les Sud-Coréens découvrent ce transfert, c’est l’incident diplomatique assuré. Elle est pas belle la vie ?

Mais alors qui est ce mystérieux Kuji qui fait trembler le Pentagone ? Et bien c’est Mathew Bevan, né le 10 juin 1974 à Cardiff, au Pays de Galles. Un gamin qui vit un calvaire à l’école, harcelé par ses camarades, en difficulté scolaire, alors la nuit, pendant que ses parents dorment, il trouve refuge dans les bulletin boards (BBS) et les premiers forums Internet.

L’univers de Mathew Bevan : une chambre, un ordinateur, et des rêves d’extraterrestres

C’est là qu’il découvre le phone phreaking, l’art de manipuler les systèmes téléphoniques pour passer des appels gratuits n’importe où dans le monde. Cette compétence devient son passeport pour le monde du hacking et un jour, quelqu’un lui donne accès à Sin City, un bulletin board belge, repaire de hackers bien connu de l’époque. En échange de ses techniques de phone phreaking, les habitants de Sin City lui offrent alors documents et méthodes pour pirater des ordinateurs.

Mais le véritable déclic arrive quand Bevan tombe sur Destiny Stone, un bulletin board géré par un phone phreaker australien surnommé Ripmax. “Ce que j’ai trouvé sur son système, c’étaient des centaines de documents sur les OVNIs, les dissimulations gouvernementales et les théories du complot”, se souvient Bevan. Il y découvre notamment l’histoire de 40 hackers qui auraient disparu mystérieusement après avoir ciblé des systèmes militaires pour découvrir la vérité sur les OVNIs.

X-Files - La série qui a inspiré toute une génération de hackers conspirationnistes

Et là, c’est le moment “eureka” de Bevan car si ces 40 hackers ont disparu en cherchant la vérité sur les OVNIs, c’est qu’il y a forcément quelque chose à cacher. Sa mission est donc toute trouvée : reprendre là où les disparus se sont arrêtés, pirater chacune des bases militaires citées par le magazine underground PHRACK, et prouver une bonne fois pour toutes que le gouvernement américain cache l’existence des extraterrestres.

En 1994, Bevan entre alors en contact via IRC avec Richard Pryce, un gamin de 16 ans passionné de musique et d’informatique. Pryce, qui se fait appeler “Datastream Cowboy”, partage la même fascination pour les théories du complot. Il admire les compétences techniques de son aîné et accepte de devenir son “apprenti” dans cette quête de vérité.

IRC : le terrain de jeu des hackers des années 90

C’est Pryce qui découvre Rome Laboratory par hasard, en scannant les adresses IP du réseau militaire américain. “Regarde ce que j’ai trouvé”, écrit-il à Kuji. “Un labo de recherche de l’Air Force avec des sécurités ridiculement faibles.” Bevan comprend immédiatement l’opportunité. Rome Lab est un nœud central du réseau militaire américain, une porte d’entrée vers des dizaines d’autres installations.

Mais contrairement aux espions professionnels, les deux compères ne cherchent pas à passer inaperçus. Ils laissent des traces partout, copient des gigaoctets de données sans discrimination, et communiquent entre eux sans précaution particulière. C’est cette négligence va permettre à Christy de les traquer.

Pour traquer les deux fantômes, l’AFOSI fait appel à son réseau d’informateurs sur Internet. Un de ces informateurs parvient à entrer en contact avec Datastream Cowboy sur Cyberspace, un fournisseur d’accès à Seattle. Le gamin, naïf et impatient de communiquer avec d’autres hackers, tombe alors directement dans le piège et donne son numéro de téléphone personnel à l’informateur.

Le 12 mai 1994, Scotland Yard arrête Richard Pryce à son domicile de Colindale. Le gosse est terrorisé et il avoue tout : les intrusions dans Rome Lab, les attaques contre la NASA, le transfert des données coréennes. Mais surtout, il balance son complice Kuji, même s’il ne connaît pas sa véritable identité.

Pryce comparaît devant la Woolwich Crown Court en mars 1996. Il plaide coupable pour 12 infractions au Computer Misuse Act britannique et écope d’une amende dérisoire de 1 200 livres sterling. Pas de prison, pas de casier judiciaire lourd.

Pendant ce temps, Christy continue sa traque obsessionnelle de Kuji et l’AFOSI met des moyens considérables sur l’enquête. Les experts en profilage psychologique dressent un portrait-robot : homme, entre 25 et 35 ans, très intelligent, formation scientifique, probablement financé par une organisation étatique. Le Senate Permanent Subcommittee on Investigations va même jusqu’à qualifier Kuji “d’agent étranger, possiblement d’origine est-européenne”.

Ils se plantent complètement puisque Kuji n’est qu’un jeune employé informatique de Cardiff, obsédé par X-Files et financé par son maigre salaire dans une petite boîte galloise. Breeeef, les profileurs du FBI peuvent aller se rhabiller.

Le matos de Mathew Bevan à l’époque

Le 21 juin 1996, à l’aube, une escouade de Scotland Yard débarque chez Mathew Bevan. Ils s’attendent à tomber sur un espion professionnel, un agent dormant est-européen et ils découvrent un geek de 21 ans vivant chez ses parents dont la chambre est tapissée d’affiches d’X-Files et de science-fiction. “Les agents ont finalement découvert que l’identité de Kuji était Mathew Bevan, 21 ans, un informaticien avec une fascination pour la science-fiction”, rapporte le dossier d’enquête.

Bevan est arrêté et inculpé, mais contrairement à son jeune complice, il refuse de coopérer. Son père étant policier, il connaît ses droits et prend un avocat. S’ensuit un bras de fer judiciaire de 20 audiences. En novembre 1997, coup de théâtre : le Crown Prosecution Service abandonne toutes les charges. “Décision commerciale”, justifie le procureur. Traduction : ça coûte trop cher et l’opinion publique s’en fout.

Bevan sort libre mais marqué à vie. “Je ne peux plus faire de mal à une mouche maintenant”, confie-t-il. Il se reconvertit dans la sécurité informatique éthique, rejoint Tiger Computer Security, devient développeur chez Nintendo, et finit par fonder sa propre entreprise, Kuji Media Corporation. L’ironie de l’histoire veut que l’ancien pirate du Pentagone soit aujourd’hui payé pour empêcher d’autres de faire ce qu’il a fait.

De hacker à protecteur : la reconversion réussie de Mathew Bevan

Quant à Pryce, traumatisé par son arrestation, il disparaît complètement des radars. Après la confiscation de son ordinateur, il n’en rachète même pas un nouveau. Certains disent qu’il a repris ses études de musique, d’autres qu’il s’est reconverti totalement. Une chose est sûre : l’expérience l’a vacciné à vie contre le hacking.

Le rapport d’évaluation des dégâts, publié le 31 octobre 1994, chiffre les pertes directes de l’US Air Force à 211 722 dollars, sans compter les coûts de l’enquête et du nettoyage des systèmes. Mais les enquêteurs admettent n’avoir découvert que la partie émergée de l’iceberg. Combien d’autres Kuji et Datastream Cowboy se baladent dans les systèmes militaires américains ? On verra bien…

Avant 1994, les militaires américains considéraient leurs réseaux comme protégés par leur complexité technique mais après Kuji et Datastream Cowboy, ils comprennent qu’Internet a aboli les frontières et que n’importe quel ado avec un modem peut devenir une menace nationale. Cette prise de conscience va déclencher une révolution dans la cybersécurité militaire, avec des milliards de dollars investis pour sécuriser ce que deux gamins britanniques avaient démontré être un gruyère numérique.

Et la mauvaise nouvelle, c’est que malgré des mois d’intrusions dans les systèmes les plus secrets de l’US Air Force et de la NASA, Bevan n’a jamais trouvé la moindre preuve de l’existence d’extraterrestres. Pas de débris de Roswell, pas de documents sur la Zone 51, pas de technologies aliens. “J’ai fouillé partout”, confiera-t-il. “Wright-Patterson, la NASA, tous les endroits où étaient supposés être cachés les secrets sur les OVNIs. Rien, nada, que dalle.

Cette conclusion aurait dû clore le débat, mais les théoriciens du complot ont retourné l’argument : si Kuji n’a rien trouvé, c’est justement la preuve que la conspiration existe et qu’elle est plus complexe et secrète que ce qu’on pourrait imaginer. The truth is ‘still’ out there, comme dirait Mulder… Mais elle n’est pas dans les serveurs du Pentagone visiblement…

Sources : Security in Cyberspace - Rome Laboratory Case Study, Wikipedia - Mathew Bevan, Kuji Media - Confessions of a hacker, InformIT - The Rome Labs Case, ISC2 - 30 Years After Two Kids Broke into the Air Force, Cryptologic Foundation - 1994: Griffiss Air Force Base finds malware

Prxy - Reverse proxy WireGuard pour votre homelab

Par : Korben
11 juin 2025 à 22:08

Développé par Madh93, cet outil en Go baptisé Prxy résout un problème que beaucoup d’entre nous subissent en silence à savoir comment accéder proprement à ses services auto-hébergés sans transformer sa connexion en passoire ou en goulot d’étranglement. L’idée, c’est du split-tunneling application par application, une approche chirurgicale qui évite les compromis habituels.

Logo de prxy - Un petit personnage turquoise avec des câbles représentant la connectivité proxy

Comment installer Carbonio CE - Votre propre Google Workspace 100% libre en 10 étapes

Par : Korben
24 avril 2025 à 04:17

– Article en partenariat avec Zextras –

Marre de laisser Google fouiller dans vos mails comme un chat de gouttière dans une poubelle ? Envie de claquer la porte au nez de Microsoft 365 tout en gardant des outils collaboratifs cools ? Alors c’est l’heure d’installer Carbonio CE, votre serveur de mail badass et open source qui fait tout ce que les géants du web font, mais chez vous et sans vous stalker!

❌
❌