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.

Available scripts

The extension have these scripts:

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

What it does:

1. •Creates workspace directory
2. •Initializes git repository for diff tracking
3. •Configures git user for commits
4. •Creates subdirectories: decompiled/, output/

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

What it does:

1. •Creates decompiled directory in workspace dir
2. •Decompiles the jar file in the dir.

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

What it does:

1. •Creates decompiled directory in workspace dir
2. •Decompiles the dll file in the dir.

• •analyze-diff.sh <workspace>

What it does:

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

Workflow Decision Tree

When a user requests patch analysis:

1. •

   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
2. •

   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
3. •

   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

Binary Identification

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

Identification Methods

1. •

   Explicit Naming:

   • •Files named patched.jar / unpatched.jar
   • •Files named vulnerable.jar / fixed.jar
   • •→ Use as specified
2. •

   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
3. •

   File Timestamps:

   bash

   ls -lt *.jar
   

   • •Newer timestamp typically indicates patched version
   • •Note: Not reliable if files were copied/moved
4. •

   When Ambiguous:

   • •ALWAYS ask the user for clarification
   • •Do not guess if there's any uncertainty

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.

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/

Extract Proprietary Code Only

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

Step 1: Decompile Unpatched Version (Proprietary Code)

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

Step 2: Commit Unpatched Version

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

CRITICAL: The unpatched tag is used by the diff analysis script.

Step 3: Decompile Patched Version

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

rm -rf <workspace>/decompiled/*

Step 4: Commit Patched Version

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

CRITICAL: The patched tag is used by the diff analysis script.

.NET Decompilation Workflow

Step 1: Decompile Unpatched Version

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

Step 2-4: Same as JAR Workflow

Follow the same git commit process as the JAR workflow:

1. •Commit unpatched with tag
2. •Clear directory
3. •Decompile patched
4. •Commit patched with tag

Diff Generation & Analysis

Generate Diff

• •Use analyze-diff.sh <workspace> to generate patch-analysis.diff and changed-files.txt list

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.

Security Analysis

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

Step 1: Filter Third-Party Libraries

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

Step 2: Analysis Process

1. •Read Every Change: Don't skip any modifications, even small ones
2. •Understand Context: Look at surrounding code, not just the diff lines
3. •Identify Security Changes: Distinguish security fixes from refactoring/features
4. •Reason About Vulnerability: What attack was possible before? What does the fix prevent?
5. •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)

Reporting Findings

Report Structure

MANDATORY: Use this structure for your analysis report:

# 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]%)

Error Messages & Solutions

"No decompiler found"

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

"Not a git repository"

Solution: Run setup-workspace.sh script first

"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