Tout d'abord, veuillez noter que le CPUID n'est certainement pas un marqueur d'identification unique communément accessible pour un système ultérieur à un Intel Pentium III. Bien que le hacher avec des adresses MAC puisse certainement conduire à des marqueurs uniques, cela n'est dû qu'aux qualités uniques des MAC eux-mêmes et le CPUID dans ce cas n'est rien de plus que circonstanciel. De plus, le hachage résultant n'est probablement pas plus unique que l'UUID de la carte mère, ce qui est beaucoup plus facile à récupérer et le processus est beaucoup moins sujet à l'erreur. De wikipedia.org/wiki/cpuid :
EAX = 3 : numéro de série du processeur
Voir aussi: Pentium III § Controverse sur les problèmes de confidentialité
Cela renvoie le numéro de série du processeur. Le numéro de série du processeur a été introduit sur Intel Pentium III, mais en raison de problèmes de confidentialité, cette fonctionnalité n'est plus implémentée sur les modèles ultérieurs (le bit de fonctionnalité PSN est toujours effacé). Les processeurs Efficeon et Crusoe de Transmeta offrent également cette fonctionnalité. Cependant, les processeurs AMD n'implémentent cette fonctionnalité dans aucun modèle de processeur.
Vous pouvez afficher vous-même un processeur analysé en faisant cat /proc/cpuinfo
ou même simplement lscpu
.
Cela vous donne toutes les adresses MAC pour les interfaces réseau reconnues par le noyau linux, je pense:
ip a | sed '\|^ *link[^ ]* |!d;s|||;s| .*||'
Il peut être nécessaire de filtrer cette liste si elle peut inclure des cartes réseau virtuelles avec des MAC générés de manière aléatoire. Vous pouvez le faire avec des indicateurs dans l'appel à ip
directement. Voir ip a help
pour savoir comment procéder.
Notez également que ce problème n'est pas propre à ip
et doit également être traité si vous utilisez ifconfig
, mais qu'il peut être traité de manière plus fiable ip
- qui fait partie de la iproute2
suite réseau et est activement géré - qu'il ne peut le faire ifconfig
- qui est membre du net-tools
package et a vu une version Linux pour la dernière fois en 2001 . En raison de l'évolution des fonctionnalités du noyau depuis sa dernière version, il ifconfig
est connu de mal déclarer certains indicateurs de fonctionnalité de réseau et son utilisation doit être évitée si possible.
Comprenez, cependant, que le filtrage avec des noms d'interface du noyau comme eth[0-9]
n'est pas un moyen fiable de le faire, car ceux-ci peuvent changer en fonction de leur ordre de détection en parallèle udev
pendant le processus de démarrage. Veuillez consulter les noms de réseau prévisibles pour en savoir plus.
Parce qu'il dmidecode
n'est pas installé sur mon système, j'ai d'abord pensé à hacher une liste de publications en série sur le disque dur générées comme:
lsblk -nro SERIAL
Faites lsblk --help
quelques indices pour affiner cette liste - par type de disque, par exemple. Considérez également lspci
et / ou lsusb
peut - être.
Les combiner est facile:
{ ip a | sed ... ; lsblk ... ; } | #abbreviated... for brevity...
tr -dc '[:alnum:]' | #deletes all chars not alphanumeric - including newlines
sha256sum #gets your hash
Comme vous m'avez informé que vous saisissez les ressources des utilisateurs de votre côté à leurs identifiants uniques, et que les disques durs ne peuvent pas être invoqués pour exister, j'ai pensé à changer de tactique.
Cela considéré, j'ai de nouveau examiné le système de fichiers et trouvé le /sys/class/dmi/id
dossier. J'ai vérifié quelques fichiers:
cat ./board_serial ./product_serial
###OUTPUT###
To be filled by O.E.M.
To be filled by O.E.M.
Cependant, celui-ci semble être assez bon, mais je ne publierai pas la sortie:
sudo cat /sys/class/dmi/id/product_uuid
Je m'attends à ce que ce soit là où dmidecode
obtient la plupart de ses informations de toute façon et en fait, cela lui ressemble . Selon man dmidecode
vous, vous pouvez également simplifier considérablement votre utilisation de cet outil en spécifiant l'argument:
dmidecode -s system-uuid
Plus simple encore, cependant, vous pouvez simplement lire le fichier. Notez que ce fichier particulier identifie spécifiquement une carte mère. Voici un extrait du correctif du noyau 2007 qui implémentait à l'origine ces exportations vers le /sysfs
système de fichiers virtuel:
+DEFINE_DMI_ATTR_WITH_SHOW(bios_vendor, 0444, DMI_BIOS_VENDOR);
+DEFINE_DMI_ATTR_WITH_SHOW(bios_version, 0444, DMI_BIOS_VERSION);
+DEFINE_DMI_ATTR_WITH_SHOW(bios_date, 0444, DMI_BIOS_DATE);
+DEFINE_DMI_ATTR_WITH_SHOW(sys_vendor, 0444, DMI_SYS_VENDOR);
+DEFINE_DMI_ATTR_WITH_SHOW(product_name, 0444, DMI_PRODUCT_NAME);
+DEFINE_DMI_ATTR_WITH_SHOW(product_version, 0444, DMI_PRODUCT_VERSION);
+DEFINE_DMI_ATTR_WITH_SHOW(product_serial, 0400, DMI_PRODUCT_SERIAL);
+DEFINE_DMI_ATTR_WITH_SHOW(product_uuid, 0400, DMI_PRODUCT_UUID);
+DEFINE_DMI_ATTR_WITH_SHOW(board_vendor, 0444, DMI_BOARD_VENDOR);
+DEFINE_DMI_ATTR_WITH_SHOW(board_name, 0444, DMI_BOARD_NAME);
+DEFINE_DMI_ATTR_WITH_SHOW(board_version, 0444, DMI_BOARD_VERSION);
+DEFINE_DMI_ATTR_WITH_SHOW(board_serial, 0400, DMI_BOARD_SERIAL);
+DEFINE_DMI_ATTR_WITH_SHOW(board_asset_tag, 0444, DMI_BOARD_ASSET_TAG);
+DEFINE_DMI_ATTR_WITH_SHOW(chassis_vendor, 0444, DMI_CHASSIS_VENDOR);
+DEFINE_DMI_ATTR_WITH_SHOW(chassis_type, 0444, DMI_CHASSIS_TYPE);
+DEFINE_DMI_ATTR_WITH_SHOW(chassis_version, 0444, DMI_CHASSIS_VERSION);
+DEFINE_DMI_ATTR_WITH_SHOW(chassis_serial, 0400, DMI_CHASSIS_SERIAL);
+DEFINE_DMI_ATTR_WITH_SHOW(chassis_asset_tag, 0444, DMI_CHASSIS_ASSET_TAG);
Vous pourrez peut-être utiliser ces données seules pour identifier le système - si la carte mère est suffisante. Mais vous pouvez combiner ces informations avec les MAC du système de la même manière que j'ai démontré que vous pourriez faire avec les disques durs:
sudo sh <<\CMD | tr -dc '[:alnum:]' | sha256sum
ip a | sed '\|^ *link[^ ]* |!d;s|||;s| .*||'
cat /sys/class/dmi/id/product_uuid
CMD
Le noyau Linux peut également générer des UUID pour vous:
cat /proc/sys/kernel/random/uuid #new random uuid each time file is read
Ou:
cat /proc/sys/kernel/random/boot_id #randomly generated per boot
Certes, il est généré de manière aléatoire et vous devrez repenser l'attribution des ID, mais c'est à peu près aussi simple que possible d' obtenir au moins. Et cela devrait être assez solide si vous pouvez trouver un moyen de le saisir.
Enfin, sur les systèmes UEFI, cela devient beaucoup plus facile à faire, car chaque variable d'environnement du micrologiciel EFI comprend son propre UUID. La variable d'environnement {Platform,}LangCodes-${UUID}
doit être présente sur chaque système UEFI, doit persister les redémarrages et même la plupart des mises à niveau et modifications du micrologiciel, et tout système Linux avec le efivarfs
module chargé peut répertorier l'un ou les deux noms aussi simplement que:
printf '%s\n' /sys/firmware/efi/efivars/*LangCodes-*
L'ancienne forme - LangCodes-${UUID}
est apparemment désormais obsolète , et sur les systèmes plus récents, PlatformLangCodes-${UUID}
mais, selon les spécifications, l'un ou l'autre devrait être présent dans chaque système UEFI. Avec peu d'effort, vous pouvez définir vos propres variables persistantes de redémarrage, et peut-être utiliser davantage le générateur UUID du noyau de cette façon. Si vous êtes intéressé, consultez efitools .