Patch Diff Analyzer

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:

   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.