IDE_DEVICE_PARAMETERS structure (irb.h)
The IDE_DEVICE_PARAMETERS structure contains configuration information that the port driver provides to the miniport driver to configure a device.
Syntax
Members
Indicates the size of the Device parameters structure. The miniport driver should verify that sizeof(IDE_DEVICE_PARAMETERS) is less than or equal to the Version field.
Indicates the type of the device. The allowed device types are DeviceIsAta for ATA devices, DeviceIsAtapi for ATAPI devices, and DeviceNotExist if no device was found at that address. The other fields in this structure are not valid if the IdeDeviceType is set to DeviceNotExist.
Specifies the target ID of the device.
The miniport driver must update this field to indicate the maximum logical unit number supported by this device. By default, the member is set to 0 indicating the existence of just one LUN.
The miniport driver must update this field to specify the number of overlapped requests it can handle for this device. By default, the member is set to 1.
Specifies the number of sectors in a block of data to be transferred. This value applies to the data blocks used in ATA block transfer commands such as Read Multiple (0xC4), Write Multiple (0xC5). For more information about the ReadMultiple and WriteMultiple commands, see the ATA Specification.
Specifies the device characteristics. The table below lists the characteristics that could be set in this member. The high byte of this member is opaque and shall not be changed by the ATA miniport.
| Device Characteristic | Description |
|---|---|
| DFLAGS_REMOVABLE_MEDIA | Indicates that the drive has removable media |
| DFLAGS_ REMOVABLE_DEVICE | Indicates that the device can be safely unplugged |
| DFLAGS_FUA_SUPPORT | Indicates that the device supports FUA (Force Unit Access) |
| DFLAGS_INT_DRQ | Indicates that the device interrupts as DRQ is set after receiving ATAPI Packet command |
| DFLAGS_MSN_SUPPORT | Indicates that the device supports Media Status Notification. |
Contains an enumeration value of type ATA_ADDRESS_TRANSLATION that specifies the sort of address translation used during data transfers.
Specifies the maximum user-addressable logical block address (LBA). This member is defined when AddressTranslation is equal to either LbaMode or Lba48BitMode.
Specifies the drive geometry with the values for the number of cylinders, heads per cylinder, and the sectors per track. This member is defined when AddressTranslation is equal to ChsMode.
This member specifies the number of bytes per logical sector (LBA) for the given device.
This member specifies the number of bytes per physical sector (that is, the smallest amount of data that the device can physically write internally) for the given device.
This member specifies the location of sector 0 within the first physical sector as defined in the ATA specification represented in bytes.
Contains a bitmap that indicates the supported transfer modes.
Indicates the selected transfer modes on the device. The miniport driver must set this member.
Remarks
The port driver passes a IDE_DEVICE_PARAMETERS structure to the miniport driver when it calls IdeHwInitialize.
История использования USB
Ни для кого уже не секрет, что информация о разного рода активности многочисленных компонентов операционной системы попадает в реестр и файлы в виде записей заданного формата. При этом, информация эта нередко содержит чувствительные пользовательские данные: историю посещенных браузером страниц, кеш данных программ, информацию о подключаемых устройствах и многое многое другое. Во основном журналирование обеспечивается функциональными особенностями пользовательских программ, которые имеют встроенные алгоритмы сохранения истории операций, отчасти это возможно благодаря архитектурным особенностям ядра/HAL операционной системы, которые, производя конфигурирационные действия с устройствами, сохраняют информацию о последних в виде записей в системном реестре. Из всего многообразия подобной информации, в рамках данной статьи нас будет интересовать исключительно история использования USB устройств.
Система создает артефакты в момент обнаружения (инициализации) устройства (сменных накопителей, модемов, гаджетов, камер, медиаплееров и прч.) на шине компьютера. Дополнительным плюсом данного материала будет возможность сбора доказательной базы по факту неправомерного использования рабочей станции пользователя в корпоративной среде при помощи незадекларированных USB-устройств.
Не так давно в нашу жизнь вошел интерфейс USB, привнеся в неё довольно существенные изменения. Неожиданно многие вещи стали проще, отпала необходимость инсталляции устройства во внутренний интерфейсный разъем (шина), или внешний интерфейс, требующий перезагрузки станции для корректной инициализации устройства, да и сам процесс конфигурирования устройств стал, во множестве случаев, тривиальнее. На интерфейсе USB появились тысячи разнообразных по назначению устройств, которые достаточно было подключить к разъему на панели корпуса, после чего от момента подключения до состояния «готов к работе», порой проходили считанные минуты. Наряду с очевидными достоинствами: легкостью конфигурирования/использования, компактностью, функциональностью, подобные устройства сразу стали источником проблем как для безопасности персональных данных самого пользователя, так и безопасности корпоративных сред. Компактный, легко маскируемый «брелок» с интерфейсом USB может запросто явиться той ахиллесовой пятой, которая станет причиной «падения» гиганта корпоративной безопасности. Если порты USB в корпоративных рабочих станциях находятся без надлежащего контроля со стороны политик безопасности, то любое приспособление может запросто выступить в качестве средства для обхода периметра безопасности компании. И тут уж насколько хватит фантазии «взломщика», например, достаточно пронести на флешке свежий, не определяемый антивирусами вредоносный код и выполнить его (умышленно или нет), и вот вам уже прецедент, поскольку даже без локальных административных привилегий учетной записи пользователя сохраняется пространство для маневра. Не меньшую опасность представляют и USB-модемы, которые, в случае установки (а при использовании локальных/доменных политик по умолчанию это достигается достаточно просто), могут выступить в роли неконтролируемого канала передачи данных, по которому может осуществляться передача чувствительной корпоративной информации за пределы защищенного внутреннего периметра. При этом, даже декларируемые (заявленные/согласованные) пользовательские устройства (например, телефоны) могут содержать в своих микропрограммах или операционных системах уязвимости, которые, в случае эксплуатации, наносят вред не только владельцу, но и могут выступать в роли средства несанкционированного доступа к служебным данным. Поэтому, в случае возникновения инцидента информационной безопасности, связанного с эксплуатацией USB-устройств,
В связи со всем перечисленным, достаточно важно не только уметь ограничивать использование устройств, но и иметь доступ к истории USB подключений в системе. Этому вопросу и будет посвящена данная статья. Сразу оговорюсь, что весь список точек создания информации о подключении тех или иных устройство чрезвычайно обширен, поэтому по теме данной статьи мы будем рассматривать лишь историю использования USB устройств.
Перечисление (энумерация) USB устройств
Поскольку я сам в данном вопросе «плаваю», перед тем как перейти к практике, предлагаю немного усилить нашу теоретическую базу и описать терминологию, которая будет использоваться на протяжении всего материала. Сразу оговорюсь, что мы не будем освещать все виды взаимодействия, выполняющиеся на шине USB на аппаратном уровне, а сосредоточимся исключительно на основных понятиях, относящихся к USB-устройствам и требующихся нам для понимания практической стороны вопроса.
Подключение любого нового оборудования сопряжено с выполнением модулями ядра системы Windows предопределенных фаз опроса и инициализации. Начинается всё с того, что при подключении устройства к разъему USB, контроллером USB (встроенным в чипсет на материнской плате) генерируется аппаратное прерывание. Драйвер USB, ответственный за обработку данного прерывания, запрашивает статус порта, и если статус указывает на подключенное устройство, то ответственными подсистемами ядра производится последовательность действий, которую условно можно разделить на две стадии:
Отсюда следует вывод, что любое USB-устройство должно уметь реагировать на запросы от хоста и иные события на шине. В ответ на подобного рода запросы, микрокод устройства возвращает из ПЗУ требуемую информацию. Данные, возвращаемые устройством в ответ на запросы разнообразных дескрипторов, являются важными для операционной системы, поскольку именно часть этих данных представляет собой различного рода идентификаторы, используемые системой в дальнейшем в процессе нумерования устройства. Давайте приведем наиболее значимую информацию:
| Название поля | Терминология Windows | Размер (байт) | Комментарий |
|---|---|---|---|
| idVendor | VID | 2 | Идентификатор производителя устройства. При присвоении идентификатора производителя, соответствующее числовое значение вносится в реестр производителей. |
| idProduct | PID | 2 | Идентификатор продукта. Назначается производителем устройства. Product ID используется для дифференциации продуктов в рамках одного производителя. |
| bcdDevice | REV | 2 | Идентификатор ревизии. Используется для дифференциации разных аппаратных модификаций в рамках одной модели устройства. Может использоваться при выпуске новой версии платы/контроллера/логики. |
| bDeviceClass, bFunctionClass, bInterfaceClass | Class | 1 | Класс устройства. Используется для задания класса схожих устройств с общим набором идентичных свойств. |
| bDeviceSubclass, bFunctionSubClass, bInterfaceSubclass | SubClass (SUB) | 1 | Подкласс устройства. Используется для задания подкласса схожих устройств в рамках класса. |
| bDeviceProtocol, bFunctionProtocol, bInterfaceProtocol | Protocol (Prot, PROTO) | 1 | Протокол устройства. Используется для задания протокола для устройств в рамках класса и подкласса. |
| iProduct | Product | ? | Текстовая строка-описатель продукта. Когда устройство подключено к компьютеру, данная информация отображается в Диспетчере устройств. |
| iSerialNumber | Serial | ? | Серийный номер. Используется для уникализации абсолютно одинаковых устройств, например две одинаковых флешки. Назначается и поддерживается производителем устройства. Связанный механизм носит имя Сериализация. Сериализация так же участвует в уникальной идентификации устройства, поскольку добавляет еще один уровень уникальности. |
Более того, использование пары VID / PID в дескрипторе любого USB-устройства предписывается спецификацией, согласно которой данные параметры должны быть уникальны для каждой модели устройства. Ну это, опять же, все в теории, а на практике пару раз встречались экземпляры устройств, при работе с которыми становилось очевидно, что значения VID/PID взяты произвольно, либо взяты свободные значения (!) из реестра производителей. Понятно кому выгодно подобным заниматься 🙂 Ну это скорее редко встречающаяся ситуация, когда производителю хочется сэкономить на внесении в реестр производителей.
Затем, после того, как у устройства запрошены ключевые параметры, для USB устройства создан уникальный идентификатор HardwareID ( CompatibleID ), однозначно идентифицирующий устройство/класс устройства. Драйвер USB-концентратора уведомляет специализированный модуль ядра под названием Диспетчер Plug-n-Play (PnP Manager) о новом устройстве. Диспетчер PnP получает идентификаторы HardwareID и CompatibleID устройства и пытается обнаружить устройства с аналогичными идентификаторами HardwareID/CompatibleID. В этот момент в системе создается узел устройства (devnode), что является, по сути, первым отпечатком USB устройства в системе. Если похожее устройство найдено, то производится установка соответствующих драйверов в автоматическом режиме, если же не найдено, то Диспетчер PnP получается уведомление о новом устройстве и далее действует по определенным правилам, описание которых выходит за рамки данного материала.
Эксперимент
В Сети много противоречивой информации относительно истории подключения USB, поэтому давайте проведем собственный эксперимент по выявлению всех возможных системных местоположений, формирующих историю USB подключений. С целью выявления следов подключения USB стоит отследить абсолютно все изменения, происходящие в системе в момент подключения USB устройства. С этой целью на просторах Сети была найдена замечательная утилита под названием SysTracer, которая обладает всем необходимым функционалом. Утилита настолько проста и функциональна, что во многих случаях она окажется незаменимым средством в руках специалиста, поскольку предоставляет возможность сделать КРАЙНЕ полезное действие: создать мгновенный снимок (snapshot) состояния ключевых компонентов системы, таких как реестр и файлы. В качестве системы я использовал чистую инсталляцию Windows 7 Professional, при этом главным требованием было отсутствие каких-либо подключений внешних носителей. Итак, делаем снимок чистой системы, затем вставляем тестовую USB-флешку SanDisk Cruzer mini 1.0Gb и через некоторое время делаем второй снимок. Встроенными средствами утилиты SysTracer сравниваем полученные образы с выводом отчета. В итоге у нас получился некий набор системных изменений, среди которых мы попытаемся выбрать именно те, которые могут относиться к следам подключения USB устройств. Выбранный мною метод имеет и свои недостатки, поскольку наблюдения за активностью системы применительно к USB устройствам не проводилось «в динамике», то есть мы не работали с открытыми с подключаемого носителя файлами (.docx/.xlsx) в различных пользовательских приложениях, а это могло привести к тому, что мы можем упустить факты попадания частей информации с USB-носителя в файлы подкачки, различные временные файлы кеша и файлы иного назначения. Поэтому материал, скорее всего, потребует последующей доработки.
История в файлах
После изучения изменений файловой части системных изменений, подтвердился факт того, что в операционной системе Windows 7 все действия над устройствами отражаются в следующих журнальных файлах:
Алгоритм упорядочения логических томов в среде ОС 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 путем:
HKU\SID\Software\Microsoft\Windows\CurrentVersion\Explorer\MountPoints2\CPC\Volume\GUID, где 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 значений по путям:
HKLM\SYSTEM\CurrentControlSet\Services\cdrom и
HKLM\SYSTEM\CurrentControlSet\Services\partmrg.
2. Извлечение детальной информации об устройствах на основу PnPDeviceID. Настал момент дополнить описание PnPDeviceID, представленное в первой части, еще и упоминанием о том, что PnPDeviceID обязательно содержит в качестве префикса к строке описания устройства, еще и префикс, указывающий интерфейс, согласно которому устройство подключено. Причем я не могу сказать уверенно, приписывает ли этот префикс Windows к тому описанию устройства, которое предоставляет производитель или сам производитель. В любом случае, PnPDeviceID предоставляет точную информацию о том, по какому пути следует считать детальные данные из
HKLM\SYSTEM\CurrentControlSet\Enum. Продемонстрируем этот важнейший источник информации об устройствах, снимком экрана.
Помимо HKLM\SYSTEM\CurrentControlSet\Enum\PnPDeviceID, дополнительно используется еще два пути:
HKLM\SYSTEM\CurrentControlSet\Enum\PnPDeviceID\Device Parameters\Partmgr, содержащий значение важнейшего свойства DiskId, которое всюду ранее упоминалось в качестве DevGUID.
Еще раз напомним, что для устройств, обслуживаемых службой cdrom, DiskId не создается и поэтому алгоритм присваивает свойству DevID значение PnPDeviceID с символами “\” замененными на символ “#”.
HKLM\SYSTEM\CurrentControlSet\Enum\PnPDeviceID\Device Parameters\Storport содержит InitialTimestamp, дату выпуска устройства производителем в формате REG_QWORD.
Дополнительными источниками информации исключительно для внутренних дисков, являются пути:
HKLM\HARDWARE\DESCRIPTION\System\MultifunctionAdapter\0\DiskController\0\DiskPeripheral
HKLM\HARDWARE\DEVICEMAP\Scsi\Scsi Port 1\Scsi Bus 0\Target Id 0\Logical 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. Перечисление HKLM\SYSTEM\CurrentControlSet\services\volsnap\Enum
ОБЯЗАНО предоставлять упорядоченный список Storage#Volume, томов памяти. Однако случаются казусы даже в такой вылизанной системе, как Windows 8.1. Самое время продемонстрировать сохраненный фрагмент Registry, хранимый с именем файла BecameCrazy-volsnap.reg. Вот фрагмент из этого файла.
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\volsnap\Enum]
«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.2015.
Но проще не сетовать на неожиданные глюки, а создавать алгоритмы, позволяющие правильно работать независимо от сюрпризов. Поэтому казус вынудил немедленно пересмотреть алгоритм: если раньше алгоритм всецело доверял порядку строк, считываемых по указанному пути, то после случившегося в алгоритм был заложен принцип самостоятельного упорядочения в соответствии с родительским индексом и собственным смещением.
Этот же принцип применяется и на шаге 3 при создании коллекции логических томов, и он гарантирует, что упорядочение будет правильным, если только не станет “дурить” еще и служба partmgr и смещения перестанут поступать в порядке возрастания. Именно это (нарушение порядка следования смещений) и случилось под Windows 10 RTM TH1, в которой, как уже было сказано, был изменен алгоритм упорядочения Volume GUID. Естественно, что в начале это вызвало у меня бурные эмоции и всякие недоброжелательные слова в адрес программистов от MS: не то, чтобы используемый алгоритм перестал работать, но уж очень резал глаз неупорядоченный список смещений для LVGroup. И лишь через пару часов я осознал, ЧЕМ было вызвано это изменение алгоритма, что оно принесло и с того момента лишь пою дифирамбы автору идеи нового алгоритма упорядочения.
2. HKLM\SYSTEM\CurrentControlSet\Enum\STORAGE\Volume\_??_SD#DISK&Generic&SA08G&0.4#6&447d92&0&9c053461&0#
Содержит следующие свойства:
«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 драйвера. Так что не уверен, что вообще имеет смысл тратить драгоценные миллисекунды на считывание этих свойств. Гораздо важнее немедленно связать объект, представленный строкой описания тома памяти с родительским устройством. Поэтому еще до того, как считывается информация из HKLM\SYSTEM\CurrentControlSet\Enum\STORAGE\Volume\, осуществляется разбор текстовой строки, описывающей том памяти с целью определить значения следующих свойств:
Последнее из свойств устанавливается равным полю F1 GUID, предшествующего смещению для Type=”Partition”. В противном случае отсекается префикс “STORAGE\Volume\” и суффикс “#<53f56307-b6bf-11d0-94f2-00a0c91efb8b>” так что приведенная выше строка из файла с именем “crazy” для SD-карты превращается в:
Эта строка присваивается в качестве свойства 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
где 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_USERS\S-1-5-21-1478854878-1022661374-1075113013-1004\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer
\MountPoints2\CPC\Volume\<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_USERS\S-1-5-21-1478854878-1022661374-1075113013-1004\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\
MountPoints2\CPC\Volume\
«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, чтобы доказать, что я не ошибся В ПОРЯДКЕ СЛЕДОВАНИЯ детей.
В заключение стоит отметить, что по окончании цикла по объектам, предназначенным для размещения в коллекции логических томов, у нас появляется возможность окончательно разобраться со стилями форматирования разделов на внешних дисках и на VHD. Для этого достаточно сравнить значения свойств NumberOfSV и NumberOfLV. Совпадение значений однозначно свидетельствует о том, что разделы на диске имеют стиль форматирования Mbr, а вот NumberOfLV
