Vue lecture

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.

L'Inde coupe internet, puis exige le retrait du code de bitchat

Le 23 juillet à 23h16 précisément, GitHub reçoit une notice du ministère de l'Intérieur indien avec un compte à rebours de seulement 3 heures. Ce qu'exige cette notice c'est de faire disparaître 3 dépôts de code, et pas n'importe lesquels. Ceux de bitchat , la messagerie Bluetooth de Jack Dorsey qui fonctionne sans le moindre réseau.

Trois jours plus tôt, le 20 juillet, des étudiants du Cockroach Janata Party manifestent à Jantar Mantar, en plein centre de Delhi, et réclament la démission du ministre de l'Éducation.

La police disperse leur marche à la matraque et au gaz lacrymogène, ferme des stations de métro et coupe l'internet mobile autour du site. Alors au bout de 2 jours de coupure, les manifestants basculent sur des applis qui n'en ont pas besoin.

Bitchat, sorti l'été dernier, fait exactement ça. Chaque téléphone discute en Bluetooth Low Energy avec ceux qui sont à sa portée, soit une trentaine de mètres, et relaie les messages de proche en proche. Dans une foule dense, la chaîne de relais pousse alors la portée à 300 mètres et plus.

Aucun compte à créer et aucun numéro de téléphone à fournir. Il n'y a pas non plus de serveur central, et les messages privés passent par du chiffrement Noise Protocol. Puis quand le réseau revient, l'application bascule sur le protocole Nostr pour la portée mondiale.

Le code iOS de Bitchat est dans le domaine public, tout comme la version Android en GPL-3.0. Dorsey avait d'ailleurs ressorti la même boîte à outils il y a quelques jours avec Buzz, son chat d'équipe .

L'application, dit la notice de l'Indian Cybercrime Coordination Centre, "permet la communication même pendant des restrictions réseau" et crée "un risque substantiel d'utilisation abusive par des éléments antinationaux, des organisations terroristes, des groupes criminels organisés". Plus loin, on lui reproche une architecture qui entrave "l'interception légale, l'attribution et l'enquête". En clair, le reproche c'est de continuer à marcher quand l'État a coupé le net.

Côté droit, l'ordre s'appuie sur la Section 79(3)(b) de l'IT Act et la Rule 3(1)(d) des IT Rules, c'est-à-dire les articles en Inde qui protègent les hébergeurs de la responsabilité des contenus publiés par leurs utilisateurs.

Les infractions listées, elles, vont de l'accès non autorisé à un système informatique à la complicité, plus trois articles du nouveau code pénal indien sur le complot criminel et l'atteinte à l'unité nationale. Oui, oui, pour un dépôt de code... Bien sûr, l'Internet Freedom Foundation qualifie la manœuvre d'"inconstitutionnelle et autoritaire" et lui reproche de court-circuiter la procédure de blocage officielle. Certes, la Section 79 conditionne une immunité, mais elle n'ouvre absolument pas un droit de censure, puis surtout, cette notice ne désigne aucun message ni aucun fichier illicite précis mais vise le projet entier. Bref, c'est trop vague !

Et même si les rêves les plus humides du gouvernement indien se réalisaient, retirer un dépôt ne retire pas grand-chose. Si vous avez déjà l'app sur votre téléphone, elle y reste, et un maillage qui ne dépend d'aucun serveur continue de faire circuler les messages quoi qu'il arrive à la page GitHub.

MediaNama écrit que GitHub a obtempéré et retiré les liens de sa plateforme. Comme j'y ai encore accès, je pense que ça ne concerne que l'Inde et que Github a fait ça en mode géoblocage. Mais bon, peu importe, ça + l'effet Streisand, dans les heures qui ont suivi la notice, le code était de toute façon recopié sur d'autres sites. Il est sous licence libre, donc il peut être forké dans tous les sens.

En tout cas, ce n'est pas la première fois que cette messagerie sert de plan B à la population puisqu'au Népal, en septembre 2025, elle a été téléchargée près de 49 000 fois en une seule journée durant les manifestations Gen Z, soit près de 40 % de son adoption mondiale sur ce seul pays. Couper le réseau pour calmer une foule, l'Égypte avait déjà essayé en janvier 2011 , la Syrie quelques mois plus tard et on le sait, ça ne fonctionne pas.

Source

Nearby Glasses - L'app qui détecte les lunettes caméra Meta

Les Ray-Ban Meta, c'est quand même le gadget parfait pour les voyeurs technophiles. Ce sont quand même des lunettes qui filment, prennent des photos et diffusent en live... le tout sans que PERSONNE autour ne s'en rende compte (ou presque). Alors forcément, quelqu'un a fini par coder une app pour les détecter !

Nearby Glasses , c'est une application Android développée par Yves Jeanrenaud qui scanne en permanence les signaux Bluetooth Low Energy autour de vous. Chaque appareil BLE diffuse en fait des trames pour s'annoncer avec un identifiant constructeur et les lunettes caméra de Meta utilisent les IDs 0x01AB et 0x058E (Meta Platforms) ainsi que 0x0D53 (Luxottica/Ray-Ban). Donc cette app écoute ces identifiants et vous balance une alerte dès qu'elle en capte un.

La détection repose sur le RSSI, en gros la puissance du signal reçu et par défaut, le seuil est à -75 dBm, soit environ 10-15 mètres en extérieur et 3-10 mètres en intérieur. Donc c'est pas foufou non plus mais c'est configurable, évidemment. Vous pouvez donc le durcir un peu pour ne choper que les lunettes vraiment proches, ou l'assouplir pour ratisser large (au prix de faux positifs en pagaille).

Les faux positifs, parlons-en d'ailleurs... Les casques Meta Quest utilisent les mêmes identifiants constructeur, du coup ça ne marche pas à tous les coups. Par exemple, si votre voisin joue en VR, votre téléphone va sonner ! L'app détecte aussi les Snap Spectacles (0x03C2)... pour les trois personnes qui en portent encore ^^.

Ah et l'app est UNIQUEMENT pour Android. La version iOS serait "on the way" selon le développeur... faut donc pas être pressé mais au moins c'est open source (AGPL-3.0), du coup n'importe qui peut vérifier ce que l'app fait de vos données Bluetooth.

Si le sujet vous parle, vous connaissez peut-être Ban-Rays , un projet hardware à base d'Arduino et de LEDs infrarouges qui détecte les Ray-Ban Meta via infrarouge et Bluetooth ! Hé bien Nearby Glasses, c'est l'approche 100% logicielle plutôt que hardware, ce qui est plus accessible mais forcément plus limitée... pas besoin de fer à souder, cela dit ^^.

C'est une rustine mais bon, c'est mieux que de se retrouver à poil sans permission sur le web.

Source

La clé magique qui déverrouille tous les scooters Äike

Vous connaissez le concept de clé maître ? Hé bien Rasmus Moorats, un chercheur en sécurité estonien, vient d'en trouver une qui déverrouille l'intégralité du parc de scooters électriques Äike. Et vous vous en doutez, c'est pas vraiment ce que le fabricant avait prévu.

Le bougre a décidé de reverse-engineerer son propre deux-roues connecté après que la boîte ait fait faillite en 2025. Logique, quand le cloud menace de fermer, autant comprendre comment fonctionne sa bécane. Du coup il a décompilé l'app React Native, hooké les communications Bluetooth avec Frida, et là... surprise !

L'authentification entre l'app et l'engin utilise un système de challenge-response. Le scooter envoie un défi aléatoire, l'app le concatène avec une clé secrète, hash le tout en SHA-1, et renvoie le résultat. Simple et efficace. Sauf que la clé secrète en question, c'est FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF. Vingt octets de FF.

Vous l'aurez peut-être compris, c'est la valeur par défaut du SDK fourni par le fabricant du module IoT.

Bref, les devs d'Äike n'ont jamais personnalisé cette clé. Chaque scooter sorti d'usine embarque exactement la même. Du coup avec un script Python et la lib bleak, n'importe qui peut déverrouiller n'importe quel Äike qui passe dans la rue. Hop, on scanne, on répond au challenge avec la clé universelle, et on envoie les commandes : déverrouiller, activer le mode éco, ouvrir le compartiment batterie... tout y passe.

Le plus rigolo dans l'histoire c'est que la société sœur Tuul, qui fait de la location de trottinettes, n'a pas de Bluetooth sur ses engins ! Du coup elle n'est pas touchée. Comme quoi, parfois l'absence de fonctionnalité devient une feature de sécurité.

Évidemment, Rasmus a fait les choses proprement avec une disclosure responsable en septembre dernier. Le fabricant a alors confirmé que c'était bien leur faute, et pas celle du fournisseur du module. Mais bon, maintenant que la boîte a coulé, les correctifs risquent d'attendre looongtemps.

Source

Ban-Rays - Les lunettes qui détectent les smart glasses

De nos jours, quand un mec chelou avec des lunettes cheloues nous fixe, on ne sait plus si c’est parce qu’il nous trouve irrésistible ou s’il est en train de balancer notre tronche à une IA pour savoir qui on est. Bon, pour vous, la question se pose peut-être moins, mais vous voyez l’idée ^^.

Heureusement, pour lutter contre ça, y’a maintenant un projet open source pour détecter ces petits curieux équipés de Ray-Ban Meta ou d’autres lunettes-caméras. Ce projet s’appelle Ban-Rays (jeu de mots avec “banned”, roh roh roh) et le but c’est de créer des lunettes capables de repérer les smart glasses équipées de caméras.

Et pour arriver à cela, le dev derrière ce projet utilise deux approches complémentaires.

La première, c’est l’approche optique basée sur un principe physique assez marrant. En effet, mes capteurs CMOS des caméras ont la particularité de renvoyer la lumière infrarouge directement vers sa source. C’est ce qu’on appelle l’effet “cat-eye” ou rétro-réflectivité, du coup, en balançant des impulsions IR vers une paire de lunettes suspecte et en analysant le signal réfléchi, on peut théoriquement détecter la présence d’une caméra. Et les capteurs produisent des pics de signal bien nets et rapides, contrairement aux surfaces réfléchissantes classiques qui génèrent des ondes plus longues.

Pour le moment, les tests avec les Ray-Ban Meta montrent des résultats un peu inconsistants à courte distance (genre 10 cm), mais le principe est là et ça s’améliore. Ah oui et le matos utilisé c’est un Arduino Uno, des LEDs infrarouges (940nm et 850nm), une photodiode et un transistor. Rien de bien méchant donc niveau budget.

Et la deuxième approche, c’est côté réseau avec la détection Bluetooth Low Energy. Les Ray-Ban Meta utilisent un identifiant fabricant spécifique (0x01AB pour Meta) et un Service UUID bien particulier (0xFD5F). Le souci c’est que pour le moment, ça ne détecte les lunettes que pendant l’allumage ou le mode appairage. Pour une détection continue pendant l’utilisation normale, faudrait du matos plus costaud genre modules nRF pour sniffer les paquets CONNECT_REQ. Mais bon, ça viendra puisque c’est dans la roadmap du projet.

Alors oui, vous allez me dire que les Ray-Ban Meta ont une petite LED qui s’allume quand elles filment, donc c’est pas discret. En théorie oui auf que cette LED est tellement minuscule que la Data Privacy Commission irlandaise a carrément remis en question son efficacité comme protection de la vie privée. Et surtout, un bidouilleur propose maintenant de désactiver cette LED pour une soixantaine de dollars. Meta a bien prévu une protection qui empêche les lunettes de fonctionner si on couvre la LED avec du scotch, mais le gars a trouvé comment contourner ça et sa liste de clients s’allonge…

Et l’autre truc que j’ai remarqué avec ces lunettes connectées, c’est qu’elles se déclenchent tout le temps pour tout et n’importe quoi. Comme ça écoute en permanence pour répondre aux commandes vocales, impossible d’avoir une conversation normale sans que le machin réagisse à un mot qui ressemble vaguement à “Hey Meta”. C’est encore pire que Siri ou Alexa qui font déjà des déclenchements intempestifs. Perso, c’est pour ça que je ne veux pas de ce genre de lunettes, même si je reconnais que c’est pratique pour photographier ou filmer des choses (dans le cadre de mon boulot hein…)

Et les inquiétudes sont d’autant plus justifiées qu’une étude de 2024 a montré qu’en combinant des Ray-Ban Meta hackées avec de la reconnaissance faciale en temps réel, on pouvait identifier des inconnus dans la rue. Encore plus récemment, l’Université de San Francisco a dû alerter ses étudiants après qu’une personne mystérieuse ait utilisé ces lunettes pour filmer des femmes sur le campus et partager les vidéos en ligne. Sympa l’ambiance de parano.

Bref, si vous êtes inquiet par ça (ou juste soucieux de votre vie privée), le projet Ban-Rays est sur GitHub avec tout le code en C++, Python et un peu de C. C’est encore expérimental mais les deux approches sont prometteuses et si vous voulez contribuer, y’a plein de trucs à améliorer comme les patterns de balayage IR, la fusion des données multi-longueurs d’onde, l’interrogation active BLE…

Source

Un serveur musical pour mon salon

Aujourd’hui, on va mettre en place un serveur musical pilotable à distance en utilisant MPD. Il sera notamment capable de jouer de la musique stockée dessus ou des radios Internet. Il sera aussi capable de se comporter comme une enceinte Bluetooth.

On va parler de récup de vieux matos, de Debian, MPD, PipeWire, Samba, d’agent Bluetooth, de systemd (-analyze, -logind), de Powertop et de vbetool.

Serveur musical - les clients MPD se connectent à MPD, les clients Bluetooth peuvent jouer de la musique, les clients SMB peuvent envoyer des fichier, et le serveur est relié à des enceintes en Jack

Cet article au ton très « administration système » s’adresse à :

  • des gens qui voudraient mettre en place un système plus ou moins similaire, même pour faire autre chose dans le même esprit (en mode tutoriel) ;
  • des gens qui aiment les détails techniques et voir les trucs cools qu’on peut faire avec les logiciels libres ;
  • toute autre personne curieuse pour d’autres raisons.

Il est probablement trop technique pour quelqu’un qui ne manipule pas la ligne de commande, qui pourra peut-être malgré tout, avec suffisamment de motivation, se laisser porter par la démarche.

Sommaire

Introduction

Note de lecture : cette dépêche est très détaillée, je vous conseille de passer les sections qui vous intéressent moins.

Motivation

Dans mon salon, j’ai des petites enceintes toutes bêtes qui sonnent plutôt bien. Mettre de la musique implique de s’embêter à brancher un ordinateur, sur lequel je suis le seul avoir le contrôle. Ce serait bien d’avoir un système prêt à l’emploi et que tout le monde peut contrôler.

Objectifs

  • Pas d’achat : on fait avec de la récup
  • Peu gourmand en énergie
  • Silencieux (à part la musique, bien sûr)
  • Facile à utiliser pour une personne non technique
  • Pouvoir mettre de la musique sans que ça soit pénible, en utilisant ma bibliothèque musicale locale, ou des radios internet
  • Pouvoir laisser n’importe qui se connecter en Bluetooth et lancer sa propre musique

Nous allons, ensemble, remplir ces objectifs. On va rentrer dans les détails, qui peuvent être utiles dans d’autres applications, et parce que je sais que certaines personnes ici aiment ça, bande de geeks :-)

Matériel à disposition

  • des enceintes parfaitement fonctionnelles mais sans fonctionnalité Bluetooth
  • un appareil style netbook du début des années 2010 (dans mon cas, c’est une vieille tablette Airis Kira Slimpad plus vraiment adaptée au web moderne, dotée d’un processeur Intel Atom un peu lent, d’un peu de stockage assez lent, d’un Wifi plutôt lent, du Bluetooth, d’1 Giga de mémoire vive)

Note sur les interférences Wifi et Bluetooth. Le Wifi de cette tablette est en 2,4 GHz, pareil que le Bluetooth. Tout échange wifi cause des perturbations sur le Bluetooth et tout transfert intensif rend le Bluetooth inutilisable. Du grand classique. Un Wifi 5, 6 ou 7 aurait été appréciable. Il serait possible d’utiliser une carte Wifi USB, mais je n’en ai pas donc on fera sans.

Ce qu’on va faire dans les grandes lignes

  • Installer une Debian minimale
  • La configurer pour qu’elle soit accessible par le réseau, la plus rapide et légère possible en utilisation mémoire, en temps de démarrage et en consommation énergétique
  • Installer et configurer MPD
  • Installer et configurer Samba
  • Configurer en mode « enceinte Bluetooth »

Installation standard minimaliste de Debian

Par souci de concision, on ne va pas détailler l’installation de Debian, il existe d’autres ressources au besoin.

En résumé :

  • Debian classique en 32 bits (ça consomme moins de mémoire que du 64 bits)
  • j’ai laissé l’installateur faire le partitionnement (une partition principale en ext4, et une partition swap de 1G)
  • j’ai ajouté l’option noatime sur la partition principale pour éviter d’écrire inutilement lors des accès, ce qui use le SSD et ralentit le système (d’autant que le SSD est lent)
  • lors de l’étape Tasksel, choisir console, serveur ssh et utilitaires standard, et en particulier pas d’environnement de bureau
  • on installe sudo et on ajoute l’utilisateur au groupe sudo, ou alors on se donne accès à root en ssh avec une clé SSH
  • on installe iwd (le remplaçant moderne de wpa_supplicant, supposé plus performant et plus stable permettant également de se passer de NetworkManager assez facilement) et on connecte l’appareil en wifi avec
  • on identifie et désactive ou on désinstalle le superflu avec systemd-analyze critical-chain et systemd-analyze blame (typiquement, si vous avez installé NetworkManager, ModemManager a peut-être été installé alors que vous n’avez pas de modem à gérer)
  • on peut configurer le menu de Grub pour moins attendre au démarrage

Note : sur cette tablette, l’installateur Debian n’arrive pas à se connecter en Wifi, j’ai donc utilisé la version DVD (le premier suffit).

Gains énergétiques potentiels

Éteindre l’écran

L’écran est potentiellement une des plus grosses sources de consommation électrique. On n’en a pas besoin, donc on va l’éteindre au démarrage et à la sortie de veille.

Pour cela, on va installer vbetool (sources : outils pour éteindre l’écran, lancer une commande au démarrage, lancer une commande après la veille):

sudo apt install vbetool
cat << EOF | sudo tee /etc/systemd/system/screenoff.service
[Unit]
Description=Screen off
After=suspend.target

[Service]
ExecStart=vbetool dpms off

[Install]
WantedBy=multi-user.target suspend.target
EOF

Attention : ça peut compliquer grandement l’usage de l’appareil, on peut vouloir appliquer un délai avant extinction pour se faciliter la vie.

Powertop pour améliorer la consommation électrique

Powertop permet de voir ce qui utilise le CPU et les diverses ressources, et d’ajuster un peu les paramètres de mise en veille de différents périphériques.

On va l’installer :

sudo apt install powertop

Ensuite, ça peut être cool de lancer l’outil pour constater un peu ce qui tourne et consomme des ressources, de se déplacer dans les onglets, et de tenter des trucs dans l’onglet « Tunables » :

sudo powertop

Si passer tout à Good ne cause pas de problème d’instabilité évidente, alors on peut appliquer la configuration de Powertop à chaque démarrage (source) :

cat << EOF | sudo tee /etc/systemd/system/powertop.service
[Unit]
Description=PowerTOP auto tune

[Service]
Type=oneshot
Environment="TERM=dumb"
RemainAfterExit=true
ExecStart=/usr/sbin/powertop --auto-tune

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable powertop.service

Sinon, il y a des solutions mentionnées dans la source pour désactiver certains changements (si vous observez des dysfonctionnements avec certains périphériques par exemple, et notamment si vous avez des problèmes de Wifi ou Bluetooth)

Perso, je sais que sur cette tablette, passer tout à Good fait (faisait il y a 10 ans en tout cas) qu’après un délai la première frappe sur le clavier ou le premier clic de la souris était ignoré, et aussi était nécessaire pour réveiller l’USB – clairement je m’en fiche ici, mais si votre wifi ou votre Bluetooth est en USB et que les paramètres causent une extinction après un délai, clairement ce n’est pas bon).

Bonus : Configurer le bouton power pour mettre en veille

Sur ma tablette, un appui court sur le bouton power éteint la tablette (et ensuite on la rallume en appuyant 3 longues secondes). Si on souhaite qu’un appui court mette en veille l’appareil et un appui long l’éteigne, comme ça on fait un compromis énergétique supposément raisonnable pour rendre l’ensemble un poil plus pratique, c’est facile avec systemd.

Ajoutez ces deux lignes au fichier /etc/systemd/logind.conf :

HandlePowerKey=suspend
HandlePowerKeyLongPress=poweroff

Rechargez les paramètres :

sudo systemctl restart systemd-logind

MPD : Music Player Deamon

Ok, passons au cœur du sujet : mpd.

Késako

Simplement, c’est un lecteur de musique pilotable à distance qui est capable de :

  • lire de la musique que vous mettez dans son dossier de travail ;
  • lire des playlists que vous mettez dans son dossier de travail ;
  • lire des flux radio, qui sont par exemple définis dans des playlists.

Entre autres.

Certains clients MPD, comme Cantata (une application Qt5 plus ou moins abandonnée mais encore dans les dépôts), sont même capables de lire de la musique sur votre serveur MPD que vous avez localement sur votre ordinateur, ou de gérer les playlists. Ça rend d’ailleurs la constitution de playlists vaguement confortable. Vous n’avez pas besoin d’écrire des playlists M3U à la main, quoi.

Les avantages sont multiples :

  • c’est méga léger, une machine épuisée peut faire tourner MPD à l’aise
  • si vous lisez la musique stockée sur le serveur, le réseau n’est pas engorgé
  • on peut être plusieurs à contrôler la musique, ce n’est pas une personne qui contrôle tout, et on peut le faire depuis le canapé
  • il existe toute une flopée de clients, il y en a pour tous les goûts pourvu que vous aimiez les logiciels abandonnés ou en ligne de commande / en ncurses (ouais, c’est quand même un problème que j’identifie et qui a largement retardé mon adoption de MPD)
    • les gens non techniques apprécieront les applications mobiles telles que M.A.L.P pour gérer la musique et le volume sonore.

C’est parti pour l’installation

sudo apt install mpd

On va modifier sa configuration :

sudo nano /etc/mpd.conf

On peut laisser les paramètres par défaut suivants :

music_directory         "/var/lib/mpd/music"
playlist_directory              "/var/lib/mpd/playlists"

Vous l’aurez compris, c’est là où on stocke les musiques et les playlists. Dans la section suivante, on verra comment rendre le dépôt de morceaux simple et convivial.

On va laisser la plupart des autres paramètres par défaut.

On va changer bind_to_address, qui est par défaut à localhost, mais on veut que n’importe quel appareil sur le réseau soit capable de s'y connecter. On va aussi explicitement mettre le port à la valeur par défaut (ce n’est probablement pas nécessaire, mais c’est ce que j’ai fait) :

bind_to_address                 "0.0.0.0"
port                            "6600"

On veut aussi que quand des fichiers sont changés dans les dossiers music et playlists, mpd se mette à jour tout seul pour ne pas avoir à le baby-sitter :

auto_update     "yes"

J’ai tenté d’activer zeroconf pour que les clients MPD puissent le trouver tout seul :

zeroconf_enabled                "yes"
zeroconf_name                   "Music Player @ %h"

Mais en vrai, je n’ai pas réussi à faire fonctionner ça. En tout cas, un prérequis est d’avoir installé et activé avahi-daemon, on verra ça plus tard dans la partie Samba du coup.

Vous aurez peut-être envie de mettre un mot de passe voire de changer les permissions par défaut en décommentant et adaptant les paramètres suivants, mais c’est optionnel :

#password                        "password@read,add,control,admin"

#default_permissions             "read,add,control,admin"

Ensuite, la partie critique, la sortie audio. Pour l’instant, on va dire à mpd d’utiliser Alsa directement. C’est le plus direct et le plus léger (on passera à PipeWire plus tard, pour gérer l’aspect récepteur Bluetooth)

audio_output {
       type            "alsa"
       name            "My ALSA Device"
       device          "hw:0,0"        # optional
       mixer_type      "hardware"      # optional
     # mixer_device    "default"       # optional
       mixer_control   "Master"        # optional
       mixer_index     "0"             # optional
}

Pour une de mes installations, j’ai commenté mixer_device parce que ce n’est manifestement pas la bonne valeur chez moi, et que ça marche bien sans.

Vous pouvez vous passer des autres valeurs optionnelles, mais vous n’aurez pas le contrôle du volume sonore depuis les clients MPD si vous faites ça. Vous allez donc devoir trouver les bonnes valeurs pour les paramètres mixer_*, et pour device. ainsi que mixer_control et mixer_index.

Quelques indices :

  • hw:0,0 est probablement la bonne valeur pour device, et 0 pour mixer_index aussi. Vous pouvez lister vos cartes son avec aplay -L. Vous aurez peut-être besoin d’installer le paquet alsa-utils.
  • la valeur de mixer_control est le nom du contrôle que vous utiliserez pour changer le volume dans alsamixer, du paquet alsamixergui que vous aurez probablement besoin d’installer.

Si vous galérez trop avec les valeurs de mixer-*, vous pouvez simplement utiliser mixer_type "software", c’est moins propre mais ça devrait faire le taf. Et sinon, vous pouvez toujours sortir l’artillerie lourde et passer directement à PipeWire.

Pour appliquer vos modifications :

systemctl enable --now mpd # À partir de Debian Trixie, mpd n’est plus activé par défaut au niveau du système
systemctl restart mpd # Si MPD tournait déjà

Vous pouvez déboguer vos changements avec la commande suivante, qui suit les logs en temps réel :

journalctl -fu mpd

Vous avez plusieurs options pour essayer de lire des choses avec mpd :

  • installer l’application M.A.L.P sur votre téléphone Android, ou une autre application cliente MPD, et ajouter un profil avec la bonne adresse, le bon port et le bon mot de passe ;
  • installer un client comme Cantata sur votre ordinateur, avec la bonne adresse, le bon port et le bon mot de passe ;
  • installer mpc directement sur le serveur. Normalement mpc play permet de lancer la lecture.

Moi, j’ai testé avec une webradio dans une playlist (/var/lib/mpd/playlists/radio-paradise-main-mix.m3u avec le contenu http://stream.radioparadise.com/ogg-192m), mais on peut aussi évidemment placer un morceau dans /var/lib/mpd/music/.

ReplayGain

Le niveau sonore de mes morceaux n’est pas homogène, donc il faut sans cesse adapter le volume d’un morceau à l’autre. C’est pénible, voire inutilisable en l’état. Une solution pour ça est replay gain : on analyse et on enregistre le niveau sonore d’une piste dans ses métadonnées.

Il existe plein d’outils pour faire ça, dont https://github.com/complexlogic/rsgain

On peut le faire avant d’envoyer les fichiers sur l’appareil. Pour ma part, je l’ai fait sur la tablette, et il n’existe pas de paquet Debian 32 bits, donc je l’ai compilé :

sudo apt install cmake build-essential pkd-config git libavcodec-dev libavformat-dev libtag1-dev libebur128 libinih-dev libfmt-dev
git clone --depth=1 https://github.com/complexlogic/rsgain
cd rsgain
mkdir build
cd build
cmake ..
make -j2
sudo make install

Il faudra s'assurer que les morceaux au format Opus sont étiquetés avec le tag R128_TRACK_GAIN et pas REPLAYGAIN_TRACK_GAIN, parce que c'est ce que MPD s’attend à avoir. Pour ça, on va convaincre rsgain de suivre les standards (que certains lecteurs de musiques ne comprennent pas) en créant un preset qui contient :

[Opus]
OpusMode=s

Mes morceaux ne sont pas organisés par albums, donc je désactive l’analyse par album. Je vais donc partir du preset no_album :

mkdir -p ~/.config/rsgain/presets; cat << EOF > ~/.config/rsgain/presets/no_album_standard_opus.ini 
[Global]
TagMode=i
Album=false
TargetLoudness=-18
ClipMode=p
MaxPeakLevel=0.0
TruePeak=false
Lowercase=false
ID3v2Version=keep
PreserveMtimes=false
DualMono=false
OpusMode=s
EOF

Ensuite, on peut le rsgain sur le dossier de musiques avec ce preset. Mes morceaux ne sont pas organisés par albums, donc je désactive l’analyse par album.

rsgain easy -p no_album_standard_opus -m MAX /var/lib/mpd/music

Note : l'option --skip-existing permet d'ignorer les fichiers déjà taggés :

rsgain easy --skip-existing -p no_album_standard_opus -m MAX /var/lib/mpd/music

Avec cette option, on peut exécuter cette tâche régulièrement, par exemple dans un cron, pour calculer le ReplayGain pour les nouveaux fichiers. Pour la première exécution, il vaut certainement mieux ne pas l’utiliser, sinon, si vous aviez déjà des fichiers qui avaient l'information, il se peut que le résultat ne soit pas uniforme.

Il faut dire à MPD d’utiliser le ReplayGain dans /etc/mpd.conf :

replaygain                      "track"

Vous aurez peut-être besoin de jouer avec les autres paramètres liés au volume et au ReplayGain.

Voici les miens :

# Ce paramètre définit la pré-amplification à appliquer pour les morceaux qui ont l'information du ReplayGain
replaygain_preamp              "0"

# Ce paramètre définit la pré-amplification à appliquer pour les morceaux qui ne l'ont pas
replaygain_missing_preamp      "0"

# Faut-il interdire à MPD de dépasser le niveau original d'amplification en appliquant le ReplayGain?
replaygain_limit                "no"

# Faut-il permettre à MPD d'ajuster le volume pendant la lecture pour normaliser ?
volume_normalization            "no"

Un autre paramètre qu’on peut régler, c'est la manière dont MPD règle le volume dynamiquement pour ReplayGain. Dans votre bloc audio_output, vous pouvez ajouter replay_gain_handler et la valeur "software" (c'est la valeur par défaut) ou "mixer". En théorique, les traitements software dégradent le son, mais en pratique, avec "mixer", je tombe sur ce bug qui met le volume à 100% après chaque changement de piste.

Note : je ne suis pas encore convaincu d’avoir réussi à trouver les réglages parfaits, n’hésitez pas à expérimenter.

Les clients MPD

À ce stade, vous devriez avoir un serveur MPD fonctionnel et configuré. Si applicable, vous pouvez commencer à suggérer aux gens de votre foyer d’installer l’application M.A.L.P sur leur appareil Android ; elle est libre et disponible sur F-Droid et sur le Play Store. Avec un peu de chance, votre enthousiasme était communicatif et c’est eux qui vous demanderont :-)

Pour les autres types d’appareils, vous allez devoir faire vos recherches vous-même je n’ai pas étudié les options sous Windows, Mac ou iPhone, mais il y en a. Pour Linux, j’ai essayé Cantata. Il me convient, si ce n’est qu’il a l’air un peu abandonné, et il a une interface certes conviviale, mais quand même un peu brute. Il existe des widgets qui s’intègrent aux différents environnements de bureaux pour les différents systèmes d’exploitation, je n’ai pas exploré. Le site de MPD propose une liste de clients, et le wiki de Arch aussi.

 M.A.L.P, un client mobile pour MPD

Samba pour déposer les morceaux (et les playlists)

Déposer des morceaux, vous allez probablement le faire depuis un ordinateur, et à peu près n’importe quel système d’exploitation est capable d’aller chercher un dossier SMB en réseau, alors je vous propose de configurer un serveur Samba. Ça a le bon goût d’être très léger, très simple à faire et de fonctionner depuis n’importe quel OS. Allons-y, et tant qu’à faire, on va aussi installer Avahi, qui permettra aux ordinateurs sous Linux et Mac de découvrir les dossiers partagés tous seuls :

sudo apt install samba avahi-daemon

On va partager nos dossiers music et playlists au monde entier en lecture-écriture (YOLO). On édite /etc/samba/smb.conf:

[Musique]
path=/var/lib/mpd/music
read only=no
writable=yes
comment=Fichiers musique MPD
guest ok = yes
force group = audio
force user = mpd
browsable = yes
public = yes
create mask = 0644
directory mask = 0755

[Playlists]
path=/var/lib/mpd/playlists
read only=no
writable=yes
comment=Listes de lecture MPD
guest ok = yes
force group = audio
force user = mpd
browsable = yes
public = yes
create mask = 0644
directory mask = 0755

Je ne maitrise pas particulièrement Samba et il y a peut-être des options superflues, mais globalement l’esprit c’est :

  • n’importe qui doit pouvoir accéder à ces deux en lecture et en écriture depuis le réseau. En particulier, la création de dossiers doit marcher
  • MPD doit pouvoir lire ce qu’on a écrit dans ces dossiers
  • les fichiers et dossiers doivent avoir des permissions sensées

Bien sûr, on peut vouloir restreindre l’accès à certains utilisateurs et/ou avec un mot de passe. Je vous laisse creuser.

Après un redémarrage de Samba :

sudo systemctl restart samba

Avec un peu de chance, dans l’onglet « Réseau » de votre gestionnaire de fichier, dans la section « Partages SMB », votre appareil apparait. Sinon, vous devriez pouvoir y accéder avec smb://HOST/ avec Dolphin et probablement Nautilus, probablement \\HOST sous Windows.

Alternatives possibles à Samba

  • Si on a un NAS, monter un dossier sur le serveur MPD, voire installer MPD sur le serveur de stockage, ou avoir une tâche chron qui fait un rsync bien placé
  • Mettre en place une synchronisation avec Nextcloud ou Syncthing, et faire pointer MPD vers le bon dossier, ou ajouter le dossier de MPD comme dossier de stockage externe à Nextcloud par exemple
  • SFTP
  • NFS
  • FTP (mais les autres options sont probablement meilleures)

Récepteur Bluetooth

Ce n’est bien sûr pas nécessaire si vous êtes parfaitement satisfait·e avec MPD, mais si vous voulez que votre appareil soit en plus capable de se comporter comme une enceinte Bluetooth, vous êtes au bon endroit.

Les difficultés qu’on va résoudre sont les suivantes :

  • pour l’instant, MPD accède au son directement avec ALSA, et en général on ne peut pas être plusieurs sur ALSA. En tout cas, et même s’il a l’air possible de faire fonctionner Bluetooth et ALSA ensemble, ça n’a pas l’air d’être terriblement simple ou même stable. Donc on va utiliser PipeWire. On aurait pu utiliser PulseAudio, mais PipeWire le remplace, et fonctionne généralement mieux.
  • PipeWire, c’est pensé pour être lancé dans une session graphique d’un utilisateur, mais nous, on a un serveur headless. Il va falloir faire en sorte de lancer une session utilisateur au démarrage sans interaction, et que cette session ne soit pas tuée.
  • mpd tourne avec son utilisateur, PipeWire avec son utilisateur, et après s’être rendu compte qu’il faut que ça soit les mêmes, faut aussi savoir comment, et le faire.

Lors de l’installation de Debian, on a défini un utilisateur. On peut utiliser cet utilisateur. Sinon, on peut aussi en créer un pour ça, pensez bien à l’ajouter aux groupes audio et bluetooth.

Garder une session utilisateur active

On va démarrer une session utilisateur au boot :

sudo loginctl enable-linger user # remplacer user par le nom d’utilisateur

On va s’assurer que les processus de cette session ne sont pas tués au moment où on quitte une session (par exemple quand on quitte une session ssh) : dans le fichier /etc/systemd/logind.conf, décommentez la ligne KillExcludeUsers et ajouter le nom d’utilisateur après le =. Vous deviez avoir

KillExcludeUsers=user

user est le nom d’utilisateur.

On peut maintenant recharger ces paramètres :

sudo systemctl restart systemd-logind

Installer PipeWire et les choses nécessaires

À ce stade, MPD bloque probablement l’utilisation du son parce qu’il s’y connecte via ALSA. On va le stopper.

sudo systemctl stop mpd

PipeWire et WirePlumber vont dorénavant gérer le son, et libspa-0.2-bluetooth permet au démon qui gère le Bluetooth (Bluez) de s’inter-connecter à PipeWire pour le Bluetooth Audio.

sudo apt install wireplumber pipewire libspa-0.2-bluetooth

En tant que votre utilisateur (nommé user dans les commandes précédentes) (c’est important), activez PipeWire au démarrage et lancez-le :

systemctl --user enable --now pipewire wireplumber

Notez que pipewire-pulse n’est pas nécessaire, d’ailleurs vous pouvez le supprimer ou le désactiver en toute sécurité s’il a été installé.

Installer un agent Bluetooth qui accepte toutes les connexions audio sans vérifications avec code

Normalement, accepter les connexions Bluetooth se fait à l’aide d’un agent Bluetooth :

  • qui tourne dans votre session graphique : c’est géré par votre environnement de bureau, ou une application comme bluetooth-applet (est-ce que ça existe encore ?) que vous lancez. Là, évidemment, on n’a pas de session graphique, et pour l’instant on n’a pas d’agent Bluetooth qui tourne.
  • En ligne de commande, avec un outil comme bluetoothctl. Je vous invite à essayer. Vous pouvez lancer des commandes comme pairable on, discoverable on, scan on, et essayer de vous connecter avec un autre appareil. Après vos tests, vous pouvez tout recommencer en faisant oublier les appareils des deux côtés.

Évidemment, on ne va pas se connecter en ssh pour lancer bluetoothctl à chaque fois qu’on veut se connecter en Bluetooth. On va mettre en place un agent qui démarre automatiquement et qui a un comportement similaire à un casque ou des enceintes Bluetooth : qui accepte toutes les connexions Bluetooth audio. Pour ça, on va utiliser un script Python partagé par Collabora sous Licence LGPL 2.1+ qui fait ça très bien et qu’on va lancer au démarrage.

Bien sûr, ça veut dire que vos voisins peuvent s’amuser à jouer des trucs chez vous, ou même se connecter fortuitement en choisissant la mauvaise entrée.

Ce script a une dépendance, qu’on va installer :

sudo apt install python3-dbus

On va placer ce script dans speaker-agent.py:

#!/usr/bin/python3
# SPDX-License-Identifier: LGPL-2.1-or-later

import dbus
import dbus.service
import dbus.mainloop.glib
from gi.repository import GLib

BUS_NAME = 'org.bluez'
AGENT_INTERFACE = 'org.bluez.Agent1'
AGENT_PATH = "/speaker/agent"

A2DP = '0000110d-0000-1000-8000-00805f9b34fb'
AVRCP = '0000110e-0000-1000-8000-00805f9b34fb'

bus = None


class Rejected(dbus.DBusException):
    _dbus_error_name = "org.bluez.Error.Rejected"


class Agent(dbus.service.Object):
    exit_on_release = True

    def set_exit_on_release(self, exit_on_release):
        self.exit_on_release = exit_on_release

    @dbus.service.method(AGENT_INTERFACE,
                         in_signature="", out_signature="")
    def Release(self):
        print("Release")
        if self.exit_on_release:
            mainloop.quit()

    @dbus.service.method(AGENT_INTERFACE,
                         in_signature="os", out_signature="")
    def AuthorizeService(self, device, uuid):
        # Always authorize A2DP and AVRCP connection
        if uuid in [A2DP, AVRCP]:
            print("AuthorizeService (%s, %s)" % (device, uuid))
            return
        else:
            print("Service rejected (%s, %s)" % (device, uuid))
        raise Rejected("Connection rejected by user")

    @dbus.service.method(AGENT_INTERFACE,
                         in_signature="", out_signature="")
    def Cancel(self):
        print("Cancel")


if __name__ == '__main__':
    dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)

    bus = dbus.SystemBus()

    agent = Agent(bus, AGENT_PATH)

    mainloop = GLib.MainLoop()

    # By default Bluetooth adapter is not discoverable and there's
    # a 3 min timeout
    # Set it as always discoverable
    adapter = dbus.Interface(bus.get_object(BUS_NAME, "/org/bluez/hci0"),
                             "org.freedesktop.DBus.Properties")
    adapter.Set("org.bluez.Adapter1", "DiscoverableTimeout", dbus.UInt32(0))
    adapter.Set("org.bluez.Adapter1", "Discoverable", True)

    print("RPi speaker discoverable")

    # As the RPi speaker will not have any interface, create a pairing
    # agent with NoInputNoOutput capability
    obj = bus.get_object(BUS_NAME, "/org/bluez")
    manager = dbus.Interface(obj, "org.bluez.AgentManager1")
    manager.RegisterAgent(AGENT_PATH, "NoInputNoOutput")

    print("Agent registered")

    manager.RequestDefaultAgent(AGENT_PATH)

    mainloop.run()

Le script mentionne le Raspberry Pi, mais il n’y a absolument rien de spécifique au Raspberry dedans, il est suffisamment générique.

On va lancer ce script au démarrage en créant le fichier ~/.config/systemd/user/speaker-agent.service

[Unit]
Description=Bluetooth speaker agent

[Service]
ExecStart=python3 speaker-agent.py

[Install]
WantedBy=default.target

Et en l’activant (--now le lance tout de suite) :

systemctl --user enable --now speaker-agent.service

Il faudra aussi mettre JustWorksRepairing = always dans /etc/bluetooth/main.conf pour permettre le re-appairage sans interaction. Bon là j’avoue, je paraphrase largement ma source :-)

Ensuite, on va autoriser la connexion Bluetooth même sans session active (en SSH par exemple) (source). Si on ne fait pas ça, la connexion Bluetooth n’est pas possible si l’utilisateur n’a pas une session active (les symptômes : on arrive à se connecter en Bluetooth que quand on est loggué en SSH ou autre, et la connexion Bluetooth casse dès qu’on quitte la session).

mkdir -p ~/.config/wireplumber/bluetooth.lua.d
cat > ~/.config/wireplumber/bluetooth.lua.d/80-disable-logind.lua << EOF
-- Disable arbitration of user allowance of bluetooth via D-Bus user session
bluez_monitor.properties["with-logind"] = false
EOF
systemctl --user restart wireplumber

Adapter MPD (et Samba) pour utiliser PipeWire

Pour que MPD utilise PipeWire, il faut adapter :

  1. sa configuration pour qu’il tourne avec le même utilisateur
  2. sa configuration audio_output
  3. les permissions dans /var/lib/mpd

Dans /etc/mpd.conf, changer la ligne user :

user                            "mpd"

Elle doit maintenant utiliser votre utilisateur :

user                            "user"

Commentez votre bloc audio_output, on va maintenant utiliser PipeWire (je suppose qu’on pourrait garder les deux et les clients MPD peuvent probablement permettre de choisir la sortie son, mais ça me parait complexifier l’utilisation pour un intérêt pas clair, ce qui va contre nos objectifs) :

audio_output {
        type            "pipewire"
        name            "PipeWire Sound Server"
}

Maintenant, il est temps d’adapter les permissions dans /var/lib/mpd. On va stopper Samba juste avant, et adapter sa configuration.

sudo systemctl stop mpd samba # si mpd tournait encore
sudo chown -rv user /var/lib/mpd
sudo systemctl start mpd

Note : MPD peut aussi être démarré dans une session utilisateur et à ce stade, c’est ce qu’il serait probablement le plus logique de faire, en bougeant /etc/mpd.conf et le contenu de /var/lib/mpd dans le dossier de notre utilisateur. C’est d’ailleurs la manière privilégiée de démarrer MPD à partir de Debian Trixie. Par simplicité et cohérence, et parce que cette section « Récepteur Bluetooth » est optionnelle mais que les manipulations pour lancer une session utilisateur au démarrage décrites dans cette section seraient nécessaires pour lancer MPD en tant que service utilisateur au démarrage dans tous les cas et que ça apporte une réelle complexité, on fait le choix de garder MPD en tant que service système.

Modifiez /etc/samba/smb.conf. Dans les deux blocs de partages qu’on a ajouté précédemment, changez la ligne force user = mpd en:

force user = user

Puis on peut redémarrer Samba :

sudo systemctl start samba

Permettre à PipeWire de configurer sa priorité

Si vous voyez cela dans les logs de PipeWire :

user@tablette:~$ journalctl --user -fu pipewire
avril 29 13:41:01 tablette systemd[514]: Started pipewire.service - PipeWire Multimedia Service.
avril 29 13:41:01 tablette pipewire[531]: mod.rt: Can't find org.freedesktop.portal.Desktop. Is xdg-desktop-portal running?
avril 29 13:41:01 tablette pipewire[531]: mod.rt: found session bus but no portal
avril 29 13:41:02 tablette pipewire[531]: mod.rt: RTKit error: org.freedesktop.DBus.Error.AccessDenied
avril 29 13:41:02 tablette pipewire[531]: mod.rt: could not set nice-level to -11: Permission non accordée
avril 29 13:41:02 tablette pipewire[531]: mod.rt: RTKit error: org.freedesktop.DBus.Error.AccessDenied
avril 29 13:41:02 tablette pipewire[531]: mod.rt: could not make thread 547 realtime using RTKit: Permission non accordée

Ça veut grosso modo dire que PipeWire cherche à se rendre plus prioritaire via un mécanisme fourni par les environnements de bureau (xdg-desktop-portal), n’y arrive pas parce qu’évidemment, aucun environnement de bureau ne tourne, alors il essaie de demander au service système rtkit, et se fait jeter.

Ce n’est pas très grave et on pourrait vivre sans, mais ça pourrait aider à limiter les saccades sonores, donc on va réparer ça (et je pense avoir vu une bonne amélioration grâce à ça).

Le fichier /usr/share/polkit-1/actions/org.freedesktop.RealtimeKit1.policy dicte qui a le droit ou non de configurer sa priorité (découvert ici, mais le conseil de modifier ce fichier système n’est pas bon, au moins parce qu’une mise à jour future risque d’écraser les modifications) :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE policyconfig PUBLIC
        "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
        "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd">
<policyconfig>
        <vendor>Lennart Poettering</vendor>

        <action id="org.freedesktop.RealtimeKit1.acquire-high-priority">
                <description>Grant high priority scheduling to a user process</description>
                <description xml:lang="tr">Bir sürece yüksek öncelikli çalışabilme yetkisi ver</description>
                <message>Authentication is required to grant an application high priority scheduling</message>
                <message xml:lang="tr">Sürecin yüksek öncelikli çalıştırılabilmesi için yetki gerekiyor</message>
                <defaults>
                        <allow_any>no</allow_any>
                        <allow_inactive>yes</allow_inactive>
                        <allow_active>yes</allow_active>
                </defaults>
        </action>

        <action id="org.freedesktop.RealtimeKit1.acquire-real-time">
                <description>Grant realtime scheduling to a user process</description>
                <description xml:lang="tr">Bir sürece gerçek zamanlı çalışabilme yetkisi ver</description>
                <message>Authentication is required to grant an application realtime scheduling</message>
                <message xml:lang="tr">Sürecin gerçek zamanlı çalıştırılabilmesi için yetki gerekiyor</message>
                <defaults>
                        <allow_any>no</allow_any>
                        <allow_inactive>yes</allow_inactive>
                        <allow_active>yes</allow_active>
                </defaults>
        </action>

</policyconfig>

Dans un système Unix, les paramètres systèmes sont dans /etc. Pour Polkit, il existe un mécanisme pour écrire des règles, qu’on va utiliser. On va créer une règle qui permet à n’importe quel utilisateur du groupe audio de modifier la priorité de ses processus. C’est probablement trop large, mais je ne connais pas bien Polkit et ça fera le taf pour notre application dédiée à l’audio. Si vous avez des meilleures idées, n’hésitez pas à partager en commentaire.

sudo cat > /etc/polkit-1/rules.d/rt.rules << EOF
polkit.addRule(function(action, subject) {
        if (subject.isInGroup("audio") && (
                action.id == "org.freedesktop.RealtimeKit1.acquire-high-priority" ||
                action.id == "org.freedesktop.RealtimeKit1.acquire-real-time"
        )) {
                return polkit.Result.YES;
        }
})
EOF

sudo systemctl restart polkit.service
systemctl --user restart pipewire

On pourra constater l’absence des échecs dans les journaux de PipeWire.

Bon, on sent bien que toute cette utilisation audio sans session utilisateur standard n’est pas un cas d’utilisation hyper bien prévu et on se retrouve à toucher des coins un peu sombres du système…

Évitez les flux Wifi 2,4 GHz

Si vous avez un Wifi en 2,4 GHz, ça peut causer des soucis avec le Bluetooth, et le son peut saccader. Si vous observez cela, il faudra alors limiter au maximum les services et autres tâches de fond qui font des communications réseau. Évidemment, si vous pouvez utiliser un câble Ethernet, c’est encore mieux.

Sur ce plan, tous les codecs audio Bluetooth ne semblent pas se valoir. Pour tester ça, j’ai lancé un test iperf3 entre la tablette et mon ordinateur portable pour saturer le Wifi. Ça devenait immédiatement catastrophique avec le codec SBC-XQ, alors qu’avec le codec Opus 05, il y a initialement des saccades, puis ça s’améliore vite. J’imagine que le codec Opus dégrade très efficacement la qualité pour compenser. Bon, malheureusement, tous les systèmes ne permettent pas de choisir son codec donc ce n’est qu’une solution partielle au problème.

Note sur l’utilisation des ressources

C'est léger :

load average: 0,12, 0,10, 0,05
$ free -mh
               total       utilisé      libre     partagé tamp/cache   disponible
Mem:           986Mi       253Mi       324Mi       6,1Mi       550Mi       733Mi
Échange:       974Mi          0B       974Mi

Globalement, le CPU s’ennuie en pleine lecture, et à peine un tiers du Giga de mémoire vive est utilisé, la partition d’échange s’ennuie, donc il y a encore largement la place de faire tourner d’autres trucs sur cet appareil si jamais. On peut aussi constater qu’ajouter MPD et tout ce bazar à une installation existante ne la surchargerait pas plus que ça.

On a aussi un temps de démarrage autour des 20 secondes, ce qui est franchement pas mal.

Conclusion et améliorations possibles

On est pas mal rentrés dans les détails, c’était l’occasion d’explorer plein de choses mine de rien. J’ai à la fois appris des choses, précisé des connaissances, et mis plein de choses que je savais ensemble pour obtenir un résultat très satisfaisant. On se retrouve à manipuler de la gestion de services, des configurations systemd un peu poussées, du bluetooth, du son avec ALSA et PipeWire, de la gestion de session utilisateur sur un système headless, et plein d’autres trucs et aller dans les détails comme le boot pour avoir quelque chose de rapide, comme l’écran éteint au bon moment, ou la personnalisation du comportement du bouton power (honnêtement, je n’étais pas très sûr que c’était possible, j’avais lancé la recherche au cas où !).
J’espère que l’aventure vous a plu aussi.

Bien sûr l’ensemble est perfectible, alors je vous laisse avec des idées, n’hésitez pas à partager les vôtres en commentaires :

  • Jouer un son au démarrage / à l’appairage Bluetooth. – pour l’instant, la tablette s’allume et puis plus rien. En général, les enceintes Bluetooth jouent un petit son quand elles sont prêtes ou qu’elles viennent d’être appairées et ça peut être pratique
  • Commande vocale. Il y a clairement des manières d’utiliser le micro de la tablette pour demander le morceau suivant, précédent ou régler le volume. Ça peut être pratique quand on n’a pas le téléphone sous la main et ça peut avoir son petit effet en soirée la première fois, tant que les gens ne sont pas encore complètement blasés par le concept parce que tout le monde n’a pas un Google Nest ou un Alexa chez soi, surtout dans ma bulle sociale. Mais c’est probablement finalement très gadget et je me vois mal interrompre une conversation en criant un ordre pour gérer la musique…
  • Appairage Bluetooth plus sécurisé. En général, les enceintes Bluetooth acceptent les nouveaux appareils dans un mode spécial. En appuyant sur le bouton Bluetooth, ou quelque chose comme ça. Ça peut éviter que les voisin·e·s ne te rickrollent au moment le plus inopportun. Ça vaudrait le coup de travailler sur quelque chose comme ça. Avec l’écran tactile, il est probablement possible de dessiner une forme particulière reconnue (ça serait un peu badasse, ou plus probablement, n’accepter (une seule) nouvelle connexion que dans les X minutes après le démarrage ou le retour de veille. Comme ça, demander l’appairage consiste à appuyer deux fois sur le bouton power, ce qui est plutôt acceptable. Si vous avez des idées, n’hésitez pas à partager…
  • Réveil à distance avec du Wake-on-LAN. Ça ne s’applique probablement pas à mon matériel, mais il est possible d’utiliser astucieusement le WoL pour réveiller l'appareil à distance, avec éventuellement la complicité d’un routeur ou d’un serveur toujours allumé chez vous.
  • Désactiver le Wifi quand le Bluetooth est utilisé. Pour éviter les interférences, on pourrait imaginer que quand un appareil se connecte en Bluetooth, on éteint le Wifi (avec rfkill par exemple), on met MPD en pause (ou on le stoppe s’il est en train de jouer un flux) parce qu’on ne peut plus le contrôler, puisque le Wifi n’est plus actif, et on réactive le Wifi quand l’appareil Bluetooth est déconnecté. On pourrait même être plus fin et détecter quand du son est joué.
  • Automatiquement mettre MPD en pause lors d’une connexion Bluetooth. (un peu doublon avec le précédent point) Pour l’instant, il faut manuellement mettre en pause mpd, sinon les deux flux audios se jouent en même temps. -- Changer la classe Bluetooth de l’appareil. Ça permettrait à l’appareil de se déclarer comme appareil audio, pour que ça affiche le bon icône sur les autres appareils.
  • Mises à jour automatiques. Il ne faut pas que ça casse des choses en pleine lecture, ni que ça cause des interférences avec le Bluetooth à cause des téléchargements.
  • Ne pas persister les logs. Pour l’instant, les logs sont écrits dans /var/log sur le SSD, entrainant une usure et un ralentissement cependant probablement tous deux négligeables. On pourrait vouloir ne pas les garder, mais c’est aussi risquer de perdre des informations de débogage le jour où il y a un pépin.

Je vais probablement trouver d’autres choses à améliorer après publication de l’article. Je partagerai peut-être les choses intéressantes en commentaires ou dans des journaux, et je ferai peut-être vivre l’article sur mon site.

Commentaires : voir le flux Atom ouvrir dans le navigateur

BlueDucky – Automatiser l’exploitation d’une faille Bluetooth pour exécuter du code à distance

Vous pensiez que votre Bluetooth était safe ? Détrompez-vous ! Un chercheur en sécurité vient de dénicher une faille bien vicieuse qui permet d’exécuter du code à distance sur tout un tas d’appareils : smartphones Android, Chromecast, casques VR, TV connectées…

Le principe est diabolique : il suffit de se faire passer pour un clavier Bluetooth et hop, on peut envoyer des frappes de touches à la victime sans même qu’elle ait besoin d’accepter l’appairage. Pas besoin d’être à portée de main, quelques mètres suffisent. C’est ballot hein ?

Mais attendez, ça devient encore plus fort (ou pire, c’est selon). Des petits malins ont créé un outil baptisé BlueDucky qui automatise complètement l’exploitation de cette faille. Ça scanne les appareils vulnérables à proximité, ça les enregistre dans un fichier et ça balance un script Ducky bien sournois pour prendre le contrôle à distance. Le tout depuis un Raspberry Pi ou un smartphone Android !

Autant vous dire qu’ils se sont éclatés à tester ça sur tout ce qui passait : des smartphones, des objets connectés, des ordinateurs… Si c’est pas patché et que ça a du Bluetooth, ça tombe comme des mouches. Ils ont même réussi à ouvrir un navigateur et à envoyer la victime sur une page bien flippante, juste pour le fun.

Bon, vous allez me dire : « OK, mais comment on se protège de ce truc ?« . Eh bien c’est là que ça se gâte. Si vous avez un appareil récent, foncez installer les dernières mises à jour de sécurité. Mais pour les vieux machins sous Android 10 ou moins, c’est cuit, ça ne sera jamais patché. La seule solution : désactiver carrément le Bluetooth. Sinon, vous pouvez dire adieu à votre intimité numérique !

Mais ne cédons pas à la panique pour autant. Les chercheurs en sécurité font un boulot remarquable pour dénicher ces failles et alerter les fabricants. Maintenant, c’est à ces derniers de réagir en proposant des correctifs. Et à nous d’être vigilants en mettant à jour régulièrement nos appareils.

En attendant, si vous voulez jouer avec le feu dans la limite de ce que la loi permet, évidemment, le code de BlueDucky est disponible sur GitHub. Mais attention, c’est à vos risques et périls ! Ne venez pas vous plaindre si votre grille-pain se met à afficher des messages d’insulte au petit-déjeuner.

Pour l’installer :

# update apt
sudo apt-get update
sudo apt-get -y upgrade

# install dependencies from apt
sudo apt install -y bluez-tools bluez-hcidump libbluetooth-dev \
                    git gcc python3-pip python3-setuptools \
                    python3-pydbus

# install pybluez from source
git clone https://github.com/pybluez/pybluez.git
cd pybluez
sudo python3 setup.py install

# build bdaddr from the bluez source
cd ~/
git clone --depth=1 https://github.com/bluez/bluez.git
gcc -o bdaddr ~/bluez/tools/bdaddr.c ~/bluez/src/oui.c -I ~/bluez -lbluetooth
sudo cp bdaddr /usr/local/bin/

Et pour le lancer :

git clone https://github.com/pentestfunctions/BlueDucky.git
cd BlueDucky
sudo hciconfig hci0 up
python3 BlueDucky.py

Comme dirait l’autre, « le Bluetooth c’est comme le nucléaire, c’est génial tant que ça reste dans les mains des gentils« . Alors, soyez sympa et patchez-moi tout ça fissa ! Et si vous avez un appareil trop ancien qui traîne, coupez le Bluetooth et on n’en parle plus.

Pour en savoir plus sur cette faille et son exploitation, je vous invite à lire l’article ici.

La faille Bluetooth qui permet d’écouter à distance les gens et de leur jouer votre meilleure playlist

Ça n’arrête plus ! Une faille de sécurité critique dans le protocole Bluetooth permettrait à un utilisateur tiers malveillant d’enregistrer l’audio capté par le microphone d’une enceinte Bluetooth se trouvant à proximité, même si celle-ci est déjà appairée et connectée à un autre appareil. Cette vulnérabilité peut malheureusement conduire à de l’espionnage de conversations privées que ce soit via une enceinte ou un casque. Tant que c’est bluetooth et qu’il y a un micro, ça fonctionne !

Et s’il n’y a pas de micro, cette faille permettrait également jouer ses propres fichiers audio sur vos enceintes sans votre consentement !

Ce problème de sécurité a été découvert et présenté la semaine dernière par Tarlogic lors de la conférence RootedCon 2024 avec en cadeau bonux un PoC (proof of concept) baptisé BlueSpy permettant d’exploiter la faille.

Ce script n’utilise pas de vulnérabilité non corrigée, non, non. Il exploite tout simplement la méthode d’appairage Bluetooth non sécurisée baptisée « Just Work« . C’est d’autant plus effrayant quand on considère le nombre d’enceintes ou de casques vulnérables qui traînent dans les zones résidentielles, les espaces de travail, les salles de réunion, les lieux publics, etc.

Pour sa démonstration, Tarlogic a utilisé un Raspberry Pi 4 sous Kali Linux, contrôlé par un smartphone. Notez que pour étendre la zone de couverture, il est également possible d’utiliser un adaptateur Bluetooth externe avec une antenne externe.

Mais alors, comment se protéger ? La clé de votre tranquilité et de votre sécurité réside dans la visibilité de votre appareil Bluetooth. Si votre enceinte ou casque est visible par d’autres appareils alors qu’il est déjà connecté à votre smartphone, il est vulnérable. Par contre, s’il n’est plus visible une fois appairé, vous êtes à l’abri.

Pour vérifier facilement si vos appareils audio Bluetooth sont vulnérables, vous pouvez utiliser l’application gratuite nRF Connect for Mobile sur un smartphone Android non rooté. Lancez un scan et si l’application détecte et permet de se connecter à votre appareil audio Bluetooth LE, c’est qu’il est probablement vulnérable. À l’inverse, si votre appareil n’apparaît pas dans les résultats du scan alors qu’il est allumé et connecté, vous pouvez souffler.

Malheureusement, si votre appareil autorise une telle connexion, il n’y a pas grand-chose à faire. Certains appareils émettent cependant une notification visuelle ou sonore lorsqu’un autre appareil se connecte, comme un bip, une vibration ou un changement de couleur des LED donc ouvrez l’œil et l’oreille ! Et surtout, éteignez vos appareils Bluetooth quand vous ne les utilisez pas.

Source

❌