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/Konloch/bytecode-viewer 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 — Mixed signals — read the receipts

• Last commit 5w ago
• 9 active contributors
• GPL-3.0 licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 50% of recent commits
• ⚠ GPL-3.0 is copyleft — check downstream compatibility

_{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 Konloch/bytecode-viewer repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/Konloch/bytecode-viewer.

What it runs against: a local clone of Konloch/bytecode-viewer — 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 Konloch/bytecode-viewer | Confirms the artifact applies here, not a fork | | 2 | License is still GPL-3.0 | 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 ≤ 65 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of Konloch/bytecode-viewer. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/Konloch/bytecode-viewer.git
#   cd bytecode-viewer
#
# 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 Konloch/bytecode-viewer and re-run."
  exit 2
fi

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(GPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"GPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is GPL-3.0" \\
  || miss "license drift — was GPL-3.0 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 "src/main/java/the/bytecode/club/bytecodeviewer/BytecodeViewer.java" \\
  && ok "src/main/java/the/bytecode/club/bytecodeviewer/BytecodeViewer.java" \\
  || miss "missing critical file: src/main/java/the/bytecode/club/bytecodeviewer/BytecodeViewer.java"
test -f "src/main/java/the/bytecode/club/bytecodeviewer/bootloader/Boot.java" \\
  && ok "src/main/java/the/bytecode/club/bytecodeviewer/bootloader/Boot.java" \\
  || miss "missing critical file: src/main/java/the/bytecode/club/bytecodeviewer/bootloader/Boot.java"
test -f "src/main/java/the/bytecode/club/bytecodeviewer/api/ClassNodeLoader.java" \\
  && ok "src/main/java/the/bytecode/club/bytecodeviewer/api/ClassNodeLoader.java" \\
  || miss "missing critical file: src/main/java/the/bytecode/club/bytecodeviewer/api/ClassNodeLoader.java"
test -f "src/main/java/the/bytecode/club/bytecodeviewer/bootloader/resource/DataContainer.java" \\
  && ok "src/main/java/the/bytecode/club/bytecodeviewer/bootloader/resource/DataContainer.java" \\
  || miss "missing critical file: src/main/java/the/bytecode/club/bytecodeviewer/bootloader/resource/DataContainer.java"
test -f "src/main/java/the/bytecode/club/bytecodeviewer/api/Plugin.java" \\
  && ok "src/main/java/the/bytecode/club/bytecodeviewer/api/Plugin.java" \\
  || miss "missing critical file: src/main/java/the/bytecode/club/bytecodeviewer/api/Plugin.java"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 65 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~35d)"
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/Konloch/bytecode-viewer"
  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).

A software project. See architecture tab.

Developers.

See activity metrics.

Standard open source risks apply.

Check recent commits.

Check README for instructions.

• src/main/java/the/bytecode/club/bytecodeviewer/BytecodeViewer.java — Main application entry point and core UI orchestrator; every contributor must understand the initialization flow and event dispatcher.
• src/main/java/the/bytecode/club/bytecodeviewer/bootloader/Boot.java — Bootstrap loader that initializes the JVM, loads external decompilers, and manages resource extraction; critical for understanding startup sequence.
• src/main/java/the/bytecode/club/bytecodeviewer/api/ClassNodeLoader.java — Core abstraction for loading and parsing Java class bytecode; used by all decompilers and analysis tools.
• src/main/java/the/bytecode/club/bytecodeviewer/bootloader/resource/DataContainer.java — Central data model holding all loaded JAR/APK resources and class metadata; accessed across decompiler backends.
• src/main/java/the/bytecode/club/bytecodeviewer/api/Plugin.java — Plugin interface and lifecycle management; extensibility mechanism for adding custom decompilers and tools.
• pom.xml — Maven configuration for all dependencies (ASM, CFR, JD-GUI, Krakatau, apktool); essential for build reproducibility and version control.
• src/main/java/the/bytecode/club/bytecodeviewer/Configuration.java — Global configuration and settings manager; controls decompiler selection, UI themes, and runtime behaviors.

Add a New Decompiler Integration

1. Create a new decompiler class extending Plugin in src/main/java/the/bytecode/club/bytecodeviewer/api/ (src/main/java/the/bytecode/club/bytecodeviewer/api/Plugin.java)
2. Implement execute(String classPath) method to invoke your decompiler on ClassNodeLoader data (src/main/java/the/bytecode/club/bytecodeviewer/api/ClassNodeLoader.java)
3. Register the plugin in Configuration.java's decompiler list and add menu item in BytecodeViewer.java (src/main/java/the/bytecode/club/bytecodeviewer/Configuration.java)
4. Add external decompiler JAR as a library dependency in pom.xml (pom.xml)

Add a Custom Analysis Tool or String Decrypter

1. Create a new plugin class in plugins/java/ extending Plugin, or use a scripting language (JavaScript, Groovy, Python, Ruby) (plugins/java/ExampleStringDecrypter.java)
2. Access loaded classes via BCV.getBcvInstance().getWorkspace().getDataContainer() (src/main/java/the/bytecode/club/bytecodeviewer/api/BCV.java)
3. Use ASMUtil and ASMResourceUtil to walk class trees and analyze bytecode instructions (src/main/java/the/bytecode/club/bytecodeviewer/api/ASMUtil.java)
4. Write results to the plugin console via PluginConsole.addMessage() (src/main/java/the/bytecode/club/bytecodeviewer/api/PluginConsole.java)

Add a New UI Tab or Viewer Panel

1. Create a JPanel subclass that listens to ClassTree selection events in BytecodeViewer (src/main/java/the/bytecode/club/bytecodeviewer/BytecodeViewer.java)
2. Register the panel in BytecodeViewer.java's initComponents() method and add it to the tabbed pane (src/main/java/the/bytecode/club/bytecodeviewer/BytecodeViewer.java)
3. Access the selected class via DataContainer.getResources() and render using ASMResourceUtil visitors (src/main/java/the/bytecode/club/bytecodeviewer/bootloader/resource/DataContainer.java)
4. For hex/binary viewing, integrate with bined library (already in pom.xml dependencies) (pom.xml)

Support a New Archive Format (APK, XAPK, etc.)

1. Create a new ILoader implementation in src/main/java/the/bytecode/club/bytecodeviewer/bootloader/loader/ (src/main/java/the/bytecode/club/bytecodeviewer/bootloader/loader/ILoader.java)
2. Implement extractClasses() to parse the archive format and populate ClassNode objects (src/main/java/the/bytecode/club/bytecodeviewer/api/ClassNodeLoader.java)
3. Register the new loader in LoaderFactory.getLoader() based on file extension (src/main/java/the/bytecode/club/bytecodeviewer/bootloader/loader/LoaderFactory.java)
4. Add external archive parsing library to pom.xml (e.g., apktool, enjarify) (pom.xml)

Standard debugging applies.

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.

Add unit tests for decompiler integration (CFR, JD-GUI, Fernflower, Krakatau)

The repo integrates multiple decompilers (CFR 0.152, JD-GUI 1.6.6bcv, Fernflower, Krakatau) but there's no visible test suite for decompiler execution or output validation. Given that decompilers are core functionality and version updates are frequent (ASM 9.9.1, CFR, etc.), unit tests would catch regressions. This is especially critical since CVE-2022-21675 was patched—decompiler output validation tests would prevent similar security issues.

• [ ] Create src/test/java/the/bytecode/club/bytecodeviewer/decompiler/ directory
• [ ] Add DecompilerIntegrationTest.java to test CFR, JD-GUI, and Fernflower with sample bytecode
• [ ] Add DecompilerOutputValidationTest.java to verify decompiled output is syntactically valid Java
• [ ] Add tests for dex2jar (2.4.34) and Krakatau integration with sample APKs
• [ ] Update pom.xml with JUnit 5 and test dependencies (likely missing)
• [ ] Reference test samples in src/test/resources/

Add Maven shade plugin configuration for consistent JAR distribution

The pom.xml shows 30+ dependencies (ASM, CFR, Apktool, Guava, Commons libraries, etc.) across different Maven repositories (./libs/eu/bibl, ./libs/org/jd). There's no visible shade/assembly plugin configuration to bundle all dependencies into a single executable JAR, which likely complicates distribution. The install/ directory scripts (jar2exe_config.j2e, launch4j_config.xml) suggest manual JAR assembly. A proper Maven shade config would streamline builds and reduce distribution friction for Windows/Linux users.

• [ ] Add maven-shade-plugin configuration to pom.xml with proper transformers for service files (asm, commons-*)
• [ ] Configure finalName as 'bytecode-viewer-${version}-all.jar'
• [ ] Add maven-assembly-plugin as fallback with descriptor for distribution package
• [ ] Update .github/workflows/maven.yml to build and attach shaded JAR to releases
• [ ] Test that launch4j_config.xml and jar2exe can consume the output JAR without modification
• [ ] Document the new JAR build process in CONTRIBUTING.md

Add comprehensive GitHub Actions workflow for cross-platform testing and releases

The .github/workflows/maven.yml exists but the repo has complex native dependencies (Krakatau, enjarify, Apktool) and targets Java 8+ across Windows/Linux/macOS. There's no visible test matrix workflow to catch platform-specific issues (e.g., APK parsing on Windows vs Linux, bytecode editing with different JVMs). Given the install scripts for Windows (.bat files) and the project's maturity, a complete CI/CD pipeline would improve release quality and catch regressions before publication.

• [ ] Expand .github/workflows/maven.yml with matrix strategy: [ubuntu-latest, windows-latest, macos-latest] × [Java 8, 11, 17, 21]
• [ ] Add test job that runs unit tests (from PR #1) across all matrix combinations
• [ ] Add smoke-test job: load sample JARs/APKs, run decompilers, verify no exceptions
• [ ] Add code-quality job: run checkstyle (checkstyle.xml exists) and fail on violations
• [ ] Add release job: on tag, build shaded JAR (from PR #2), create GH release with multi-platform JARs
• [ ] Document CI/CD status and setup in README.md's 'Building from Source' section

Check the issue tracker.

• High · Outdated and Vulnerable ASM Dependency — pom.xml - asm.version property (9.9.1). ASM version 9.9.1 is used, but this version may contain known vulnerabilities. ASM is a critical bytecode manipulation library used in this decompiler. Check CVE databases for reported issues in this specific version. Fix: Update to the latest stable version of ASM and review security advisories. Verify compatibility with Java 8+ target.
• High · Incomplete Dependency Version in pom.xml — pom.xml - httprequest.version property. The httprequest dependency version is truncated/incomplete in pom.xml (httprequest.version>2.2.0</httprequest is cut off). This makes it impossible to determine if the correct version is being used and may indicate a build configuration issue. Fix: Complete the pom.xml configuration with the full httprequest dependency version string and verify all dependencies are properly defined.
• Medium · Outdated Commons Compress Library — pom.xml - commons-compress.version (1.28.0). Commons Compress 1.28.0 is used. While relatively recent, this is a library frequently targeted for deserialization and zip slip vulnerabilities. Historical versions have had security issues. Fix: Monitor Apache Commons Compress security advisories and ensure the latest patch version is used. Test zip file handling thoroughly.
• Medium · Plugin System with External Code Execution — plugins/ directory and src/main/java/the/bytecode/club/bytecodeviewer/api/Plugin.java. The codebase supports multiple plugin types (Java, Groovy, JavaScript, Python, Ruby) loaded at runtime. This creates significant attack surface if plugins are loaded from untrusted sources, potentially allowing arbitrary code execution. Fix: Implement plugin signing/verification, run plugins in restricted sandboxes, validate plugin sources, and document security implications of loading external plugins.
• Medium · Dynamic Code Compilation in ClassParser Plugin — plugins/java/ClassParser.java. The ClassParser.java plugin (plugins/java/ClassParser.java) suggests dynamic compilation of user-provided bytecode. This could lead to arbitrary code execution if not properly sandboxed. Fix: Ensure any bytecode compilation is isolated in a separate process with restricted permissions. Validate inputs before compilation and log compilation attempts.
• Medium · Dependency on Modified/Custom Libraries — libs/ directory structure with custom Maven repository. The libs directory contains custom-built or modified versions of dependencies (byteanalysis-1.0bcv.jar, jd-gui-1.6.6bcv.jar with 'bcv' suffix). These custom builds are not from official repositories and their security status is unclear. Fix: Document why custom library versions are necessary, ensure they are version-controlled with source code, perform security audits of modifications, and consider contributing upstream.
• Medium · Missing Input Validation in Decompiler Operations — src/main/java/the/bytecode/club/bytecodeviewer/ - resource loading and decompiler integration. The codebase processes untrusted APK and JAR files with multiple decompilers (CFR, JD-GUI, Fernflower, Krakatau). Malformed files could trigger buffer overflows, denial of service, or other exploits in decompiler code. Fix: Implement file format validation before processing, run decompilers in isolated processes, set resource limits (memory, time), and handle decompiler errors gracefully.
• Low · Verbose Error Messages and Exception Handling — src/main/java/the/bytecode/club/bytecodeviewer/api/ExceptionUI.java. ExceptionUI.java suggests detailed exception messages are displayed to users. This could leak internal implementation details or file paths to attackers. Fix: Implement user-friendly error messages for the UI while logging detailed errors server-side. Avoid exposing file paths, stack traces, or internal component names to end users.
• Low · Insecure Update Check Mechanism — undefined. UpdateCheck.java is present in the bootloader. If update checks use HTTP instead of HTTPS 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.