Есть ли бинарный файл (.exe) в папке System32, отвечающий за функциональные возможности Windows UAC? (например, uac.exe). Что произойдет, если этот файл был принудительно удален? Будет ли Windows ломаться или не загружаться?

Здесь нет проблем XY; Мне просто любопытно узнать, что произойдет, если UAC будет принудительно удален из ПК.

UAC - это многокомпонентная архитектура, реализованная несколькими двоичными файлами

Контроль учетных записей (UAC) относится к нескольким компонентам, которые вместе образуют архитектуру UAC . Я кратко рассмотрю некоторые из них, а также двоичные файлы, отвечающие за их реализацию, но сначала приведу обзор архитектуры UAC из статьи Microsoft Docs « Как работает контроль учетных записей» :

Локальный орган безопасности (LSA) / фильтрованный токен

Концептуально «первый» компонент UAC реализуется подсистемой Local Security Authority, которая обрабатывает создание токена доступа пользователя в процессе входа в систему. Начиная с Windows Vista, процесс входа в систему был изменен так, что когда администратор входит в систему с включенным UAC, подсистема LSA создает два отдельных маркера доступа для пользователя:

1. Один с полным доступом администратора и
2. Второй «фильтрованный токен» со стандартным доступом пользователя

Как показано здесь, этот процесс отличается от обычного входа пользователя в систему:

Сервис подсистемы LSA живет в lsass.exeпроцессе.

Виртуализация

Виртуализация файлов и реестра, добавленная в Windows 7, является компонентом UAC, который скрывает старые приложения, которые не совместимы с UAC, но требуют только административных прав для доступа к определенным защищенным областям файловой системы или реестра:

Когда административное приложение, которое не совместимо с UAC, пытается выполнить запись в защищенный каталог, такой как Program Files, UAC предоставляет приложению собственное виртуализированное представление ресурса, которое оно пытается изменить. Виртуализированная копия сохраняется в профиле пользователя.

Источник

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

Эта виртуализация реализована в ядре .

Информационная служба приложения

Информационная служба приложения (AIS) считывает манифест приложения и работает с запросом согласия UAC, чтобы определить, может ли приложение выполняться с повышенными правами (т. Е. Запускаться в контексте нефильтрованного токена доступа административного уровня, созданного при входе в систему) , Этот пост в блоге дает хороший обзор его роли в процессе UAC:

AIS Облегчает запуск интерактивных приложений с дополнительными административными привилегиями. Если эта служба остановлена, пользователи не смогут запускать приложения с дополнительными административными привилегиями, которые могут им потребоваться .... Оболочка проверяет эту службу при запуске приложения. AIS - это тот, который читает манифест и раздел «trustInfo» xml, который имеет требования для «требуемого исползования» ...

Вот рисунок, который следует за приведенной выше цитатой с подробным описанием роли AIS в процессе запроса согласия UAC:

АИС реализована в DLL,appinfo.dll которая выполняется svchost.exe.

Согласие

@ Бенн ответ объясняет ключевую роль (в) известном UAC Согласии Prompt. Это реализовано consent.exeи отвечает за получение согласия пользователя или учетных данных пользователя с правами администратора для запуска приложения, требующего прав администратора.

Безопасный рабочий стол

Безопасный рабочий стол - это то место, где по умолчанию отображается запрос согласия UAC. UACBlog от Microsoft рассказывает нам, что уникально в этом рабочем столе по сравнению с рабочим столом пользователя:

Вы чаще всего взаимодействуете с [защищенным рабочим столом] при входе в Windows, поскольку пользовательский интерфейс входа в систему работает на защищенном рабочем столе. Основное отличие Secure Desktop от User Desktop состоит в том, что здесь разрешено запускать только доверенные процессы, работающие в качестве SYSTEM (то есть ничего, работающего не как уровень привилегий пользователя), а путь к Secure Desktop с рабочего стола пользователя также должен быть доверенным через вся цепочка.

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

Вывод: UAC - это не просто двоичный файл. Это ткань переплетенных подсистем.

Есть и другие аспекты архитектуры UAC, которые здесь не рассматриваются, но это должно предоставить достаточно доказательств того, что:

1. UAC не реализован в одном двоичном файле.
2. Если включено, это неотъемлемая часть выполнения административных задач.

С момента своего появления в Windows Vista он был глубоко интегрирован в ключевые части операционной системы, что делает невозможным удаление всего кода, отвечающего за UAC, без ущерба для других вещей (например, вашей возможности входа в систему!)

Я думаю, можно с уверенностью сказать, что если вы «принудительно удалили» UAC, вы сломаете Windows.

Как прекрасно объяснил Твисти , существует множество компонентов, которые помогают реализовать UAC. Часть UAC, с которой люди больше всего знакомы, это диалог повышения / согласия:

Это обеспечивается consent.exe"Согласным пользовательским интерфейсом для административных приложений". Я попытался переименовать его в ВМ и посмотреть, что произойдет. Как и ожидалось, при использовании «Запуск от имени администратора» не отображаются подсказки повышения прав - вместо этого вы получаете сообщение об ошибке «файл не найден», в котором обвиняется то, что вы пытаетесь поднять:

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

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