Параметр userinit в реестре windows 10

Удалил параметр в реестре. Винда перестала грузиться. Ни в безопасном не грузит, ни в обычном. Переустанавливать не хочу, так как понимаю, что удалил один параметр Userinit и только из реестра, так что если его обратно прописать все вернется на круги своя. Помогите плиз. Или киньте идейку?

Ответ:
До боли знакомая ситуация сталкивался точно с такой же траблой. Решается не так сложно, но придется повозиться.

Приступим. Для начала нам надо что-то типа LiveCD или LiveUSB.

Грузимся. Открываем реестр (Win+r, regedit, Enter) перед нами открылся реестр той ОС, с которой мы загрузились. Теперь закрузим кустик реестра полудохлой винды.

Устанавливаем курсор на HKLM жмякаем на файл и затем Загрузить куст…

Выбираем файлик, который лежит в мертвой оси C:WindowsSystem32config и выбираем файлик SOFTWARE. Теперь обзываем его как-нибудь например 111111111.

В реестре появится куст с именем 111111111. в этой веточке открываем MicrosoftWindows NTCurrentVersionWinlogon и ручками добавляем там параметр Userinit присваеваем ему значение: C:Windowssystem32userinit.exe,

Затем жмякаем Файл выбираем Выгрузить куст и собственно все. Параметр реестра в мертвой винде восстановлен.

Будут сложности — пишите, постараюсь описать более подробно. 🙂

Процесс входа в Windows (Winlogon, %SystemRoot%System32Winlogon.exe) обрабатывает интерактивные пользовательские входы в систему и выходы из нее.

Winlogon получает уведомление о запросе пользователя на вход в систему, когда с помощью определенной комбинации клавиш вводится безопасная последовательность привлечения внимания — secure attention sequence (SAS). В качестве SAS в Windows используется комбинация Ctrl+Alt+Delete. Причиной применения SAS является защита пользователей от программ перехвата паролей, имитирующих процесс входа в систему (эта клавиатурная последовательность не может быть перехвачена приложением, работающем в пользовательском режиме).

Аспекты идентификации и аутентификации процесса входа в систему реализованы через DLL-библиотеки, называемые поставщиками учетных данных (credential providers). Стандартные поставщики учетных данных Windows реализуют интерфейсы аутентификации, используемые в Windows по умолчанию: паролей и смарт-карт.

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

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

Кроме того, Winlogon может загрузить дополнительные DLL-библиотеки сетевых поставщиков (network providers), необходимые для дополнительной аутентификации.

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

Как только будут зарегистрированы имя пользователя и пароль, они будут отправлены для аутентификации процессу сервера проверки подлинности локальной системы безопасности (%SystemRoot%System32Lsass.exe). LSASS вызывает соответствующий пакет аутентификации (реализованный в виде DLL-библиотеки) для выполнения фактической проверки — например, для проверки соответствия пароля тому, что сохранено в Active Directory или в SAM (части реестра, в которой содержатся определения локальных пользователей и групп).

После успешной аутентификации LSASS вызывает функцию в мониторе безопасности (например, NtCreateToken) для генерации объекта маркера доступа, содержащего профиль безопасности пользователя. Если используется управление учетными записями пользователей (User Account Control, UAC) и входящий в систему пользователь относится к группе администраторов или имеет права администратора, LSASS создаст вторую, ограниченную версию маркера.

Затем этот маркер доступа используется Winlogon для создания исходного процесса (процессов) в пользовательском сеансе. Исходный процесс (процессы) хранится в параметре реестра Userinit, который находится в разделе HKLMSOFTWAREMicrosoftWindowsNTCurrentVersionWinlogon. (По умолчанию это Userinit.exe, но в списке может быть более одного образа.)

Userinit выполняет действия по инициализации пользовательской среды окружения (например, запускает сценарий входа в систему и применяет групповую политику), а затем смотрит в реестр на значение параметра Shell (в разделе Winlogon) и создает процесс для запуска определяемой системой оболочки (по умолчанию Explorer.exe). Затем Userinit завершается.

Именно поэтому для процесса Explorer.exe родительский процесс не показывается — его родительский процесс завершился, и средство tlist выравнивает имена процессов, чьи родительские процессы не работают по левому краю.

(По другому это выглядит так, что процесс Explorer является внуком процесса Winlogon.)

Winlogon является активным не только во время входа пользователя в систему и выхода из нее, но также и при перехвате SAS с клавиатуры. Например, если войдя в систему нажать комбинацию клавиш Ctrl+Alt+Delete, появится экран безопасности Windows, предоставляющий возможности для выхода из системы, запуска диспетчера задач, блокировки компьютера и т. д. Этим взаимодействием занимаются процессы Winlogon и LogonUI.

Подробности вызываемых функций, устанавливающих связь с LSASS (функций, чьи имена начинаются с префикса Lsa), даны в документации по Windows SDK.

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

Утилита системной конфигурации MSConfig.exe

Начиная с Windows версии 98, Microsoft поставляет утилиту «MSConfig.exe», предоставляющую удобный интерфейс для управления файлами, запускающимися при загрузке Windows. Она находится в каталоге установки Windows. Ее можно запустить из диалогового окна «Выполнить». В ней нет возможности добавлять новый элемент с именем приложения или документа для автозапуска, но можно отключать, не удаляя, любой пункт из находящихся в списках. Есть еще одна интересная возможность — проверка правильности пути, соответствующего элементу автозапуска, и удаление из списков элементов, пути к которым не верны. Возможности этого приложение достаточно убогие и годятся для пользователей системы, но никак не для администраторов. Далее в статье я, по необходимости, буду ссылаться на эту утилиту.

Автозапуск из файлов инициализации

Изложение мест автозапуска будет вестись в хронологическом порядке, начиная с первых версий Windows и устаревших технологий. Файлы инициализации достались в наследство от 16-битных версий Windows 3.x. Microsoft несколько раз декларировала, что она избавляется от устаревших файлов, но на самом деле они до сих пор обрабатываются при запуске.

В файле «Win.ini» в разделе «[windows]» есть два параметра, которые могут служить местом для автозапуска. Первый параметр это «load», второй — это «run». Содержимое по умолчанию для них — это пустая строка. Имена файлов в них не должны содержать пробелов, указание полного имени файла в двойных кавычках не допускается. В них можно перечислить несколько имен файлов через запятую. Обычно они используются для загрузки драйверов, но могут загружать «троянских коней» или «клавиатурных шпионов».

Еще один файл инициализации, который может быть использован для автоматического запуска программ, — это файл «System.ini». В этом файле в разделе «[boot]» есть параметр «shell», который хранит имя оболочки Windows. Значение по умолчанию этого параметра — «Explorer.exe». Значение «shell» может содержать список приложений для автоматического запуска как параметры командной строки «Explorer.exe». Приложение «Explorer.exe» обрабатывает командную строку и пытается запускать приложения или документы, перечисленные в командной строке. Требования к формату параметра «shell» такие же, как и у вышеупомянутых параметров файла «Win.ini». В последнее время этот параметр начал широко использоваться для запуска сетевых червей. Это делает локализацию трудно обнаруживаемой, т.к. администраторы забывают просматривать этот параметр как место для запуска деструктивных приложений.

Утилита «MSConfig.exe» позволяет просматривать состояние и редактировать содержимое этих трех параметров: «load», «run», «shell», находящихся в файлах инициализации.

Папки автозапуска

Первая папка, которая отрабатывается после завершения загрузки Windows, — это папка «Автозагрузка», которая может хранить список ярлыков (*.lnk) приложений или документов. Ее состояние можно увидеть, выйдя из меню «Пуск» в подменю «Программы». Это — папка, относящаяся к «Текущему пользователю».

Чтобы найти ее размещение, сначала надо найти в системном реестре ключ «HKEY_CURRENT_USER SOFTWARE Microsoft Windows CurrentVersion Explorer User Shell Folders», хранящий размещение всех измененных папок, и отыскать там параметр «Startup» строкового типа. Если искомый параметр отсутствует, то ее размещение по умолчанию на жестком диске прописано в системном реестре в параметре «Startup» ключа «HKEY_CURRENT_USER SOFTWARE Microsoft Windows CurrentVersion Explorer Shell Folders».

Ярлыки к приложениям, находящимся в папке «Автозагрузка», отображаются в программе для настройки системы «MSConfig.exe». Если отключить автоматический запуск какого-нибудь элемента через «MSConfig.exe», то в папке «Программы» (она же и подменю в меню «Пуск») будет создана папка с названием «Отключенные элементы запуска», куда «MSConfig.exe» и переместит отключенный элемент. Для того чтобы временно исключить ярлык из автоматической загрузки, я прибегаю к более простому способу: у необходимого ярлыка я выставлю атрибут «скрытый» и при следующей загрузке он пропускается.

Следующая папка — это «Общая» для всех пользователей папка «Автозагрузки» (Common Startup Folder), которая также отрабатывается после загрузки Windows в поисках ярлыков с документами или приложениями. Увидеть ее в подменю «Пуск» можно в Windows NT или 2000. В Windows 9.x, ME ее содержимое не отображается. Она должна хранить ярлыки общие для профилей всех пользователей. В документации Microsoft (MSDN) сказано, что эта папка создавалась для Windows. Однако ее содержимое отрабатывается, даже если Windows 95, 98, ME работают в однопользовательском режиме.

В системном реестре ее размещение на жестком диске прописано в строковом параметре «Common Startup» ключа «HKEY_LOCAL_MACHINE SOFTWARE Micro-soft Windows CurrentVersion Explorer Shell Folders», который хранит измененные пути папок. При отсутствии этого параметра следует посмотреть размещение этой папки по умолчанию в параметре «Common Startup» ключа «HKEY_LOCAL_MA-CHINE SOFTWARE Microsoft Windows CurrentVersion Explorer Shell Folders».

Список исполнимых файлов, находящихся в «Общей» (для профилей всех пользователей) папке «Автозагрузка» также показываются «MSConfig.exe». Если отключить автоматический запуск какого-нибудь элемента через «MSConfig.exe», то в той же папке, где находится папка «Общего запуска», будет создана папка с названием «Отключенные элементы запуска», куда утилитой «MSConfig.exe» будут перемещены отключенные элементы запуска.

Администраторам следует обращать внимание на содержимое этой папки как место для возможного запуска приложений.

Системный реестр: автозапуск, общий для всех версий Windows

В системном реестре Windows есть ветвь «SOFTWARE Microsoft Windows CurrentVersion», содержащая несколько групп для автоматического запуска приложений. Все эти группы могут быть как в разделе HKEY_LOCAL_MACHINE, так и в разделе HKEY_CURRENT_USER. Изложение будет общим, и все может быть экстраполировано на оба этих раздела. Если Windows используется как многопользовательская среда, другими словами, это либо Windows версий NT/2000/XP, либо 95, 98, ME с задействованными профилями пользователей, то группы запуска следует искать также в разделе «HKEY_USERS .Default». Это раздел общий для всех пользователей системы. Если Windows 95, 98, ME работают в однопользовательском режиме, то раздел «HKEY_USERS .Default» идентичен разделу HKEY_CURRENT_USER.

Итак, я приведу полные пути к ключам: «SOFTWARE Microsoft Windows CurrentVersion Run», «SOFTWARE Microsoft Windows CurrentVersion RunOnce», «SOFTWARE Microsoft Windows CurrentVersion RunOnceEx», «SOFTWARE Microsoft Windows CurrentVersion RunOnce Setup», «SOFTWARE Microsoft Windows CurrentVersion RunServices», «SOFTWARE Microsoft Windows CurrentVersion RunServicesOnce», которые могут содержать строковые параметры, с именами приложений или документов запускающиеся при старте системы. Раздел реестра «RunOnce» не поддерживается в Windows NT 3.5. Имена строковых параметров, содержащихся в этих ключах, могут быть произвольными.

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

Ключи, содержащиеся в разделе HKEY_LOCAL_MACHINE, отрабатываются раньше соответствующих ключей, находящихся в разделе HKEY_CURRENT_USER.

Содержимое ключей системного реестра «RunServices», «RunServicesOnce» обрабатывается раньше параметров ключей «Run», «RunOnce».

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

Запуск приложений или документов, как это следует из самого названия, прописанных в ключах «RunOnce» и «RunServicesOnce», происходит один раз, независимо от того, был он успешным или нет. Параметр, находящийся в ключе «RunOnce» или «RunServicesOnce», удаляется до запуска приложения, имя которого он содержит.

Параметры, содержащиеся в ключах «Run», «RunOnce», запускаются синхронно и в неопределенном порядке, но после того, как закончило загрузку содержимое «RunServices» и «RunServicesOnce».

Ключи системного реестра обрабатываются в следующем порядке. Первыми отрабатывается содержимое «RunServices» и «RunServicesOnce» раздела HKEY_LOCAL_MACHINE. Далее выдается окно регистрации пользователя в системе. После этого операционная система переходит к обработке ключей «RunOnce» и «Run» раздела HKEY_LO-CAL_MACHINE, далее «Run» раздела HKEY_CURRENT_USER. Следующими запускаются элементы, содержащиеся в папке «Автозагрузка». После этого наступает очередь параметров ключа «RunOnce» раздела HKEY_CURRENT_USER.

Списками параметров, автоматически запускающих приложения при старте Windows, находящихся в ключах «RunServices» и «Run», можно управлять с помощью приложения для настройки системы «MSConfig.exe». Если отключить какой-либо элемент из списка, то «MSConfig.exe» переместит этот элемента в ключ «RunServices-» или «Run-» соответственно.

Следует обратить внимание на ключ «Setup», который может содержаться в ключе «RunOnce» как в разделе HKEY_LOCAL_MACHINE, так и в разделе HKEY_CURRENT_USER. Этот ключ используется как мастером установки Windows, так и мастером «установки — удаления» программ. При отработке параметров, содержащихся в этом ключе, отображается диалоговое окно с индикатором прогресса. Имя параметра используется как имя пункта в диалоговом окне. Аналогично содержимому ключа «RunOnce», пункты ключа «RunOnce Setup» удаляются и запускаются один раз.

Еще один ключ системного реестра, на который следует обратить внимание, — это «RunOnceEx». Приведу отличия запуска параметров, находящихся в «RunOnceEx» от запуска параметров, содержащихся в ключах системного реестра «RunOnce» и «Run».

Параметры, находящиеся в ключе «RunOnceEx», запускаться не будут. Для автоматической отработки необходимо создать в нем ключ реестра, и уже в нем должны быть параметрами с именами приложений. Ключи и параметры, находящиеся в ключе «RunOnceEx», сортируются в алфавитном порядке для того, чтобы принудительно придать им строго определенный порядок запуска. Другими словами, элемент, находящийся выше по алфавиту, будет запущен раньше, независимо от того, когда он был добавлен в ключ «RunOnceEx». Приложения или файлы сценариев должны или сами себя завершать, или не требовать отдельного вмешательства для завершения, пока не завершится один элемент запуска или остановится дальнейшая отработка списка, или загрузка Windows остановится в ожидании принудительного завершения запущенного приложения. Для приложений, запущенных из ключа «RunOnceEx», в отличие от ключей «RunOnce» и «Run», отдельные процессы не создаются.

Содержимое ключей «RunOnce», «RunOnceEx», «RunOnce Setup» и «RunServicesOnce» приложением настройки системы «MSConfig.exe» не отображается.

Особенности автозапуска в Windows NT/2000/XP

В добавление к вышеперечисленным ключам, для Windows версий NT, 2000 и XP специфичен еще один ключ системного реестра — «Software Microsoft Windows NT CurrentVersion Windows Run», который может находиться в разделах LO-CAL_MACHINE или HKEY_CURRENT_USER.

В ключе «Software Microsoft Windows NT CurrentVersion Windows» могут находиться два строковых параметра «Load» и «Run», которые могут хранить списки приложений для автоматического запуска.

Эти параметры аналогичны одноименным параметрам из файла инициализации «Win.ini». При установке Windows NT (2000) поверх Windows 95, 98 значения параметров из «Win.ini» раздела «[windows]» переносятся в соответствующие параметры ключа «Software Microsoft Windows NT CurrentVersion Windows». Если в параметре указывается несколько файлов, то имена должны быть разделены пробелами. Поэтому в них невозможно прописать путь к файлу, содержащим пробелы, — двойные кавычки не принимаются. «Значение по умолчанию» для этих параметров — пробел. Программы, запущенные из параметра «Load», минимизируются при запуске.

Особенности автозапуска в Windows ME/2000/XP

У Windows версий ME, 2000 и XP появляется еще один список автозагрузки программ или документов, запускающихся после регистрации пользователя в системе, который может размещаться как в разделе HKEY_LOCAL_MACHINE, так и в разделе HKEY_CURRENT_USER. Он размещается в строковых параметрах ключа «Software Microsoft Windows CurrentVersion Policies Explorer Run». Имена параметров для этого ключа имеют особенность: они должны быть представлены в виде порядковых номеров, начиная с «1». Список, находящийся в разделе HKEY_LOCAL_MACHINE, будет отработан раньше списка раздела HKEY_CURRENT_USER.

Автозапуск при отработке Windows Logon

Отдельная группа Windows Logon для управления инициализацией при регистрации пользователя появляется в Windows NT и далее развивается Microsoft для Windows версий 2000 и XP. Параметры Winlogon находятся в системном реестре в ключе «SOFTWARE Microsoft Windows NT CurrentVersion Winlogon» раздела HKEY_LOCAL_MACHINE. Все описываемые в статье параметры, относящиеся к Winlogon, имеют строковый тип.

Параметр Shell

Параметр «Shell», отвечающий за программную оболочку, присутствует в ветви реестра «Winlogon» в версиях Windows NT, 2000 и XP.

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

По умолчанию Windows запускает программы, перечисленные в параметре «Userinit», расположенном в ветви «Winlogon», включая и сам «Userinit.exe». Если же по какой-то причине «Winlogon» процесс не смог запустить программы, определенные в параметре «Userinit», тогда «Winlogon» переходит непосредственно к обработке исполнимых файлов, имена которых записаны в параметре «Shell».

Значение по умолчанию параметра «Shell» может варьироваться. Это — «taskman, progman, wowexec» для Windows NT и «Explorer.exe» для Windows 2000, XP.

Параметр System

Этот параметр присутствует в Windows версий NT, 2000 и XP. Он содержит список имен исполнимых файлов, запускаемых Winlogon в системном контексте во время инициализации системы. Этот список можно варьировать, редактируя значение этого параметра.

Значение по умолчанию этого параметра — «lsass.exe, spoolss.exe» для Windows NT, и «lsass.exe» для Windows 2000, XP. Интересно замечание Microsoft, приведенное в MSDN: «Этот параметр появляется, но не используется самой Windows 2000».

Параметр VmApplet

Параметр «VmApplet», запускающий приложение «Панели управления» для настройки конфигурации системы, специфичен для Windows версий 2000 и XP.

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

Значение по умолчанию этого параметра — «rundll32 shell32, Control_RunDLL «sysdm.cpl»». Не стоит без нужды и изменять значение этого параметра, потому что это может привести к изменению настроек виртуальной памяти в Windows 2000, XP.

Параметр Userinit

«Userinit» (инициализация пользователя) специфичен для версий Windows NT, 2000 и XP.

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

По умолчанию Winlogon запускает «Userinit.exe», который ответственен за запуск программной оболочки и исполняет файлы сценариев для регистрации, переустанавливает сетевые соединения и затем запускает «Explorer.exe».

Значение по умолчанию параметра «Userinit»: «userinit, nddeagnt.exe» для Windows NT, «userinit» для Windows 2000, XP. Приложение «nddeagnt.exe» необходимо для запуска NetDDE — сетевого динамического обмена данными.

Расширения в именах файлов, перечисленных в этом параметре, не обязательны.

Значение этого параметра можно изменять, добавляя или убирая программы из списка.
Если необходимо запустить приложение до загрузки интерфейса пользователя вместе с «проводником» Windows, то для этого можно заменить «Userinit.exe» на имя своей программы, не забыв включить в приложение код для запуска «Userinit.exe», или поступить еще проще, создав исполнимый файл для пакетной обработки с именем «userinit.bat», со списком программ для запуска и в одной из строк прописать собственно «Userinit.exe».

P.S. Информация, систематизированная в этой статье, была адресована в первую очередь администраторам Windows-систем, а не хакерам. Все сведения, приведенные в статье, содержатся в том или ином виде в официальной документации Microsoft.

Userinit

Данная статья описывает методы восстановления загрузки системы с помощью дополнительного ПО.

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

Для восстановления системы воспользуемся загрузочным диском ERDCommander.

Содержание

Подготовительный этап

1. Скачать ERDCommander.

2. Записать на CD/DVD диск.

3. В настройках BIOS установить загрузку с CD/DVD.

4. Загрузиться с CD/DVD.

Запуск системы

1. Выбрать Run ERD Commander. Нажать ОК.

2. Выбрать загружаемую системы. Их может быть несколько. Нажать ОК.

Поиск проблемм

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

1.Необходимо заменить файл userinit.exe

Как правило этот файл находится в каталоге C:WINDOWSsystem32. Этот файл можно взять в дистрибутиве Windows или же взять другого компьютера с такой же операционной системой.

2. Запустить редактор реестра. Для этого нажать кнопку «Start»-«Administrative Tools»-«RegEdit»

3. Найти ветку реестра

4. Если там прописан еще какой-нибудь путь, то нужно его обрезать до выше указанного.

Вот пример неправильной записи в реестре. В этой ветке прописался неизвестный троян.

Если при попытке входа в учетную запись загружается пустой рабочий стол.

1. Найти ветку реестра

2. Если в ключе прописано что-то другое, то замените на указаное выше.

3.Посмотреть что прописано в ветке

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

-Запускаем утилиту Start-Administrative Tools-Autoruns

-Дважды щелкаем по своей учетной записи (1).

-Правой кнопкой выделяем подозрительную запись и нажимаем удалить(2).

Источник

Userinit в реестре windows 10

Последнее время на сайт приходят пользователи по запросу «userini.exe». Скорее всего, это люди столкнувшиеся с вирусом ntos.exe или подобным, который обсуждался на форуме. Хитрость заключается в том, что вирус подменяет системный файл userinit.exe, который требуется для инициализации пользователя в системе.

[HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionWinlogon]
«UserInit» = «%System%userinit.exe,»

Который в свою очередь совершает что-то нехорошее на компьютере и уже после своих черных дел запускает настоящий userinit, в данный момент переименованный в userini.exe (без буквы «t»).

Что происходит, когда антивирус обнаруживает файл вируса? Правильно, он его удаляет. И получается, что при следующей попытки входа в систему, файл userinit.exe не будет найден, а сеанс пользователя завершится так и не начавшись.

Если это произошло, необходимо вернуть настоящий файл userinit.exe, копия которого есть в папке: C:WINDOWSsystem32dllcache. Понадобится загрузить компьютер с помощью загрузочной дискеты или диска, флешки, LiveCD или просто подключить жесткий диск к другому компьютеру. Если в этой папке оригинал отсутствует (добавлено: некоторые модификации вируса уже подкладывают в данную папку зараженный файл, поэтому…), необходимо его скопировать с установочного диска или с другого компьютера.

Добавлено в 2011. За полтора года мне повстречалось множество записей о всяческих разновидностях подобного вируса, который прописывает свой файл в Winlogon вместо userinit.exe — то есть, там указан файл вируса (имя файла может быть любое), который после отработки должен вызвать userinit.exe. Получается тоже самое, что и в примере выше: антивирус удаляет файл вируса и система не может начать сеанс, при том что настоящий userinit.exe может быть на своем месте и не быть испорченным. В таких случаях достаточно исправить значение параметра «UserInit» на

«C:WindowsSystem32userinit.exe,» (с запятой) в разделе реестра:

Для этого можно воспользоваться диском LiveCD, на котором обычно присутствует утилита для редактирования реестра на гостевом компьютере.

Подытожим. Для нормального начала сеанса пользователя и загрузки рабочего стола необходимо выполнение двух условий:

1. Указанный в реестре файл userinit.exe в качестве инициализатора сеанса;
2. Наличие оригинального файла userinit.exe в системной папке Windows.

Однако, на сегодняшний день вирусы уже не ограничиваются подменой одного только файла userinit.exe, их жертвами также могут стать и другие не менее важные системные файлы.

Источник

IT-WeB-LOG.ru

Избавляемся от вируса блокирующего систему

Прогресс не стоит на месте, а с ним в пред движутся и разработчики вирусов смс-блокеров. С методом удаления и лечения одного нового вируса блокирующего компьютер вы сможете ознакомиться в данной статье.

Действия нового вируса блокирующего систему

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

Столкнувшись с таким вирусом, я почистил реестр, прописав в параметре shell родное значение explorer.exe, удалил вирусный файл (как это сделать можно посмотреть в статье Удаляем вирус заблокировавший компьютер ) и был очень удивлен, когда при перезагрузке компьютера, с ново появилось окно блокирующего вируса.

Новый вирус блокирующий систему

Проверив реестр я обнаружил что измененный мной параметр shell снова указывает на вирусный файл, а сам файл как не вчем не бывало, находится в директории из которой он был недавно удален.

Пришлось поломать голову над тем как это происходит. И вот что я выяснил.

Новый смс-блокер меняет параметры реестра, только для отвода глаз. Основное действие вируса это подмена файла userinit.exe находящегося на системном диске в каталоге WindowsSystem32

Восстанавливаем систему после работы нового смс-блокера.

Восстановление системы после рекламного вируса

Для тех у кого нет под рукой рабочей системы выкладываю свой файлик:

Читайте так же:

Вы можете подписаться на новые комментарии к этой записи по RSS 2.0 Feed. Вы можете оставить комментарий или trackback со своего сайта.

Источник

Где прячутся вирусы и как пользоваться командой msconfig в Windows 🕔 1 мин.

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

В зависимости от «продвинутости» создателя вируса, это может быть реализовано по-разному. Рассмотрим самые распространенные случаи:

1. В автозагрузке операционной системы

Проверить это можно с помощью команды msconfig, запущенной через меню Пуск — Выполнить

В столбце «Команда» не должно быть подозрительных элементов, например C:Program Filesnovirus.exe

Команда msconfig позволяет только отображать и отключать ненужные программы из автозагрузки, для полного удаления следов необходимо почистить соответствующие ветки реестра (посмотреть в столбце «Расположение»).

Как альтернативe команде msconfig можно использовать программу XPTweaker (скачайте с официального сайта).

В разделе «Система» перейти на закладку «Загрузка системы», прокрутить скроллом немного вниз до заголовка «Автозагрузка». Также просмотреть внимательно список загружаемых вместе с операционной системой приложений и при необходимости удалить ненужные. Программа удаляет информацию сразу и в реестре Windows.

Внимание! Для того, чтобы случайно не удалить важный системный процесс Windows — уточните предварительно у компьютерных гуру или найдите ответ через поисковую систему Яндекс или Гугл о неизвестных вам загружаемых приложений, например RTHDCPL.EXE

Данный способ загрузки вируса — самый элементарный. Он легко обнаруживается, и вирус удаляется. Так действовали вирусы 5−10-летней давности.

2. Вместо проводника

Это очень распространенный случай при заражении вирусами, особо часто он был замечен при установке пopнo-баннеров на операционную систему. Вирус в этом случае грузится вместо проводника Windows, заменив запись в реестре:

В ветке HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinlogon

Параметр Shell (reg_sz) вместо значения «explorer.exe» заменяется вирусом на свой, например C:WINDOWSsystem32h6d8dn.exe или подобную хрень.

В ветке HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinlogon

Параметр Shell (reg_sz) вместо значения «explorer.exe» заменяется вирусом на свой, например C:WINDOWSsystem32h6d8dn.exe или подобную хрень.

Исправить это с наименьшими потерями можно, загрузившись с загрузочного CD-ROM или USB, проверить систему с помощью утилиты от Доктора Веба — launcher.exe. Но только в том случае, если в базе вирусов Доктора Веба есть информация об этом вирусе.

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

Нужно посмотреть запись в реестре по адресу HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinlogon, исправить «хрень» у записи параметра Shell (reg_sz) на «explorer.exe» и запомнить путь нахождения и имя файла вируса, чтобы удалить его вручную.

3. Вместе с userinit.exe или uihost.exe

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

Userinit.exe — программа, которая открывает Рабочий стол и активирует сетевые функции после запуска Windows. Находится он по адресу C:WINDOWSsystem32userinit.exe. Размер оригинального файла составляет 26,0 КБ (26 624 байт), на диске: 28,0 КБ (28 672 байт).

Некоторые вирусы могут изменить запись в реестре у трех параметров (у всех или только некоторых) Userinit, UIHost и Shell, расположенных по адресу:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon

Оригинальные параметры записи в реестре должны быть следующими:

Вирус может прописать себя например так:

В данном примере файл gertinw.exe — это 100% вирус! Обязательно запомнить путь к файлу вируса и удалить его!

После удаления нужно заменить файлы userinit.exe, logonui.exe (находятся в C:WINDOWSsystem32) и explorer.exe (находится в C:WINDOWS) на аналогичные файлы из дистрибутива виндовса (найдете поиском), т.к. остатки червя могут находиться в файлах ключей.

Где находятся вирусы

После нужно проверить файл hosts (открыть любым тестовым редактором) на наличие запретов на известные сайты антивирусных программ: C:windowssystem32driversetchosts. Удалить все после строки 127.0.0.1 localhost

Также запрет на загрузку сайтов может быть прописан в реестре по следующим адресам:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParametersPersistentRoutes

HKEY_LOCAL_MACHINESYSTEMControlSet <номера 001 или 002>ServicesTcpipParameters PersistentRoutes

Удалить их содержимое полностью кроме строки «По умолчанию» с неприсвоенным значением.

Автор текста: Сергей «Остров»

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Источник

Userinit в реестре windows 10

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

В зависимости от продвинутости создателя вируса это может быть реализовано по-разному. Рассмотрим самые распространенные случаи, где прячутся вирусы:

1. В автозагрузке операционной системы

В столбце «Команда» не должно быть подозрительных элементов, например C:Program Filesnovirus.exe

Команда msconfig позволяет только отображать и отключать ненужные программы из автозагрузки, для полного удаления следов необходимо почистить соответствующие ветки реестра (посмотреть в столбце «Расположение»).

Как альтернативe команде msconfig можно использовать программу XPTweaker.

В разделе «Система» перейти на закладку «Загрузка системы», прокрутить скроллом немного вниз до заголовка «Автозагрузка». Также просмотреть внимательно список загружаемых вместе с операционной системой приложений и при необходимости удалить ненужные. Программа удаляет информацию сразу и в реестре Windows.

Дополнительно:

HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun и

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionRun

2. Вместо проводника

В ветке HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinlogon
Параметр Shell (reg_sz) вместо значения «explorer.exe» заменяется вирусом на свой, например C:WINDOWSsystem32h6d8dn.exe или подобную хрень.

Нужно посмотреть запись в реестре по адресу HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinlogon, исправить «хрень» у записи параметра Shell (reg_sz) на «explorer.exe» и запомнить путь нахождения и имя файла вируса, чтобы удалить его вручную.

3. Вместе с userinit.exe или uihost.exe

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

Некоторые вирусы могут изменить запись в реестре у трех параметров (у всех или только некоторых) Userinit, UIHost и Shell, расположенных по адресу:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindows NTCurrentVersionWinlogon

Оригинальные параметры записи в реестре должны быть следующими :

Userinit = C:WINDOWSsystem32userinit.exe
UIHost = logonui.exe
Shell = explorer.exe

Вирус может прописать себя например так :

После удаления нужно заменить файлы userinit.exe, logonui.exe (находятся в C:WINDOWSsystem32) и explorer.exe (находится в C:WINDOWS) на аналогичные файлы из дистрибутива виндовса (найдете поиском), т.к. остатки червя могут находиться в файлах ключей. Или скачайте отсюда.

После нужно проверить файл hosts (открыть любым тестовым редактором) на наличие запретов на известные сайты антивирусных программ: C:windowssystem32driversetchosts. Удалить все после строки 127.0.0.1 localhost

Также запрет на загрузку сайтов может быть прописан в реестре по следующим адресам:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParametersPersistentRoutes

HKEY_LOCAL_MACHINESYSTEMControlSet <номера 001 или 002>ServicesTcpipParameters PersistentRoutes

Удалить их содержимое полностью кроме строки «По умолчанию» с неприсвоенным значением.

Источник

0

Отредактировано: Raijin 2022.08.11 07:04:18

Мы продолжаем разбираться как работает ПК на примере клавиатуры и Windows 10. В этой статье поговорим о том как происходит единение софта и железа.

Старт системы

Полностью компьютер выключен когда он отключен от питания и конденсаторы на материнской плате разрядились. До эры смартфонов мобильные телефоны часто глючили и если перезагрузка не лечила проблему, то приходилось доставать батарею и ждать 10 секунд, потому что сбрасывалось программное состояние ОС, в то время как чипы на материнской плате и контроллеры устройств оставались активными сохраняя состояние, драйвера ОС к ним просто реконнектились. 10 секунд — время на разрядку конденсаторов, состояние чипов сбрасывается только при полном отключении.
Если же ПК подключен к розетке или батарее, то он находится в режиме Stand-By, это значит что по шине питания подаётся маленькое напряжения (5В) от которого запитываются некоторые чипы на материнке. Как минимум это системный контроллер, по сути это мини-компьютер запускающий большой компьютер. Получив уведомление о нажатии кнопки Power он просит блок питания/батарею подать больше напряжения и после инициализирует весь чип-сет, в том числе и процессор. Инициализация включает в себя перекачку кода и данных прошивки материнки (BIOS/UEFI) в оперативную память и настройку CPU на её исполнение.
Думать что кнопка Power это рубильник который подаёт электричество на CPU и тот начинает исполнять с заранее известного адреса прошивку BIOS неправильно. Возможно старые компьютеры так и работали. Кнопка включения находится на своей плате, вместе со светодиодами состояний и к материнке она подключается через специальный разъём. На картинке ниже видны контакты для кнопки Power, Reset, а также светодиодов с состоянием Power и чтения жёсткого диска. Нажатие кнопки включения переводится в сигнал на контакты материнки, откуда он достигает системный контроллер.

Контакты на материнке для подключения кнопки включения, светодиодов состояния Power, жёсткого диска и динамиков.

Плата ноутбука с кнопкой включения и светодиодом состояния

Cистемный контроллер обладает огромными полномочиями – включать и выключать компьютер, исполнять код в режиме ядра. Помимо него могут быть и другие чипы со сравнимыми возможностями, такие как Intel Management Engine или AMD Secure Technology (часть CPU), которые так же работают когда компьютер «выключен». Чип с Intel ME имеет в себе x86 CPU с операционной системой MINIX 3. Что он может делать:

1. Включать и выключать компьютер, т.е. выполнять программы имея доступ ко всей вычислительной мощности, периферии машины и сети.
2. Обходить ограничения файервола.
3. Видеть все данные в CPU и RAM, что даёт доступ к запароленным файлам.
4. Красть ключи шифрования и получать доступ к паролям
5. Логировать нажатия клавиш и движения мыши
6. Видеть что отображается на экране
7. Вредоносный код в Intel ME не может быть детектирован антивирусом, потому как на такой низкий уровень он добраться не может
8. И конечно же скрытно отправлять данные по сети используя свой стек для работы с сетью.

Это вызывает серьёзные вопросы безопасности, потому как он может быть хакнут или использовать в шпионских целях.

Прикладная иллюстрация как блок питания получает сигнал от материнки на включение. Если вы задумаете установить мощную видеокарту (Nvidia 2070 S) на офисный ПК, то просто вставить её недостаточно, потому как она требует питание в 600W, в то время как такой ПК имеет блок на ~500W. Первое что придёт в голову – купить новый блок питания на 650W с отдельной линией для видеокарты. Но и здесь будут разочарования, потому как разъёмы материнки будут не совпадать с разъёмами БП, а если его отдельно воткнуть в розетку и подключить к видюхе тоже ничего не будет – в блоке питания вентилятор не крутится и изображения нет. Так происходит, потому что БП должен получить сигнал от материнки на полное включение. Очевидное решение – новая материнка с совместимыми разъёмами, однако она стоит ~$300. Есть решение проще, хоть оно и вызывает опасения пожаробезопасности. Берём скрепку, разгибаем и вставляем в зелёный (PS_ON) и один из чёрных пинов (COM). Теперь всё должно работать.

Поиск загрузчика ОС

Есть два вида прошивки материнки – BIOS (Basic Input Output System) на старых машинах и UEFI (Unified Extensible Firmware Interface) на новых. Windows 10 поддерживает обе и абстрагирует различия между ними. UEFI правильней называть ОС чем прошивкой, потому как он предлагает больше возможностей, к примеру богатый графический интерфейс вместо текстового, наличие мышки, больший объём доступной памяти, улучшенная модель безопасности и валидации файлов ОС, взаимодействие с железом через API, вместо прерываний как в BIOS.

Пример экрана монитора BIOS.

Программа BIOS хранится на отдельном чипе, подключенном к Южному мосту. Этот чип можно достать и перепрошить новой программой, по факту это просто носитель памяти, а не самостоятельный микрокомпьютер.

Настройки BIOS (системное время, например), хранятся на другом чипе который как правило находится возле круглой батарейки, которая на самом деле является литиевым аккумулятором, подзаряжающимся во время работы ПК. Называется он CMOS, что означает Complementary Metal Oxide Semiconductor, а по-русски просто — КМОП, что есть комплементарная структура металл-оксид-полупроводник.

Первым делом программа BIOS выполняет проверку подсистем, эта процедура называется POST – Power On Self Test. Тест может быть сокращённый либо полный, это задаётся в настройках BIOS. Процитирую Википедию, что в себя включают эти тесты:
Сокращённый тест включает:

1. Проверку целостности программ BIOS в ПЗУ, используя контрольную сумму.
2. Обнаружение и инициализацию основных контроллеров, системных шин и подключённых устройств (графического адаптера, контроллеров дисководов и т. п.), а также выполнение программ, входящих в BIOS устройств и обеспечивающих их самоинициализацию.
3. Определение размера оперативной памяти и тестирования первого сегмента (64 килобайт).

Полный регламент работы POST:

1. Проверка всех регистров процессора;
2. Проверка контрольной суммы ПЗУ;
3. Проверка системного таймера и порта звуковой сигнализации (для IBM PC — ИМС i8253 или аналог);
4. Тест контроллера прямого доступа к памяти;
5. Тест регенератора оперативной памяти;
6. Тест нижней области ОЗУ для проецирования резидентных программ в BIOS;
7. Загрузка резидентных программ;
8. Тест стандартного графического адаптера (VGA или PCI-E);
9. Тест оперативной памяти;
10. Тест основных устройств ввода (НЕ манипуляторов);
11. Тест CMOS
12. Тест основных портов LPT/COM;
13. Тест накопителей на гибких магнитных дисках (НГМД);
14. Тест накопителей на жёстких магнитных дисках (НЖМД);
15. Самодиагностика функциональных подсистем BIOS;
16. Передача управления загрузчику.

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

Если всё прошло успешно, BIOS начинает процесс поиска загрузчика ОС. Для этого он начинает просматривать все подключенные к материнской плате жёсткие диски. Данные на физических дисках адресуются в единицах называемых сектор, обычно он 512 байт, однако современный стандарт – 4096 байт. Установщик Windows в самый первый сектор на диске записывает специальный программный код и данные о разделах. Этот сектор называется Master Boot Record. Диск разбивается на разделы (partitions), отформатированный своей файловой системой. Максимум 4 раздела, каждый из который может быть расширенным (extended partition), такой можно рекурсивно делить на 4 раздела и теоретически их число не ограничено. Как только BIOS находит Master Boot Record он считывает оттуда код и передаёт ему управление. Этот код поочередно просматривает данные о разделах и находит тот который помечен как активный, в нём находится код загрузчика Windows (Это не раздел с C:WindowsSystem32!), этот раздел называется system partition. Как правило он занимает 100Мб и скрыт от пользователя. В первом секторе этого раздела хранится загрузочный код, которому передаётся управление. Это volume boot sector, код в нём ищет файл Bootmgr, с которого и начинается процесс загрузки Windows. Файл Bootmgr создан через соединение в один файлов Startup.com и Bootmgr.exe.

Процессор начинает свою работу в режиме который называется «Реальный». Это режим совместимости, в нём CPU работает так же как и старые 16-bit процессоры, не имевшие поддержки виртуальной памяти и работавшие напрямую с физической памятью через 20-bit шину адресов, позволявшую адресовать 1Мб памяти. Простые MS-DOS программы выполнялись в этом режиме и имели расширение .COM. Первое что делает Startup.com (Bootmgr) – переключает процессор в режим «Защищённый», где под защитой понимается защита процессов друг от друга. В этом режиме поддерживается виртуальная память и 32х битные адреса, которыми можно адресовать 4Гб оперативной памяти. Следующим этапом Bootmgr заполняет таблицу виртуальных адресов на первые 16Мб RAM и включает трансляцию с виртуальных адресов в физические. В этом режиме и работает Windows. Поскольку на этом этапе подсистемы ОС ещё не созданы, Bootmgr имеет свою простую и неполную реализацию файловой системы NTFS, благодаря которой он находит BCD файл (Boot Configuration Data), в котором хранятся настройки параметров загрузки ОС. Вы можете редактировать его через утилиту BcdEdit.exe. В этих настройках BCD может быть указано, что Windows была в состоянии гибернации, и тогда Bootmgr запустит программу WinResume.exe, которая считывает состояние из файла Hyberfil.sys в память и перезапускает драйвера. Если BCD говорит, что есть несколько ОС, то Bootmgr выведет на экран их список и попросит пользователя выбрать. Если ОС одна, то Bootmgr запускает WinLoad.exe, этот процесс и выполняет основную работу по инициализации Windows:

1. Выбирает соотвествующую версию ядра Windows. Можете думать о нём как о Windows10.exe, хотя на самом деле он называется NtOsKrnl.exe. Какие есть версии? Согласно википедии:
   • ntoskrnl.exe — однопроцессорное ядро Windows. без поддержки режима PAE
   • ntkrnlmp.exe (англ. NT Kernel, Multi-Processor version) — многопроцессорное ядро Windows. без поддержки режима PAE
   • ntkrnlpa.exe — однопроцессорное ядро Windows с поддержкой режима PAE.
   • ntkrpamp.exe — многопроцессорное ядро Windows с поддержкой режима PAE.

2. Загружает HAL.dll (Hardware Abstraction Layer), который абстрагирует особенности материнки и CPU.
3. Загружает файл шрифтов vgaoem.fon
4. Загружает файлы в которых содержится инфомрация о представлениях даты времени, форматов чисел и пр. Эта функциональность называется National Language System.
5. Загружает в память реестр SYSTEM, в нём содержится информация о драйверах которые надо загрузить. Информация о всех драйверах находится в HKLMSYSTEMCurrentControlSetServices. Драйвера которые надо загрузить имеют ключ start = SERVICE_BOOT_START (0). Об устройстве реестра мы поговорим в другой статье.
6. Загружает драйвер файловой системы для раздела на котором располагаются файлы драйверов.
7. Загружает драйвера в память, но пока не инициализирует их из-за круговых зависимостей.
8. Подготавливает регистры CPU для выполнения ядра Windows выбранного на первом шаге – NtOsKrnl.exe.

Во время загрузки драйверов WinLoad проверяет их цифровые подписи и если они не совпадают, то будет синий (BSOD) или зелёный (GSOD, для insider preview сборок) «экран смерти».

Запуск на UEFI

Пример экрана загрузки UEFI

BIOS существует больше 30 лет и в попытках исправить его недостатки компания Intel в 1998 году создала стандарт Intel Boot Initiative, позже переименованный в EFI и в 2005 году пожертвованный организации EFI Forum. Недостатки BIOS:
• Работает только в 16-битном режиме
• Может адресовать только 1Mb оперативной памяти
• Часто имеет проблемы совместимости
• MBR ограничен только четырьмя главными разделами диска
• Диск с ОС не может быть больше чем 2.2Tb.
• Имеет очень ограниченные возможности для валидации загрузчика ОС.
На смену BIOS пришёл UEFI, по сути это миниатюрная ОС которая может работать и в 32-bit и в 64-bit. Для совместимости есть опция Compatibility Support Module, которая включается в настройках и эмулирует работу BIOS.

В UEFI загрузка происходит в родной для процессора битности – 32 или 64, есть доступ ко всей памяти, поддерживается виртуальная память, включен Secure Boot и есть возможность запустить antimalware до начала загрузки ОС. Порядок загрузки ОС в UEFI:

1. Инициализация и запуск Firmware, запуск чип-сета.
2. POST тест, аналогично BIOS
3. Загрузка EFI-драйверов и поиск диска подпадающего под требования EFI для загрузочного диска
4. Поиск папки с именем EFI. Спецификация UEFI требует чтобы был раздел для EFI System Partition, отформатированный под файловую систему FAT, размером 100Мб – 1Гб или не более 1% от размера диска. Каждая установленная Windows имеет свою директорию на этом разделе – EFIMicrosoft.
   
5. Читает из настроек UEFI сохранённых в NVRAM (энергонезависимая память) путь к файлу загрузчика.
6. Находит и запускает EFI/Microsoft/Boot/BootMgrFw.efi.
7. BootMgrFw.efi находит раздел реестра BCD, который хранится в отдельном файле с именем BCD. Из него он находит WinLoad.efi, который расположен в C:WindowsSystem32winload.efi.

Чтобы посмотреть содержимое раздела EFI System Partition откройте консоль с правами админа (WinKey+X => Windows PowerShell (Admin)) и выполните команды mountvol Z: /s, Z:, dir. CD — меняет директорию.
Главное отличие компонентов BootMgr и WinLoad для UEFI от своих копий для BIOS тем что они используют EFI API, вместо прерываний BIOS и форматы загрузочных разделов MBR BIOS и EFI System Partition сильно отличаются.

Инициализация ядра

Напоминаю, что мы рассматриваем загрузку ПК в контексте работы клавиатуры, поэтому не стоит заострять внимание на всех этапах. Надо понять где в этом процессе находится клавиатура, важные для понимания этапы выделены.
На предыдущем этапе был запущен компонент WinLoad.exe/WinLoad.efi, который запускает NtOsKrnl.exe указав ему параметры загрузки в глобальной переменной nt!KeLoaderBlock (память режима ядра доступна всем процессам), которые WinLoad собрал во время своей работы. Они включают:

1. Пути к System (загрузчик Windows) и Boot (C:WindowsSystem32) директориям.
2. Указатель на таблицы виртуальной памяти которые создал WinLoad
3. Дерево с описанием подключенного hardware, оно используется для создания HKLMHARDWARE ветки реестра.
4. Копия загруженного реестра HKLMSystem
5. Указатель на список загруженных (но не инициализированных) драйверов участвующих в старте Windows.
6. Прочая информация необходимая для загрузки.

Инициализация ядра Windows происходит в два этапа. До этого происходит инициализация Hardware Abstraction Layer, который в числе всего прочего настраивает контроллеры прерывания для каждого CPU.
На этой же стадии загружаются в память строки с сообщениями для BSOD, потому как в момент падения они могут быть недоступны или повреждены.

• Первая фаза инициализации ядра:
  1. Слой Executive инициализирует свои объекты состояний – глобальные объекты, списки, блокировки. Производится проверка Windows SKU (Stock Keeping Unit), примеры Windows 10 SKU — Home, Pro, Mobile, Enterprise, Education.
  2. Если включен Driver Verifier, то он инициализируется.
  3. Менеджер памяти создаёт структуры данных, необходимые для работы внутренних API для работы с памятью (memory services), резервирует память для внутреннего пользования ядром.
  4. Если подключен отладчик ядра (kernel debugger) ему отправляется уведомление загрузить символы для драйверов загружаемых во время старта системы.
  5. Инициализируется информация о версии билда Windows.
  6. Старт Object Manager – позволяет регистрировать именованные объекты к которым могут получать доступ по имени другие компоненты. Яркий пример – мьютекс по которому приложение позволяет запустить единственный экземпляр. Здесь же создаётся храниться handle table, по которой устанавливается соответствие к примеру между HWND и объектом описывающим окно.
  7. Старт Security Reference Monitor подготавливает всё необходимое для создания первого аккаунта.
  8. Process Manager подготавливает все списки и глобальные объекты для создания процессов и потоков. Создаются процесс Idle и System (в нём исполняется “Windows10.exe” он же NtOsKrnl.exe), они пока не исполняются, потому как прерывания выключены.
  9. Инициализация User-Mode Debugging Framework.
  10. Первая фаза инициализации Plug and Play Manager. PnP – это стандарт который реализовывается на уровне производителей периферии, материнских плат и ОС. Он позволяет получать расширенную информацию о подключенных устройствах и подключать их без перезагрузки ПК.

• Вторая фаза инициализации ядра. Она содержит 51 шаг, поэтому я пропущу многие из них:
  1. По завершению первой фазы главный поток процесса System (NtOsKrnl.exe) уже начал исполнение. В нём производится вторая фаза инициализации. Поток получает самый высокий приоритет – 31.
  2. HAL настраивает таблицу прерываний и включает прерывания.
  3. Показывается Windows Startup Screen, которая по умолчанию представляет из себя чёрный экран с progress bar.
  4. Executive слой инициализирует инфраструктуру для таких объектов синхронизации как Semaphore, Mutex, Event, Timer.
  5. Объекты для User-Mode Debugger проинициализированы.
  6. Создана symbolic link SystemRoot.
  7. NtDll.dll отображена в память. Она отображается во все процессы и содержит Windows APIs.
  8. Инициализирован драйвер файловой системы.
  9. Подсистема межпроцессного общения между компонентами Windows ALPC проинициализирована. Можете думать о ней как о named pipes или Windows Communication Foundation для межпроцессного общения.
  10. Начинается инициализация I/O Manager, который создаёт необходимые структуры данных для инициализации и хранения драйверов подключенной к компьютеру периферии. Этот процесс очень сложный.
      Здесь же инициализируются компоненты Windows Management Instrumentation и Event Tracing for Windows (на него полагается Windows Performance Analyzer). После этого шага все драйвера проинициализированы.
  11. Запускается процесс SMSS.exe (Session Manager Sub System). Он отвечает за создание режима пользователя, в котором будет создана визуальная часть Windows.

Запуск подсистем – SMSS, CSRSS, WinInit

SMSS.exe отличается от пользовательских процессов, это нативный процесс и это даёт ему дополнительные полномочия. SMSS.exe работает с ядром в обход Windows API, он использует то что называется Native API. Windows API – обёртка вокруг Native API. SMSS.exe первым делом запускает подсистему Windows (CSRSS.exe – Client Server Runtime Sub System) и заканчивает инициализацию реестра.

Процесс и потоки SMSS.exe помечены как критические, это значит что если они неожиданно завершаться, к примеру из-за ошибки, это приведёт к падению системы. Для общения с подсистемами, к примеру вызову API создающему новую сессию, SMSS создаёт ALPC-порт с именем SmApiPort. Загружаются из реестра переменные среды окружения, запускаются программы такие как Check Disk (autochk.exe, эти программы записаны в реестре HKLMSYSTEMCurrentControlSetControlSession ManagerBootExecute). SMSS.exe запускается для каждой пользовательской сессии. Глобальные переменные (очередь сообщений например) у каждой сессии своя за счёт механизма виртуальной памяти. В Windows есть контексты потока, процесса и сессии. Каждый SMSS.exe запускает свой экземпляр подсистемы, на данный момент это только CSRSS.exe (Windows), в прошлом поддерживались операционные системы OS/2 (os2ss.exe) и POSIX (psxss.exe), но эта идея была неудачной. Самый первый SMSS.exe засыпает в ожидании процесса WinInit.exe. Остальные экземпляры вместо этого создают процесс WinLogon который показывает UI для входа.

WinInit.exe инициализирует подсистемы для создания графической оболочки – Windows Station и десктопы, это не тот рабочий стол который вы видите, это иная концепция Windows. Далее он запускает процессы:

1. Services.exe – Services Control Manager (SCM) запускает сервисы и драйвера помеченные как AutoStart. Сервисы запускаются в процессах svchost.exe. Есть утилита tlist.exe, которая запущенная с параметром tlist.exe -s напечатает в консоли имена сервисов в каждом из svchost.exe.
2. LSASS.exe – Local System Authority.
3. LSM.exe – Local Session Manager.

WinLogon.exe – загружает провайдеры аутентификации (credential providers), которые могут быть password, Smartcard, PIN, Hello Face. Он порождает процесс LogonUI.exe который и показывает пользователю интерфейс для аутентификации, а после валидирует введённые данные (логин и пароль, PIN).

Если всё прошло успешно, то WinLogon запускает процесс указанный в ключе реестра HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinLogonUserinit. По умолчанию это процесс UserInit.exe, который:

1. Запускает скрипты указанные в реестрах:
   • HKCUSoftwarePoliciesMicrosoftWindowsSystemScripts
   • HKLMSOFTWAREPoliciesMicrosoftWindowsSystemScripts
2. Если групповая политика безопасности определяет User Profile Quota, запускает %SystemRoot%System32Proquota.exe
3. Запускает оболочку Windows, по умолчанию это Explorer.exe. Этот параметр конфигурируется через реестр:
   • HKCUSoftwareMicrosoftWindows NTCurrentVersionWinlogonShell
   • HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinlogonShell

WinLogon уведомляет Network Provider о залогинившемся пользователе, на что тот восстанавливает и подключает системные диски и принтеры сохранённые в реестре. Network Provider представляет из себя файл mpr.dll из системной папки, который хостится в процессе svchost.exe, т.е. сервис Windows.

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

Где здесь клавиатура?

Во время запуска ядро Windows считывает из реестра информацию о контроллере системной шины, как правило это шина PCI (реже MSI), к ней подключены контроллеры портов ввода-вывода, в том числе и USB, PS/2. Информация о нём записывается во время установки Windows. Система загружает для него драйвер и рекурсивно обходит все порты так же загружая для каждого из них свой драйвер. Драйвера могут комбинироваться в узлы (driver node), к примеру драйвер клавиатуры, будет соединён с драйвером порта PS2. А вот порт USB сложнее — сначала драйвер порта, потом драйвер для работы с протоколом HID и только потом клавиатура.

Каждый порт контроллируется своим чипом, который мониторит подключение, принимает/отправляет сигналы между CPU и устройством. Если чип-сет Южный мост не встроен в CPU, как это часто делают в ноутбуках, а существует отдельным чипом на материнке, то правильней говорить: сигнал между Южным мостом и контроллером порта. Чип контроллирующий порт имеет выделенную линию с контроллером прерываний (PIC или APIC), по которой он может попросить обратить на себя внимание CPU, к примеру считать данные от клавиатуры (порт PS/2, с USB другая история). Поскольку ОС загрузила для порта драйвер, она может отдавать ему команды, читать и отправлять данные. В нашем примере был загружен драйвер из C:WindowsSystem32i8042prt.sys. Давайте вспомним предыдущую статью. В старых компьютерах с PIC на чипе Intel 8259 было 15 линий прерываний, где клавиатура была подключена к ножке IRQ1, таймер IRQ0, а мышка к IRQ12, который на самом деле был пятой ножкой второго чипа 8259, который мультиплексировал свои прерывания через ножку IRQ2 первого контроллера. В современных PIC могут быть 255 контактов для сигналов прерываний. Во время загрузки ОС программирует APIC/PIC возвращать определённое число когда скажем пришло прерывание от порта клавиатуры или USB и по этому номеру CPU находит в таблице векторов прерываний функцию которую надо выполнить. Номер прерываний определяют HAL и Plug’n’Play Manager. Контроллер прерываний ищет сигнал на своих ножках в определённом порядке, к примеру в бесконечном цикле проверяет напряжение на ножках от 1 до MAX_PIN. Этот порядок определяет приоритет, к примеру клавиатура будет замечена раньше мышки, а таймер раньше клавиатуры. Чтобы не зависеть от особенностей работы контроллеров прерываний Windows абстрагирует концепцию IRQ (Interrupt Request) в IRQL (Interrupt Request Level). Будь у контроллера прерываний хоть 15 хоть 255 линий они все будут отображены на 32 IRQL для x86 и 15 IRQL для x64 и IA64.

Что означают приоритеты IRQL:

1. High – когда происходит краш системы, обычно это вызов функции KeBugCheckEx.
2. Power Fail – не используется. Изначально был придуман для Windows NT.
3. Interprocessor Interrupt – нужен отправить запрос другому CPU на мультипроцессорной системе выполнить действие, например обновить TLB cache, system shutdown, system crash (BSOD).
4. Clock – нужен чтобы обновлять системные часы, а так же вести статистику сколько времени потоки проводят в режиме пользователя и ядра.
5. Profile – используется для real-time clock (local APIC-timer) когда механизм kernel-profiling включен.
6. Device 1 … Device N – прерывания от устройств I/O. Во время прерывания данные от клавиатуры, мыши и других устройств считываются в отдельные буфера и сохраняются в объектах типа DPC (Deferred Procedure Call), чтобы обработать их позже и дать возможность устройствам переслать данные. После приоритет снижается до Dispatch DPC
7. Dispatch DPC — как только данные от устройств получены можно начинать их обрабатывать.
8. APC — Asynchronous Procedure Call. Через этот механизм вы можете исполнить код когда поток будет спать вызвав WaitForSingleObject, Sleep и другие.
9. Passive/Low — здесь исполняются все приложения в User Mode.

Если вы всегда программировали в режиме пользователя, то никогда не слышали про IRQL, потому что все пользовательские программы выполняеются с приоритетом Passive/Low (0). Как только происходит событие с большим уровнем приоритета (событие от клавиатуры, таймер планировщика потоков), процессор сохраняет состояние прерванного потока, которое представляет из себя значения регистров CPU, и вызывает диспетчер прерываний (interrupt dispatcher, просто функция), который повышает приоритет IRQL через API KeRaiseIrql в HAL и вызывает непосредственно сам код обработчика (interrupt’s service routine). После этого IRQL CPU понижается до прежнего уровня через функцию KeLowerIrql и прерванный поток начинает обработку с того же места где его прервали. На этом механизме основан планировщик потоков. Он устанавливает таймер, который с определённым интервалом (квант времени) генерирует прерывание с приоритетом DPC/Dispatch (2) и в своей interrupt’s service routine по определённому алгоритму назначает новый поток на исполнение.

Механизм IRQL реализовывается на уровне софта в Hardware Abstraction Layer (HAL.dll), а не железа. В Windows системах есть драйвер шины (bus driver), который определяет наличие устройств подключенных к шинам – PCI, USB и др. и номера прерываний которые могут быть назначены каждому устройству. Драйвер шины сообщает эту информацию Plug and play manager, который уже решает какие номера прерываний назначить каждому устройству. Далее арбитр прерываний внутри PnP Mgr (PnP interrupt arbiter) устанавливает связи между IRQ и IRQL.

Когда приходит прерывание от клавиатуры, любой исполняемый в данный момент поток (это может быть ваша программа) назначается на его обработку. Interrupt dispatcher повышает приоритет IRQL CPU до одного из уровней Device1-DeviceN. После этого менеджер виртуальной памяти не сможет найти страницу если она не загружена в RAM (не сможет обработать Page Fault), планировщик потоков не сможет прервать выполнение, потому что они все работают с меньшим уровнем IRQL. Главная задача драйвера клавиатуры в этот момент считать полученные данные и сохранить их для дальнейшей обработки. Данные записываются в объект типа _DPC (Deferred Procedure Call), который сохраняется в список DPC потока (что-то вроде std::list<DPC>, в ядре ОС вместо массивов используются связанные списки). Как только прерывания от всех внешних устройств обработаны, IRQL потока понижается до уровня DPC в котором и производится обработка отложенных процедур (DPC). В коде обработчика DPC для клавиатуры вызывается функция из драйвера клавиатуры Kbdclass.sys:

VOID KeyboardClassServiceCallback(
  _In_    PDEVICE_OBJECT       DeviceObject,
  _In_    PKEYBOARD_INPUT_DATA InputDataStart,
  _In_    PKEYBOARD_INPUT_DATA InputDataEnd,
  _Inout_ PULONG               InputDataConsumed
);

Так вот, драйвер клавиатуры (kbdclass.sys) получает данные от порта (USB, PS2) через прерывание и записывает их через WriteFile, компонент внутри ядра Windows просыпается, считывает их используя API ReadFile и добавляет в очередь сообщений с клавиатуры. API для работы с файлом могут использоваться для чтения данных с драйверов. С этого момента начинается обработка данных стеком ввода Windows, об этом в следующей статье.

Если у вас есть ПК с PS2 портом и вы умеете пользоваться WinDbg в режиме ядра, то можете легко найти обработчик прерываний клавиатуры напечатав команду !idt, которая выведет на экран всю таблицу векторов прерываний. Прерывание вклинивается в ход выполнения программы, слово вектор здесь подразумевает направление, направление исполнения программы. WinDbg был сделан специально для отладки Windows, самая последняя версия называется WinDbgX. Он имеет текстовый интерфейс, который отпугивает людей привыкших к Visual Studio, однако предоставляет гораздо больше возможностей, в частности исполнение скриптов. Прерывание фиолетового порта PS2 выделено красным. Функция которая его обрабатывает называется I8042KeyboardInterruptService, которая находится в файле i8042prt.sys.

BOOLEAN
I8042KeyboardInterruptService(
  IN  PKINTERRUPT Interrupt,
  IN  PVOID Context
  );

Routine Description:

    This is the interrupt service routine for the keyboard device when
    scan code set 1 is in use.

Arguments:

    Interrupt - A pointer to the interrupt object for this interrupt.

    Context - A pointer to the device object.

Return Value:

    Returns TRUE if the interrupt was expected (and therefore processed);
    otherwise, FALSE is returned.

Сейчас возникает вопрос, откуда у обработчика прерываний аргумент? Кто его передаёт? Ведь CPU ничего не знает о нём. Если поставите в неё breakpoint, то удивитесь ещё больше увидев несколько функций выше по стеку:

0: kd> kC
# Call Site
00 i8042prt!I8042KeyboardInterruptService
01 nt!KiCallInterruptServiceRoutine
02 nt!KiInterruptSubDispatch
03 nt!KiInterruptDispatch
04 nt!KiIdleLoop

Объяснение здесь простое – это не та функция которая сохранена в регистре IDT процессора. То что вы видите на картинке выше на самом деле объекты типа _KINTERRUPT. В таблице прерываний сохранён специальный ассемблерный код (nt!KiIdleLoop), который знает как найти объект описывающий прерывание в памяти. Что же интересного есть в нём?

1. Указатель на объект представляющий драйвер в памяти.
2. Указатель на функцию i8042prt!I8042KeyboardInterruptService, которая и вызывает код считывающий данные из порта PS2 через ассемблерную команду IN AL, 0x60 – сохранить значение из порта номер 0x60 в регистре AL.
3. Функция dispatcher – ей передаётся указатель функцию из пункта №2 и она вызывает её.
4. Состояние регистров CPU. Перед вызовом прерывания состояние CPU будет сохранено сюда, и отсюда же будет восстановлено.
5. Приоритет прерывания. Не тот который определяет контроллер прерываний, а тот который Windows считает нужным. Это IRQL (Interrupt Request Level) – абстракция над IRQ.

Как только обработчик прерываний клавиатуры будет вызван, он уведомит драйвер клавиатуры о полученных данных, после чего будет уведомлено ядро ОС, которое обработав данные отправит их дальше по стеку ввода, где они могут быть доставлены приложению, которое на них отреагирует, или перед этим в обработчик языков (азиатские иероглифы, автокоррекция, автозаполнение).
Ядро ОС напрямую не взаимодействует с драйвером клавиатуры, для этих целей используется Plug’n’Play Manager. Этот компонент предоставляет API IoRegisterPlugPlayNotification, который вызовет предоставленную callback-функцию когда устройство будет добавлено или удалено.

Пару слов о USB

Ознакомление с работой порта USB потребовало бы отдельной статьи описывающей его работу и плюс описание обработки данных HID на Windows. Это очень сильно усложнило бы материал, к тому же уже есть хорошие статьи по теме, поэтому PS2 идеальный пример из-за своей простоты.

USB создавался как универсальный порт для всех устройств, будь то клавиатура, фотоаппарат, сканнер, игровой руль с педалями, принтер и пр. Вдобавок он поддерживает вложенность портов – USB материнки => монитор с USB => клавиатура с USB к которой подключена мышка, флешка и USB-hub к которому подключен жёсткий диск. Взглянув на контакты USB 2.0 вы увидите что они не заточены под передачу каких-то определённых данных, как у PS2. Их всего четыре – витая пара для передачи битов данных, плюс и минус питания.

Провода кабеля USB 2.0

USB 3.0 быстрее за счёт дополнительных пяти контактов. Как видите там нету линии CLOCK для синхронизации, поэтому логика передачи данных сложнее. Слева USB 2.0 и справа USB 3.0 для сравнения.

Все данные передаются через протокол HID (Human Interface Device), который описывает форматы, порядок взаимодействия и передачи данных и всё остальное. Стандарт USB 2.0 занимает 650 страниц, документ HID Class Specification, описывающий работу устройств (мыши, клавиатуры и пр) – 97 страниц, их рекомендуется изучить если вы работаете с USB.

Первым делом подключенное устройство должно рассказать о себе, для этого оно отправляет несколько структур данных, в которых указывается ID устройства и ID производителя по которым Plug’n’Play manager может найти в реестре информацию, загрузить и соединить драйвера. USB устройства пассивны, т.е. хост должен сам с определённым интервалом проверять наличие данных. Частота опроса и размер пакета данных задаются в одном из дескрипторов устройства USB. Максимальный размер пакета – 64 байта, что для информации о нажатых клавишах более чем достаточно.

В Windows есть встроенная поддержка HID, она не такая простая как связь драйвера порта PS2 с драйвером клавиатуры, потому что драйвер HID должен уметь обрабатывать все поддерживаемые протоколом сценарии. Вне зависимости от провайдера данных — порты PS2, USB или Remote Desktop или виртуальная машина – на самом верху driver node будет находится Kbdclass, от которого ядро ОС и будет получать информацию. Уведомление о подсоединении клавиатуры будет обрабатываться через Plug’n’Play Manager, так что для ядра Windows не имеет значение какой порт или источник данных от устройства используется.

ч.1 — Основы ОС и компьютера
ч.2 — Как работает материнская плата и клавиатура через порт PS2