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/avast/retdec 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.

GO — Healthy across all four use cases

• Last commit 10mo ago
• 11 active contributors
• Distributed ownership (top contributor 30% of recent commits)
• MIT licensed
• CI configured
• ⚠ Slowing — last commit 10mo ago
• ⚠ No test directory detected

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

What it runs against: a local clone of avast/retdec — 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 avast/retdec | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | 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 ≤ 340 days ago | Catches sudden abandonment since generation |

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT 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 "CMakeLists.txt" \\
  && ok "CMakeLists.txt" \\
  || miss "missing critical file: CMakeLists.txt"
test -f "cmake/deps.cmake" \\
  && ok "cmake/deps.cmake" \\
  || miss "missing critical file: cmake/deps.cmake"
test -f ".github/workflows/retdec-ci.yml" \\
  && ok ".github/workflows/retdec-ci.yml" \\
  || miss "missing critical file: .github/workflows/retdec-ci.yml"
test -f "deps/capstone/CMakeLists.txt" \\
  && ok "deps/capstone/CMakeLists.txt" \\
  || miss "missing critical file: deps/capstone/CMakeLists.txt"
test -f "deps/eigen/Eigen/Core" \\
  && ok "deps/eigen/Eigen/Core" \\
  || miss "missing critical file: deps/eigen/Eigen/Core"

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

RetDec is a retargetable LLVM-based decompiler that transforms machine code (x86, ARM, MIPS, PowerPC, ARM64) across multiple binary formats (ELF, PE, Mach-O, COFF, Intel HEX) into high-level C or Python-like code. It performs static analysis including compiler/packer detection, DWARF/PDB debugging info extraction, C++ RTTI reconstruction, and symbol demangling to reverse-engineer stripped or optimized binaries. Single monolith structure: CMakeLists.txt orchestrates a unified build; deps/ contains vendored libraries (authenticode-parser in C); core decompiler logic sits in unnamed subdirectories (not shown in top 60, but inferred to be substantial). CI is multi-platform via .github/workflows with platform-specific scripts (install-deps.sh, prepare-clang.sh, run-tests.sh) for Linux, Windows, and macOS.

Reverse engineers, malware analysts, and security researchers who need to decompile proprietary or unknown binaries without source code. Also used by security teams performing vulnerability assessment and by researchers studying binary obfuscation and compiler behavior.

Mature but in limited maintenance mode (per README). The project has substantial C++ codebase (14M+ lines), multi-platform CI via GitHub Actions (.github/workflows for Linux/Windows/macOS), and established release artifacts. However, the team explicitly states PRs are prioritized but issues face 1-quarter delays and minimal new development—active maintenance only, no active expansion.

Maintenance risk is high: the project is in 'limited maintenance mode' with acknowledged resource constraints and slow issue resolution. Dependency risk is moderate—builds against LLVM (external, evolving) and custom authenticode-parser (embedded in deps/). No recent snapshot of commit frequency visible in the file listing, and the SECURITY.md file's existence suggests known vulnerability handling but the specific process is opaque from this data.

Active maintenance of existing functionality: CI pipelines are live (retdec-ci.yml, retdec-release.yml), and the team accepts PRs with priority. However, no major feature development is visible—efforts are focused on keeping builds passing across Linux/macOS/Windows and maintaining test suites (ignore_Debug, ignore_Release files suggest test filtering per build type).

Clone and build: git clone https://github.com/avast/retdec.git && cd retdec && mkdir build && cd build && cmake .. && make. Dependency installation is platform-specific: run .github/workflows/Linux/install-deps.sh (or Windows/macOS equivalent), then .github/workflows/Linux/prepare-clang.sh, then build. Pre-built releases are available at https://github.com/avast/retdec/releases as an alternative.

Daily commands: Build via CMake: cd build && cmake .. && make. Tests are run via .github/workflows/Linux/run-tests.sh (or platform equivalent). No traditional 'dev server'—RetDec is a batch decompiler. Run decompiled output via retdec-bin <binary> -o <output.c>.

• CMakeLists.txt — Root build configuration defining the entire project structure, dependencies, and compilation targets for RetDec across all platforms.
• cmake/deps.cmake — Manages external dependencies (LLVM, Capstone, Eigen, authenticode-parser) critical to the decompiler's functionality.
• .github/workflows/retdec-ci.yml — Defines CI/CD pipeline for Linux, Windows, and macOS builds; essential for understanding the automated test and release workflow.
• deps/capstone/CMakeLists.txt — Capstone disassembler integration—core to machine-code analysis, required for all decompilation pipelines.
• deps/eigen/Eigen/Core — Eigen matrix library integration used for numerical computations in decompilation algorithms.
• README.md — Project overview, architecture rationale, and maintenance status critical for onboarding and contribution guidelines.
• CHANGELOG.md — Historical record of changes, architectural decisions, and deprecated features for understanding project evolution.

• File Loader (Format-specific parsers, authenticode-parser for PE validation) — Detects and parses binary file formats (ELF, PE, Mach-O, COFF, AR); extracts sections, symbols, and metadata
  • Failure mode: Corrupted or unsupported binary format causes analysis abort; symbol table missing leads to degraded decompilation quality
• Capstone Disassembler (Capstone engine with architecture plugins) — Decodes machine instructions to mnemonics; performs instruction-level analysis across multiple ISAs
  • Failure mode: Incorrect instruction decoding produces malformed IR; unsupported instruction causes exception
• LLVM IR Generator (LLVM API, Eigen for numeric analysis) — Translates disassembled instructions to LLVM IR; performs type inference, CFG construction, and semantic analysis
  • Failure mode: Type inference errors propagate through decompilation; infinite loops in CFG cause analyzer hang
• Decompiler Engine (LLVM passes, custom pattern matching) — Converts LLVM IR to C pseudocode; applies optimizations, variable renaming, and code simplification
  • Failure mode: Overly aggressive optimization loses semantic meaning; failed renaming heuristic produces unreadable output
• Output Formatter (clang-format integration, file I/O) — Serializes decompiled code to C source files with proper formatting and comments
  • Failure mode: Encoding issues with special characters; file permissions prevent output write

• User Input (binary file path) → File Loader — Binary executable provided as CLI argument
• File Loader → Capstone Disassembler — Extracted code sections and entrypoints
• Capstone Disassembler → LLVM IR Generator — Decoded instructions with operands and

Add Support for a New File Format

1. Create format parser in a new directory under the appropriate layer (e.g., src/fileformat/parsers/) (CMakeLists.txt)
2. Register the new format parser in the loader factory (cmake/deps.cmake)
3. Add integration tests in tests/retdectests/ for the new format (.github/workflows/retdec-ci.yml)
4. Update CHANGELOG.md with the new format support (CHANGELOG.md)

Integrate a New Disassembly Backend

1. Create wrapper module in src/backend/ for the new disassembler (CMakeLists.txt)
2. Add dependency declaration and CMake configuration (cmake/deps.cmake)
3. Implement disassembly interface matching Capstone abstraction (cmake/options.cmake)
4. Add CI test matrix entries for the new backend (.github/workflows/retdec-ci.yml)

Add a New Platform/Architecture Target

1. Define architecture triplet and ABI constants (cmake/options.cmake)
2. Create platform-specific build configuration (CMakeLists.txt)
3. Add workflow for new platform in .github/workflows/ (.github/workflows/retdec-ci.yml)
4. Update README.md with new platform in supported list (README.md)

• LLVM — Provides retargetable IR and optimization infrastructure, enabling architecture-agnostic decompilation across x86, ARM, MIPS, etc.
• Capstone — Industry-standard disassembly engine supporting 15+ architectures with consistent instruction decoding API.
• Eigen — High-performance matrix library for numerical analysis in type inference and program analysis algorithms.
• CMake — Cross-platform build system essential for supporting Linux, Windows, and macOS with unified configuration.

• Limited maintenance mode

  • Why: Resource constraints prioritize core functionality and bug fixes over new feature development.
  • Consequence: Feature requests and issues have delayed responses; community contributions become critical for feature additions.

• Retargetable architecture based on LLVM IR

  • Why: Enables support for multiple architectures and instruction sets from a single codebase.
  • Consequence: Higher complexity in the core decompilation engine; architectural changes require broader testing across all targets.

• Support multiple file formats (ELF, PE, Mach-O, COFF, AR)

  • Why: Provides cross-platform and cross-OS compatibility essential for reverse engineering.
  • Consequence: Increased codebase complexity; each format parser must be maintained and tested independently.

• Real-time decompilation or interactive debugging—RetDec performs offline batch analysis
• Decompilation to languages other than C/pseudocode—focused on C output as primary target
• Obfuscation removal or de-obfuscation strategies—decompiler operates on binary as-is
• Source-level debugging integration—produces static analysis output, not a runtime debugger

LLVM version pinning: deps.cmake locks a specific LLVM major version; mismatching breaks the build silently. Platform-specific quirks: .github/workflows/{Linux,Windows,macOS} have distinct install-deps.sh scripts—build on one platform, then try another, and you'll miss critical deps. Test filtering: ignore_Debug and ignore_Release files suggest certain tests are skipped per build type; running tests locally requires knowing which to skip. Authenticode parser is C-based in a C++ codebase; integration points are non-obvious. No Docker setup in the top 60 (but Dockerfile and Dockerfile.dev exist)—check if you need containerized builds for reproducibility.

• Intermediate Representation (IR) — RetDec uses LLVM IR as the common abstraction layer to support multiple source architectures and target languages; understanding IR is essential to modify decoders or code generators
• Signature-Based Library Stripping — RetDec uses YARA patterns to identify and remove statically linked library code before decompilation; this is critical for reducing noise in malware analysis
• DWARF and PDB Debugging Information — RetDec extracts and leverages DWARF (ELF) and PDB (PE) metadata to recover function signatures and type information; knowing how to parse these formats is key for symbol recovery
• C++ RTTI and vtable Reconstruction — RetDec detects C++ class hierarchies via Run-Time Type Information and virtual method tables; essential for correctly decompiling OOP binaries
• Binary Format Loaders (ELF, PE, Mach-O, COFF) — RetDec implements format-specific parsers for each file type; understanding loader architecture is necessary to add support for new formats or fix parsing bugs
• Instruction Idiom Reconstruction — RetDec detects and reconstructs high-level constructs from low-level instruction sequences (e.g., loop patterns, function prologues); this improves readability of decompiled code
• Retargetability via Backend Abstraction — RetDec's architecture decouples frontend (loader, decoder) from backend (code generator); this design allows adding new architectures or output languages with minimal core changes

• radareorg/radare2 — Alternative reverse-engineering platform with disassembly and analysis; directly competes on binary analysis but lacks LLVM-based decompilation output
• NationalSecurityAgency/ghidra — NSA's decompiler offering similar high-level code recovery; ghidra is Java-based with GUI, while RetDec is LLVM-native and CLI-focused
• llvm/llvm-project — Upstream LLVM dependency; RetDec's entire optimization and code generation layer depends on this project
• avast/retdec-regression-tests — Likely companion repo containing test binaries and expected decompilation outputs (inferred from prepare-retdec-tests.sh)
• capstone-engine/capstone — Lightweight disassembly library used alongside RetDec's decoder for cross-validation of instruction decoding

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 macOS and Windows CI workflow status badges and fix outdated Travis CI reference

The README.md currently shows only Travis CI and TeamCity badges, but the repo has migrated to GitHub Actions (retdec-ci.yml exists). The .travis.yml file is still present but the project uses .github/workflows/retdec-ci.yml for CI/CD. Adding badges for Linux, Windows, and macOS GitHub Actions workflows and removing the Travis CI badge would provide accurate CI status visibility and reflect the current build infrastructure.

• [ ] Update README.md to remove deprecated Travis CI badge reference
• [ ] Add GitHub Actions workflow badges for .github/workflows/retdec-ci.yml (already exists)
• [ ] Verify retdec-ci.yml triggers on all three platforms (Linux/Windows/macOS) or add separate badge links if they're in different workflows
• [ ] Consider deprecating or removing .travis.yml file in a follow-up PR

Consolidate platform-specific build scripts with unified error handling and validation

The repo contains parallel build scripts for Linux, Windows, and macOS (.github/workflows/{Linux,Windows,macOS}/{build.sh,install-deps.sh,prepare-clang.sh,run-tests.sh}) with likely duplicated logic. There's also a common script (.github/workflows/common/prepare-retdec-tests.sh). These scripts should be consolidated into a unified CI script with platform detection, reducing maintenance burden and ensuring consistency across platforms.

• [ ] Audit .github/workflows/Linux/.sh, .github/workflows/Windows/.sh, .github/workflows/macOS/*.sh to identify duplicated logic
• [ ] Review .github/workflows/common/prepare-retdec-tests.sh to understand shared utilities
• [ ] Create a unified build orchestration script with platform detection (e.g., scripts/ci-build.sh) that sources platform-specific overrides only when needed
• [ ] Update retdec-ci.yml to call the unified script instead of platform-specific ones
• [ ] Add error handling and validation checks (e.g., verify CMake, LLVM dependencies) before build steps

Add comprehensive CMake dependency validation and version checking in deps/CMakeLists.txt

The project has complex dependencies (Capstone, Eigen, authenticode-parser) defined in deps/CMakeLists.txt and cmake/deps.cmake. There are separate config files like retdec-capstone-config.cmake and retdec-system-capstone-config.cmake, suggesting support for both vendored and system libraries. Adding explicit version constraints, ABI compatibility checks, and clear error messages when dependencies are missing or incompatible would improve the contributor experience and reduce build failures.

• [ ] Review cmake/deps.cmake and deps/CMakeLists.txt for existing dependency version constraints
• [ ] Add minimum version requirements for each major dependency (CMake, LLVM, Capstone, Eigen)
• [ ] Implement clear error messages when dependencies are not found, including installation instructions for common platforms
• [ ] Add optional feature flags (e.g., -DUSE_SYSTEM_CAPSTONE) with validation in cmake/options.cmake
• [ ] Document dependency requirements in README.md or a new DEPENDENCIES.md file with version matrix for each supported platform

• Add documentation for the signature-based library code removal YARA integration—there are no docs in the file list explaining how to add custom YARA rules or how the matching pipeline works; docs/yara-signatures.md would be a good start.
• Create test coverage report for the authenticode-parser (deps/authenticode-parser/src/)—it's a critical PE verification component but the file list shows no dedicated unit tests; add tests/authenticode_test.cpp to increase coverage.
• Fix or document the test filtering logic in ignore_Debug and ignore_Release files—they exist but are unexplained; add a comment in the root README or CMakeLists.txt explaining why certain tests are platform/config-specific.

RetDec's security posture is moderate with notable concerns around maintenance status and dependency management. The project uses an outdated Ubuntu base image and lacks version pinning for OS-level dependencies, creating exposure to known vulnerabilities. The limited maintenance mode status poses ongoing risk for timely security updates. Key strengths include the existence of a security reporting mechanism and organized CI/CD infrastructure. Primary recommendations focus on updating the Docker base image, implementing stricter dependency version controls, and expanding security documentation. The codebase itself (based on visible structure) shows no obvious injection vulnerabilities or hardcoded secrets, but comprehensive review of actual implementation code and CI/CD workflows is needed for complete assessment.

• Medium · Outdated Base Docker Image — Dockerfile (line 1). The Dockerfile uses 'ubuntu:focal' (Ubuntu 20.04) as the base image. This version reached standard support end in April 2025 and may not receive critical security updates. Using outdated base images exposes the container to known vulnerabilities. Fix: Update to a more recent Ubuntu LTS version such as 'ubuntu:jammy' (22.04 LTS) or 'ubuntu:noble' (24.04 LTS) to ensure access to current security patches.
• Medium · Missing Package Version Pinning — Dockerfile (apt-get install section). The Dockerfile installs dependencies without specifying version constraints (e.g., 'apt-get install -y build-essential'). This can lead to inconsistent builds and potential installation of vulnerable package versions if security updates introduce breaking changes. Fix: Pin specific versions for critical dependencies: 'openssl=1.1.1*', 'libssl-dev=1.1.1*', etc. Use 'apt-get update' followed by explicit version specifications.
• Low · Project in Limited Maintenance Mode — README.md. According to the README, RetDec is in 'limited maintenance mode' with delayed issue response (up to one quarter) and minimal development. This increases security risk as vulnerabilities may not be addressed promptly. Fix: Monitor the project actively for security disclosures. Consider forking or maintaining a private patch set for critical security issues. Subscribe to security notifications through the SECURITY.md reporting channel.
• Low · Incomplete Security Policy Documentation — SECURITY.md. While a SECURITY.md file exists with a vulnerability reporting form, it lacks details about security practices, supported versions, security update timelines, or disclosure policies. This is critical information for users relying on the project. Fix: Expand SECURITY.md to include: supported versions, security patch timelines, responsible disclosure practices, PGP key for secure communication, and historical security advisories.
• Low · Build Automation with Limited Visibility — .github/workflows/ and .travis.yml. Multiple CI/CD workflows exist (.github/workflows/retdec-ci.yml, .travis.yml) but only workflow file names are visible. Without reviewing the actual workflow content, potential security risks in CI/CD pipeline configuration cannot be fully assessed. Fix: Review all CI/CD workflow files for: secure secret management, dependency verification, signed commits, and artifact integrity checks. Ensure GitHub Actions use versioned action references, not 'latest'.
• Low · Large Third-Party Dependencies — deps/ directory. The project includes multiple third-party dependencies (capstone, eigen, authenticode-parser). These significantly increase the attack surface and may contain unpatched vulnerabilities. Fix: Implement automated dependency scanning using tools like 'dependabot' or 'snyk'. Regularly audit and update dependencies. Document the rationale for each dependency and maintain a software bill of materials (SBOM).

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.