9,90 € TTC
p. 06 Pourquoi utilise-t-on GNU/Linux ? Vraiment ?
p. 14 Créer un Escape Game VR avec Godot
p. 26 DaC ou pas DaC : comment vont vos diagrammes ?
p. 40 Tests unitaires avec Jest
p. 56 Découverte et prise en main de Kivy
p. 66 Le namespace cgroup ne sera pas le dernier de la lignée
Cache-caméra ou cache-misère ?
Les « goodies » sont généralement l’une des bonnes raisons de se rendre à des salons et autres événements. Au FIC 2022 à Lille le mois dernier, le cache-caméra était partout, comme c’est le cas depuis plusieurs années. L’objectif de ce petit dispositif est de simplement obstruer l’objectif de la webcam intégrée à votre laptop, si d’aventure un vilain pirate (ou un agent d’un pays tout aussi vilain) venait à en prendre le contrôle.
L’idée n’est pas mauvaise, l’intention est louable, mais reposer sur une « sécurité » sans en connaître les limites est généralement un traitement pire que le mal. Il n’y a pas plus fragile que la personne qui se croit à l’abri de tout alors qu’elle ne l’est pas. Or, quiconque aura pris le temps un jour de retirer le cadre en plastique autour de son écran de portable saura que se trouvent là une webcam USB et... un ou plusieurs micros. Et sachant cela, la question pertinente est alors : quel média a le plus de chance de transporter des informations potentiellement sensibles, une image de vous en sous-vêtement ou ce que vous êtes susceptible de dire ou d’entendre à proximité du laptop ?
Donc, oui les cache-caméras peuvent être utiles et peut-être rassurants, mais si vous cherchez la sécurité, la bonne solution consiste à transporter une webcam USB et à faire un brin de bricolage, pour tout simplement débrancher le périphérique intégré :

Problème réglé !
Denis Bodor
GNU/Linux Magazine s'adresse aux professionnels et aux particuliers désireux de mieux maîtriser les techniques et problématiques liées à la programmation et à l’utilisation de solutions open source. Tous les deux mois avec ses articles techniques, la publication couvre les thématiques suivantes : programmation système, algo, bas niveau, sécurité du code, développement web...

La domotique, c'est fantastique ! Surtout quand ça ne coûte pas trop cher, que ça rend service aussi bien pour le contrôle des lumières, le suivi de la consommation électrique, le contrôle de l'environnement ou l'automatisation, et que tout cela fonctionne avec du logiciel libre, sans exfiltrer des tonnes de données privées chez un fournisseur qui se fera tôt ou tard pirater. Mais à trop vouloir jouer la carte de la sécurité, on se prive parfois de certains avantages. Trouvons donc le bon compromis pour rendre notre installation accessible, sans créer d'énormes brèches...
Que faut-il pour reproduire un badge NFC (Near Field Communication) ? Bien qu’il n’y paraisse rien, un badge NFC est en réalité une véritable prouesse d’électronique et d’informatique embarquée. Comment un simple « bout de plastique », sans aucun composant électronique visible ni alimentation, peut-il communiquer et échanger des informations avec un autre système informatique, sans même un contact physique, par le simple fait de sa proximité avec un lecteur ? Dans cet article, nous expliquerons en détail le fonctionnement d’un badge NFC et chercherons à créer un badge « maison ». Après avoir conçu une antenne adaptée, nous analyserons le protocole de communication entre le lecteur et le badge, puis tenterons de reproduire le comportement du badge pour leurrer le lecteur NFC. Tout cela nous amènera à réviser la physique des ondes électromagnétiques et à revoir plusieurs montages électroniques courants. Nous découvrirons également le périphérique RMT (Remote Controller) de l’ESP32, qui permet de générer des signaux temporels rapides et stables, tout en gérant de manière indépendante les interruptions du processeur pour synchroniser l’envoi des réponses.
Durant mes pérégrinations dans le petit monde du développement FPGA avec LiteX s'est posée une problématique intéressante, consistant à devoir écrire un support pour une interface série (UART) en n’ayant à disposition rien d'autre qu'une poignée de registres où lire ou écrire. Cet exercice, pour moi, était une phase préalable à l'implémentation d'un pilote pour un système d'exploitation, mais serait transposable à n'importe quel type d'interface reposant sur des mécanismes similaires, et ce, sur n'importe quel MCU ou SoC, actuel ou ancien. Faisons donc connaissance avec l'UART LiteX, voulez-vous ?