Pensées Libres dans un Monde Binaire
Focus rapide sur l’accès aux paquets AUR sous ArchLinux. J’utilisais jusqu’à présent yaourt, mais celui-ci n’étant plus maintenu, je vais tester yay pour la gestion de mes paquets AUR.
Le processus d’installation est simple, récupération d’une copie des sources, construction du paquet puis installation. Le programme étant écrit en go, on installera au préalable de quoi le compiler: sudo pacman -S go.
Installation :
git clone https://aur.archlinux.org/yay.git
cd yay
makepkg -si
Cela faisait un petit moment que j’avais envie de m’intéresser au monde des puces RFID. Après quelques recherches, j’ai fait le choix d’un lecteur RFID chinois de type ACS / ACR122U, qui a l’avantage de son prix abordable en comparaison de certains autres lecteurs. Pour cette première entrée en matière, je me suis donné pour objectif la création d’un clone de mon badge d’immeuble. Voici les étapes qui ont permis d’y arriver.
Sous ArchLinux, il est nécessaire d’installer quelques paquets pour la gestion du NFC, à savoir :
sudo pacman -S libnfc mfoc
Maintenant que les programmes nécessaires sont installés, nous pouvons connecter le lecteur à notre ordinateur, poser une puce RFID sur celui-ci et vérifier que tout est détecté.
$ nfc-listnfc-list uses libnfc 1.7.1
NFC device: ACS / ACR122U PICC Interface opened
1 ISO14443A passive target(s) found:
ISO/IEC 14443A (106 kbps) target:
ATQA (SENS_RES): 00 04
UID (NFCID1): 5a 7a 3f 10
SAK (SEL_RES): 08
Comme nous pouvons le voir dans le retour de la commande, le lecteur et la puce sont bien reconnus.
Passons maintenant à l’extraction des données de la puce source à proprement parler. La création d’un dump de la puce dans un fichier s’effectue avec la commande suivante :
mfoc -P 500 -O badge-entree.dmp
Afin de créer une copie parfaite, il convient de modifier l’UID de la puce cible. Attention, pour effectuer une opération de ce type, il est bien sûr nécessaire de disposer de puce RFID inscriptible dans leur totalité. On parle notamment de puce dont le bloc 0 est modifiable.
nfc-mfsetuid 5a7a3f10
A ce stade, les informations que j’ai pu trouver en divers endroits sur le web préconise d’exécuter une nouvelle fois la commande ci-dessus, mais cette fois sur la puce cible afin d’obtenir un fichier badge-vierge.dmp. Il est ensuite question de procéder à l’écriture des données sur la puce vierge de la façon suivante :
nfc-mfclassic w a badge-entree.dmp badge-vierge.dmp
En particulier, pour copier également le contenu du bloc 0, on remplacera l’option w par W, ce qui aura pour effet d’écrire l’intégralité des 64 blocs sur la puce, toujours si celle-ci le permet.
Pour ma part, j’ai noté que je n’ai pas réussi à modifier l’UID de ma carte cible avec la commande nfc-mfclassic, bien que le bloc 0 de la puce rfid soit modifiable. Je me suis donc tourné vers la commande présentée plus haut afin de remplacer spécifiquement l’UID de ma puce cible par celui de ma puce RFID source.
Par ailleurs, la commande ci-dessus ne m’a pas permis pas de créer une puce identique. Les clés ne sont pas modifiés et comparer le hash des dump permet de vérifier leur différence. La clé par défaut reste utilisée sur la puce chinoise. Un petit tour du côté de l’entrée de mon immeuble et la petite lumière rouge clignotante me confirme que les puces crées ne sont pas correctes.
Cette première tentative s’étant révélée infructueuse, j’ai donc tenté la création du clone de la manière suivante :
nfc-mfclassic W a u badge-entree.dmp
En exécutant mfoc sur la puce ainsi créée, le résultat n’est plus immédiat, ce qui est plutôt encourageant car cela prouve que la clé par défaut n’est plus utilisée.
Vérification avec les sommes de contrôle:
$ sha256sum badge-entree.dmp
0ca740e1a69a5eb379c96e232b6c39ed70daf8072912e2950e73f91876d3ec35
badge-entree.dmp
$ sha256sum badge-cible.dmp
0ca740e1a69a5eb379c96e232b6c39ed70daf8072912e2950e73f91876d3ec35 badge-cible.dmp
Dernier point, pour afficher le contenu d’un fichier hexadécimal dans le terminal, on pourra utiliser la commande hexdump (ou xxd, bien pratique également).
Avec le matériel et les logiciels adéquats, il est possible en quelques minutes de créer une copie parfaite d’une puce RFID, tel qu’un badge d’entrée d’immeuble. Étant donné que certaines puces RFID se présentent sous la forme de porte-clés, nous pouvons alors envisager une manière plus pratique d’ouvrir, par exemple, la porte d’accès de son entreprise. Il serait également intéressant de pouvoir fournir le contenu extrait de la puce à l’aide de son téléphone portable; l’idéal serait alors une identification automatique du lecteur pour un choix automatique de la puce RFID à émuler.
Il est possible d’installer une ancienne version d’un package en utilisant le cache de pacman, si celui-ci n’a pas été nettoyé depuis la mise à jour précédente. Par exemple, pour revenir à la version 5.6.0-1 de npm, on utilisera la commande:
pacman -U /var/cache/pacman/pkg/npm-5.6.0-1-any.pkg.tar.xz
Et on attendra la correction du bug 19989 pour réinstaller une version 5.7.x.
Dernièrement, j’ai rencontré un problème à la mise à jour d’un ordinateur sous Arch. L’erreur indiquait: « la préparation de la transaction a échoué (paquet invalide ou corrompu) ».
$ sudo pacman -Syu :: Synchronisation des bases de données de paquets... core est à jour extra est à jour community est à jour :: Début de la mise à jour complète du système... erreur : l’ouverture du fichier /var/lib/pacman/local/blender-17:2.78-1/desc a échoué : Aucun fichier ou dossier de ce type résolution des dépendances... recherche des conflits entre paquets... avertissement : les métadonnées pour le paquet blender-17:2.78-1 n’ont pas pu être totalement chargées. erreur : la préparation de la transaction a échoué (paquet invalide ou corrompu)
La première étape pour que Pacman accepte d’effectuer la mise à jour du système consiste à retirer le paquet posant problème, ici blender.
sudo pacman -R blender
Une fois le paquet retiré, on peut procéder à la mise à jour.
sudo pacman -Syu
Ou pas, puisque j’obtiens cette fois des erreurs de conflits de fichiers :
erreur : la validation de la transaction a échoué (conflit de fichiers) ttf-dejavu : /etc/fonts/conf.d/20-unhint-small-dejavu-sans-mono.conf est déjà présent dans le système de fichiers ttf-dejavu : /etc/fonts/conf.d/20-unhint-small-dejavu-sans.conf est déjà présent dans le système de fichiers ttf-dejavu : /etc/fonts/conf.d/20-unhint-small-dejavu-serif.conf est déjà présent dans le système de fichiers ttf-dejavu : /etc/fonts/conf.d/57-dejavu-sans-mono.conf est déjà présent dans le système de fichiers ttf-dejavu : /etc/fonts/conf.d/57-dejavu-sans.conf est déjà présent dans le système de fichiers ttf-dejavu : /etc/fonts/conf.d/57-dejavu-serif.conf est déjà présent dans le système de fichiers Des erreurs se sont produites, aucun paquet n’a été mis à jour.
Dans ce cas précis, la procédure à suivre consiste à vérifier pour chaque fichier, si celui-ci est utilisé par l’un des paquets du système.
$ sudo pacman -Qo /etc/fonts/conf.d/20-unhint-small-dejavu-sans-mono.conf erreur : aucun paquet ne contient /etc/fonts/conf.d/20-unhint-small-dejavu-sans-mono.conf
Une fois assuré que le fichier est inutilisé, on le renomme pour en conserver un exemplaire, au cas où. D’après la documentation, celui-ci sera nettoyer lors de la mise à jour.
$ sudo mv /etc/fonts/conf.d/20-unhint-small-dejavu-sans-mono.conf /etc/fonts/conf.d/20-unhint-small-dejavu-sans-mono.conf.save
Une fois ces opérations effectuées pour chacun des fichiers posant problème, on peux relancer à nouveau le processus de mise à jour.
sudo pacman -Syu
Cette fois, les paquets sont mis à jour correctement, tant mieux! En me basant sur ce que j’ai lu, il semble que l’erreur « paquet invalide ou corrompu » apparaisse dans différents cas de figure. Si l’erreur devait réapparaître, il n’est donc pas exclu de devoir trouver une autre solution pour la résoudre.
J’ai installé, il y a de cela plusieurs mois, un serveur miniDLNA sur l’une de mes machines équipée d’Arch Linux pour pouvoir partager facilement du contenu multimédia sur le réseau local. Jusqu’à présent, j’effectuais le transfert de fichier vers cette machine en branchant directement un disque dur sur la machine, en m’y connectant en SSH, en montant le disque puis en copiant les données à coup de commande cp. J’ai également effectué quelques transferts en montant un répertoire distant de la machine sur ma machine principale via sshfs. Ces deux solutions fonctionnent plutôt bien. Je me tourne aujourd’hui vers la mise en place d’un partage Samba, afin d’être en mesure de déposer facilement des fichiers depuis Windows également. Voici donc les quelques étapes nécessaires à la mise en place d’un répertoire accessible en lecture écriture sans restriction.
# Installation de Samba sudo pacman -S samba # Mise en place du fichier de configuration par défaut cp /etc/samba/smb.conf.default /etc/samba/smb.conf # Edition de la configuration sudo nano /etc/samba/smb.conf
Pour le partage d’un répertoire, j’ajoute les lignes suivantes dans le fichier configuration :
[Media] path = /vers/le/répertoire public = no writable = yes printable = no
Avec cette configuration, le répertoire est bien disponible en lecture écriture et visible sous Windows. Pour configurer plus précisément l’ensemble, il faudra regarder les autres options disponibles. Dans mon cas, cette configuration me permet de faire ce que j’espérais. Suite de l’installation :
# Démarrage des services sudo systemctl start smbd.service sudo systemctl start nmbd.service # Mise en place du service au démarrage sudo systemctl enable smbd.service sudo systemctl enable nmbd.service # Ajout du user système dans Samba # A vérifier si nécessaire sudo smbpasswd -a <user> # Vérifier la syntaxe de la configuration testparm -s
En cas de modification de la configuration, ne pas oublier de redémarrer le service :
sudo systemctl restart smbd.service
Informations issues de l’excellent wiki Arch Linux pour la page concernant Samba.