Hkey local machine system mounteddevices

Компания Microsoft не рекомендует менять букву системного/загрузочного диска Windows. Однако если автоматический системный процесс, например, отключения зеркального образа диска, приводит к изменению буквы диска, букву диска можно изменить следующим образом (перед этим обязательно проведите полное резервное копирование системы). В данном примере меняются местами буквы дисков C: и D:.

1. Зарегистрируйтесь в системе с правами администратора.

2. Запустите редактор системного реестра (REGEDT32.EXE).

3. Перейдите к разделу HKEY_LOCAL_MACHINESYSTEMMountedDevices.

4. Щелкните на записи MountedDevices.

5. В меню Безопасность (Security) выберите параметр Разрешения (Permissions). Удостоверьтесь в том, что администратору предоставлены все разрешения (верните параметру первоначальное значение после внесения необходимых изменений).

6. Закройте редактор REGEDT32.EXE и запустите редактор системного реестра (REGEDIT.EXE) (для выполнения следующих инструкций необходимо использовать именно редактор Regedit).

7. Перейдите к разделу HKEY_LOCAL_MACHINESYSTEMMountedDevices.

8. Найдите первую букву диска, которую необходимо заменить. В этом примере нас интересует DosDevicesC.

9. Щелкните правой кнопкой мыши на записи DosDevicesC
и выберите команду Переименовать (Rename).

10. Переименуйте запись, указав свободную букву диска (например, DosDevices). Это позволит зарезервировать букву диска С: для дальнейшего использования.

11. Найдите вторую букву диска, которую необходимо изменить. В этом примере нас интересует DosDevicesD.

12. Щелкните правой кнопкой мыши на записи DosDevicesD
и выберите команду Переименовать (Rename).

13. Переименуйте запись с использованием подходящей буквы диска, например, DosDevicesC.

14. Щелкните правой кнопкой мыши на записи DosDevices
и выберите команду Переименовать (Rename). Переименуйте запись в DosDevicesD.

15. Завершите работу с редактором Regedit и если в системные права администратора вносились изменения, запустите редактор Regedt32.

16. Верните первоначальные разрешения для администратора.

Just another weblog for students, IT people and programmers

Увеличение размера и различные действия с системным диском в MS Windows

Данная статья подходит только для операционных систем MS Windows 2000, XP, Vista, Server 2003, Server SB, Server 2008, Server HPC

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

Все кто хоть раз администрировал одну из данных операционных систем знает, что Microsoft крайне не рекомендует что-либо делать с системным диском. Через стандартные утилы у нас запрещено все. Поэтому для данных операций нам понадобиться Acronis Disk Director(Server для серверных операционных систем).

Acronis Disk Director довольно сильна программа, но очень плохо работает с серверными выпусками Windows

Для более плавного понятия данной довольно не легкой темы мы возьмем пример, самый сложный с множеством проблем после изменения системного диска Acronis Disk Director.

Испытуемый: Windows Server 2008 Enterprise x64 SR1

Требуемые средтва: Установочный диск MS Windows, желательно от Vista или Server 2008

имеем 2 физических диска и 3 раздела.

получить 2 физических диска и 2 раздела.

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

После завершения работы мы видим, что Windows не запускается, при попытке загрузки не находит winload.exe. Если внимательно посмотреть то он просто не находит диск, пишет «не найден :winload.exe». Следовательно мы имеем проблему с загрузкой boot сектора. Тут нам и понадобится дистрибутив MS Windows.

Вставляем диск или образ, если это удаленный сервер. После запуска оболочки установщика, мы видим установить и восстановить. Если выбрать установить и дойти до шага воставление старой версии или новой Windows, то восстановление будет не доступно, тк в boot файле нет записи об установленной Windows.

Поэтому выбираем опцию восстановление на первой странице оболочки установщика. Далее командная строка.

В командной строке набираем простую команду:

bcdedit, которая дает нам полное описание параметров нашего boot файла

Windows Boot Manager
———————
identifier
device No (Должно быть partition=C:)
description Windows Boot Manager
locale en-US
inherit
default
displayorder
<50c73d4f-e6b3-11da-bc73-d30cdb1ce216>
toolsdisplayorder
timeout 30

Windows Boot Loader
——————-
identifier <50c73d4f-e6b3-11da-bc73-d30cdb1ce216>
device No (Должно быть partition=C:)
path Windowssystem32winload.exe
description Microsoft Windows Server 2008
locale en-US
inherit
osdevice No (Должно быть partition=C:)
systemroot Windows
resumeobject <50c73d50-e6b3-11da-bc73-d30cdb1ce216>
nx OptIn
detecthal Yes

И как же это исправить? исправляется все также простой командой Bootrec с нужным параметром. Подходит только для Vista, Server 2008, Server HPC. Для предыдущих выпусков используется bcdedit.

В командной строке набираем:

Bootrec /ScanOs

после чего увидим, что найдена папка Windows на диске C

Bootrec /RebuildBcd

после чего увидим, что найдена папка Windows на диске C и он предложит добавить эту запись, нажимаем «Y»

Всё Boot файл восстановлен и операционная система загружается.

Но почему-то операционная система не откликается на комбинация «CTRL+ALT+DEL». Единственный выход — это зайти по RDP после загрузки профиля, мы увидим пустой рабочий стол.Нажимаем «CTRL+ALT+ESC» -> Файл->Новая задача->explorer. Загружается стандартный рабочий стол без пользовательских настроек. Открываем мой компьютер и видим, что диск «C», это второй диск, который мы не трогали. Как же это произошло? Когда второй раз загружала ОС она не нашла диск «C», тк он была заблокирован Acronis. Следовательно Windows назвала диском «C» первый попавшийся активный диск. При попытке зайти в управление, мы встречам отрицательный ответ ОС и не возможность найти указанный путь. Единственный выход остается внести изменение в реестре. Но тут мы встречаем опять отрицательный ответ ОС и не хватке прав для запуска, даже если учетная запись в группе Администраторов. У нас есть один выход зайти в систему под встроенной учеткой администратора, но представим что у нас нет пароля от нее и скидывать его нам нельзя. И тут нам приходит на ум, что нам надо запустить систему, где UAC сразу выключен и все приложения запускаются с максимальным приоритетом. Этот режим называется «Режим восстановления служб каталогов», его вызвать можно при нажатии «F8» до загрузки Windows.

Режим восстановления служб каталогов

Запускает контроллер домена Windows, на котором работает Active Directory, в режиме, позволяющем восстановить службу каталогов. Этот вариант предназначен для специалистов ИТ и администраторов.

Теперь дело осталось за малым. Поменять буквы на дисках.

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

1. Создайте резервную копию состояния системы и данных, находящихся на компьютере.
2. Войдите в систему с правами администратора.
3. Запустите программу Regedt32.exe.
4. Перейдите к следующему разделу реестра:

Всё после перезагрузки мы имеем полностью рабочую операционную систему со всеми нашими старыми файлами.

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

Система создает артефакты в момент обнаружения (инициализации) устройства (сменных накопителей, модемов, гаджетов, камер, медиаплееров и прч.) на шине компьютера. Дополнительным плюсом данного материала будет возможность сбора доказательной базы по факту неправомерного использования рабочей станции пользователя в корпоративной среде при помощи незадекларированных USB-устройств.

Не так давно в нашу жизнь вошел интерфейс USB, привнеся в неё довольно существенные изменения. Неожиданно многие вещи стали проще, отпала необходимость инсталляции устройства во внутренний интерфейсный разъем (шина), или внешний интерфейс, требующий перезагрузки станции для корректной инициализации устройства, да и сам процесс конфигурирования устройств стал, во множестве случаев, тривиальнее. На интерфейсе USB появились тысячи разнообразных по назначению устройств, которые достаточно было подключить к разъему на панели корпуса, после чего от момента подключения до состояния "готов к работе", порой проходили считанные минуты. Наряду с очевидными достоинствами: легкостью конфигурирования/использования, компактностью, функциональностью, подобные устройства сразу стали источником проблем как для безопасности персональных данных самого пользователя, так и безопасности корпоративных сред. Компактный, легко маскируемый "брелок" с интерфейсом USB может запросто явиться той ахиллесовой пятой, которая станет причиной "падения" гиганта корпоративной безопасности. Если порты USB в корпоративных рабочих станциях находятся без надлежащего контроля со стороны политик безопасности, то любое приспособление может запросто выступить в качестве средства для обхода периметра безопасности компании. И тут уж насколько хватит фантазии "взломщика", например, достаточно пронести на флешке свежий, не определяемый антивирусами вредоносный код и выполнить его (умышленно или нет), и вот вам уже прецедент, поскольку даже без локальных административных привилегий учетной записи пользователя сохраняется пространство для маневра. Не меньшую опасность представляют и USB-модемы, которые, в случае установки (а при использовании локальных/доменных политик по умолчанию это достигается достаточно просто), могут выступить в роли неконтролируемого канала передачи данных, по которому может осуществляться передача чувствительной корпоративной информации за пределы защищенного внутреннего периметра. При этом, даже декларируемые (заявленные/согласованные) пользовательские устройства (например, телефоны) могут содержать в своих микропрограммах или операционных системах уязвимости, которые, в случае эксплуатации, наносят вред не только владельцу, но и могут выступать в роли средства несанкционированного доступа к служебным данным. Поэтому, в случае возникновения инцидента информационной безопасности, связанного с эксплуатацией USB-устройств,

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

Перечисление (энумерация) USB устройств

Поскольку я сам в данном вопросе "плаваю", перед тем как перейти к практике, предлагаю немного усилить нашу теоретическую базу и описать терминологию, которая будет использоваться на протяжении всего материала. Сразу оговорюсь, что мы не будем освещать все виды взаимодействия, выполняющиеся на шине USB на аппаратном уровне, а сосредоточимся исключительно на основных понятиях, относящихся к USB-устройствам и требующихся нам для понимания практической стороны вопроса.
Подключение любого нового оборудования сопряжено с выполнением модулями ядра системы Windows предопределенных фаз опроса и инициализации. Начинается всё с того, что при подключении устройства к разъему USB, контроллером USB (встроенным в чипсет на материнской плате) генерируется аппаратное прерывание. Драйвер USB, ответственный за обработку данного прерывания, запрашивает статус порта, и если статус указывает на подключенное устройство, то ответственными подсистемами ядра производится последовательность действий, которую условно можно разделить на две стадии:

1. Нумерование устройства;
2. Установка драйвера устройства;

Ядро (?) инициирует к вновь подключенному устройству серию запросов GET_DESCRIPTOR с различными типами запрашиваемых дескрипторов ( Device , Configuration , LangID , iProduct ). Запросы опрашивают устройство на предмет наличия серии дескрипторов, представляющих собой структуры данных, описывающие возможности 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	?	Серийный номер. Используется для уникализации абсолютно одинаковых устройств, например две одинаковых флешки. Назначается и поддерживается производителем устройства. Связанный механизм носит имя Сериализация. Сериализация так же участвует в уникальной идентификации устройства, поскольку добавляет еще один уровень уникальности.

Наверняка многие из перечисленных в таблице полей Вам уже встречались в составе значений различных параметров в том же Диспетчере устройств либо в разнообразных системных лог-файлах.
Помимо стандартных дескрипторов, существуют еще так называемые Дескрипторы Microsoft (Microsoft OS Descriptors, MOD), которые содержат специфичную для ОС Windows информацию. Для поддержки производителей, чьи устройства из-за функциональных особенностей не подходят под стандартный набор классов, Майкрософт разработала набор специальных классов и собственных дескрипторов. Пользовательское и системное ПО может идентифицировать устройства, принадлежащие к разработанным Майкрософт классам устройств путем опроса устройства на предмет наличия дескрипторов Microsoft. Помимо поддержки описанных классов устройств, дескрипторы Microsoft имеют и иное применение, например при помощи них можно использовать память устройства для хранения файлов помощи, иконок, списков адресов URL, настроек системного реестра и других данных, используемых для обеспечения прозрачности установки и достижения смежных целей. Устройства, поддерживающие дескрипторы Microsoft, должны хранить специальный строковый дескриптор в прошивке с фиксированным индексом 0xEE . Операционные системы Windows XP SP1 и более поздние запрашивают этот строковый дескриптор у устройства при первом его подключении.

Более того, использование пары 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 все действия над устройствами отражаются в следующих журнальных файлах: