Windows UAC機能を担当するSystem32フォルダーにバイナリ（.exe）がありますか？（例：）uac.exe。そのファイルを強制的に削除するとどうなりますか？Windowsが壊れたり、起動に失敗したりしませんか？

ここにはXYの問題はありません。UACをPCから強制的に削除するとどうなるか知りたいのですが。

UACは、複数のバイナリによって実装されるマルチコンポーネントアーキテクチャです

ユーザーアカウント制御（UAC）は、UACアーキテクチャを形成するいくつかのコンポーネントを指します。それらのいくつかとその実装を担当するバイナリについて簡単に説明しますが、最初に、Microsoft Docsの記事User Account Control WorksからUACアーキテクチャの概要を説明します。

ローカルセキュリティ機関（LSA）/フィルタートークン

概念的には、UACの「最初の」コンポーネントは、ログオンプロセス中にユーザーのアクセストークンの作成を処理するローカルセキュリティ機関サブシステムによって実装されます。Windows Vista以降、ログオンプロセスが変更され、管理者がUACを有効にしてログオンすると、LSAサブシステムがユーザー用に2つの個別のアクセストークンを生成するようになりました。

1. 完全な管理者アクセス権を持つもの、および
2. 標準ユーザーアクセスを備えた2番目の「フィルタートークン」

ここに示すように、このプロセスは標準ユーザーログオンのプロセスとは異なります。

LSAサブシステムサービスはlsass.exeプロセス内に存在します。

仮想化

Windows 7で追加されたFile and Registry Virtualizationは、UACに準拠していないが、ファイルシステムまたはレジストリの特定の保護領域にアクセスするために管理者権限のみを必要とする古いアプリケーションをシムする UACのコンポーネントです。

UACに準拠していない管理アプリケーションがProgram Filesなどの保護されたディレクトリに書き込もうとすると、UACは変更しようとしているリソースの独自の仮想化ビューをアプリケーションに提供します。仮想化されたコピーは、ユーザーのプロファイルで維持されます。

ソース

管理者権限を必要としない領域へのこれらのアクセス試行をリダイレクトすることにより、これらのアプリケーションは、システムでUACが有効になっていても機能し続けます。

この仮想化はカーネルに実装されています。

アプリケーション情報サービス

アプリケーション情報サービス（AIS）は、アプリケーションのマニフェストを読み取り、UAC同意プロンプトと連携して、アプリケーションが昇格された権限で実行できるかどうかを判断します（つまり、ログオン時に作成されたフィルター処理されていない管理レベルアクセストークンのコンテキストで開始します） 。このブログ投稿では、UACプロセスにおけるその役割の概要を説明しています。

AISは、追加の管理特権で対話型アプリケーションの実行を促進します。このサービスが停止すると、ユーザーは必要な追加の管理者権限でアプリケーションを起動できなくなります。...シェルは、アプリケーションの起動時にこのサービスをチェックします。AISは、マニフェストと「requestedExecutionLevel」の要件を持つ「trustInfo」xmlセクションを読み取るものです...

UAC同意プロンプトプロセスでのAISの役割を詳述した上記の引用に続く図を次に示します。

AISは、appinfo.dllによって実行されるDLLに実装されていますsvchost.exe。

同意プロンプト

@BenNの回答は、有名な（非）UAC同意プロンプトの重要な役割を説明しています。これはconsent.exe、管理者権限が必要なアプリケーションの起動を許可するために実装され、ユーザーの同意または管理ユーザーの資格情報を取得する責任があります。

安全なデスクトップ

セキュアデスクトップは、UAC同意プロンプトがデフォルトで表示される場所です。MicrosoftのUACBlogは、ユーザーデスクトップと比較してこのデスクトップのユニークな点を示しています。

ログオンUIはセキュアデスクトップ上で実行されるため、Windowsにログオンするときに最も一般的に[セキュアデスクトップ]と対話します。Secure DesktopのUser Desktopとの主な違いは、SYSTEMとして実行される信頼できるプロセスのみがここで実行できることです（つまり、ユーザーの特権レベルとして実行されるものは何もありません）。UserDesktopからSecure Desktopに到達するパスも信頼できる必要があります。チェーン全体。

昇格されたアクセス許可でアプリケーションを実行するためにユーザーの同意を求めるときにそれを使用する背後にあるアイデアは、マルウェアが既に管理者権限を持っていない限りSecure Desktopを模倣できないことです。この場合、ユーザーをだまして許可を与えることは意味がありません。

結論：UACは単なるバイナリではありません。それは織り交ぜられたサブシステムのファブリックです。

UACアーキテクチャには、ここで取り上げていない他の側面もありますが、これは次の事実について十分な証拠を提供するはずです。

1. UACは単一のバイナリに実装されていません。
2. 有効にした場合、管理タスクの実行に不可欠な部分です。

Windows Vistaでの導入以来、オペレーティングシステムの主要部分に深く統合されており、UACに関与するすべてのコードを他の物（ログオン機能など）を壊すことなく実行不可能に削除しています。

UACを「強制的に削除」するとWindowsが壊れると言っても安全だと思います。

Twistyが上手く説明したように、UACの実装に役立つコンポーネントがたくさんあります。人々が最もよく知っているUACの部分は、昇格/同意ダイアログです。

これはconsent.exe、「管理アプリケーションの同意UI」によって提供されます。VMで名前を変更して、何が起こるか見てみました。予想どおり、「管理者として実行」を使用すると昇格プロンプトは表示されません。代わりに、昇格しようとしているものを非難するfile-not-foundエラーが表示されます。

管理者としてログインしている場合でも、昇格が必要な（つまり、シールドアイコンがある）コントロールパネルUI要素を使用しようとすると、同様のエラーで失敗します。[スタート]メニューから管理項目を起動しようとすると、わずかに異なるエラーが生成されます。

すべてを壊した名前変更を行うときに設定されたACLによっては、ファイル操作には昇格が必要になる場合があるため（通常は同意ダイアログを生成しない場合でも）、OS内からこれを修正することは不可能です。ただし、通常のユーザーのようなアクティビティが低下することはありません。