Как окна вычисляют уникальный идентификатор тома?

Насколько я понимаю, драйвер Windows (ftdisk) создает объект "HardDiskVolume" для каждого тома, который он находит в системе, и создает для него запись реестра:

HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices\
\??\Volume{GUID} = BINARY_DATA

С этого момента объем монтируется как \??\Volume{GUID}

BINARY_DATA используется для сопоставления этого диска с \DosDevices\<DISK_NAME> в том же куске реестра, что и диск имеет букву.

BINARY_DATA должен быть уникальным для тома и не должен изменяться, даже если я поместил этот диск в другой компьютер, не так ли?

Мой вопрос:

что здесь GUID? Это случайное число, генерируемое ftdisk каждый раз, когда загружаются окна?
Как Windows вычисляет BINARY_DATA?

Я прочитал lpVolumeSerialNumber, используя GetVolumeInformation. Он просто длинный и не похож на этот BINARY_DATA.

Я считаю, что BINARY_DATA - это функция из lpVolumeSerialNumber (которая генерируется ОС при форматировании тома) и что-то еще:

BINARY_DATA= F(VolumeSerialNumber, SOMETHING).

Что такое ЧТО-ТО?

Я читал MSDN и Руссинович/Соломон книги уже и до сих пор не могу понять.

О, я нашел.

В нем говорится: "Данные, хранящиеся в реестре в значениях для основных букв и томов дисковода томов, представляют собой подпись диска под Windows NT 4 и начальное смещение первого раздела, связанного с томом".

но что такое "подпись диска под Windows NT 4"?

Отсюда: http://www.microsoft.com/resources/documentation/windowsnt/4/server/reskit/en-us/resguide/diskover.mspx?mfr=true

Это "четырехбайтная подпись диска, которая находится в первом секторе каждого жесткого диска"

Итак, я использую инструмент HxD и нашел эти четыре байта из моего BINARY_DATA Я нашел его в строке 1B0 и столбцах с 08 по 0B.

Похоже, в интернете есть еще один человек, который знает об этом: http://www.pcreview.co.uk/forums/image-copy-drive-wont-boot-properly-t3761034.html))

Итак, если я изменю MBR на диске, он потеряет его письмо:)

Ответ 1

Вот (основная часть) ответа от Wikipedia:

"Серийный номер - это 32-разрядное число, определяемое датой и временем на часах реального времени на текущем компьютере во время форматирование".

Ответ 2

Это происходит несколько лет назад, когда я работал в компании, которая будет читать и писать на первые 62 сектора жестких дисков. Мы должны быть осторожны, чтобы не перезаписывать все 62 сектора или у нас были бы проблемы с активацией Windows. Обычно запасы хранятся там, однако это не очень секрет.

Конечно, в FAT - 62 секторах до того, как MBR "не используется" и может использоваться любой программой. Я скопировал текст с криминалистической страницы, приведенной ниже, и вы увидите, что ее вероятные уникальные идентификаторы хранятся в первых 62 секторах. Судебные аналитики могут использовать данные в реестре, чтобы определить, что вы удалили жесткий диск, а затем можете искать его. Я предполагаю, что идентификатор был написан там Windows по формату. Двоичные данные являются меткой времени и создаются по формату, и при всем этом это действительно убедительные доказательства того, что бинарные данные, надеюсь, не были закодированы в первых 62 разделах.

Собственно, правильно это я нашел! Этот WinHex - это бомба! вы хотите читать от 0 до (62 * 512) на одном из дисков PHYSICAL (не логично). Я не думаю, что у вас возникнут проблемы с изменением этого, кроме, возможно, активации howeber, который является старой проблемой, и я считаю, что они остановились, так как люди теперь часто обновляют свой SSD, когда они тают.

FROM http://www.forensicfocus.com/a-forensic-analysis-of-the-windows-registry

Судебный анализ реестра Windows

Деррик Дж. Фармер Шамплейн Колледж Берлингтон, Вермонт [email protected]

Установленные устройства

В реестре есть ключ, который позволяет просматривать каждый привод, связанный с системой. Ключом является HKLM\SYSTEM\MountedDevices и хранит базу данных смонтированных томов который используется файловой системой NTFS. Бинарные данные для каждого \ DosDevices\x: значение содержит информацию для идентификации каждого тома. Это показано на рисунке 7, где \DosDevice\F: монтируется том и указан как "Сменные носители хранения".

Рисунок 7 Идентификация объема \DosDevice\F:

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

СЕКТОРЫ 1-62 ЦИТАТЫ ОТ
http://www.beginningtoseethelight.org/fat16/index.htm секторы 1 - 62 ( >= 31,744 байт)

сектора 1 - 62 включительно обычно остаются пустыми. приложения, которые используйте его: мультизагрузочные загрузчики, такие как предварительная загрузка с помощью ranish менеджер. программ безопасности, таких как дискретная магнитная дискета. вирусы которые копируют себя в главную загрузочную запись, чтобы они могли загружать каждый раз, иногда переместите настоящий mbr в эту область, плюс больше вирусный код. программы полного шифрования диска и перенос дисков программное обеспечение для очень больших жестких дисков также может находиться здесь.

Ответ 3

Во-первых, GUID - это GUID. Это всего лишь случайная последовательность чисел, которая имеет очень низкий шанс иметь дублируемую запись. Я сомневаюсь, что он будет генерироваться каждый раз, когда Windows загрузится, хотя я признаю, что это возможно. Я никогда не замечал, что это меняется, так как я не вижу свой hdd GUID, который часто

Кроме того, вы откладываете lpVolumeSerialNumber? Если нет, вы, вероятно, получаете адрес памяти. Венгерское обозначение "lp" == "Длинный указатель на..." Серийный номер тома сам по себе выглядит как DWORD, 32-битное целое число