Windows: Универсальный перенос операционной системы на другое железо. – Trust Me I`m an Engineer

Windows: универсальный перенос операционной системы на другое железо. – trust me i`m an engineer

Небольшой мануальчик по переносу операционной системы Windows на новое железо. Подходит для большинства вариантов — замена материнки, замена всего железа кроме hdd, перенос клонированием 1в1 и тд. Целиком и полностью стырен с руборда

Часть 1

Подготовка операционной системы для переноса на другое железо.

В большинстве случаев достаточно выполнения трех первых пунктов.

  • Intel base &Non Intel base matherboard >> Intel base matherboard1
    Перенос операционной системы с одной материнки  с процессором Интел или  Не Интел на  другую материнку с процессором Интел.
    1. Установка драйвера (HAL) – “Компьютер с ACPI”  
      Если уже стоит такой драйвер, тогда пропускаем.
      Панель управления > Система > Оборудование > Диспетчер устройств > Компьютер > правой кнопкой по установленному драйверу HAL > Обновить драйвер  > Нет, не в этот раз > Установка из указанного места > Не выполнять поиск. Я сам выберу нужный драйвер > Компьютер с ACPI > Далее > Готово!  
    2. Установка драйвера – “Стандартный двухканальный контроллер PCI IDE”
      Если уже стоит такой драйвер, тогда пропускаем.
      Панель управления > Система > Оборудование > Диспетчер устройств > IDE ATA/ATAPI контроллеры > правой кнопкой по установленному IDE-контроллеру > Обновить драйвер  > Нет, не в этот раз > Установка из указанного места > Не выполнять поиск. Я сам выберу нужный драйвер > Стандартный двухканальный контроллер PCI IDE > Далее > Готово!
    3. Удалить в реестре ссылки на старые диски.
      Очистить раздел реестра HKEY_LOCAL_MACHINESYSTEMMountedDevices
  • Intel base matherboard >> Non Intel base matherboard2
    Если требуется выполнить перенос OS установленой на материнке с процессором Интел на новую материнку с процессором Не Интел.
    4. Удалить в реестре ссылки на драйвер процессора Интел.
    Пуск > Выполнить > Regedit > HKLM > SYSTEM > ControlSet001 > Services > удаляем раздел Intelppm
    Повторить для ControlSet002.
  • IDESATASCSIRAID >> SATASCSIRAID3
    Если  на новом железе имеется диск(и) с SATASCSI или на дисках организован RAID – SATASCSI.
    5. Установить нужные драйвера для этих устройств.
    Панель управления > Установка оборудования > Добавление нового устройства > Установка оборудования, выбранного из списка  
    в ручную > SCSI и RAID контроллеры > Установить с диска.4
    Внимание:установить перед переносом, т.е. установить нужные драйвера на старую систему на старом железе, а потом делать перенос.
  • Перенос системы с современного железа на устаревшее. 5
    Просто невероятный случай. Если вы переносите систему с новой материнки на старую мать не поддерживающую APIC (усовершенствованный контроллер прерываний). К слову, такие материнки не выпускаются с 1999-00 гг.
    6. Устанавливаем драйвер (HAL) – “Стандартный компьютер”
    Панель управления > Система > Оборудование > Диспетчер устройств > Компьютер > правой кнопкой по установленному
    драйверу HAL > Обновить драйвер  > Нет, не в этот раз > Установка из указанного места > Не выполнять поиск. Я сам
    выберу нужный драйвер > Стандартный компьютер > Далее > Соглашаемся на перезагрузку > Идём в BIOS > Отключаем APIC.

    Комментарии к Первой части
    1Трех первых пунктов достаточно.
    2И напротив, если перенос выполняется с Non Intel base matherboard >>  Intel base matherboard, то этот пункт выполнять не нужно.
    3Перенос системы на разноуровневые RAID  не возможен. может быть RAID5>IDE>RAID1?
    4Если список оборудования не появился, открыть .*inf, найти секцию [ControlFlags] , в этой секции найти ExcludeFromSelect=* ,  удалить в этой строке * (звездочку).
    5Наличие этого условия автоматически отменяет выполнение первого пункта инструкции
    ######################################################################################################

    Часть 2

    Подготовка железа для принятия клона.

  • old HDD >> new HDD
    Перенос системы со старого HDD на новый HDD.
    1. Произвести подготовку системы к переносу по инструкции Часть 1 пункт 3. Клонировать систему подходящей программой.
    Внимание:Если по каким-либо причинам вы не выполнили подготовку к переносу, то после переноса,
    ни в коем случае не загружайте OS с нового HDD, пока не отключите старый HDD.
  • old HDD & Zalivka >> new matherboard
    Разворачивание клона на новое железо
    2. Отключите любые сетевые контроллеры.
    3. Произвести подготовку системы к переносу по инструкции Часть 1 пункты 1-3(4). Клонировать систему подходящей программой.  
    Перед проведением процедуры клонирования отключите все HDD, кроме диска на который вы будите проводить клонирование.  
    Подключайте все остальные диски только после окончания процедуры клонирования.
    Внимание: Окончанием процедуры клонирования является успешная Загрузка OS с нового HDD.  
    До этого момента не подключайте других дисков.
    ######################################################################################################

    Часть 3

    * Это не окончательная редакция Третьей Части

    Универсальный образ или Zalivka.

    Употребление sysprep не нужно, не обсуждается и больше не упоминается. 1
     


    Комментарии к Третьей части
    1Sysprep в самом процессе подготовки к клонированию не участвует. Sysprep нужен для EULAOEM.
    2Больший размер не нужен для сохранения возможности разворачивать клон на небольшие разделы или диски. Но и меньший размер не желателен, по соображениям оптимального расположения таблицы MFT.
    3Очистка этих директорий нужна для сохранения вашей конфиденциальности (например вы админите на предприятии, или установщик в сервисном). Если вас конфиденциальность не беспокоит, тогда очистка данных директорий на ваше усмотрение.
    4При обращении на WindowsUpdate в логе пишется дата и версия Биос.  
    5Категорически не рекомендуется. Места много не сэкономите, но в будущем траблы будут. Проверено.
    ######################################################################################################

    Часть 4

    Решение проблем.

    Q. После клонирования не могу сменить HAL с “Стандартный компьютер” или “Компьютер с ACPI” на другой.
    A. Удалите в C:WINDOWSinfhal.pnf
    Q. Сгорела мать и т.п. , в результате подготовить систему к переносу не могу. На новом железе получаю ошибку 0х7b. Что делать?
    A. by Artyk
    Тут рег-файл устанавливающий драйвер “Стандартный двухканальный контроллер PCI IDE” .

Алгоритм упорядочения логических томов в среде ос windows, часть 2

Алгоритм упорядочения логических томов в среде ОС Windows, часть 2

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

Как алгоритм хранит данные.

В процессе выполнения четырех шагов алгоритма, создаются три коллекции, содержащие объекты представляющие Устройства хранения данных, DevicesCollection, создается самой первой, на шаге 1 и постоянно используется на всех последующих шагах для обращения к родительскому объекту. На шаге 2 создается StorageVolumesCollection, а на шаге 3, LogicalVolumesCollection. Все коллекции организованы по единому принципу: все хранимые объекты проиндексированы и для того, чтобы обратиться непосредственно к хранимому объекту, надо просто обратиться к XXXXXCollection[ index ], где XXXXX: { Devices, StorageVolumes, LogicalVolumes }, а индекс – любое целое число в диапазоне [0, XXXXXCollection.Count]. Свойство Count содержит количество объектов соответствующего типа в коллекции.

Строки описания устройств, хранимые в бинарном блобе Data, не содержат DeviceGUID не только для DVD-ROM, но и для Removables. Упомянутый бинарный блоб содержит детальные характеристики логического тома и адресуется Registry путем:
HKUSIDSoftwareMicrosoftWindowsCurrentVersionExplorerMountPoints2CPCVolumeGUID, где GUID это VolumeGUID, SID – Security Identifier текущего пользователя. В связи с этим коллекция DevicesCollection и LogicalVolumesCollection содержат “ключи прямого доступа” как в виде коротких 8-ми символьных DeviceGUID.F1, так и длинных, непредсказуемой длины для DVD-ROM и Removables. Ключи прямого доступа возвращают индекс объекта, соответствующего указанному ключу. Таким образом используя длинный ключ, PnPDeviceID для обращения к DevicesCollection, можно получить индекс родительского устройства. Это индекс немедленно присваивается в качестве значения свойства ParentIndex тому объекту типа StorageVolume или LogicalVolume, который надо разместить в собственной коллекции.

Описание первого шага алгоритма: создание DevicesCollection.

Источники информации:
1. Перечисления, создаваемые службами cdrom и partmgr. Трудяга partmgr мало того, что получает информацию от нескольких драйверов устройств и выполняет свою главную задачу – создание перечисления томов памяти, дополнительно создает еще и перечисление все устройств кроме тех, которые обслуживает служба cdrom. Понятно, что речь идет о считывании всех REG_SZ значений по путям:
HKLMSYSTEMCurrentControlSetServicescdrom и
HKLMSYSTEMCurrentControlSetServicespartmrg.

2. Извлечение детальной информации об устройствах на основу PnPDeviceID. Настал момент дополнить описание PnPDeviceID, представленное в первой части, еще и упоминанием о том, что PnPDeviceID обязательно содержит в качестве префикса к строке описания устройства, еще и префикс, указывающий интерфейс, согласно которому устройство подключено. Причем я не могу сказать уверенно, приписывает ли этот префикс Windows к тому описанию устройства, которое предоставляет производитель или сам производитель. В любом случае, PnPDeviceID предоставляет точную информацию о том, по какому пути следует считать детальные данные из
HKLMSYSTEMCurrentControlSetEnum. Продемонстрируем этот важнейший источник информации об устройствах, снимком экрана.

Windows: Универсальный перенос операционной системы на другое железо. - Trust Me I`m an Engineer

Рисунок 4

Помимо HKLMSYSTEMCurrentControlSetEnumPnPDeviceID, дополнительно используется еще два пути:
HKLMSYSTEMCurrentControlSetEnumPnPDeviceIDDevice ParametersPartmgr, содержащий значение важнейшего свойства DiskId, которое всюду ранее упоминалось в качестве DevGUID.
Еще раз напомним, что для устройств, обслуживаемых службой cdrom, DiskId не создается и поэтому алгоритм присваивает свойству DevID значение PnPDeviceID с символами “” замененными на символ “#”.

HKLMSYSTEMCurrentControlSetEnumPnPDeviceIDDevice ParametersStorport содержит InitialTimestamp, дату выпуска устройства производителем в формате REG_QWORD.

Дополнительными источниками информации исключительно для внутренних дисков, являются пути:

HKLMHARDWAREDESCRIPTIONSystemMultifunctionAdapterDiskControllerDiskPeripheral
HKLMHARDWAREDEVICEMAPScsiScsi Port 1Scsi Bus 0Target Id 0Logical Unit Id M.

По первому из путей считывается REG_SZ свойство Identifier, представляющее для Mbr-форматированных дисков подпись диска, а для Gpt-форматированных содержит нули, что и свидетельствует о том, что диск содержит Gpt-форматированные разделы. Это очень важная информация для алгоритма, но, к сожалению, эта информация доступна лишь для внутренних дисков.

После того, как объект, представляющий устройство хранения данных полностью наделен всеми свойствами, считанными из Registry и дополнительными свойствами, нужными алгоритму, объект наделяется важнейшим свойством OrderIndex, значение которого устанавливается равным DevicesCollection.Count. После этого объект помещается в коллекцию по индексу равному значению свойства коллекции Count и Count инкрементируется.

Дополнительно создаются ключи прямого доступа для всех Removables и DVD-ROM, а также инициализируются групповые свойства, реальные значения которых устанавливаются на втором и третьем шагах. Перечислим здесь эти свойства:

LVGroupStyle – стиль форматирования, возможные значения Mbr, Gpt.
NumberOfLV — количество логических томов, размещенных на разделах устройства.
LVGroup — список смещений логических томов
NumberOfSV — количество разделов, Storage#Volume, размещенных на устройстве
SVGroup — список смещений разделов

Описание второго шага алгоритма: создание StorageVolumesCollection

Источники информации:

1. Перечисление HKLMSYSTEMCurrentControlSetservicesvolsnapEnum
ОБЯЗАНО предоставлять упорядоченный список Storage#Volume, томов памяти. Однако случаются казусы даже в такой вылизанной системе, как Windows 8.1. Самое время продемонстрировать сохраненный фрагмент Registry, хранимый с именем файла BecameCrazy-volsnap.reg. Вот фрагмент из этого файла.

[HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesvolsnapEnum]«0»=«STORAGE\Volume\_??_SD#DISK&Generic&SA08G&0.4#6&447d92&0&9c053461#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}»
«Count»=dword:00000011
«NextInstance»=dword:00000011
«1»=«STORAGE\Volume\{714ce426-d2a2-11e4-824f-806e6f6e6963}#0000000000007E00»
«2»=«STORAGE\Volume\{714ce426-d2a2-11e4-824f-806e6f6e6963}#0000000016260000»

Обратите внимание на строку “0”, соответствующую SD-карте. Каким образом этой карте был присвоен такой индекс, можно объяснить тем, что видимо случился сбой при чтении второго раздела первого внутреннего диска, система обрабатывала сбой, выставляла бит Dirty для раздела и потому отчет partmgr о томе памяти на SD-карте опередил поступление отчетов о томах памяти на внутренних дисках. К чести системы должен уточнить, что случилось это лишь однажды, могу назвать даже точную дату – 01.07.2021.

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

Этот же принцип применяется и на шаге 3 при создании коллекции логических томов, и он гарантирует, что упорядочение будет правильным, если только не станет “дурить” еще и служба partmgr и смещения перестанут поступать в порядке возрастания. Именно это (нарушение порядка следования смещений) и случилось под Windows 10 RTM TH1, в которой, как уже было сказано, был изменен алгоритм упорядочения Volume GUID. Естественно, что в начале это вызвало у меня бурные эмоции и всякие недоброжелательные слова в адрес программистов от MS: не то, чтобы используемый алгоритм перестал работать, но уж очень резал глаз неупорядоченный список смещений для LVGroup. И лишь через пару часов я осознал, ЧЕМ было вызвано это изменение алгоритма, что оно принесло и с того момента лишь пою дифирамбы автору идеи нового алгоритма упорядочения.
2. HKLMSYSTEMCurrentControlSetEnumSTORAGEVolume_??_SD#DISK&Generic&SA08G&0.4#6&447d92&0&9c053461&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}

Содержит следующие свойства:
«Capabilities»=dword:000000b0
«ContainerID»=”{33b560f6-21b5-11e5-b2ff-806e6f6e6963}”
«HardwareID»=hex(7):530054004f0052004100470045005c0056006f006c0075006d00650000000000
«ClassGUID»=”{71a27cdd-812a-11d0-bec7-08002be2092f}”
«Service»=«volsnap»
«DeviceDesc»=”@volume.inf,%storage\volume.devicedesc%;Generic volume”
«Driver»=”{71a27cdd-812a-11d0-bec7-08002be2092f}\0000″
«Mfg»=”@volume.inf,%msft%;Microsoft”
«ConfigFlags»=dword:00000000

Большинство из этих свойств может быть заранее “вписано ручками”. Интерес представил лишь ContainerID, уникальное свойство, но лень было терять время на поиск применения этого GUID, скорее всего представляющего GUID драйвера. Так что не уверен, что вообще имеет смысл тратить драгоценные миллисекунды на считывание этих свойств. Гораздо важнее немедленно связать объект, представленный строкой описания тома памяти с родительским устройством. Поэтому еще до того, как считывается информация из HKLMSYSTEMCurrentControlSetEnumSTORAGEVolume, осуществляется разбор текстовой строки, описывающей том памяти с целью определить значения следующих свойств:

Type = { “Partition”, “Removable” },
Subtype = { “SD”, “Flash”, “Virtual” },
Offset, DevID

Последнее из свойств устанавливается равным полю F1 GUID, предшествующего смещению для Type=”Partition”. В противном случае отсекается префикс “STORAGEVolume” и суффикс “#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}” так что приведенная выше строка из файла с именем “crazy” для SD-карты превращается в:

_??_SD#DISK&Generic&SA08G&0.4#6&447d92&0&9c053461&0

Эта строка присваивается в качестве свойства DevID. Ну а далее вычисляется важнейшее свойство для любого из “детей”, определение родительского устройства:

obj.ParentIndex = DevicesCollection[ obj.DevID ]

Узнав индекс родительского устройства, можно для Removables узнать DevGUID родителя, точнее DevGUID алгоритму не нужен, а нужно лишь значение поля F1 от DevGUID. Это значение родитель хранит в качестве значения собственного свойства DCUniqueID. Зная родительский DCUniqueID, можно сформировать изначение собственного уникального идентификатора:

obj.SVUniqueID = DevicesCollection[ obj.ParentIndex ].DCUniqueID obj.Offset

Для томов памяти типа “Partition” используется реальное смещение, а для томов памяти, размещенных на Removables, смещение устанавливается равным “00000000”.
Теперь можно обновить свойства родительского объекта, описывающих SVGroup и количество томов памяти, размещенных на родительском устройстве. То есть инкрементировать счетчик DevicesCollection[ obj.parentIndex ].NumberOfSV и включить смещение текущего объекта в счетчик DevicesCollection[ obj.parentIndex ].SVGroup.

Совершенно аналогичные действия выполняются и на шаге три, применительно к логическим томам.

Теперь напомню, что мы находимся в цикле обработки строк, считанных из перечисления. Мы уже определили все необходимые свойства объекта класса StorageVolumesCollection, но памятуя о том, что нельзя доверять правильности перечисления, сохраним объект не в целевой коллекции, а в простенькой, временной. Но текущий объект вообще говоря является членом группы и потому по родительскому индексу во временной коллекции размещается не сам объект, а группа объектов, каждый из которых имеет того же родителя.

По завершению цикла считывания перечисления, мы имеем возможность создать правильно упорядоченную целевую коллекцию StorageVolemesCollection. Для этого мы выполним цикл по родительской коллекции, DevicesCollection и несколько коротеньких вложенных циклов по группам, имеющим одного и того же родителя. Внутри цикла мы осуществляем размещение объектов из временной коллекции в StorageVolumesCollection, используя в качестве индекса для размещения StorageVolumesCollection.Count и инкрементируя это свойство после размещения объекта. StorageVolumesCollection самая простая по принципам формирования, не нуждается в создании дополнительных ключей прямого доступа.

Описание третьего шага алгоритма: создание LogicalVolumesCollection

Источники информации:

Перечисление
HKUSIDSoftwareMicrosoftWindowsCurrentVersionExplorerMountPoints2CPCVolumeGUID

где GUID это VolumeGUID, SID – Security Identifier текущего пользователя, предоставляет список VolumeGUID, а контент бинарного блоба с именем Data, адресуемый указанным ключом, содержит детальные данные. Блоб Data имеет достаточно сложную структуру, содержащую как UTF-16 текстовые строки, так и двоичные данные. Кроме того, размер и смещения текстовых полей внутри этого блоба зависят от версии Windows, младше сборки 9600 или старше. В коде-прототипе разборку контента этого блоба осуществляет функция GetBlobs. Используемый алгоритм построен так, что отсутствует зависимость от версии Windows, не используются уже известные смещения текстовых полей. К уже сказанному выше при описании шага два, добавлю лишь то, что в данном случае устройства типа DVD-ROM не игнорируются, поскольку они содержат логический том.

На шаге три важнейшее значение имеет создание ключей прямого доступа вида:

для Mbr-форматированных: подпись диска смещение
для Mbr-форматированных: VolGUID.F1 смещение
для Gpt-форматированных: VolumeGUID.F1

Однако в тот момент, когда выполняется цикл обработки объектов для включения в коллекцию LogicalVolumesCollection, еще не известны подписи для USB-дисков и, кроме того, неизвестны СТИЛИ форматирования Mbr/Gpt как для разделов на VHD, так и на внешних дисках.

Поэтому стоит упомянуть специальный вид VolumeGUID, который появился первоначально в WMI классе MSFT_Volume в поле Path, где наряду с реальным VolumeGUID, присутствовал и фиктивный, имеющий формат {1036c1c4-0000-0000-007e-000000000000}. Затем в одной из сборок, может даже 9926, такой формат GUID появился и просуществовал во всех сборках от 9879 до 10166, а вот в 10240 – опять исчез в связи с изменением алгоритма генерации VolumeGUID.

Упоминаю указанный формат потому, что поле F1 этого GUID представляет собой подпись диска, а поля F4, F5 – смещение логического тома. Так что обнаружив в системе такой VolumeGUID, становилось возможным присвоить уникальные ключи прямого доступа к объектам LogicalVolumesCollection всем членам LVGroup. Еще одной из причин, по которой я упоминаю здесь приведенный формат VolumeGUID состоит в том, что не смотря на несомненную революционность идеи об упорядочении VolumeGUID в соответствии с порядком монтирования логических томов, впервые внедренную в сборке 10240, тем не менее алгоритм генерации самих GUID оказался неудачным в том смысле, что для Mbr-дисков, имеющих четыре раздела и соответственно четыре логических тома, два последних поступают в НЕПРАВИЛЬНОМ ПОРЯДКЕ: последний имеет МЕНЬШЕЕ смещение, чем предпоследний.

Столь серьезное обвинение надо доказывать фактами, поэтому ниже приведен контент блоба Data для предпоследнего “ребенка”, Offset = 000020789000000

Windows Registry Editor Version 5.00

[HKEY_USERSS-1-5-21-1478854878-1022661374-1075113013-1004SOFTWAREMicrosoftWindowsCurrentVersionExplorer
MountPoints2CPCVolume{714ce432-d2a2-11e4-824f-806e6f6e6963}]«Data»=hex:000000000df0adba0100000008000000000000800000
0000000000300000000000000000ff00e703ff000000160000
0026980b421f00000004000000000000000000000000000000
0000000000005c005c003f005c00530054004f005200410047 \?STORAG
004500230056006f006c0075006d00650023007b0037003100 E#Volume#{71
3400630065003400320036002d0064003200610032002d0031 4ce426-d2a2-1
003100650034002d0038003200340066002d00380030003600 1e4-824f-806
6500360066003600650036003900360033007d002300300030 f6e6963}#00
00300030003000300032003000370038003900300030003000 0000207890000
3000300023007b00350033006600350036003300300064002d 00#{5
0062003600620066002d0031003100640030002d0039003400
660032002d0030003000610030006300390031006500660062

А теперь контент блоба Data для последнего “ребенка”, Offset = 000000001620000

Windows Registry Editor Version 5.00

[HKEY_USERSS-1-5-21-1478854878-1022661374-1075113013-1004SOFTWAREMicrosoftWindowsCurrentVersionExplorer
MountPoints2CPCVolume{f0fd3322-2d89-11e5-82e0-806e6f6e6963}]«Data»=hex:000000000df0adba0100000008000000000000800000
0000000000300000000000000000ff00e703ff000000160000
00cd14ff0e1f00000004000000000000000000000000000000
0000000000005c005c003f005c00530054004f005200410047 \?STORAG
004500230056006f006c0075006d00650023007b0037003100 E#Volume#{71
3400630065003400320036002d0064003200610032002d0031 4ce426-d2a2-1
003100650034002d0038003200340066002d00380030003600 1e4-824a-806
6500360066003600650036003900360033007d002300300030 e6f6e963}#00
00300030003000300030003000310036003200360030003000 000000162600
3000300023007b00350033006600350036003300300064002d 00#{5
0062003600620066002d0031003100640030002d0039003400
660032002d0030003000610030006300390031006500660062
00380062007d00000000000000000000000000000000000000

И, наконец, снимок ветки Registry, содержащий приведенные выше VolumeGUIDs, чтобы доказать, что я не ошибся В ПОРЯДКЕ СЛЕДОВАНИЯ детей.

Windows: Универсальный перенос операционной системы на другое железо. - Trust Me I`m an Engineer

В заключение стоит отметить, что по окончании цикла по объектам, предназначенным для размещения в коллекции логических томов, у нас появляется возможность окончательно разобраться со стилями форматирования разделов на внешних дисках и на VHD. Для этого достаточно сравнить значения свойств NumberOfSV и NumberOfLV. Совпадение значений однозначно свидетельствует о том, что разделы на диске имеют стиль форматирования Mbr, а вот NumberOfLV < NumberOfSV однозначно свидетельствует о стиле форматирования Gpt, поскольку первый из Gpt-разделов, MSR, не может содержать логического тома.

Описание четвертого шага алгоритма: назначение букв логическим томам

Источник информации: HKLMSYSTEMMountedDevices

Даже начинающим пользователям Windows хорошо известен этот путь, хранящий, однако наряду с нужной информацией еще и очень много совершенно не нужной. Особенно это касается USB-флэшек, а также телефонов, большинство из которых сейчас оснащено micro-SD. Информация о всех таких устройствах очень быстро засоряет MountedDevices. Следует иметь в виду, что на каждое из таких устройств в MountedDevices заводится по две записи: одна, в которой в поле name имеет значение ??VolumeVolumeGUID и вторая, в которой поле name имеет значение формата DosDevicesQ:. Поле value для обоих записей имеет очень длинный 16-ричный текст, представляющий в UTF-16 уже хорошо знакомый нам PnPDeviceID, причем в формате с “” замененным на “#”. Такие ключи прямого доступа создавались в LogicalVolumesCollection и потому становится легко и просто отфильтровывать ненужные Removables.

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

Теперь о том, как по значениям поля value в записях MountedDevices различать логические тома, соответствующие Mbr-форматированным дискам и Gpt-форматированным. Предельно просто: если поле value имеет длину 24 символа, то оно представляет собой Signature, подпись родительского диска, 8 символов и смещение, 16 символов.

Вот только использовать в качестве ключа для доступа к LogicalVolumesCollection еще нельзя, предварительно надо инвертировать и поле Signature и поле Offset, поскольку по непонятной мне до сих пор причине, эти поля хранят инвертированную по порядку следования байтов информацию. Так что выполнив инвертирование, мы можем проверить наличие ключа прямого доступа в коллекции логических томов и, если нам повезет, то присвоить букву объекту из LogicalVolumesCollection.

Но если нам не повезло с записью MountedDevices из подмножества DosDevicesx:, то, возможно, нам повезет с ключом, составленным из VolumeGUID.F1 смещение из поля value. И вот если нам повезет с ключом VolumeGUID.F1 смещение, то нам нужно немедленно создать в коллекции логических томов дополнительные ключи прямого доступа, составленные из подписи диска смещение.

И наконец о логических томах на Gpt-форматированных дисках. Поле value для таких логических томов имеет длину 48 байт, из которых первые 16 содержат фиксированную информацию, представленную 8-ю utf-16 символами и 32 16-ричных символа в виде строки, представляющей QWORD, сформированный на основе информации из полей VolumeGUID. Вот алгоритм обратной конвертации:

String.prototype.ConvertQWORD = function()// converts 32-bytes heximal string
{
//…. x x y y z z t t t t t t
// 00 02 04 06 08 10 12 14 16 18 20 22 24 26 28 30
// 3ab0aea1c467eb4fb392a1a746d349a7 3a b0 ae a1 c4 67 eb 4f b3 92 a1 a7 46 d3 49 a7
var t = this.toLowerCase();
return t.substr( 06, 02 ) t.substr( 04, 02 ) t.substr( 02, 02 ) t.substr( 00, 02 )
t.substr( 10, 02 ) t.substr( 08, 02 ) // 4 xx
t.substr( 14, 02 ) t.substr( 12, 02 ) // 4 yy
t.substr( 16, 02 ) t.substr( 18, 02 ) // 4 zz
t.substr( 20, 12 ); // 12 }

В отличии от логических томов для Mbr-форматированных дисков, для каждого из томов на Gpt-форматированном диске в MountedDevices создается только одна запись. Причем тома Gpt-форматированных дисков, не имеющие буквы, в MountedDevices не представлены. Поэтому после вычисления VolumeGUID по описанному выше алгоритму, следует выделить поле F1 и использовать его в качестве ключа прямого доступа к коллекции логических томов.

Windows: Универсальный перенос операционной системы на другое железо. - Trust Me I`m an Engineer
Рисунок 5.

Рисунок 5 хорошо демонстрирует логику исполнения шага 4: сначала при обработке подмножества MountedDevices, содержащего VolumeGUID, создаются новые ключи прямого доступа на основе Signature Offset, а затем при обработке подмножества DosDevices, эти новые ключи позволяют “SetMountNameForMountPoint”.

На этом краткое описание алгоритма завершено. Вчера на Github была выложена обновленная версия англоязычного документа, EnumerateVolumes-LLD.docx, EnumerateVolumes-LLD.pdf. Местами эта версия документа более подробна чем русскоязычные версии документов. В частности, это касается исторических экскурсов, посвященных происхождению понятий Раздел и буква тома. Но все же лучшим документом несомненно является сам исходный текст и возрастание числа просмотров и полных закачек с Github не может не радовать, поскольку демонстрирует, что даже такая, узкоспециализированная тема находит своих читателей. Ведь не вызывает сомнения тот факт, что 99.5% JS-программистов используют этот язык для Web-программирования, а никак не для извлечения системной информации. Для этого принято использовать PShell или vbs.

При чтении комментариев не торопитесь использовать идиоматические выражения при чтении фрагментов, в которых одной единственной строке кода предшествуют 10 строк пояснительных комментариев: это означает, что выполняется некий очень важный для алгоритма код. Так же как полезны и разметочные теги в конце строк, обозначающие имя класса, которому принадлежит данный фрагмент. Поскольку три класса DevicesCollection, StorageVolumesCollection и LogicalVolumesCollection очень похожи как по логике выполнения, так и по составу кода, то такие теги позволяют легко ориентироваться в достаточно длинном тексте. Общие для всех классов методы и функции, естественно вынесены наверх, но вот к примеру, парсинг текстовых строк описания устройств разнится от класса к классу и присутствует на всех четырех шагах алгоритма.

Замечание по поводу состязательных результатов, приведенных в первой части

Надеюсь, что те, кто читал первую часть, вполне осознали, что состязания проводились по правилам формулы TopGear, а не по правилам Формулы 1 в условиях сильного траффика. В последнем случае исполняемый интерпретатором код изначально обречен на проигрыш, сколь эффективный алгоритм он бы не использован. И связано это с системными правилами выделения квантов времени каждому из параллельно исполняемых процессов согласно их приоритетам. Очевидно, что приоритет diskpart.exe всегда выше, чем у кода, исполняемого интерпретатором. Идеально было бы оценивать результаты соревнования не в календарных секундах и миллисекундах, а в количестве использованных квантов времени. Но такой возможности ОС Windows не предоставляет. Но, ВОЗМОЖНО, допустимо при запуске diskpart и EnumDevicesAndVolumes.wsf указать в командной строе ОДИНАКОВЫЕ приоритеты. Но вот как это сделать, я не знаю.

Об определении стиля форматирования на основе контента полей GUID

Ехидный читатель, заглянувший на Github в англоязычную версию документа, где в самом начале приведена классификация различных GUID, мог бы спросить: раз так просто беглым взглядом можно отличить Volume GUID для Gpt-форматированного диска от Volume GUID для Mbr-форматированного, то зачем так много слов и лишний цикл по установке стиля форматирования в конце шага 3? Ответ простой: да, на основе отсутствия отсутствия в поле Field 3 Volume GUID “11e4” или “11e5”, МОЖНО сделать такой вывод, но я не читал MS документацию и даже описание класса GUID все никак не удосужусь прочитать и потому не готов брать на себя смелость вкладывать к код БЕЗДОКАЗАТЕЛЬНЫЕ знания.

Об инструментально классе StdRegWrapperClass, используемом всеми классами и функциями для извлечения данных из Registry

Это сейчас я его так именую, “инструментальный”, а вот когда писал, то очень гордился, а вот код для извлечения данных из Registry, презрительно именовал TestCase. Но вот сейчас мне выгодней именовать его инструментальным по той простой причине, что я элементарно не успел включить в его состав Set, Delete методы и потому название инструментальный легко оправдывает это название — НЕ ТРЕБУЮТСЯ Set / Delete методы для решения описанной выше задачи. Но я собираюсь поддерживать этот класс и непременно включу в его состав все методы из StdRegProv. Надеюсь, что даже в течение августа.

Об ошибках и недоработках в алгоритме и коде

Есть ошибка в коде на шаге 4 в цикле обработки строк, считанных из MountedDevices: неожиданно в ходе отладки обнаружилось, что строка с VolumeGUID и, соответственно без буквы, считывается позже, чем обработаны все записи DosDevices. Не стал терять время, ошибка непонятно где прячется, вполне возможно, что в инструментальном классе. Потому лишь увеличил сложность алгоритма, разбрасывая считанные строки по двум массивам, первый из которых хранит лишь VolumeGUID строки, а второй лишь DosDevices строки. Затем в еще одном цикле длины N последовательно считываются и обрабатываются строки сначала из первого массива, а затем из второго. Непременно разберусь и исправлю.

В инструментальном классе метод интерпретации даты в формате REG_QWORD работает неправильно. Потратил на отладку несколько часов, но разобраться не смог. Был бы очень признателен, если бы кто-то прислал мне точно известную интерпретацию хоть одной из дат в Registry, хранимых в формате REG_QWORD. Эту “больное место”, очень хочется зафиксить.

Совершенно непонятно для меня, что же хранится в первых восьми байтах свойства Identifier, HKLMHARDWAREDESCRIPTIONSystemMultifunctionAdapterDiskControllerDiskPeripheral, «Identifier»=«9cb5ff90-00000000-A». Никаких собственных идей на это счет нет, поиски в Registry дают единственный результат. Если кто-то сможет подсказать, то буду очень признателен.

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

Комментированный список полезных ссылок по теме публикации

www.script-coding.com/WMI.html — отличная статья о WMI coding, отличный российский сайт, посвященный Scripting, содержит массу аналогичный статей.

Именно благодаря публикациям на этом сайте я стал использовать структурированный WSF-код вместо “простынь” на чистом JS. Замечательный сайт.

www.microsoft.com/en-us/download/details.aspx?id=12028 — загрузка лучшего в моем представлении “учебника” по WMI-методам, ScriptomaticV2.hta. MUST HAVE для программистов на JS, VBS, Perl с использованием WMI-методов. Выводит исходник кода для извлечения результатов работы выбранного из громаднейшего дерева WMI-классов на одном из выбранных языков.

Цикл из нескольких статей на портале www.forensicmag.com

www.forensicmag.com/articles/2021/12/windows-7-registry-forensics-part-2
www.forensicmag.com/articles/2021/02/windows-7-registry-forensics-part-3
www.forensicmag.com/articles/2021/06/retrieving-digital-evidence-methods-techniques-and-issues-part-3
www.forensicmag.com/articles/2021/04/windows-7-registry-forensics-part-4

В принципе интересный портал, потратил несколько часов, читая публикации на этом портале. Но сразу отмечу, что к моему счастью я слишком поздно его обнаружил, когда уже собственными “глазенками” успел разобраться в том, где именно в Registry хранятся перечисления актуальной информации, а где наличествуют “мусоросборки”, хранящие информацию о том, что хоть однажды побывало в системе. Так вот, автор приведенных выше публикаций вываливает на неподготовленного читателя такое количество путей в Registry, что потребуется очень много времени на то, чтобы разобраться в большинстве мусорных куч, адресуемых указанными ссылками.

winintro.ru/diskmgt.ru/html/ebd2bd6e-8b1e-43b6-a2e3-483def6ad763.htm — внятная статья о составных томах (Spanned Volumes) и динамических дисках.

xp-7.ru/blog/2021-01-13-101 — еще одна и тоже внятная, но увидел противоречия с первой.

www.webtropy.com/articles/art14-2.asp?Interop=WbemScripting — хороший Reference по WbemScripting для C# and VB.NET

Список был бы намного длиннее, если бы я включил в него все ссылки на общеизвестные, как я надеюсь, reference от Microsoft. Думаю, что в этом нет необходимости.

“Отходы производства”

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

2021.03.24 22:10:19 — 2021.03.31 15:45:14 Windows 8.1 Pro 9600
2021.03.31 16:26:15 — 2021.04.23 02:56:17 Windows 10 Pro Technical Preview 10049
2021.04.23 03:44:13 — 2021.04.29 06:36:13 Windows 10 Pro Technical Preview 10061
2021.04.29 07:25:43 — 2021.05.21 11:32:07 Windows 10 Pro Insider Preview 10074
2021.05.21 14:21:40 — 2021.05.28 21:13:37 Windows 10 Pro Insider Preview 10122
2021.05.28 22:04:16 — 2021.05.30 19:11:22 Windows 10 Pro Insider Preview 10125
2021.05.30 20:16:43 — 2021.07.01 11:17:37 Windows 10 Pro Insider Preview 10130
2021.07.01 12:11:53 — 2021.07.01 13:25:29 Windows 10 Pro Insider Preview 10158
2021.07.01 23:22:08 — 2021.07.03 22:25:40 Windows 10 Pro Insider Preview 10159
2021.07.03 23:21:16 — 2021.07.09 24:24:29 Windows 10 Pro Insider Preview 10162
2021.07.10 01:21:50 — Windows 10 Pro Insider Preview 10166

И в заключение ссылка на github:

github.com/sysprg-46/EnumerateDevicesAndVolumes/tree/master

Спасибо за терпение.

Встроенная защита и телеметрия

Теперь будем изменять локальные групповые политики, чтобы отключить OneDrive, встроенный антивирус и часть телеметрии. 

Нажимаем сочетание клавиш: Win R, открывается окно «Выполнить»:

в нем непосредственно уже пишем в строке «открыть» следующий запрос:

gpedit.msc 

У нас откроется Конфигурация компьютера. В этом разделе выбираем Административные шаблоны, практически в самом низу выбираем «Компоненты Windows», далее папку «Сборки для сбора данных и предварительные сборки» и отключаем телеметрию.

Windows: Универсальный перенос операционной системы на другое железо. - Trust Me I`m an EngineerВ меню Компоненты сборки выбираем OneDrive и отключаем его.Windows: Универсальный перенос операционной системы на другое железо. - Trust Me I`m an EngineerСледом тут же отключаем Защитника Windows. Советую воспользоваться посторонним антивирусом, а не в первоначальный встроенный.

Дальше находим в компонентах Windows – Антивирус программа. Выключаем параметр, выделенный на приведённом скриншоте ниже.

Один из последних моментов – в реестре нужно отключить телеметрию полностью, чтобы ваш ПК меньше собирал технической информации. Нажимаем уже привычные нам Win R. Пишем regedit. Откроется окно, где нам нужно будет перейти: 

нажимая каждый раз на значок стрелочки, и под конец кликаем уже на саму папку «DataCollection»:

Где меняем значение 1 на 0. После нажимаем ОК.

Самое последнее, что мы сделаем, так это проверим нет ли нашего голоса, записанного нашим же ПК. Для этого проследуем по пути:

C:WindowsTemp 

https://www.youtube.com/watch?v=subscribe_widget

Там можно обнаружить записанный голос в формате WAV. Если есть – можете смело удалять. Как показала практика, слежкой занималась не сама Windows, а фильтры, установленные в микрофон. Самый действующий вариант – отключение микрофона через панель задач.

:/>  Чем отличается windows 10 домашняя от windows 10 домашняя для одного языка

Оставьте комментарий

Adblock
detector