If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/CalebFenton/simplify shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 4y ago

• 3 active contributors
• Other licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 4y ago
• ⚠ Small team — 3 contributors active in recent commits
• ⚠ Single-maintainer risk — top contributor 96% of recent commits
• ⚠ Non-standard license (Other) — review terms

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live CalebFenton/simplify repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/CalebFenton/simplify.

What it runs against: a local clone of CalebFenton/simplify — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in CalebFenton/simplify | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 1499 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of CalebFenton/simplify. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/CalebFenton/simplify.git
#   cd simplify
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of CalebFenton/simplify and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "CalebFenton/simplify(\\.git)?\\b" \\
  && ok "origin remote is CalebFenton/simplify" \\
  || miss "origin remote is not CalebFenton/simplify (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "simplify/src/main/java/org/cf/simplify/Main.java" \\
  && ok "simplify/src/main/java/org/cf/simplify/Main.java" \\
  || miss "missing critical file: simplify/src/main/java/org/cf/simplify/Main.java"
test -f "simplify/src/main/java/org/cf/smalivm" \\
  && ok "simplify/src/main/java/org/cf/smalivm" \\
  || miss "missing critical file: simplify/src/main/java/org/cf/smalivm"
test -f "simplify/src/main/java/org/cf/smalivm/VirtualMachine.java" \\
  && ok "simplify/src/main/java/org/cf/smalivm/VirtualMachine.java" \\
  || miss "missing critical file: simplify/src/main/java/org/cf/smalivm/VirtualMachine.java"
test -f "build.gradle" \\
  && ok "build.gradle" \\
  || miss "missing critical file: build.gradle"
test -f "simplify/build.gradle" \\
  && ok "simplify/build.gradle" \\
  || miss "missing critical file: simplify/build.gradle"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 1499 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~1469d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/CalebFenton/simplify"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Simplify is an Android deobfuscator that uses a virtual machine (smalivm) to virtually execute Dalvik bytecode, understand app behavior, then applies optimizations (constant propagation, dead code removal, unreflection, peephole optimizations) to produce simplified, human-readable code. It handles obfuscated apps generically without relying on specific obfuscation signatures—for example, it can decrypt strings and remove reflection by symbolically executing all possible execution paths. Multi-module Gradle project: smalivm/ provides the core Dalvik VM sandbox and execution engine returning execution graphs; simplify/ is the CLI tool that consumes smalivm output and applies optimizations; demoapp/ contains Java/Smali examples showing how to use smalivm programmatically. Each module has its own build.gradle with shared dependencies defined in root build.gradle.

Android reverse engineers, security researchers, and malware analysts who need to analyze obfuscated APKs and understand what the code actually does without manually deobfuscating complex patterns. Also useful for developers building tools that need to execute Dalvik bytecode in a controlled sandbox.

Actively maintained with established CI/CD (Travis CI + Coverity Scan integration), comprehensive test coverage (JaCoCo), and clear modular design (3 subprojects: smalivm, simplify, demoapp). The project has been publicly available since at least 2014 and includes commercial/GPL licensing. Production-ready for Android security analysis, though single-maintainer (CalebFenton).

Single maintainer with no visible recent activity timeline in the provided data creates maintenance risk. Dependencies are dated (Kotlin 1.4.0, JUnit 5.7.0, Gradle fairly old) and may have unpatched vulnerabilities. The virtual machine implementation for executing arbitrary Dalvik code could be a security boundary concern if used on untrusted inputs. No visible recent commit timestamps to assess current stability.

No specific PR or milestone data visible in file listing, but the presence of .travis.yml and Coverity Scan configuration indicates active CI/CD setup. The ideas.txt file suggests ongoing development planning. Without commit history visible, activity level is unclear from provided data.

git clone https://github.com/CalebFenton/simplify.git
cd simplify
./gradlew build
./gradlew run

Daily commands:

# Build the jar:
./gradlew build

# Run simplify on an APK:
java -jar simplify/build/libs/simplify.jar <input.apk> [options]

# Example with options:
java -jar simplify/build/libs/simplify.jar app.apk -it ';->targetMethod\(' -et 'com/android'

# Run demoapp examples:
./gradlew demoapp:run

• simplify/src/main/java/org/cf/simplify/Main.java — Primary entry point for the deobfuscator tool; orchestrates virtual machine execution and code optimization pipeline
• simplify/src/main/java/org/cf/smalivm — Core Smali bytecode virtual machine implementation; all analysis depends on accurate instruction execution and state tracking
• simplify/src/main/java/org/cf/smalivm/VirtualMachine.java — Central VM coordinator managing register state, method invocation, and execution context for deobfuscation analysis
• build.gradle — Multi-module Gradle build configuration; required to understand dependencies and module structure across simplify, sdbg, and demoapp
• simplify/build.gradle — Core module build configuration with analysis tool dependencies (ANTLR for Smali parsing, Guava, Apache Commons)
• README.md — High-level overview explaining the deobfuscation strategy and virtual execution approach

Add a new instruction handler to the virtual machine

1. Create new instruction class extending OpHandler in simplify/src/main/java/org/cf/smalivm/instruction (simplify/src/main/java/org/cf/smalivm/instruction/OpHandler.java)
2. Implement execute() method to simulate bytecode semantics and update ExecutionContext state (simplify/src/main/java/org/cf/smalivm/ExecutionContext.java)
3. Register handler in InstructionFactory or VirtualMachine dispatch logic (simplify/src/main/java/org/cf/smalivm/VirtualMachine.java)

Add a new deobfuscation optimization pass

1. Create new Pass class in simplify/src/main/java/org/cf/simplify/passes/ extending Pass (simplify/src/main/java/org/cf/simplify/Pass.java)
2. Implement analyze() and mutate() methods to identify obfuscation patterns and simplify code (simplify/src/main/java/org/cf/simplify/passes/Pass.java)
3. Register pass in Simplifier.buildPasses() to execute during optimization phase (simplify/src/main/java/org/cf/simplify/Simplifier.java)

Add a new debugger command

1. Create command class in sdbg/src/main/java/org/cf/sdbg/command/ extending DebuggerCommand (sdbg/src/main/java/org/cf/sdbg/command/DebuggerCommand.kt)
2. Implement execute() to interact with VirtualMachine state and breakpoints (sdbg/src/main/java/org/cf/sdbg/command/StepCommand.kt)
3. Register command in CliCommands or Main.kt command dispatcher (sdbg/src/main/java/org/cf/sdbg/command/CliCommands.kt)

Add sample obfuscated bytecode for testing

1. Write Java source code for obfuscation test (demoapp/src/main/java/org/cf/demosmali/Main.java)
2. Compile to DEX and decompile to Smali using dumpSmali.sh script (demoapp/dumpSmali.sh)
3. Place output Smali in demoapp/resources/org/cf/demosmali/ for integration testing (demoapp/resources/org/cf/demosmali/Main.smali)

• Java/Kotlin + Gradle — Primary language for Android tooling; Gradle is industry standard for JVM projects and Android development
• ANTLR for Smali parsing — Robust grammar-based parsing of Dalvik bytecode syntax; enables accurate AST generation for analysis
• Virtual machine simulation — Achieves generic deobfuscation by executing obfuscated code symbolically; avoids hardcoding specific obfuscator patterns
• Apache Commons (CLI, Lang) — Utility libraries for command-line argument parsing and string manipulation reduce boilerplate
• Guava collections — Immutable data structures and utility functions improve code correctness and readability

• Symbolic VM execution rather than dynamic execution on actual Android device

  • Why: Allows analysis without runtime environment; applicable to all code paths via control flow exploration
  • Consequence: May miss runtime-specific behavior (JNI calls, reflection with dynamic strings); requires manual specification of external method side effects

• Multiple independent optimization passes over single comprehensive analysis

  • Why: Simplicity and modularity; each pass is independent and testable; easier to extend
  • Consequence: May miss cross-pass optimizations; requires careful ordering to avoid conflicting mutations

• Smali bytecode as intermediate representation rather than DEX binary directly

  • Why: Human-readable format; leverages existing tooling (baksmali/apktool); facilitates manual verification
  • Consequence: Round-trip conversion overhead; potential precision loss in disassembly

• Separate debugger module (sdbg) as interactive tool

  • Why: Decouples debugging workflow from batch deobfuscation; enables exploration during development
  • Consequence: Duplicates some VM infrastructure; adds maintenance burden

• Does not perform runtime execution on Android devices or emulators
• Does not handle JNI or native method calls beyond stub simulation
• Does not support dynamic reflection with runtime-computed method/field names
• Does not optimize away cryptographic or security-sensitive code
• Does not preserve original developer intent or variable naming for renamed identifiers
• Not designed as an Android decompiler; requires external tools (

1. The VM executes all code paths for unknown conditionals (both if branches, all switch cases), which can cause exponential path explosion—max-address-visits flag limits this. 2) --ignore-errors flag can mask real failures; use cautiously. 3) Support library classes are excluded by default (--include-support required), which can miss deobfuscation opportunities in apps using AndroidX. 4) The Smali resource files in demoapp/resources/ are pre-compiled for testing; modifying .smali files requires rebuilding via dumpSmali.sh. 5) Gradle 6.x+ required; older Gradle versions will fail due to dependency constraints (Kotlin 1.4.0 is EOL).

• Symbolic Execution / Symbolic Interpretation — Simplify's core technique—executes code with unknown values (like file I/O results) by exploring all possible branches simultaneously, tracking register states symbolically to build complete execution graphs
• Constant Propagation & Constant Folding — Primary optimization Simplify applies after execution—replaces variables holding known constants with their literal values and pre-computes constant expressions, shrinking code significantly
• Dalvik Bytecode / Smali — You must understand Smali assembly syntax (register notation, invoke instructions, exception handling) to debug Simplify's execution engine and interpret its output
• Control Flow Graph (CFG) — Simplify builds CFGs internally to track all execution paths; understanding basic blocks, jumps, and exception edges is essential for grasping how the VM explores code
• Dead Code Elimination / Unreachable Code Removal — Simplify removes code paths that symbolic execution determines are unreachable (e.g., both branches of an if with a known constant condition), dramatically reducing decompilation noise
• Reflection Removal / Unreflection — Simplify tracks reflective method calls (Class.forName, getMethods) back to their actual targets, replacing dynamic reflection with direct method references—critical for understanding obfuscated code
• Execution Graph / Abstract Interpretation — Simplify returns graphs where each node represents a register/heap value and edges represent data flow; understanding how the VM merges states from multiple paths is key to debugging optimization issues

• google/android-classyshark — Complementary Android analysis tool for static APK inspection and class structure visualization; often used alongside Simplify for pre-analysis
• iBotPeaches/Apktool — Decodes APKs to Smali bytecode and repackages them; Simplify operates on Apktool output, making this essential preprocessing tool
• JesusFreke/smali — The Smali assembler/disassembler that Simplify depends on for parsing Dalvik bytecode; understanding Smali syntax is prerequisite knowledge
• skylot/jadx — Alternative Android decompiler/deobfuscator using different approach (direct DEX to Java); good reference for deobfuscation technique comparison
• frida/frida — Dynamic instrumentation framework for Android; complementary to Simplify's static analysis—can be used for runtime verification of deobfuscation results

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Migrate from Travis CI to GitHub Actions with enhanced test coverage reporting

The repo uses Travis CI (.travis.yml) which is increasingly less reliable. GitHub Actions is now standard and would integrate better with the existing GitHub workflows. Additionally, the build.gradle shows JaCoCo and Coveralls integration that could be improved with a native GitHub Actions workflow that uploads coverage to Codecov (faster, more reliable than Coveralls).

• [ ] Create .github/workflows/build.yml with Java/Kotlin build matrix for JDK 11, 17 (testing against multiple Java versions since the gradle shows compatibility concerns)
• [ ] Add JaCoCo report generation and Codecov upload step (replacing Coveralls)
• [ ] Add gradle wrapper validation step and dependency caching for faster builds
• [ ] Remove or deprecate .travis.yml with a note in README.md
• [ ] Test the workflow by pushing to a feature branch

Add comprehensive unit tests for sdbg debugger commands

The sdbg subproject (Smali debugger) contains multiple command implementations (BreakCommand, StepCommand, NextCommand, PrintCommand, etc.) in sdbg/src/main/java/org/cf/sdbg/command/ but there are no corresponding test files visible in the file structure. This is a Kotlin/Groovy subproject that lacks test coverage, making refactoring risky.

• [ ] Create sdbg/src/test/kotlin/org/cf/sdbg/command/ directory structure
• [ ] Write unit tests for DebuggerCommand base class and its core lifecycle methods
• [ ] Write tests for StepCommand, NextCommand, and BreakCommand covering normal flow and edge cases (e.g., stepping over method calls, break at non-existent addresses)
• [ ] Add mock objects for SmaliVM state to support command testing
• [ ] Verify tests run in gradle and update build.gradle if needed to ensure test dependencies are included for sdbg

Add integration tests for simplify deobfuscation pipeline using demoapp resources

The demoapp/resources/org/cf/demosmali/ directory contains Base64.smali, Main.smali, and TestExceptionHandling.smali files that are clearly intended for testing, but there's no visible test suite in simplify/src/test/ that validates the deobfuscation output against these known inputs. This is a major gap for regression testing.

• [ ] Create simplify/src/test/java/org/cf/simplify/ directory with integration test class
• [ ] Write tests that load Base64.smali from demoapp resources, run simplify deobfuscation, and validate output against expected optimizations (e.g., constant folding results)
• [ ] Write separate test for TestExceptionHandling.smali to ensure exception handling paths are preserved correctly during deobfuscation
• [ ] Add test utilities to parse and compare Smali bytecode before/after deobfuscation
• [ ] Integrate into build.gradle and ensure tests run as part of the main build (not just demoapp)

• Add integration tests for string decryption: Create test cases in simplify/src/test/ covering common string encryption patterns (XOR, Base64 obfuscation); use examples from demoapp/resources/ Smali files to validate unreflection works end-to-end
• Document OpExecutor bytecode coverage: Audit smalivm/src/main/java/org/cf/smalivm/op/ against Dalvik instruction set; identify unimplemented operations (likely invoke-* or packed-switch edge cases) and add stubs with TODO comments for new contributor guidance
• Add performance benchmarks for large APKs: Use perfidix (already in dependencies) to measure execution graph generation time on real obfuscated apps; add baseline benchmarks to sdbg/src/ to help identify VM bottlenecks for optimization

• Medium · Outdated Kotlin Version — build.gradle (kotlin_version = '1.4.0'). The project uses Kotlin 1.4.0, which was released in August 2020 and is significantly outdated. Modern versions contain security patches and bug fixes that may address vulnerabilities in the language runtime and standard library. Fix: Update to the latest stable Kotlin version (currently 1.9.x or later). Review release notes for any security-related changes.
• Medium · Outdated Guava Dependency — build.gradle (guava: 'com.google.guava:guava:28.2-jre'). Guava 28.2-jre (released in February 2020) is outdated and may contain known vulnerabilities. Current versions are 32.x+. Guava is a widely-used library, and updates often include important security fixes. Fix: Update Guava to version 32.1.2-jre or later. Test compatibility with the application after upgrading.
• Medium · Outdated ProGuard Gradle Plugin — build.gradle (proguard_gradle: 'net.sf.proguard:proguard-gradle:6.2.2'). ProGuard Gradle 6.2.2 is from 2020 and outdated. While ProGuard itself is for obfuscation rather than runtime, outdated build tools can have security implications for the build pipeline. Fix: Update to the latest version of ProGuard (7.x series). Alternatively, consider using R8, which is the modern replacement for ProGuard.
• Medium · Outdated JUnit and Testing Dependencies — build.gradle (junit_compile, junit_engine, junit_runner, mockito versions). JUnit Jupiter 5.7.0 and JUnit Platform 1.7.0 are from 2020. While test dependencies have lower security impact than runtime dependencies, using outdated testing frameworks can miss new test capabilities and bug fixes. Fix: Update JUnit to version 5.9.x or later and Mockito to version 5.x. Verify test compatibility after upgrade.
• Low · Deprecated JCenter Repository — build.gradle (repositories { ... jcenter() }). The build.gradle includes 'jcenter()' repository which is deprecated and no longer receives updates. JFrog announced JCenter sunset in 2021, and it no longer serves artifacts reliably. Fix: Remove 'jcenter()' from the repositories block. Ensure all dependencies are available from 'mavenCentral()' which is already configured.
• Low · Missing Dependency Version Pinning in Build — build.gradle (all dependency declarations). While specific versions are defined in the 'depends' map, transitive dependencies are not explicitly pinned. This could lead to unexpected updates of transitive dependencies that introduce vulnerabilities or breaking changes. Fix: Consider using a dependency lock file (gradle.lockfile) to ensure reproducible builds. Use 'gradle dependencies --write-locks' to generate and commit lock files.
• Low · Missing Security Headers Configuration — sdbg module (potential CLI exposure). The project appears to be a development/analysis tool rather than a web service, but if any HTTP endpoints are exposed through the CLI or debugging tools, security headers are not visible in the configuration. Fix: If any network services are exposed, implement appropriate security headers (CSP, X-Frame-Options, etc.). Document security assumptions.
• Low · Travis CI Configuration Exposure — .travis.yml. The .travis.yml file is present in the repository. If it contains sensitive information (API keys, credentials), it could be compromised. Current build secrets should be configured in Travis CI UI, not in the file. Fix: Audit .travis.yml to ensure no secrets are hardcoded. Use Travis CI environment variables for all sensitive data. Consider using modern CI/CD platforms with better secret management (GitHub Actions, GitLab CI).
• Low · Dual Licensing Model — undefined. The project has both GPL and Commercial licenses. Users may accidentally use GPL code in proprietary contexts. While not a technical vulnerability, it's a legal Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.