Как узнать и изменить UUID/GUID компьютера?

Каждый компьютер в сети должен иметь уникальный идентификатор UUID или GUID (в терминологии Microsoft). Он позволяет на базе этого ID аутентифицировать и активировать (при необходимости активации лицензий) компьютер.

Чтобы узнать GUID Windows компьютера, выполните команду Powershell на локальном компьютере:

get-wmiobject Win32_ComputerSystemProduct | Select-Object -ExpandProperty UUID

get-wmiobject Win32_ComputerSystemProduct -computername PC_NAME | Select-Object -ExpandProperty UUID

Это же значение содержится в реестре в ветке HKLM\SOFTWARE\Microsoft\Cryptography\MachineGuid.

Однако, если речь идет о виртуальных машинах, Vmware технически позволяет создать (или клонировать) машины, сохраняя идентичный UUID, что конечно плохо. UUID основан на пути к конфигурационному файлу VM и он генерируется, когда вы первый раз включаете машину или ресетите (сбрасываете до изначального состояния) её. Эта информация записывается в SMBIOS файл конфигурации виртуальной машины — *.vmx. Файл текстовый, его можно редактировать в текстовом редакторе.

Нужная вам строка будет выглядеть примерно так: uuid.bios = «00 11 22 33 44 55 66 77-88 99 aa bb cc dd ee ff»

Соответственно, вы можете поменять значение на уникальное. Все действия необходимо производить на выключенной виртуальной машине.

Альтернативно, вы можете изменить UUID группы виртуальных машин, если они расположены на ESXi, через PowerCLI, используя скрипт на Powershell.

Как генерируются UUID

Вы наверняка уже использовали в своих проектах UUID и полагали, что они уникальны. Давайте рассмотрим основные аспекты реализации и разберёмся, почему UUID практически уникальны, поскольку существует мизерная возможность возникновения одинаковых значений.

Современную реализацию UUID можно проследить до RFC 4122, в котором описано пять разных подходов к генерированию этих идентификаторов. Мы рассмотрим каждый из них и пройдёмся по реализации версии 1 и версии 4.

Теория

UUID (universally unique IDentifier) — это 128-битное число, которое в разработке ПО используется в качестве уникального идентификатора элементов. Его классическое текстовое представление является серией из 32 шестнадцатеричных символов, разделённых дефисами на пять групп по схеме 8-4-4-4-12.

Информация о реализации UUID встроена в эту, казалось бы, случайную последовательность символов:

Значения на позициях M и N определяют соответственно версию и вариант UUID.

Версия

Номер версии определяется четырьмя старшими битами на позиции М. На сегодняшний день существуют такие версии:

Вариант

Это поле определяет шаблон информации, встроенной в UUID. Интерпретация всех остальных битов в UUID зависит от значения варианта.

Мы определяем его по первым 1-3 старшим битам на позиции N.

Сегодня чаще всего используют вариант 1, при котором MSB0 равняется 1 , а MSB1 равняется 0 . Это означает, что с учётом подстановочных знаков — битов, отмеченных х — единственными возможными значениями будут 8 , 9 , A или B .

1 0 0 0 = 8
1 0 0 1 = 9
1 0 1 0 = A
1 0 1 1 = B

Так что если вы видите UUID с такими значениями на позиции N, то это идентификатор в варианте 1.

Версия 1 (время + уникальный или случайный идентификатор хоста)

В этом случае UUID генерируется так: к текущему времени добавляется какое-то идентифицирующее свойство устройства, которое генерирует UUID, чаще всего это MAC-адрес (также известный как ID узла).

Идентификатор получают с помощью конкатенации 48-битного МАС-адреса, 60-битной временной метки, 14-битной «уникализированной» тактовой последовательности, а также 6 битов, зарезервированных под версию и вариант UUID.

Тактовая последовательность — это просто значение, инкрементируемое при каждом изменении часов.

Временная метка, которая используется в этой версии, представляет собой количество 100-наносекундных интервалов с 15 октября 1582 года — даты возникновения григорианского календаря.

Возможно, вы знакомы с принятым в Unix-системах исчислением времени с начала эпохи. Это просто другая разновидность Нулевого дня. В сети есть сервисы, которые помогут вам преобразовать одно временное представление в другое, так что не будем на этом останавливаться.

Хотя эта реализация выглядит достаточно простой и надёжной, однако использование MAC-адреса машины, на которой генерируется идентификатор, не позволяет считать этот метод универсальным. Особенно, когда главным критерием является безопасность. Поэтому в некоторых реализациях вместо идентификатора узла используется 6 случайных байтов, взятых из криптографически защищённого генератора случайных чисел.

Сборка UUID версии 1 происходит так:

1. Берутся младшие 32 бита текущей временной метки UTC. Это будут первые 4 байта (8 шестнадцатеричных символов) UUID [ TimeLow ].
2. Берутся средние 16 битов текущей временной метки UTC. Это будут следующие 2 байта (4 шестнадцатеричных символа) [ TimeMid ].
3. Следующие 2 байта (4 шестнадцатеричных символа) конкатенируют 4 бита версии UUID с оставшимися 12 старшими битами текущей временной метки UTC (в которой всего 60 битов) [ TimeHighAndVersion ].
4. Следующие 1-3 бита определяют вариант версии UUID. Оставшиеся биты содержат тактовую последовательность, которая вносит небольшую долю случайности в эту реализацию. Это позволяет избежать коллизий, когда в одной системе работает несколько UUID-генераторов: либо системные часы переводятся назад для генератора, либо изменение времени замедляется [ ClockSequenceHiAndRes && ClockSequenceLow ].
5. Последние 6 байтов (12 шестнадцатеричных символов, 48 битов) — это «идентификатор узла», в роли которого обычно выступает MAC-адрес генерирующего устройства [ NodeID ].

UUID версии 1 генерируется с помощью конкатенации:

Поскольку эта реализация зависит от часов, нам нужно обрабатывать пограничные ситуации. Во-первых, для минимизации коррелирования между системами по умолчанию тактовая последовательность берётся как случайное число — так делается лишь один раз за весь жизненный цикл системы. Это даёт нам дополнительное преимущество: поддержку идентификаторов узлов, которые можно переносить между системами, поскольку начальное значение тактовой последовательности совершенно не зависит от идентификатора узла.

Помните, что главная цель использования тактовой последовательности — внести долю случайности в наше уравнение. Биты тактовой последовательности помогают расширить временную метку и учитывать ситуации, когда несколько UUID генерируются ещё до того, как изменяются процессорные часы. Так мы избегаем создания одинаковых идентификаторов, когда часы переводятся назад (устройство выключено) или меняется идентификатор узла. Если часы переведены назад, или могли быть переведены назад (например, пока система была отключена), и UUID-генератор не может убедиться, что идентификаторы сгенерированы с более поздними временными метками по сравнению с заданным значением часов, тогда нужно изменить тактовую последовательность. Если нам известно её предыдущее значение, его можно просто увеличить; в противном случае его нужно задать случайным образом или с помощью высококачественного ГПСЧ.

Версия 2 (безопасность распределённой вычислительной среды)

Главное отличие этой версии от предыдущей в том, что вместо «случайности» в виде младших битов тактовой последовательности здесь используется идентификатор, характерный для системы. Часто это просто идентификатор текущего пользователя. Версия 2 используется реже, она очень мало отличается от версии 1, так что идём дальше.

Версия 3 (имя + MD5-хэш)

Если нужны уникальные идентификаторы для информации, связанной с именами или наименованием, то для этого обычно используют UUID версии 3 или версии 5.

Они кодируют любые «именуемые» сущности (сайты, DNS, простой текст и т.д.) в UUID-значение. Самое важное — для одного и того же namespace или текста будет сгенерирован такой же UUID.

Обратите внимание, что namespace сам по себе является UUID.

В этой реализации UUID namespace преобразуется в строку байтов, конкатенированных с входным именем, затем хэшируется с помощью MD5, и получается 128 битов для UUID. Затем мы переписываем некоторые биты, чтобы точно воспроизвести информацию о версии и варианте, а остальное оставляем нетронутым.

Важно понимать, что ни namespace, ни входное имя не могут быть вычислены на основе UUID. Это необратимая операция. Единственное исключение — брутфорс, когда одно из значений (namespace или текст) уже известно атакующему.

При одних и тех же входных данных генерируемые UUID версий 3 и 5 будут детерминированными.

Версия 4 (ГПСЧ)

Самая простая реализация.

6 битов зарезервированы под версию и вариант, остаётся ещё 122 бита. В этой версии просто генерируется 128 случайных битов, а потом 6 из них заменяется данными о версии и варианте.

Такие UUID полностью зависят от качества ГПСЧ (генератора псевдослучайных чисел). Если его алгоритм слишком прост, или ему не хватает начальных значений, то вероятность повторения идентификаторов возрастает.

В современных языках чаще всего используются UUID версии 4.

Её реализация достаточно простая:

1. Генерируем 128 случайных битов.
2. Переписываем некоторые биты корректной информацией о версии и варианте:

1. Берём седьмой бит и выполняем c 0x0F операцию AND для очистки старшего полубайта. А затем выполняем с 0x40 операцию OR для назначения номера версии 4.
2. Затем берём девятый байт, выполняем c 0x3F операцию AND и с 0x80 операцию OR.

Преобразуем 128 битов в шестнадцатеричный вид и вставляем дефисы.

Версия 5 (имя + SHA-1-хэш)

Единственное отличие от версии 3 в том, что мы используем алгоритм хэширования SHA-1 вместо MD5. Эта версия предпочтительнее третьей (SHA-1 > MD5).

Практика

Одним из важных достоинств UUID является то, что их уникальность не зависит от центрального авторизующего органа или от координации между разными системами. Кто угодно может создать UUID с определённой уверенностью в том, что в обозримом будущем это значение больше никем не будет сгенерировано.

Это позволяет комбинировать в одной БД идентификаторы, созданные разными участниками, или перемещать идентификаторы между базами с ничтожной вероятностью коллизии.

UUID можно использовать в качестве первичных ключей в базах данных, в качестве уникальных имён загружаемых файлов, уникальных имён любых веб-источников. Для их генерирования вам не нужен центральный авторизующий орган. Но это обоюдоострое решение. Из-за отсутствия контролёра невозможно отслеживать сгенерированные UUID.

Есть и ещё несколько недостатков, которые нужно устранить. Неотъемлемая случайность повышает защищённость, однако она усложняет отладку. Кроме того, UUID может быть избыточным в некоторых ситуациях. Скажем, не имеет смысла использовать 128 битов для уникальной идентификации данных, общий размер которых меньше 128 битов.

Уникальность

Может показаться, что если у вас будет достаточно времени, то вы сможете повторить какое-то значение. Особенно в случае с версией 4. Но в реальности это не так. Если бы вы генерировали один миллиард UUID в секунду в течение 100 лет, то вероятность повторения одного из значений была бы около 50 %. Это с учётом того, что ГПСЧ обеспечивает достаточное количество энтропии (истинная случайность), иначе вероятность появления дубля будет выше. Более наглядный пример: если бы вы сгенерировали 10 триллионов UUID, то вероятность появления двух одинаковых значений равна 0,00000006 %.

А в случае с версией 1 часы обнулятся только в 3603 году. Так что если вы не планируете поддерживать работу своего сервиса ещё 1583 года, то вы в безопасности.

Впрочем, вероятность появления дубля остаётся, и в некоторых системах стараются это учитывать. Но в подавляющем большинстве случаев UUID можно считать полностью уникальными. Если вам нужно больше доказательств, вот простая визуализация вероятности коллизии на практике.

Get BIOS UUID from C or Delphi from Win32

VMWare configuration files contains a line like

And afaik most (every?) physical BIOS has such an UUID. Is there any Windows API call to get this identifier?

I’ve tried the WMI class Win32_ComputerSystemProduct.UUID property but the value is different from the uuid.bios value. The value of HKEY_LOCAL_MACHINE\Software\Microsoft\Cryptography\MachineGuid is different, too.

1 Answer 1

That value is called Universal Unique ID number and is part of the SMBIOS tables, if you use the SerialNumber property of the Win32_BIOS WMI class youu will get the same id of the uuid.bios (from the vmx file) entry plus the prefix VMware- (example : VMware-56 4d af ac d8 bd 4d 2c-06 df ca af 89 71 44 93 )

If you want return the same uuid without the VMware- prefix you must read the SMBIOS tables directly (check the System Information table type 1 and the UUID field), try this article Reading the SMBios Tables using Delphi whcih include has a sample code to list this value.

UUID Format

A UUID is an identifier that is designed to be unique across both time and space. It requires no central registration process. The UUID is 128 bits long. Its format is described in RFC 4122, but the actual field contents are opaque and not significant to the SMBIOS specification, which is only concerned with the byte order. Table 10 shows the field names; these field names, particularly for multiplexed fields, follow historical practice.

Although RFC 4122 recommends network byte order for all fields, the PC industry (including the ACPI, UEFI, and Microsoft specifications) has consistently used little-endian byte encoding for the first three fields: time_low, time_mid, time_hi_and_version. The same encoding, also known as wire format, should also be used for the SMBIOS representation of the UUID.

The UUID <00112233-4455-6677-8899-aabbccddeeff>would thus be represented as: 33 22 11 00 55 44 77 66 88 99 AA BB CC DD EE FF.

If the value is all FFh, the ID is not currently present in the system, but it can be set. If the value is all 00h, the ID is not present in the system.

Get a unique computer ID in Python on windows and linux

I’d like to get an id unique to a computer with Python on Windows and Linux. It could be the CPU ID, the motherboard serial, . or anything else.

I looked at several modules (pycpuid, psi, . ) without luck.

Any idea on how to do that?

11 Answers 11

How about using the MAC address as unique id?

The discussion here Obtain MAC Address from Devices using Python shows how to obtain the MAC address

There seems to be no direct «python» way of doing this. On modern PC hardware, there usually is an UUID stored in the BIOS — on Linux there is a command line utility dmidecode that can read this; example from my desktop:

The problem with MAC addresses is that usually you can easily change them programmatically (at least if you run the OS in a VM)

On Windows, you can use this C API

for Windows you need DmiDecode for Windows (link) :

for Linux (non root):

For python3.6 and windows must be used decode

Funny! But uuid.getnode return the same value as dmidecode.exe.

Or if you don’t want to use subprocess, (It’s slow) use ctypes. This is for Linux non root.

You can use this like:

Invoke one of these in the shell or through a pipe in Python to get the hardware serial number of Apple machines running OS X >= 10.5:

/usr/sbin/system_profiler SPHardwareDataType | fgrep ‘Serial’ | awk ‘‘

ioreg -l | awk ‘/IOPlatformSerialNumber/ < print $4 >‘ | sed s/\»//g

BTW: MAC addresses are not a good idea: there can be >1 network cards in a machine, and MAC addresses can be spoofed.

I don’t think there is a reliable, cross platform, way to do this. I know of one network device that changes its MAC address as a form of hardware error reporting, and there are a million other ways this could fail.

The only reliable solution is for your application to assign a unique key to each machine. Yes it can be spoofed, but you don’t have to worry about it completely breaking. If you are worried about spoofing you can apply some sort of heuristic (like a change in mac address) to try and determine if the key has been moved.

UPDATE: You can use bacterial fingerprinting.

This should work on windows:

I found something else that I’m using. Mac address for linux, MachineGuid for windows and there is also something for mac.

2019 Answer (for Windows):

Uses Windows API to get the computer’s permanent UUID, then processes the string to ensure it’s a valid UUID, and lastly returns a Python object (https://docs.python.org/3/library/uuid.html) which gives you convenient ways to use the data (such as 128-bit integer, hex string, etc).

PS: The subprocess call could probably be replaced with ctypes directly calling Windows kernel/DLLs for the Win32_ComputerSystemProduct API (which is what wmic uses internally). But then you have to be very careful and ensure that you call it properly on all systems. For my purposes this wmic -based function is safer and is all I need. It does strong validation and produces correct results. And if the wmic output is wrong or if the command is missing, our function returns None to let you handle that any way you want (such as generating a random UUID and saving it in your app’s config file instead).