【テクニカル・上級編】MinGW-w64のバイナリにマルウェア検知をさせない：アンチウイルスソフト誤検知回避のためのコンパイルと署名設定 – 実行環境・ランタイム・コンパイラ生産性向上バイブル

MinGW-w64バイナリの「誤検知（False Positive）」を根絶せよ：セキュリティソフトを沈黙させるコンパイル・署名・ビルドパイプラインの極意

開発環境アーキテクトの端くれとして長年多くのプロジェクトを見てきたが、Windows向けネイティブアプリケーションのCI/CDパイプラインにおいて、これほど開発者の時間を無駄に消費している問題はない。

「ローカルのビルドは通るのに、GitHub ActionsやGitLab CIで生成したバイナリを成果物（Artifact）としてアップロードした瞬間、Windows Defenderや主要なアンチウイルス（AV）ソフトにマルウェア（Trojan/Heuristics）として隔離される」

この悪名高き「MinGW-w64バイナリの誤検知」問題である。
ネットを検索すれば「除外設定をしろ」「Defenderを切れ」といった的外れなアドバイスが溢れているが、商用プロダクトやエンドユーザー向けツールにおいて、ユーザーにそんなセキュリティリスクを取らせるわけにはいかない。

なぜMinGW-w64でコンパイルしたバイナリはこれほどまでに誤検知されやすいのか。そして、どうすればこの挙動を根本からハックし、クリーンなバイナリとして市場に送り出すことができるのか。
本稿では、PE（Portable Executable）構造の内部メカニズム、リンカの挙動、そして完全自動化されたCI/CD環境におけるコードサイニングまで、低レイヤの知見を総動員してこの課題への最終解を提示する。

—

1. なぜMinGW-w64バイナリは「マルウェア」と判定されるのか？

敵を知るためには、まずセキュリティソフトの静的・動的ヒューリスティックエンジンが何を恐れているのかを理解しなければならない。MSYS2 / MinGW-w64が生み出すPEファイルが検知網に引っかかる理由は、主に以下の3点に集約される。

1. エントロピーとセクション構造の異常性:
MSYS2のGCCやBinutils（`ld`）のデフォルト設定では、商用コンパイラ（Visual Studioなど）とは異なるセクション配置（`.text`, `.data`, `.bss`の並びやアライメント）になりやすい。また、静的リンクされたCRT（Cランタイム）コードが大量に混入するため、コード領域のエントロピー（情報のランダム性）やサイズ比率が、一般的なコンパイル済みバイナリの統計的モデルから外れやすい。
2. メタデータ（Resource）の完全な欠落:
裸の `gcc main.c -o app.exe` が生成するPEヘッダには、プロダクト名、バージョン情報、会社名、アイコン、そして最も重要な「Authenticode署名」が存在しない。AVベンダーのヒューリスティックエンジンにとって、「メタデータを持たず、ネットからダウンロードされたばかりの未知の実行ファイル」は、それだけで極めてリスクの高い「要警戒オブジェクト」となる。
3. 静的リンクによる既知の脆弱コード片（Gadget）の包含:
`-static` や `-static-libgcc` を用いた場合、過去の古いバージョンを含むlibgccやlibstdc++のランタイムコードがバイナリ内に直接埋め込まれる。AVソフトのパターンマッチングが、これらの中に含まれる特定の関数プロローグ/エピローグのバイト列パターンを悪意あるコード片と誤認することがある。

この構造的欠陥を打破するためには、「PEリソースの完全武装」「依存関係の透明化とクリーンなリンク」「暗号学的信頼（コードサイニング）」の3つを同時に達成するビルドチェーンを構築する必要がある。

—

2. 徹底解剖：PEリソースへのメタデータ埋め込み手法

WindowsのExplorerやセキュリティソフトは、バイナリのプロパティ（バージョン情報、FileVersion、CompanyNameなど）を厳しく見ている。これらを何も持たないバイナリは、エントリポイントに到達する前に信頼を失う。

MinGW環境でこれを解決するためには、Windowsリソースコンパイラ（`windres`）を使用し、`.rc` ファイルをコンパイルしてオブジェクトファイルとしてリンクに含める必要がある。

ステップ1: リソース定義スクリプトの作成 (`version.rc`)

以下の内容で `version.rc` をプロジェクトルートに作成する。これがバイナリの「身分証明書」となる。

include

// 言語と文字コードの設定（日本語 / 英語ユニバーサル）
LANGUAGE LANG_JAPANESE, SUBLANG_DEFAULT
pragma code_page(65001)

// ファイル情報の定義
VS_VERSION_INFO VERSIONINFO
FILEVERSION 1,0,0,0
PRODUCTVERSION 1,0,0,0
FILEFLAGSMASK VS_FFI_FILEFLAGSMASK
FILEFLAGS 0x0L
FILEOS VOS__WINDOWS32
FILETYPE VFT_APP
FILESUBTYPE VFT2_UNKNOWN
BEGIN
BLOCK “StringFileInfo”
BEGIN
// 041104b0 は 日本語 (0x0411) と Unicode (0x04b0 = 1200) を示す
BLOCK “041104b0”
BEGIN
VALUE “CompanyName”, “Example Corporation”
VALUE “FileDescription”, “High-Performance Native Engine”
VALUE “FileVersion”, “1.0.0.0”
VALUE “InternalName”, “engine.exe”
VALUE “LegalCopyright”, “Copyright (C) 2024 Example Corp. All rights reserved.”
VALUE “OriginalFilename”, “engine.exe”
VALUE “ProductName”, “Core Engine”
VALUE “ProductVersion”, “1.0.0.0”
END
END
BLOCK “VarFileInfo”
BEGIN
VALUE “Translation”, 0x0411, 1200
END
END

// アプリケーションアイコンの指定（存在する場合）
IDI_ICON1 ICON “app.ico”

ステップ2: `windres` によるコンパイルとリンク

この `.rc` ファイルをGCCのビルドプロセスに組み込む。

1. リソーススクリプトをCOFFオブジェクト形式にコンパイル
x86_64-w64-mingw32-windres version.rc -O coff -o version.syso

2. メインのソースコードと一緒にリンクする（.syso は自動的にリンクされる場合もあるが明示指定が安全）
x86_64-w64-mingw32-gcc main.c version.syso -o engine.exe -s -O3

※ `-s` オプションはバイナリからシンボルテーブルとデバッグ情報を完全に剥ぎ取り、ファイルサイズを劇的に縮小させるとともに、解析難易度を上げる効果がある。

—

3. 静的リンクの最適化と依存DLLの透明化

MinGWでビルドしたバイナリが `libwinpthread-1.dll` や `libstdc++-6.dll` などのランタイムDLLに依存している場合、それらのDLLが同梱されていない、あるいは署名されていない状態で配布されると、Windows環境ではロード時にエラーになるか、AVソフトが不審な挙動として検知する原因になる。

ここでアーキテクトが取るべき選択肢は2つある。
1. 完全に静的リンクし、単一の `.exe` に封じ込める
2. 必要なDLLを適切に配置し、すべてに同一の署名を施す

ここでは、多くの現場で採用される「完全静的リンク（Static Linking）」を安全に行うためのリンカフラグの最適解を示す。

Makefile のコンパイルフラグ例
CC = x86_64-w64-mingw32-gcc
CFLAGS = -Wall -O3 -ffunction-sections -fdata-sections
LDFLAGS = -static -static-libgcc -static-libstdc++ \
-Wl,–gc-sections \
-Wl,–strip-all \
-Wl,–nxcompat \
-Wl,–dynamicbase

リンカフラグの低レイヤ解説：

• `-Wl,–gc-sections`: デッドコード・オブジュエクション。ソースコードおよびリンクされたライブラリから、一度も参照されない未使用の関数やセクションをバイナリから完全に排除し、不審なコード片の混入を防ぐ。
• `-Wl,–nxcompat`: DEP（Data Execution Prevention / NXbit）を有効化する。これが有効でないバイナリは、現代のWindowsセキュリティにおいて確実にマルウェアと判定される。
• `-Wl,–dynamicbase`: ASLR（Address Space Layout Randomization）を有効化する。メモリ上の配置をランダム化し、バッファオーバーフロー等の攻撃を防ぐ必須フラグ。これがないexeはセキュリティ評価で致命的な減点を受ける。

—

4. 決定打：Authenticodeコードサイニングと証明書の仕組み

ここまでの対策を行ってもなお、未知のバイナリであるという事実自体は払拭できない。そこで最後の防壁となるのが 「コードサイニング証明書（Code Signing Certificate）」 によるデジタル署名である。

Windowsのスマートスクリーン（SmartScreen）やアンチウイルスソフトは、証明書の「信頼チェーン（Trust Chain）」と「レピュテーション（実績）」を確認する。EV証明書、または標準的なコードサイニング証明書でPEファイルを署名することで、バイナリの改ざんがないこと、および発行者の身元が保証され、誤検知の確率を劇的に下げることができる。

実務で使う署名コマンド（SignTool）

Windows環境（またはCI上のWine/専用コンテナ）において、Microsoft公式の `signtool.exe` を用いてタイムスタンプ付きの署名を行う。

signtool.exe sign /v /fd sha256 /tr http://timestamp.digicert.com /td sha256 /f “C:\certs\my_certificate.pfx” /p “your_secure_password” “path\to\engine.exe”

• `/fd sha256`: ダイジェストアルゴリズムとして強力な SHA-256 を指定（古い SHA-1 は現在完全に拒絶される）。
• `/tr http://timestamp.digicert.com`: タイムスタンプサーバーを指定。証明書の有効期限が切れた後でも、署名時点では有効であったことを証明し続けるための必須設定。

—

5. CI/CDパイプライン完全自動化：GitHub Actionsによる実装

この一連のプロセス（リソースコンパイル、静的最適化ビルド、メタデータ付与、そしてコードサイニング）を、人間の手で実行するなどあってはならない。すべてをGitHub Actionsのパイプラインにコードとして焼き付ける。

以下に、セキュアでクリーンなMinGWビルド・署名を行う実践的なワークフロー設定を示す。

name: Secure Windows Build Pipeline

on:
push:
branches: [ main ]
tags: [ ‘v’ ]

jobs:
build-and-sign:
runs-on: windows-latest # signTool.exeを利用するためWindowsランナーを使用（MSYS2も利用可能）

steps:

• name: Checkout Repository

uses: actions/checkout@v4

# 1. MSYS2環境のセットアップとMinGW-w64ツールチェーンの導入

• name: Setup MSYS2

uses: msys2/setup-msys2@v2
with:
msystem: MINGW64
update: true
install: >-
git
mingw-w64-x86_64-toolchain

# 2. リソーススクリプトのコンパイルとバイナリビルド

• name: Build with MinGW-w64

shell: msys2 {0}
run: |
echo “=== Compiling Resource Script ===”
x86_64-w64-mingw32-windres version.rc -O coff -o version.syso

echo “=== Building Executable ===”
x86_64-w64-mingw32-gcc main.c version.syso -o engine.exe \
-Wall -O3 \
-ffunction-sections -fdata-sections \
-static -static-libgcc -static-libstdc++ \
-Wl,–gc-sections \
-Wl,–strip-all \
-Wl,–nxcompat \
-Wl,–dynamicbase

# ビルド成果物の確認とPEヘッダのインスペクション
ls -la engine.exe

# 3. GitHub Secretsからコードサイニング証明書を復元して署名

• name: Sign Executable with Authenticode

env:
PFX_BASE64: ${{ secrets.CERTIFICATE_PFX_BASE64 }}
PFX_PASSWORD: ${{ secrets.CERTIFICATE_PASSWORD }}
shell: pwsh
run: |
if ([string]::IsNullOrEmpty($env:PFX_BASE64)) {
Write-Error “Certificate PFX is missing in Secrets!”
exit 1
}

# Base64形式の証明書を一時ファイルに復元
$certBytes = [System.Convert]::FromBase64String($env:PFX_BASE64)
[System.IO.File]::WriteAllBytes(“$env:TEMP\cert.pfx”, $certBytes)

# Windows SDKのSignToolのパスを特定して実行
$signtool = “C:\Program Files (x86)\Windows Kits\10\bin\10.0.22600.0\x64\signtool.exe”
if (!(Test-Path $signtool)) {
# フォールバック検索
$signtool = Get-ChildItem “C:\Program Files (x86)\Windows Kits\10\bin” -Recurse -Filter “signtool.exe” | Select-Object -ExpandProperty FullName -First 1
}

Write-Using Signtool at: $signtool
& $signtool sign /v /fd sha256 /tr http://timestamp.digicert.com /td sha256 /f “$env:TEMP\cert.pfx” /p “$env:PFX_PASSWORD” “engine.exe”

# クリーンアップ
Remove-Item “$env:TEMP\cert.pfx”

# 4. 署名済み成果物のアップロード

• name: Upload Artifact

uses: actions/upload-artifact@v4
with:
name: secure-engine-windows-x64
path: engine.exe

—

6. アーキテクトからの提言：誤検知ゼロの世界へ

ここまで実装を徹底すれば、Windows Defender等の主要なセキュリティソフトにおいて、自作のMinGWバイナリが「不明な発行元」や「ヒューリスティック検知」によって隔離されるリスクは劇的に低下する。

要点をまとめる。

• リソース（Version Info）なきバイナリは、セキュリティソフトにとって「顔のない不審者」である。 必ず `windres` でメタデータを埋め込め。
• ASLR（`–dynamicbase`）と DEP（`–nxcompat`）の有効化は現代の必須要件であり、これを怠るバイナリはマルウェアと判定されて当然の環境にある。
• 最終的な信頼の担保は「暗号学的署名」にしかできない。 自社で証明書を用意できない場合でも、テスト用の自己署名証明書（Self-Signed）ではなく、適切な信頼チェーンを持つ証明書運用を組織として確立すべきである。

低レイヤの仕様を理解し、コンパイラとリンカの挙動を完全に掌握したエンジニアだけが、セキュアでクリーンなソフトウェアデリバリーのパイプラインを構築できる。あなたの手元のビルドパイプラインも、今すぐこの水準へと引き上げてほしい。