Clone parfait d’une puce RFID

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.

Préparation du système

Sous ArchLinux, il est nécessaire d’installer quelques paquets pour la gestion du NFC, à savoir :

  • libnfc : Platform independent Near Field Communication (NFC) library
  • mfoc : MiFare Classic Universal toolKit
sudo pacman -S libnfc mfoc

Vérifications

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-list

nfc-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.

Extraction du contenu de la puce source

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

Modification de l’UID de la puce cible

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

Première tentative de clonage de la puce

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.

Création du clone

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).

Conclusion

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.

[ArchLinux] Downgrade d’un package

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.

[ArchLinux] Paquet invalide ou corrompu : réparer Pacman

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.

[ArchLinux] Partage Samba

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.

[Xorg] no screens found

During my previous installation of Arch Linux, I encountered the « error no screens found » when trying to launch X graphic server. It took me a couple hours to understand that my motherboard had « embedded graphic functionality ». So in order to solve my problem, I had to deactivate Intel pilot from the motherboard in the BIOS, so that the system would use the graphic card instead. So an easy solution in my case, but it seems that this error can be obtained in a wide variety of case. If you’re reading this having a similar problem, I hope you’ll find a solution.

Useful command to see graphic cards detected by the system:

lspci | grep VGA