Cédrix
1 line
37 KiB
JSON
1 line
37 KiB
JSON
[{"uuid":"ddb53aae-7214-4e3c-8af5-e42da60d8429","slug":"kobo-elipsa-2e-le-cahier-a4-numerique-qu-on-attendait-a-quelques-details-pres","title":"Kobo Elipsa 2E : le cahier A4 numérique qu'on attendait, à quelques détails près","category":"loisirs","author":"cedric@abonnel.fr","cover":"cover.jpg","published":true,"published_at":"2025-11-09 12:07","created_at":"2025-11-09 12:07:00","updated_at":"2026-05-12 01:43:39","tags":[],"plain":"Une liseuse qui n'en est plus tout à fait une\r\n\r\nPendant longtemps, le marché des liseuses s'est tenu à une règle non écrite : une liseuse, c'est petit, c'est noir et blanc, c'est fait pour lire des romans dans le métro. Les tentatives de sortir de ce cadre — Sony DPT-RP1, Onyx Boox, ReMarkable — restaient soit confidentielles, soit positionnées comme des outils de prise de notes pure, sans véritable identité de liseuse. Avec l'Elipsa 2E, Kobo assume frontalement l'hybridation. Ce n'est pas une liseuse à laquelle on a ajouté un stylet ; c'est un objet pensé dès le départ comme un cahier numérique qui sait aussi lire des livres.\r\n\r\nL'engin est imposant. Écran E-Ink Carta 1200 de 10,3 pouces, résolution 1404 × 1872 pour 227 ppi, processeur dual-core 2 GHz et 32 Go de stockage. Côté tarif, TechRadar la situe autour de 399 dollars ou 349 livres, ce qui la place dans une catégorie où on n'achète plus sur un coup de tête : à ce prix, on attend un usage précis, pas un gadget de chevet.\r\n\r\nLe format change tout\r\n\r\nTenir l'Elipsa 2E pour la première fois, c'est comprendre instantanément à qui elle parle. À 10,3 pouces, on est très proche d'une feuille A5, voire d'un cahier d'étudiant — un format qui colle naturellement aux PDF et aux documents grand format. Et c'est là que tout se joue.\r\n\r\nQuiconque a déjà tenté de lire un PDF technique sur une liseuse 6 ou 7 pouces sait à quel point l'exercice est frustrant : on zoome, on déplace, on perd la mise en page, les schémas explosent en morceaux. Avec l'Elipsa 2E, un PDF A4 passe à l'écran à une taille parfaitement lisible, sans gymnastique. Les manuels techniques, les articles scientifiques, les supports de cours, les rapports d'entreprise : tout ce qui était pénible devient confortable. C'est moins spectaculaire que la couleur d'une Libra Colour, mais sur un usage professionnel ou étudiant intensif, le format change littéralement la nature de l'objet.\r\n\r\nLe stylet, atout central — mais imparfait\r\n\r\nLe stylet est inclus dans la boîte. Détail qui n'a l'air de rien mais qui mérite d'être souligné, parce que l'usage prévu est clairement l'annotation directe sur les e-books et la prise de notes manuscrites. Pas de Kobo Stylus 2 à racheter en option, pas de configuration séparée : on déballe, on écrit.\r\n\r\nL'utilisation est exactement ce qu'on en attend. On peut surligner dans n'importe quel ePub, écrire dans la marge, créer des carnets vierges pour des notes manuscrites, dessiner des schémas à main levée. Tout ce qu'on griffonne reste dans le fichier, et — point essentiel — peut être ressorti ensuite. Le système prend en charge ePub, PDF, et accepte sans broncher les fichiers déposés par USB-C, Wi-Fi ou Bluetooth.\r\n\r\nMais il faut être honnête : la sensation d'écriture n'est pas au niveau de ce que proposent les meilleurs concurrents. eWritable est même cinglant, qualifiant l'expérience tactile d'« horrible » et pointant le choix par Kobo du protocole Microsoft Pen Protocol (MPP 2.0) plutôt que la technologie Wacom qui équipe le ReMarkable 2 et reste la référence du secteur. Concrètement, qu'est-ce que ça veut dire ? Que la pointe glisse un peu trop sur le verre, qu'il manque cette résistance subtile qui fait penser au crayon sur papier, et qu'à très haute vitesse d'écriture la latence devient perceptible. Pour quelqu'un qui annote ses lectures, surligne, prend des notes ponctuelles, c'est largement suffisant. Pour quelqu'un qui veut remplacer son carnet Moleskine en cours magistral et écrire trois pages d'affilée à vitesse normale, ce sera frustrant.\r\n\r\nC'est une différence de positionnement, pas un défaut technique grave : l'Elipsa 2E est d'abord une liseuse qui annote, pas un cahier qui sait aussi lire.\r\n\r\nL'export des annotations, ce qui fait vraiment la différence\r\n\r\nC'est probablement le point sur lequel Kobo creuse l'écart avec ses concurrents, et notamment avec le Kindle Scribe. Le manuel officiel explique qu'on peut exporter ses annotations sous forme de fichier .txt et le récupérer sur son ordinateur, mais en réalité l'écosystème va plus loin : les PDF annotés ressortent avec les annotations intégrées à la page, prêts à être imprimés ou partagés.\r\n\r\nCe flux, en apparence banal, change tout pour qui travaille sérieusement avec ses lectures. Un étudiant peut annoter ses cours et imprimer la version surlignée pour les révisions. Un enseignant peut corriger des copies en PDF et renvoyer le fichier annoté à l'élève. Un consultant peut lire un rapport, le commenter en marge, le réintégrer dans sa documentation projet. Aucune annotation perdue, aucune resaisie. Là où Kindle Scribe limite encore largement l'export de ses annotations, Kobo joue le jeu de l'ouverture.\r\n\r\nLe talon d'Achille : l'entrée des fichiers\r\n\r\nC'est ici que l'Elipsa 2E montre ses limites les plus tangibles, et il faut le savoir avant d'acheter. Contrairement à Kindle, il n'existe pas d'adresse e-mail officielle « envoyer à ma liseuse » : il faut transférer les fichiers manuellement, par USB ou via un service tiers comme Dropbox. Pour qui s'envoie régulièrement des articles ou des e-books depuis son ordinateur ou son téléphone, ce manque crée une vraie friction quotidienne.\r\n\r\nLes workarounds existent, à condition d'accepter de mettre un peu les mains dans le moteur. Un projet open source baptisé KoboMail propose un système d'envoi par e-mail pour certaines Kobo, et plus intéressant encore, un daemon Nextcloud-Kobo permet de synchroniser automatiquement un dossier Nextcloud via WebDAV vers la liseuse. C'est ouvert, c'est élégant, ça respecte le principe d'auto-hébergement — mais ce n'est pas du plug and play. Il faut un serveur Nextcloud opérationnel, savoir configurer une connexion WebDAV, et accepter que l'installation se fasse dans le dossier du système Kobo. Bref, c'est superbe pour qui maîtrise déjà son infrastructure ; c'est rédhibitoire pour qui veut juste une solution clé en main.\r\n\r\nSur ce point précis, Kobo et Amazon proposent deux philosophies opposées : le confort immédiat d'un écosystème fermé contre la liberté d'un écosystème ouvert mais exigeant. À vous de voir où vous vous situez.\r\n\r\nPour qui ce produit a-t-il du sens ?\r\n\r\nL'Elipsa 2E est faite pour vous si vous lisez beaucoup de documents grand format — PDF techniques, cours universitaires, rapports professionnels, partitions — et si l'idée d'annoter ces documents fait partie intégrante de votre flux de travail. Elle est faite pour vous si vous voulez un objet unique au lieu de jongler entre une liseuse classique et un cahier papier. Elle est faite pour vous, aussi, si vous avez déjà (ou êtes prêt à monter) un Nextcloud ou un Dropbox pour synchroniser vos fichiers proprement.\r\n\r\nElle ne l'est pas si votre priorité est la prise de notes manuscrite intensive et fluide : sur ce terrain, un ReMarkable 2 ou un Supernote restent supérieurs. Elle ne l'est pas non plus si vous attendez le confort de l'envoi par e-mail à la Kindle, ou si l'idée d'installer un plugin communautaire pour combler un manque officiel vous donne de l'urticaire. Et elle est sans doute disproportionnée si vous lisez essentiellement des romans : à ce moment-là, une Clara BW à 150 € vous donnera plus de plaisir, dans un format de poche.\r\n\r\nMon avis\r\n\r\nL'Elipsa 2E est un produit ambitieux qui réussit l'essentiel et trébuche sur quelques détails finalement révélateurs. L'essentiel, c'est le format, la qualité de l'écran, l'export des annotations, l'ouverture du système et l'autonomie typique d'une liseuse — autant de raisons qui en font la meilleure proposition du marché pour un usage documentaire sérieux à ce niveau de prix.\r\n\r\nLes détails, ce sont le ressenti perfectible du stylet et l'absence d'un système d'entrée des fichiers digne de 2026. Kobo aurait pu intégrer nativement WebDAV — ça lui coûterait à peu près rien — et opter pour une dalle Wacom — ça lui coûterait plus cher mais lui ferait gagner une catégorie entière d'utilisateurs. À la place, on hérite d'un produit excellent à 80 %, et qui demande qu'on accepte ses zones grises sur les 20 % restants.\r\n\r\nPour qui cherche un véritable cahier A4 numérique sans basculer dans une tablette Android Onyx — plus chère, plus complexe, et au confort de lecture moindre — l'Elipsa 2E reste, à mes yeux, le meilleur compromis du moment. Pas le produit parfait. Le meilleur compromis. Ce n'est pas la même chose, et c'est très bien aussi."},{"uuid":"4df6d166-5451-4d4f-a29f-a094f2e68f7f","slug":"20230112-qu-est-ce-linux","title":"Le cœur de l'OS GNU/Linux","category":"Journal geek","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-09 15:20:59","created_at":"2023-02-09 15:20:59","updated_at":"2023-02-09 15:20:59","tags":[],"plain":"Le noyau Linux est le cœur du système d'exploitation GNU/Linux. Il gère les processus, les fichiers, la mémoire, et les périphériques d'entrée/sortie. Il fournit également des services tels que la gestion des communications réseau et des pilotes pour les périphériques. Linus Torvalds en 1991, alors étudiant à l'Université d'Helsinki, en Finlande, créé le noyau. Le noyau Linux est basé sur le noyau Unix, respecte les normes POSIX et fournit une interface de programmation pour les développeurs qui s'appuient sur les fonctionnalités Unix standard. Il est multitâche et permet à plusieurs processus d'exécuter simultanément sur un ordinateur, en gérant efficacement les ressources système telles que la mémoire et les processeurs. Il est également orienté sécurité et intègre des fonctionnalités de sécurité pour protéger les données et les ressources de l'utilisateur contre les logiciels malveillants et les attaques extérieures. Il est compatible avec les périphériques et offre une prise en charge pour une grande variété de matériel, y compris les processeurs, les cartes graphiques, les périphériques d'entrée et de sortie, les réseaux, etc. Les utilisateurs au sens large du terme, peuvent lire, modifier et distribuer le code source de Linux. Le noyau Linux, est libre et open-source, c'est-à-dire qu'il est développé par une communauté de développeurs et est utilisé dans de nombreux systèmes d'exploitation différents, notamment Linux, Android, Chrome OS. Le système d'exploitation (OS) GNU/Linux est un logiciel qui gère les ressources d'un ordinateur et fournit un environnement pour les programmes. Il gère les interactions entre le matériel de l'ordinateur et les logiciels, et fournit des services de base pour les programmes tels que la gestion de la mémoire, de la sauvegarde des fichiers, et de l'accès aux périphériques d'entrée/sortie. Il comprend le noyau Linux ainsi que des logiciels supplémentaires pour les tâches courantes telles que la navigation sur le Web, la lecture de courrier électronique, la création de documents, etc. Les utilisateurs peuvent adapter GNU/Linux à leurs besoins spécifiques et que de nombreuses versions de GNU/Linux ont été créées, appelées \"distributions\" qui ont des objectifs différents, des ensembles de programmes différents, et des philosophies différentes. Les utilisateurs utilisant GNU/Linux, cherchent un système d'exploitation stable, sécurisé et personnalisable. Il est convenu que dire \"GNU/Linux\" est fastidieux, nous utiliserons donc le terme \"Linux\" pour désigner ce système d'exploitation. Bientôt d'autres informations plus passionnantes."},{"uuid":"ce482d0d-cefb-47d3-91ac-129b62cc7b91","slug":"telecharger-raspbian","title":"- Télécharger Raspberry Pi OS","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-11-26 09:23:13","created_at":"2023-11-26 09:23:13","updated_at":"2023-11-26 09:23:13","tags":[],"plain":"Le système d'exploitation pour le Raspberry Pi s'appelle Raspberry Pi OS. C'est un Linux dérivé de Debian. Il est optimisé pour Raspberry Pi. Il existe deux méthodes pour obtenir Raspberry Pi OS : 1. Télécharger l'outil de gestion d'image Raspberry Pi Imager\n1. Télécharger l’image de déploiement (ISO) Ces deux méthodes vous permettent d'obtenir Raspberry Pi OS, mais elles diffèrent légèrement dans la manière dont vous l'installez sur votre matériel. La première méthode utilise Raspberry Pi Imager pour simplifier le processus, tandis que la deuxième vous oblige à télécharger manuellement l'image de déploiement (ISO), la flasher sur un support bootable, puis l'installer sur votre Raspberry Pi. Choisissez celle qui convient le mieux à vos compétences et préférences techniques. Voyons cela en détail.\nRaspberry Pi Imager\nCette méthode implique d'aller sur le site officiel de Raspberry Pi Foundation pour télécharger Raspberry Pi Imager, un logiciel spécialement conçu pour simplifier le processus d'installation de Raspberry Pi OS. L'outil est disponible pour plusieurs systèmes d'exploitation, y compris Windows, macOS et Linux. [[https:www.raspberrypi.com/software/|]] Sous Linux Debian (et ses dérivées), vous avez la possibilité d'exécuter la commande suivante pour installer Raspberry Pi Imager : En revanche, si vous utilisez Linux Red Hat (et ses dérivées), vous pouvez installer Raspberry Pi Imager avec la commande : Enfin, si vous préférez une autre méthode, vous avez également la possibilité d'installer Raspberry Pi Imager à partir de Flathub en utilisant la commande suivante : Une fois que vous avez téléchargé et installé Raspberry Pi Imager, lancez l'application. Ensuite, sélectionnez la version spécifique de votre Raspberry Pi pour filtrer les résultats et afficher les versions d'OS disponibles qui sont compatibles avec votre modèle :\nRaspberry Pi 5\nRaspberry Pi 4\nRaspberry Pi Zero 2 W\nRaspberry Pi 3\nRaspberry Pi 2\nRaspberry Pi Zero\nRaspberry Pi 1 Raspberry Pi Imager vous permet de choisir Raspberry Pi OS parmi une liste de systèmes d'exploitation compatibles :\nRaspberry Pi OS (64-bit)\nRaspberry Pi OS (32-bit)\nRaspberry Pi OS (Legacy)\nRaspberry Pi OS (other)\nOther general-purpose OS\nMedia player OS\nEmulation and game OS\nOther specific-purpose OS\nFreemium and paid-for OS\nMisc utility images\nErase\nUser custom Vous pouvez sélectionner \"Raspberry Pi OS (other)\" pour choisir entre Raspberry Pi OS Lite 32-bit ou 64-bit** si vous souhaitez installer une version de Raspberry Pi OS sans bureau. Cette option vous permettra d'obtenir une version minimale du système d'exploitation, idéale pour les projets qui n'ont pas besoin d'une interface graphique. Après avoir choisi Raspberry Pi OS, l'outil vous guide à travers le processus de création d'une carte SD ou d'une clé USB bootable avec le système d'exploitation. Une fois cela fait, vous pouvez insérer la carte SD ou la clé USB dans votre Raspberry Pi et démarrer l'appareil.\nEnsuite ?\nJe vous propose de vous rendre au chapitre pour déployer cette image sur une carte SD."},{"uuid":"4cf880e6-e4e0-42dd-aae2-675837850b83","slug":"compromission-de-jdownloader-6-7-mai-2026-analyse-indicateurs-et-procedure-de-detection","title":"JDownloader : quand le CMS devient la faille","category":"informatique","author":"cedric@abonnel.fr","cover":"cover.webp","published":true,"published_at":"2026-05-12 17:09","created_at":"2026-05-12 17:10:36","updated_at":"2026-05-12 17:21:01","tags":[],"plain":"À propos de l'incident de sécurité affectant le site officiel jdownloader.org les 6 et 7 mai 2026.\r\n\r\nJDownloader expliqué simplement\r\n\r\nJDownloader est un gestionnaire de téléchargements écrit en Java, distribué gratuitement par l'éditeur allemand AppWork GmbH depuis plus de quinze ans. Il sert essentiellement à automatiser la récupération de fichiers depuis des hébergeurs (Mega, Uptobox, Rapidgator…), des plateformes vidéo et des services de liens premium. Côté utilisateur, c'est l'outil qu'on lance pour récupérer une série de fichiers en une opération, plutôt que cliquer sur cent liens un par un. L'application est multiplateforme — Windows, Linux, macOS — et tourne sur quelques millions de postes dans le monde.\r\n\r\nLe projet est distribué de plusieurs façons : un JAR principal (le binaire Java pur), des installateurs natifs par OS depuis le site officiel, et des paquets passant par des canaux distribués comme Flatpak, Snap ou Winget. C'est cette diversité de canaux qui va jouer un rôle central dans ce qui suit.\r\n\r\nL'incident : ce qui s'est passé\r\n\r\nEntre le 6 mai 2026 à 00 h 01 UTC et le 7 mai 2026 à 17 h 06 UTC, le site officiel a distribué des installateurs piégés à la place des binaires légitimes. La fenêtre n'a duré qu'environ 48 heures, et seuls deux liens ont été affectés. Mais pendant cette fenêtre, tout utilisateur qui passait par le bon parcours téléchargeait un cheval de Troie au lieu d'un gestionnaire de téléchargements.\r\n\r\nLe scénario reconstitué par l'équipe d'AppWork et les chercheurs en sécurité (BleepingComputer, Thomas Klemenc, équipe Rescana) se déroule en quatre temps.\r\n\r\n1. Compromission du CMS du site. Les attaquants ont exploité une vulnérabilité non corrigée dans le système de gestion de contenu de , qui permettait de modifier les listes de contrôle d'accès et le contenu publié sans authentification. Point crucial : ils n'ont pas eu accès au serveur sous-jacent, ni au système de fichiers, ni à l'infrastructure de build. Juste au contenu web — et ça a suffi.\r\n\r\n2. Réécriture de deux liens. Plutôt que de tenter de modifier les binaires originaux (qui étaient hors de leur portée), les attaquants ont fait beaucoup plus simple : ils ont changé l'URL cible de deux liens publics sur la page de téléchargement. Le lien « Download Alternative Installer » pour Windows et le script shell pour Linux pointaient désormais vers des fichiers malveillants hébergés sur une infrastructure tierce. Le HTML autour, lui, restait identique. Visuellement, rien ne distinguait la page propre de la page piégée.\r\n\r\n3. Charges utiles différenciées par plateforme. Sur Windows, l'installateur piégé agit comme un loader qui déploie un RAT (Remote Access Trojan) écrit en Python, fortement obfusqué, communiquant avec deux serveurs de commande et contrôle ( et ). Le RAT est modulaire : il reçoit du code Python depuis le C2 et l'exécute, ce qui donne aux attaquants une porte ouverte indéfiniment extensible. Sur Linux, le script shell modifié télécharge une archive depuis , déguisée en fichier SVG, dont il extrait deux binaires ELF — et . Le second est installé en SUID-root dans , le premier est copié dans , et la persistance est assurée par un script déposé dans . Le malware se lance ensuite déguisé en , un nom de processus qui existe légitimement sur la plupart des distributions.\r\n\r\n4. Détection par la communauté. L'alerte n'est pas venue d'un système de surveillance, mais d'un utilisateur Reddit (PrinceOfNightSky) qui a remarqué que Microsoft Defender bloquait son installateur fraîchement téléchargé. La signature numérique indiquait « Zipline LLC » au lieu de « AppWork GmbH ». L'équipe AppWork a confirmé, mis le site hors ligne pour investigation dans les heures qui ont suivi, puis publié un rapport d'incident détaillé. Le site est revenu en ligne dans la nuit du 8 au 9 mai avec des liens vérifiés.\r\n\r\nPourquoi c'est systémique\r\n\r\nÀ première vue, c'est un incident isolé : une faille CMS, une équipe qui patche, le service revient. Vu de loin, ça ressemble à un mauvais quart d'heure. Mais en prenant un peu de recul, le schéma est troublant.\r\n\r\nCPUID, début avril 2026. Le site officiel de l'éditeur de CPU-Z est compromis, des installateurs piégés sont distribués pendant plusieurs jours.\r\n\r\nDAEMON Tools, début mai 2026. Même schéma : compromission du site officiel, substitution d'installateurs, plusieurs versions infectées (12.5.0.2421 à 12.5.0.2434) distribuées avant détection.\r\n\r\nJDownloader, 6–7 mai 2026. Toujours le même schéma.\r\n\r\nTrois compromissions d'éditeurs logiciels en cinq semaines, exactement sur le même schéma : pas d'intrusion dans l'infrastructure de build, pas de modification du code source, pas de vol de certificat de signature de l'éditeur. À chaque fois, le maillon faible est le CMS qui sert la page de téléchargement. Ce qu'on attaque, ce n'est pas le logiciel ; c'est le panneau publicitaire qui pointe vers le logiciel.\r\n\r\nCette mécanique est intéressante parce qu'elle déjoue à peu près toutes les défenses « modernes » de la chaîne d'approvisionnement.\r\n\r\nLa signature de code ne protège pas. Le binaire légitime de JDownloader est toujours signé proprement par AppWork GmbH. Mais le binaire malveillant servi à sa place est signé, lui aussi — par un autre éditeur (Zipline LLC, The Water Team), avec des certificats vraisemblablement volés ou achetés au marché noir. La signature certifie que le fichier vient bien de celui qui l'a signé ; elle ne certifie pas que c'est le bon fichier.\r\n\r\nLe HTTPS ne protège pas. La page de téléchargement est servie en HTTPS valide, depuis le bon domaine, avec le bon certificat. Le navigateur n'a aucune raison de tiquer.\r\n\r\nLes mises à jour in-app sont, elles, protégées. AppWork le souligne : chaque mise à jour livrée par le mécanisme intégré de JDownloader est signée RSA et vérifiée cryptographiquement, indépendamment du site web. Ce canal n'a pas été touché. C'est tout le paradoxe : les utilisateurs qui mettaient à jour JDownloader depuis l'application elle-même n'ont rien risqué ; ceux qui sont allés sur le site officiel pour le télécharger « proprement » sont les seuls exposés.\r\n\r\nLes paquets distribués sont protégés. Flatpak, Snap, Winget, le JAR principal — tout ce qui passe par une chaîne d'approvisionnement où l'intégrité est vérifiée par checksum hors site est resté propre. AppWork le résume sans détour : « Winget/Flatpak/Snap infra is outside of our reach — files downloaded by those are hosted on other infra and secured by sha256 checksums that are unchanged. »\r\n\r\nAutrement dit, plus le canal est court et naïf, plus il est vulnérable. Le téléchargement direct depuis un site web est le canal le plus naïf qui soit : on fait confiance au CMS, point. Tout l'effort de sécurisation de l'écosystème logiciel — signatures, builds reproductibles, SBOMs, attestations de provenance — porte sur la chaîne de production et la chaîne de distribution centralisée. Le maillon « page HTML qui dit clique ici », lui, est resté tel qu'il était en 2005.\r\n\r\nComment vérifier si on est touché\r\n\r\nLa fenêtre est étroite, donc le filtrage est simple. Trois questions, dans l'ordre :\r\n\r\n1. L'installateur a-t-il été récupéré entre le 6 mai 2026 (00 h 01 UTC) et le 7 mai 2026 (17 h 06 UTC) ?\r\n2. S'agit-il du lien « Download Alternative Installer » Windows ou du script shell Linux depuis ?\r\n3. Le fichier a-t-il été exécuté ?\r\n\r\nTrois oui → traiter la machine comme compromise. N'importe quel non dans la liste → aucun risque lié à cet incident. Une installation pré-existante mise à jour automatiquement, un paquet Flatpak/Snap/Winget, le JAR, la version macOS : rien à craindre.\r\n\r\nSous Windows\r\n\r\nLe contrôle de référence, c'est la signature numérique. Clic droit sur l'installateur → Propriétés → onglet Signatures numériques. La valeur attendue est . Toute autre signature (notamment Zipline LLC ou The Water Team), ou l'absence de signature, désigne un fichier malveillant.\r\n\r\nEn PowerShell :\r\n\r\n\r\n\r\nSi n'est pas ou si le certificat ne contient pas , ne pas exécuter.\r\n\r\nSous Linux\r\n\r\nTrois artefacts sont à chercher en post-exécution :\r\n\r\n\r\n\r\nL'apparition de l'un de ces trois éléments suffit à confirmer l'infection. Pour aller plus loin, un coup d'œil au trafic sortant vers les trois domaines C2 (, , ) dans les logs DNS ou via permet de confirmer l'activité du malware.\r\n\r\nSi le script installateur traîne encore quelque part, sa signature est sans ambiguïté : taille de 7 934 496 octets, SHA-256 commençant par .\r\n\r\nEn cas de compromission confirmée\r\n\r\nLa position officielle d'AppWork est sans nuance : réinstallation complète du système. Un RAT modulaire avec persistance SUID-root et exécution arbitraire de code Python depuis un C2 n'est pas quelque chose qu'on retire avec un antivirus. Il faut considérer que tout secret qui a transité sur la machine est compromis — mots de passe saisis au clavier, clés SSH, jetons API, cookies de session, configurations cloud — et les faire tous tourner après réinstallation, depuis une autre machine saine.\r\n\r\nCe que ça change pour qui s'auto-héberge\r\n\r\nL'incident JDownloader est un exemple éclairant pour qui exploite ses propres services exposés sur Internet — un Forgejo, un reverse proxy, un site personnel. La leçon n'est pas vraiment côté utilisateur (la procédure de détection plus haut suffit), elle est côté opérateur.\r\n\r\nLe CMS de JDownloader n'a probablement pas été ciblé pour ses qualités intrinsèques. C'est un dommage collatéral d'un schéma plus large : tout site qui distribue un binaire avec un nombre significatif d'utilisateurs devient une cible rentable, et le CMS public est souvent la pièce la moins surveillée du dispositif. On sécurise le serveur Git, le pipeline de build, la signature des paquets — et on laisse tourner un CMS qui n'a pas été patché depuis huit mois parce qu'il « ne sert qu'à afficher la page d'accueil ».\r\n\r\nQuelques principes opérationnels qui en découlent.\r\n\r\nSéparer le canal de publication du canal de vérification. AppWork a eu raison sur un point essentiel : leurs mises à jour in-app passent par une infrastructure indépendante du site web, avec signature RSA vérifiée côté client. Quand on auto-héberge, ça se traduit par : ne jamais utiliser le même serveur pour distribuer un binaire et publier son empreinte. Le checksum doit vivre ailleurs — dans un dépôt Git séparé, sur un domaine différent, idéalement sur une infrastructure qu'on n'administre pas soi-même.\r\n\r\nSurveiller la dérive du contenu publié. Une simple vérification quotidienne du hash des pages publiques (un cron qui calcule le SHA-256 des URL critiques et alerte en cas de changement non planifié) aurait détecté la compromission de JDownloader en moins d'une heure. C'est le genre de surveillance qu'aucune solution commerciale ne propose nativement, et qui s'écrit en quinze lignes de bash.\r\n\r\nPatcher le CMS avec la même rigueur que l'OS. L'automatisation des mises à jour applicatives reste sous-investie, surtout pour les outils « périphériques » (CMS, wiki, formulaire de contact). Une mise à jour automatique de niveau correctif n'est pas plus risquée qu'une mise à jour du noyau, et elle évite ce type de scénario.\r\n\r\nAuditer les ACL régulièrement. La faille exploitée ici permettait de modifier les ACL sans authentification. C'est l'équivalent CMS d'un répertoire dans un coin du système. Un audit périodique des permissions sur les pages publiques fait partie du minimum syndical pour un service exposé.\r\n\r\nEn résumé\r\n\r\nJDownloader n'a pas été cassé. Son code source est intact, son infrastructure de build est intacte, ses paquets officiels distribués via Flatpak ou Snap sont intacts, ses mises à jour internes sont intactes. Ce qui a été cassé, c'est le panneau qui dit où aller chercher le binaire.\r\n\r\nC'est une mécanique élégante du point de vue de l'attaquant, et inquiétante du point de vue de l'opérateur. Elle illustre quelque chose que l'incident NPM avait déjà mis en lumière dans un autre registre : la chaîne d'approvisionnement logicielle n'est pas une chaîne, c'est un réseau, et les points faibles ne sont jamais là où on les attend. On peut investir massivement dans la sécurité du code, du build et de la signature ; si la page web qui sert le lien reste un Wordpress non patché derrière un nom de domaine prestigieux, tout cet investissement passe à côté.\r\n\r\nLe rôle de l'opérateur en 2026, ce n'est plus de protéger le code. C'est de protéger chaque maillon qui sert à dire au monde où trouver le code — et de partir du principe que ce maillon-là sera le prochain à céder.\r\n\r\nLiens & sources\r\n\r\nJDownloader site hacked to replace installers with Python RAT malware | BleepingComputer\r\n\r\nRapport d'incident officiel | jdownloader.org\r\n\r\nJDownloader Website Supply Chain Attack | Rescana\r\n\r\nLe site officiel de JDownloader compromis | IT-Connect"},{"uuid":"5a0cced3-40d0-46bf-8501-b533f3c2608e","slug":"reparer-une-instance-uptime-kuma-installee-via-le-script-proxmox","title":"Réparer une instance Uptime Kuma installée via le script Proxmox","category":"informatique","author":"cedric@abonnel.fr","cover":"cover.svg","published":true,"published_at":"2025-11-26 08:33","created_at":"2025-11-26 08:33:49","updated_at":"2026-05-12 09:16:00","tags":[],"plain":"Méthode basée sur l'installation via le script communautaire :\r\ncommunity-scripts.github.io/ProxmoxVE/scripts?id=uptimekuma\r\n\r\nSi tu utilises Uptime Kuma pour monitorer ton infra, tu finiras tôt ou tard par tomber sur un de ces grands classiques : le service qui refuse de démarrer après une mise à jour, des erreurs SQLite louches dans , ou pire — l'interface qui tourne mais ne remonte plus aucun heartbeat. Dans 90 % des cas, c'est la base SQLite qui a pris cher, souvent à cause d'un arrêt brutal du conteneur LXC ou d'une migration qui s'est mal passée.\r\n\r\nAvant de paniquer et de tout réinstaller, il y a une série d'étapes à dérouler. Je les mets ici dans l'ordre, parce que l'ordre compte : on commence toujours par le moins destructif.\r\n\r\nPourquoi SQLite et pas un vrai SGBD ?\r\n\r\nPetite parenthèse pour les juniors qui se demanderaient. Uptime Kuma embarque SQLite parce que c'est une appli pensée pour être facile à déployer : pas de serveur de base à installer à côté, pas de credentials à gérer, juste un fichier sur le disque. C'est génial pour démarrer, mais ça a un défaut majeur — SQLite n'aime pas du tout être coupé en plein milieu d'une écriture. Si ton LXC tombe pendant que Kuma écrit un heartbeat, tu peux te retrouver avec un fichier corrompu. D'où l'importance de toujours arrêter proprement le service avant de toucher au fichier.\r\n\r\n1. Arrêter le service proprement\r\n\r\n\r\n\r\nC'est la première chose à faire, toujours. Tant que le service tourne, il a un verrou sur et il continue d'y écrire. Tu peux ouvrir le fichier en lecture avec malgré ce verrou, mais dès que tu veux faire un ou un , tu vas soit avoir une erreur , soit — pire — corrompre encore plus la base si tu forces.\r\n\r\nVérifie que c'est bien arrêté avant de continuer :\r\n\r\n\r\n\r\nTu dois voir . Pas , pas , pas avec un process encore en l'air.\r\n\r\n2. Aller dans le dossier de l'app\r\n\r\nLe script communautaire installe Kuma dans :\r\n\r\n\r\n\r\nDans ce dossier, ce qui nous intéresse c'est le sous-dossier . C'est là que vit tout ce qui compte : le fichier (la base), les uploads, et quelques fichiers de config. Le reste (, , etc.) c'est le code de l'application — tu peux le casser, un ou une réinstallation le remettra en place. Mais , si tu le perds, tu perds toute ta config de monitoring.\r\n\r\n3. Sauvegarder avant de toucher à quoi que ce soit\r\n\r\nRègle d'or de l'ops : on ne touche jamais à une base de données sans avoir une copie au chaud. Jamais.\r\n\r\n\r\n\r\nLe te génère un suffixe du genre . Comme ça si tu fais plusieurs interventions dans la même semaine, tu sais laquelle date de quand, et tu ne risques pas d'écraser une sauvegarde par une autre.\r\n\r\nCette copie embarque :\r\nla base elle-même\r\nles fichiers WAL (, ) si SQLite est en mode Write-Ahead Logging — c'est important de les prendre avec, sinon ta sauvegarde est incomplète\r\nles uploads et certificats si tu en as\r\n\r\nSi tu sautes cette étape et que tu te plantes à l'étape 5 ou 6, tu n'auras aucun moyen de revenir en arrière. Sérieusement, fais-le.\r\n\r\n4. Vérifier l'intégrité de la base\r\n\r\n\r\n\r\n, c'est la commande de diagnostic native de SQLite. Elle parcourt toute la base, vérifie que les index pointent bien sur les bonnes lignes, que les pages ne sont pas corrompues, que les contraintes sont respectées. Deux issues possibles :\r\n* : la base est saine sur le plan structurel. Si Kuma ne démarre toujours pas, le problème vient probablement d'une migration coincée (voir étape 5) ou du code de l'app, pas du fichier.\r\nUne liste d'erreurs : il y a de la corruption. Selon ce qui est touché, on passera à l'étape 5 ou 6.\r\n\r\nPour les juniors qui découvrent SQLite : , c'est le mot-clé que SQLite utilise pour les commandes qui ne sont pas du SQL standard — c'est spécifique à SQLite, tu ne le verras pas dans PostgreSQL ou MySQL.\r\n\r\n5. Supprimer un paramètre de migration corrompu\r\n\r\nSur certaines versions de Kuma (notamment autour des montées de version qui touchent à l'agrégation des heartbeats), il y a un bug connu : l'entrée dans la table se retrouve dans un état incohérent, et le service refuse de démarrer parce qu'il pense être au milieu d'une migration qui n'avance plus.\r\n\r\nLa fix :\r\n\r\n\r\n\r\nCe qu'on fait, c'est qu'on dit à Kuma : \"oublie où tu en étais, repars de zéro sur ce point\". Au redémarrage, il va recréer la clé proprement et relancer la migration depuis le début. C'est non destructif pour tes données de monitoring — on ne touche qu'à un drapeau d'état interne.\r\n\r\nSi ce n'est pas ton problème (clé absente ou suppression sans effet), passe à la suite.\r\n\r\n6. Solution radicale : vider la table \r\n\r\nSi la corruption est concentrée sur l'historique de monitoring (et c'est souvent le cas, parce que c'est la table où Kuma écrit le plus souvent — un INSERT toutes les 20-60 secondes par sonde, ça finit par faire du volume), tu peux la vider :\r\n\r\n\r\n\r\nÀ lire attentivement : cette commande supprime tout l'historique des sondes. Tu perds les graphes de uptime, les SLA calculés sur les 30/90/365 derniers jours, tout. En revanche :\r\ntes sondes sont conservées (table )\r\ntes utilisateurs aussi (table )\r\ntes notifications également (table )\r\nta config générale est intacte (table )\r\n\r\nC'est à utiliser uniquement quand :\r\npointe vers des problèmes sur ou ses index\r\nKuma refuse de démarrer et l'étape 5 n'a rien donné\r\nou plus simplement, ta base a tellement grossi que Kuma rame et que tu acceptes de perdre l'historique pour repartir propre\r\n\r\nTant qu'à faire, profites-en pour faire un derrière, qui va vraiment libérer l'espace disque (un seul ne récupère pas la place sur le disque, il marque juste les pages comme libres pour réutilisation) :\r\n\r\n\r\n\r\n7. Redémarrer le service\r\n\r\n\r\n\r\nEt vérifie qu'il a bien démarré :\r\n\r\n\r\n\r\nTu dois voir . Si tu vois ou si le service redémarre en boucle, ne le laisse pas dans cet état — passe directement à l'étape 8 pour comprendre pourquoi.\r\n\r\n8. Lire les logs\r\n\r\n\r\n\r\nLe cible le service, le fait du (équivalent de ) — les nouvelles lignes s'affichent en temps réel. Laisse tourner pendant deux ou trois minutes, le temps que Kuma rejoue ses migrations, recharge ses sondes, et envoie les premiers heartbeats.\r\n\r\nCe qu'il faut chercher dans les logs :\r\nerreurs SQLite : , , — ça veut dire que t'as encore un problème de fichier, voire de permissions\r\nmigrations bloquées : des messages du genre qui ne sont jamais suivis d'un \r\npermissions : , — typiquement après une intervention faite en root sur des fichiers qui doivent appartenir à un autre utilisateur. Vérifie avec que les fichiers sont bien possédés par l'user qui fait tourner le service\r\nmodules Node manquants : — ça arrive après une mise à jour qui s'est mal passée. La fix, c'est généralement de relancer dans \r\nport déjà utilisé : — tu as un autre process qui squatte le port 3001 (ou celui que tu as configuré)\r\n\r\nPour sortir du , c'est .\r\n\r\nEt après ?\r\n\r\nUne fois que Kuma tourne propre, prends cinq minutes pour mettre en place ce qui t'aurait évité d'arriver ici :\r\n\r\n1. Une sauvegarde régulière de . Un simple cron qui fait du dossier vers un autre serveur, ça suffit largement pour un Kuma perso. Pense à arrêter le service avant le tar, ou utilise qui fait un snapshot cohérent sans devoir couper Kuma.\r\n2. Un monitoring du monitoring. Oui, c'est méta. Mais si Kuma tombe, c'est lui qui t'aurait alerté de la chute de tes autres services — donc personne ne te prévient. Un check externe (UptimeRobot gratuit, healthchecks.io, ou un autre Kuma sur une autre machine) qui ping ton instance, c'est cinq minutes à mettre en place.\r\n3. Garder ta sauvegarde au moins une semaine** avant de la supprimer. Au cas où un effet de bord apparaîtrait quelques jours plus tard.\r\n\r\nEt voilà. Avec ces huit étapes, tu couvres 95 % des cas de Kuma cassé. Pour les 5 % restants — typiquement quand le LXC lui-même a un souci de filesystem — c'est une autre histoire, et il faudra sortir l'artillerie côté Proxmox."}] |