patch-diff-analyzer

パッチ差分アナライザー

重要：ユーザーから、修正された脆弱性を把握するために、コンパイル済みバイナリ（JAR、DLL など）のセキュリティパッチを分析するよう依頼される場合があります。この拡張機能は、バイナリの逆コンパイル、差分の生成、セキュリティに関連する変更の特定に役立ちます。

利用可能なスクリプト

この拡張機能には、次のスクリプトがあります。

• setup-workspace.sh <workspace-name>

実行内容：

1. ワークスペースディレクトリを作成します
2. 差分追跡用に git リポジトリを初期化します
3. コミット用に git ユーザーを設定します
4. サブディレクトリ decompiled/ と output/ を作成します

• decompile-jar.sh <app.jar> /decompiled/

実行内容：

1. ワークスペースディレクトリ内に逆コンパイル済みファイル用のディレクトリを作成します
2. そのディレクトリ内で jar ファイルを逆コンパイルします

• decompile-dll.sh <app.dll> /decompiled/

実行内容：

1. ワークスペースディレクトリ内に逆コンパイル済みファイル用のディレクトリを作成します
2. そのディレクトリ内で dll ファイルを逆コンパイルします

• analyze-diff.sh

実行内容：

1. git リポジトリに 2 件以上のコミットがあることを確認します
2. unpatched タグと patched タグを特定します（または HEAD~1 と HEAD を使用します）
3. 差分の統計情報を生成します
4. patch-analysis.diff ファイルを作成します
5. 変更されたファイルの一覧 changed-files.txt を作成します

---

ワークフローの判断ツリー

ユーザーからパッチ分析を依頼された場合：

1. バイナリの特定：パッチ適用済みか未適用かを判別する必要がありますか？

   • はい → バイナリの特定に進みます
   • いいえ → ユーザーがバージョンを指定しているため、セットアップと逆コンパイルに進みます

2. ファイル形式：どの種類のバイナリを分析しますか？

   • Java JAR → JAR 逆コンパイルのワークフローを使用します
   • .NET DLL/EXE → .NET 逆コンパイルのワークフローを使用します
   • その他 → 適切な逆コンパイラーについてユーザーに確認します

3. 分析の背景情報：ユーザーから脆弱性に関する情報が提供されていますか？

   • はい（CVE／説明あり） → 関連する変更に焦点を当てて分析します
   • いいえ（予備知識なしの分析） → セキュリティ関連の変更を包括的に分析します

---

バイナリの特定

最重要：逆コンパイルする前に、どちらのバイナリがパッチ適用済みのバージョンかを正しく特定してください。

特定方法

1. 明示的なファイル名：

   • patched.jar／unpatched.jar という名前のファイル
   • vulnerable.jar／fixed.jar という名前のファイル
   • → 指定されたとおりに使用します

2. バージョン番号：

   • app-1.2.3.jar と app-1.2.4.jar
   • → 通常、バージョン番号が大きいほうがパッチ適用済みです（1.2.4 > 1.2.3）
   • セマンティックバージョニングの形式は major.minor.patch です

3. ファイルのタイムスタンプ：

   ls -lt *.jar
   

   • 通常、新しいタイムスタンプはパッチ適用済みのバージョンを示します
   • 注：ファイルがコピーまたは移動されている場合、信頼できません

4. 判断が難しい場合：

   • 必ずユーザーに確認してください
   • 少しでも不確実な点がある場合は推測しないでください

---

セットアップと逆コンパイル

ワークスペースのセットアップスクリプト

用意されているセットアップスクリプトを使用します。

---

効率的な抽出（サードパーティライブラリを除外）

最重要：WAR ファイルや大規模なアプリケーションでは、逆コンパイルの前に独自コードのみを抽出してください。これにより、時間とストレージを大幅に節約できます。

独自コードの場所を特定する

WAR ファイルの構造：

application.war
├── WEB-INF/
│   ├── classes/          ← Application code (DECOMPILE THIS)
│   │   └── com/
│   │       └── vendor/   ← Proprietary packages
│   └── lib/              ← Third-party JARs (SKIP THESE)
│       ├── jackson-*.jar
│       ├── spring-*.jar
│       └── hibernate-*.jar
└── META-INF/

独自コードのみを抽出する

# 1. List WAR contents to identify proprietary packages
unzip -l unpatched.war | grep "WEB-INF/classes" | grep "\.class$" | head -30

# Look for company-specific packages:
# WEB-INF/classes/com/acme/
# WEB-INF/classes/com/vendor/
# WEB-INF/classes/org/internal/

# 2. Extract ONLY proprietary classes
mkdir -p temp-unpatched
unzip unpatched.war "WEB-INF/classes/com/vendor/*" -d temp-unpatched/
unzip unpatched.war "WEB-INF/classes/com/acme/*" -d temp-unpatched/

# 3. Create JAR from extracted classes
cd temp-unpatched/WEB-INF/classes
jar cf ../../../vendor-unpatched.jar .
cd ../../..

# 4. Repeat for patched version
mkdir -p temp-patched
unzip patched.war "WEB-INF/classes/com/vendor/*" -d temp-patched/
unzip patched.war "WEB-INF/classes/com/acme/*" -d temp-patched/
cd temp-patched/WEB-INF/classes
jar cf ../../../vendor-patched.jar .
cd ../../..

# Now decompile ONLY proprietary code (much faster!)

---

JAR 逆コンパイルのワークフロー

手順 1：パッチ未適用バージョンを逆コンパイルする（独自コード）

• 拡張機能に付属する JAR 逆コンパイルスクリプトを使用して、JAR を逆コンパイルします。

手順 2：パッチ未適用バージョンをコミットする

cd <workspace>
git add -A
git commit -m "Unpatched version"
git tag unpatched

最重要：差分分析スクリプトでは unpatched タグが使用されます。

手順 3：パッチ適用済みバージョンを逆コンパイルする

重要：ファイルが混在しないよう、まず逆コンパイル済みディレクトリを空にしてください。

rm -rf <workspace>/decompiled/*

手順 4：パッチ適用済みバージョンをコミットする

cd <workspace>
git add -A
git commit -m "Patched version"
git tag patched

最重要：差分分析スクリプトでは patched タグが使用されます。

---

.NET 逆コンパイルのワークフロー

手順 1：パッチ未適用バージョンを逆コンパイルする

• 拡張機能に付属する DLL 逆コンパイルスクリプトを使用して、DLL を逆コンパイルします。

ステップ 2-4：JAR ワークフローと同じ

JAR ワークフローと同じ Git コミット手順に従います。

1. パッチ未適用の状態をタグ付きでコミットする
2. ディレクトリを空にする
3. パッチ適用済みの状態を逆コンパイルする
4. パッチ適用済みの状態をタグ付きでコミットする

---

差分の生成と分析

差分を生成する

• analyze-diff.sh <workspace> を使用して、patch-analysis.diff と changed-files.txt の一覧を生成します

差分を読み取って分析する

必須：生成された差分ファイルを最後まで読みます。

grep やパターンマッチングは使用しないでください。LLM は実際のコード変更を読み取り、推論する必要があります。

---

セキュリティ分析

重要：ここでは、セキュリティの専門知識を活用して、脆弱性の修正内容を理解します。

ステップ 1：サードパーティライブラリを除外する

最初に必ず実施：変更を分析する前に、プロプライエタリなコードとサードパーティライブラリを分けます。

これが重要な理由：

• サードパーティライブラリの更新は想定されるもので、十分に文書化されています（Jackson、Spring、Hibernate など）
• プロプライエタリなコードの変更は、アプリケーション固有のセキュリティ修正を示しています
• 独自の脆弱性は、既知のライブラリの CVE よりも注目に値します
• プロプライエタリなコードに焦点を当てることで、独自の攻撃経路を明らかにできます

ステップ 2：分析プロセス

1. すべての変更を読む：小さな変更も含め、変更を一つも見落とさないでください
2. コンテキストを理解する：差分の行だけでなく、周辺のコードも確認します
3. セキュリティに関する変更を特定する：セキュリティ修正とリファクタリング／機能追加を区別します
4. 脆弱性について推論する：修正前にどのような攻撃が可能だったのか、修正によって何を防ぐのかを考えます
5. 修正の完全性を評価する：修正は包括的か、あるいは回避される可能性があるかを確認します

確認する項目

優先度の高い指標：

• これまでなかった入力検証の追加
• ユーザーが制御するデータのサニタイズ／エンコード
• 認証／認可チェックの導入
• 配列／バッファへのアクセス前の境界チェック
• 型チェックやキャストの変更
• ファイルパスの正規化
• 文字列連結をパラメーター化クエリに置き換える変更
• デシリアライズフィルターまたは許可リスト
• リソース制限（サイズ、タイムアウト、レート）

---

分析結果の報告

レポートの構成

必須：分析レポートには次の構成を使用します。

# Patch Analysis Summary

## Overview
[Brief description of what was analyzed]

## Vulnerability Identified: [Type/CVE]

**Severity**: [Critical/High/Medium/Low]

## Detailed Analysis

### File: [path/to/file.java:line-range]

[Detailed analysis following the framework above]

## Completeness Assessment

[Is the fix complete? Any potential bypasses? Additional recommendations?]

## Confidence Level

Overall confidence: [HIGH/MEDIUM/LOW] ([percentage]%)

---

エラーメッセージと解決方法

"No decompiler found"

解決方法：jadx（JAR 用）または ilspycmd（DLL 用）をインストールします

"Not a git repository"

解決方法：最初に setup-workspace.sh スクリプトを実行します

"Need at least 2 commits"

解決方法：パッチ未適用版とパッチ適用済み版の両方がコミットされていることを確認します

"No differences found"

解決方法：

• 異なるバージョンを逆コンパイルしたことを確認します
• git log を確認してコミットを確認します
• ファイルが同一である可能性があります