themalwareguardian/uefi-security-research-howyar-sysreturn-netcopyHowyar SysReturn NetCopyのCVE-2024-7344後の分析 - リバースエンジニアリングノート、脆弱なバイナリ、ベンダーとのやり取り、およびCVE-2026-79298（BOOTia32.efi内のRxPEカスタムPEローダーを介したIA-32 Secure Bootバイパス）の概念実証ツール。
Secure Bootの外套の下では、それを露呈させた脆弱性よりも深く沈むアーキテクチャもある。失効させられるバイナリもあれば、配信されるパッチもある。しかし水面下深くでは、古い習慣が痕跡を残す。これが、脆弱性が開示され、パッチが当てられ、忘れ去られた後に残るものだ。
このリポジトリに記録された調査結果には CVE-2026-79298 が割り当てられました。
調整された開示プロセスの中で、ベンダーは CVE-2024-7344 に関連する修正が x64 ブートパスのみを対象としていたことを確認しました。IA-32 ブートパス - SysReturn NetCopy 機能の一部として配布された BOOTia32.efi を含む - は、当初の修正に一切含まれていませんでした。その結果、脆弱な IA-32 コンポーネントはバージョン 11.3.034(2026年7月)まで商業的に配布され続けました。
専用の CVE リポジトリは、完全な技術的詳細 - リバースエンジニアリング、バイナリ解析、ベンダーとのやり取り、再現用アーティファクト、概念実証ツール - についてここにリンクしています。
2026年を通じて、私は UEFI セキュリティに深く取り組んできました - ブートキットの開発、Secure Boot バイパス、ファームウェアエクスプロイト、CVE 分析、攻撃ツールの開発、リサーチの公開。これは私が専門として選んだ領域であり、毎週何か新しいことが起こります。その仕事の一部は UEFI コンポーネントにおける既知の CVE の悪用を含みます。一部は UEFI ブートローダを出荷しながら公的な精査をほとんど受けていないソフトウェアの調査を含みます。そして一部は - このリポジトリが記録している部分は - 私がしばしば見過ごされすぎていると考えるある問いを投げかけることを含みます:
CVE の後、製品はどのような姿になるのか?
パッチ対応に追われる最中ではない。アドバイザリが公開された週でもない。18か月後、プレッシャーが消え、研究者たちが去り、誰も見ていないときのことだ。
このリポジトリは、特定の製品 - Howyar SysReturn NetCopy - についてその問いに答えるための私の試みです。
そして、私が発見したものは人々を驚かせるだろうと思います。
セキュリティリサーチにおけるすべては、糸を十分にたどれば何か別のものにつながります。この特定の糸は職場から始まりました。私たちは、特定のカテゴリの環境 - 教育センター - に対する UEFI およびブートキット攻撃の実世界リスクを分析する任務を負っていました。ニッチに聞こえます。そうではありません。
この分野の外にいるほとんどの人が十分に理解していない現実があります。中規模の都市では、学校全体に展開された共用デバイスが容易に70,000台以上存在し得ます - 8歳から15歳の生徒が使用するラップトップとワークステーションで、その規模での Windows ライセンスはしばしば法外なため Linux ディストリビューションを実行しています。
さて、自問してください: それらのマシンのうち、Secure Boot が適切に有効化されているのは何台あるでしょうか? 正直な答えは、ほとんどの場所でごくわずかです。そしてその理由は怠慢ではありません。運用上の現実です。
Linux 環境で Secure Boot を適切に有効化するには、すべてのカーネルに署名する必要があります。すべてのカーネル更新 - そして Linux カーネルの脆弱性は近年急速に登場しています - は、すべてのマシンに新しい署名済みイメージを展開することを要求します。それは、調整された更新パイプライン、鍵管理インフラ、訓練された人員、そして数十の拠点に分散した数千のエンドポイントにわたる継続的なメンテナンスを意味します。
そうしたリソースを持つ組織にとっては管理可能です。ほとんどの学区にとってはそうではありません。その規模で正しく行うには、人が足りず、予算が足りず、ツールも足りません。だから Secure Boot は無効のままになります。
BIOS パスワードも設定されません - 限られたスタッフで70,000台のマシンにわたってローテーションするのは非現実的だからです。そしてそれらのマシンは、ファームウェアレベルで完全に露出したまま、毎日何百人もの生徒に使用されています。
セキュリティの観点からこれが実際に意味するのは、UEFI エクスプロイトを理解する攻撃者が、それらのマシンの1台をファームウェア層で - OS がロードされる前に、あらゆるセキュリティソフトウェアが起動する前に、あらゆる保護機構が介入する機会を得る前に - 侵害できるということです。ブートキットは再起動を越え、OS の再インストールを越え、あらゆるものを越えて永続化できます。私がそうしたツールを自ら開発しているので、これはわかります。技術は存在します。理論上のものではありません。
これは既知の問題です。広く認識されています。そしてすぐに消えることはありません。
その問題に対する運用上の対応 - 学校が適切な Secure Boot の代わりに実際に導入するもの - は リカバリソフトウェア です。
考え方は単純です: 生徒がセッション中に何をしようと、次の再起動後にはすべてが既知のクリーンな状態に戻る。マルウェア、設定変更、壊れたシステムファイル、偶発的または意図的に削除されたデータ - すべて消える。これはメンテナンスコストを劇的に削減し、管理者がすべてのデバイスで完璧なファームウェアレベルのセキュリティ制御を必要とせずに共用マシンを管理する手段を与えます。
これらの環境でどの製品が使われているかを評価し始めたとき、いくつかの名前が挙がりました。その一つが Howyar SysReturn でした - 教育展開向けに特別に設計された台湾製製品で、学校のコンピュータラボ、共用ワークステーション、大規模管理環境を明示的にサポートしています。
その名前を見た瞬間、私は自分が何をしたいのか正確にわかりました。
2025年1月、ESET Research は CVE-2024-7344 の開示を公開しました - SysReturn および同じコードベースで構築された他のいくつかのリカバリ製品に影響する Secure Boot バイパスです。
この脆弱性は、深くもどかしい形でエレガントでした。Microsoft が署名した UEFI アプリケーション - ファームウェアに信頼され、Secure Boot が有効でも実行できる - が、完全にゼロから独自の カスタム PE ローダー を実装していました。Secure Boot の署名検証を強制する標準の UEFI LoadImage および StartImage 関数を使う代わりに、cloak.dat というファイルから EFI バイナリを手動で解析して実行していました。単一バイト鍵による XOR 暗号化。署名チェックなし。そのファイルの中身は何であれ、完全なファームウェアレベルの信頼で実行されました。
Microsoft は2025年1月の Patch Tuesday 更新で脆弱なバイナリを失効させました。セキュリティ業界は次の話題へと移りました。しかし私は考え続けていました。
脆弱性自体が未解決だったからではありません - ESET はそれを徹底的に文書化し、失効は明確でした。私を引き寄せ続けたのは別の問いでした。時間だけが答えを与える種類の問いです:
彼らは実際に修正したのか? それともプレッシャーをやり過ごしただけなのか?
違いがあります。本当の修正は根本原因に対処します - この場合、Secure Boot をバイパスするカスタム PE ローダーの使用です。回避策は、根本的なアーキテクチャをそのままにしながら、目先の問題を消し去ります。
私は Howyar がどちらを行ったのか知りたかったのです。
私は Howyar Technologies に直接連絡し、専門的な調達評価のために SysReturn の評価版を要求しました - そもそもこのリサーチを生み出した専門的な文脈を考えれば、これは完全に正確な説明でした。
ベンダーは協力的で迅速に対応してくれました。彼らは完全なトライアルライセンス、マニュアル、チュートリアルビデオ、完全な評価パッケージを提供しました。また、Secure Boot 互換性に関する詳細な質問にも答えてくれましたが、これは後に私が発見したことと直接関連していました。
それらのやり取りはすべて、編集なしでこのリポジトリに含まれています。
ここで技術的詳細を台無しにするつもりはありません - それは Vulnerability Research ディレクトリの役割であり、私はそれを完全に読むことを心から勧めます。しかし、これだけは言います。
UEFI はそれ自体が一つの世界です。そこで働く開発者は少数です。アプリケーションソフトウェアや Web サービスに存在するセキュリティレビュープロセスは、ファームウェアコンポーネントには日常的に及びません。悪い習慣は、一度定着すると持続する傾向があります - 悪意からではなく、エコシステムが小さく、精査が稀で、間違えた結果が注意を払っている一握りの研究者以外にはしばしば見えないからです。
私が SysReturn v11.2.031 - 2026年4月 リリース、Microsoft の失効から15か月以上後 - で発見したものは、まさにその力学の明確な例です。
根本原因は修正されていませんでした。脆弱なバイナリは置き換えられていませんでした。変わったのは運用上のことでした: Secure Boot 有効システム向けの別のブートパスで、それ以外のほとんどすべては手つかずのままでした。
カスタム PE ローダー - バイナリ自身のデバッグ文字列で名付けられた RxPE コンポーネント - は2026年4月リリースに存在し、ESET が2024年に分析したバージョンと同一に機能しています。
Howyar が2026年4月に出荷したバイナリの Authenticode ハッシュは、Microsoft が2025年1月に失効させたハッシュとバイト単位で一致します。
これは重要だと思います。人々はこれを知るべきだと思います。そして、このリポジトリの技術文書は、これらの発見を自分で検証したい人がそうできるほど詳細であると思います。
| ディレクトリ | 説明 |
|---|---|
📚 00 Manual | Howyar が提供したベンダーマニュアル、パンフレット、公式製品ドキュメント |
📦 01 Binaries | 分析のために評価パッケージから抽出された主要バイナリ |
📬 02 Disclosure | 評価プロセス中の Howyar Technologies との完全なメールやり取り |
🔬 03 Vulnerability Research | リバースエンジニアリング、バイナリ解析、Authenticode 検証、ALRM フォーマット解析、スクリプト、技術的発見 |
技術的な話 - BOOTia32.efi の完全なリバースエンジニアリング、ALRM ペイロードフォーマット、XOR 復号、RxPE カスタム PE ローダー、失効したバイナリとの Authenticode ハッシュ一致、そして Howyar が実際に変更したものと手つかずのままにしたものの分析 - はすべてここにあります:
「パッチ」後の分析に飛び込む前に CVE 自体の背景を知りたい場合は、ESET のアドバイザリが良い参考になります。私はまた、CVE-2024-7344 を文書化したリポジトリ と関連する UEFI 脆弱性をより詳細に維持しています。
読み始めてください。外套はまだそこにあります。
