patch-diff-analyzer

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Patch Diff Analyzer

补丁差异分析器

IMPORTANT: Users may request analysis of security patches in compiled binaries (JARs, DLLs, etc.) to understand what vulnerabilities were fixed. This extension helps decompile binaries, generate diffs, and identify security-relevant changes.

重要提示：用户可能会请求分析编译后二进制文件（JAR、DLL等）中的安全补丁，以了解修复了哪些漏洞。此扩展工具可帮助反编译二进制文件、生成差异对比并识别与安全相关的变更。

Available scripts

可用脚本

The extension have these scripts:

setup-workspace.sh
```
<workspace-name>
```

What it does:

Creates workspace directory
Initializes git repository for diff tracking
Configures git user for commits
Creates subdirectories:
```
decompiled/
```
,
```
output/
```

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

What it does:

Creates decompiled directory in workspace dir
Decompiles the jar file in the dir.

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

What it does:

Creates decompiled directory in workspace dir
Decompiles the dll file in the dir.

analyze-diff.sh <workspace>

What it does:

Verifies git repository has 2+ commits
Identifies
```
unpatched
```
and
```
patched
```
tags (or uses HEAD~1 and HEAD)
Generates diff statistics
Creates
```
patch-analysis.diff
```
file
Creates
```
changed-files.txt
```
list

该扩展工具包含以下脚本：

setup-workspace.sh
```
<workspace-name>
```

功能：

创建工作区目录
初始化git仓库用于差异追踪
配置git用户信息用于提交
创建子目录：
```
decompiled/
```
、
```
output/
```

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

功能：

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

功能：

analyze-diff.sh <workspace>

功能：

验证git仓库是否有2个及以上提交
识别
```
unpatched
```
和
```
patched
```
标签（或使用HEAD~1和HEAD）
生成差异统计信息
创建
```
patch-analysis.diff
```
文件
创建
```
changed-files.txt
```
文件列表

Workflow Decision Tree

工作流决策树

When a user requests patch analysis:

Identifying Binaries: Do you need to determine which file is patched vs unpatched?
- YES → Go to Binary Identification
- NO → User has specified versions, proceed to Setup & Decompilation
File Format: What type of binary are you analyzing?
- Java JAR → Use JAR Decompilation Workflow
- .NET DLL/EXE → Use .NET Decompilation Workflow
- Other → Consult user for appropriate decompiler
Analysis Context: Does the user provide vulnerability information?
- YES (CVE/Description provided) → Focus analysis on related changes
- NO (Blind analysis) → Perform comprehensive security change analysis

当用户请求补丁分析时：

识别二进制文件：是否需要确定哪个文件是已补丁版本 vs 未补丁版本？
- 是 → 前往二进制文件识别
- 否 → 用户已指定版本，继续设置与反编译
文件格式：正在分析的二进制文件类型是什么？
- Java JAR → 使用JAR反编译工作流
- .NET DLL/EXE → 使用.NET反编译工作流
- 其他 → 咨询用户以获取合适的反编译器
分析上下文：用户是否提供了漏洞信息？
- 是（提供了CVE/描述） → 重点分析相关变更
- 否（盲分析） → 执行全面的安全变更分析

Binary Identification

二进制文件识别

CRITICAL: Before decompilation, correctly identify which binary is the patched version.

关键：在反编译之前，正确识别哪个二进制文件是已补丁版本。

Identification Methods

识别方法

Explicit Naming:
- Files named
```
patched.jar
```
  /
```
unpatched.jar
```
- Files named
```
vulnerable.jar
```
  /
```
fixed.jar
```
- → Use as specified
Version Numbers:
- ```
app-1.2.3.jar
```
  vs
```
app-1.2.4.jar
```
- → Higher version number is typically patched (1.2.4 > 1.2.3)
- For semantic versioning: major.minor.patch format
File Timestamps:
bash
```
ls -lt *.jar
```
- Newer timestamp typically indicates patched version
- Note: Not reliable if files were copied/moved
When Ambiguous:
- ALWAYS ask the user for clarification
- Do not guess if there's any uncertainty

明确命名：
- 文件名为
```
patched.jar
```
  /
```
unpatched.jar
```
- 文件名为
```
vulnerable.jar
```
  /
```
fixed.jar
```
- → 按指定方式使用
版本号：
- ```
app-1.2.3.jar
```
  vs
```
app-1.2.4.jar
```
- → 版本号更高的通常是已补丁版本（1.2.4 > 1.2.3）
- 语义化版本格式：主版本号.次版本号.补丁版本号
文件时间戳：
bash
```
ls -lt *.jar
```
- 时间戳更新的文件通常表示已补丁版本
- 注意：如果文件被复制/移动，此方法不可靠
存在歧义时：
- 务必向用户确认
- 如有任何不确定性，请勿猜测

Setup & Decompilation

设置与反编译

Workspace Setup Script

工作区设置脚本

Use the provided setup script.

使用提供的设置脚本。

Efficient Extraction (Skip Third-Party Libraries)

高效提取（跳过第三方库）

CRITICAL: For WAR files or large applications, extract ONLY proprietary code before decompiling. This saves significant time and storage.

关键：对于WAR文件或大型应用，反编译前仅提取专有代码。这能节省大量时间和存储空间。

Identify Proprietary Code Location

识别专有代码位置

WAR file structure:

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/

WAR文件结构：

application.war
├── WEB-INF/
│   ├── classes/          ← 应用代码（需反编译此部分）
│   │   └── com/
│   │       └── vendor/   ← 专有包
│   └── lib/              ← 第三方JAR（跳过此部分）
│       ├── jackson-*.jar
│       ├── spring-*.jar
│       └── hibernate-*.jar
└── META-INF/

Extract Proprietary Code Only

仅提取专有代码

bash

undefined

bash

undefined

1. List WAR contents to identify proprietary packages

1. 列出WAR内容以识别专有包

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

2. 仅提取专有类

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

3. 从提取的类创建JAR

cd temp-unpatched/WEB-INF/classes jar cf ../../../vendor-unpatched.jar . cd ../../..

4. Repeat for patched version

4. 对已补丁版本重复上述步骤

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 Decompilation Workflow

JAR反编译工作流

Step 1: Decompile Unpatched Version (Proprietary Code)

步骤1：反编译未补丁版本（专有代码）

Use the JAR decompilation script provided with extension to decompile the JAR.

使用扩展工具提供的JAR反编译脚本反编译JAR文件。

Step 2: Commit Unpatched Version

步骤2：提交未补丁版本

bash

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

CRITICAL: The

unpatched

tag is used by the diff analysis script.

bash

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

关键：

unpatched

标签会被差异分析脚本使用。

Step 3: Decompile Patched Version

步骤3：反编译已补丁版本

IMPORTANT: Clear the decompiled directory first to avoid mixing files.

bash

rm -rf <workspace>/decompiled/*

重要提示：先清空反编译目录，避免文件混淆。

bash

rm -rf <workspace>/decompiled/*

Step 4: Commit Patched Version

步骤4：提交已补丁版本

bash

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

CRITICAL: The

patched

tag is used by the diff analysis script.

bash

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

关键：

patched

标签会被差异分析脚本使用。

.NET Decompilation Workflow

.NET反编译工作流

Step 1: Decompile Unpatched Version

步骤1：反编译未补丁版本

Use the DLL decompilation script provided with extension to decompile the DLL.

使用扩展工具提供的DLL反编译脚本反编译DLL文件。

Step 2-4: Same as JAR Workflow

步骤2-4：与JAR工作流相同

Follow the same git commit process as the JAR workflow:

Commit unpatched with tag
Clear directory
Decompile patched
Commit patched with tag

遵循与JAR工作流相同的git提交流程：

提交未补丁版本并添加标签
清空目录
反编译已补丁版本
提交已补丁版本并添加标签

Diff Generation & Analysis

差异生成与分析

Generate Diff

生成差异

Use analyze-diff.sh

<workspace>

to generate

patch-analysis.diff

and

changed-files.txt

list

使用analyze-diff.sh

<workspace>

生成

patch-analysis.diff

和

changed-files.txt

文件列表

Read and Analyze Diff

读取并分析差异

MANDATORY: Read the generated diff file completely.

DO NOT use grep or pattern matching. The LLM must read and reason about the actual code changes.

强制要求：完整读取生成的差异文件。

请勿使用grep或模式匹配。大语言模型必须读取并推理实际的代码变更。

Security Analysis

安全分析

CRITICAL: This is where you apply security expertise to understand the vulnerability fix.

关键：在此步骤中，您需要应用安全专业知识来理解漏洞修复内容。

Step 1: Filter Third-Party Libraries

步骤1：过滤第三方库

MANDATORY FIRST STEP: Before analyzing changes, separate proprietary code from third-party libraries.

Why This Matters:

Third-party library updates are expected and well-documented (Jackson, Spring, Hibernate, etc.)
Proprietary code changes indicate application-specific security fixes
Custom vulnerabilities are more interesting than known library CVEs
Focusing on proprietary code reveals unique attack vectors

强制第一步：在分析变更之前，将专有代码与第三方库分离。

重要原因：

第三方库更新是预期之内且有详细文档的（Jackson、Spring、Hibernate等）
专有代码变更表明应用特定的安全修复
自定义漏洞比已知库的CVE更值得关注
专注于专有代码可揭示独特的攻击向量

Step 2: Analysis Process

步骤2：分析流程

Read Every Change: Don't skip any modifications, even small ones
Understand Context: Look at surrounding code, not just the diff lines
Identify Security Changes: Distinguish security fixes from refactoring/features
Reason About Vulnerability: What attack was possible before? What does the fix prevent?
Assess Completeness: Is the fix comprehensive or could there be bypasses?

读取每一处变更：不要跳过任何修改，即使是微小的变更
理解上下文：查看周围的代码，而不仅仅是差异行
识别安全变更：区分安全修复与重构/功能变更
推理漏洞：修复前可能存在何种攻击？修复内容阻止了什么？
评估完整性：修复是否全面？是否存在绕过的可能性？

What to Look For

需要关注的内容

High-Priority Indicators:

Input validation added where none existed
Sanitization/encoding of user-controlled data
Authentication/authorization checks introduced
Bounds checking before array/buffer access
Type checking or casting changes
Canonicalization of file paths
Parameterized queries replacing string concatenation
Deserialization filters or whitelists
Resource limits (size, timeout, rate)

高优先级指标：

在原本没有输入验证的地方添加了输入验证
对用户可控数据进行 sanitization/编码
引入了身份验证/授权检查
在数组/缓冲区访问前添加了边界检查
类型检查或强制转换变更
文件路径规范化
使用参数化查询替代字符串拼接
反序列化过滤器或白名单
资源限制（大小、超时、速率）

Reporting Findings

报告结果

Report Structure

报告结构

MANDATORY: Use this structure for your analysis report:

markdown

undefined

强制要求：使用以下结构撰写分析报告：

markdown

undefined

Patch Analysis Summary

补丁分析摘要

Overview

概述

[Brief description of what was analyzed]

[简要描述分析内容]

Vulnerability Identified: [Type/CVE]

识别到的漏洞：[类型/CVE]

Severity: [Critical/High/Medium/Low]

严重程度：[Critical/High/Medium/Low]

Detailed Analysis

详细分析

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

文件：[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]%)

---

总体置信度：[HIGH/MEDIUM/LOW] ([百分比]%)

---

Error Messages & Solutions

错误信息与解决方案

"No decompiler found"

Solution: Install jadx (for JAR) or ilspycmd (for DLL)

解决方案：安装jadx（用于JAR）或ilspycmd（用于DLL）

"Not a git repository"

Solution: Run

setup-workspace.sh

script first

解决方案：先运行

setup-workspace.sh

脚本

"Need at least 2 commits"

Solution: Ensure both unpatched and patched versions were committed

解决方案：确保已提交未补丁和已补丁两个版本

"No differences found"

Solution:

Verify you decompiled different versions
Check
```
git log
```
to see commits
May indicate files are identical

解决方案：

验证是否反编译了不同版本
查看
```
git log
```
确认提交记录
可能表明文件完全相同