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/rizinorg/cutter 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 1w ago
• 17 active contributors
• Distributed ownership (top contributor 35% of recent commits)
• GPL-3.0 licensed
• CI configured
• ⚠ GPL-3.0 is copyleft — check downstream compatibility
• ⚠ 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 rizinorg/cutter repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/rizinorg/cutter.

What it runs against: a local clone of rizinorg/cutter — 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 rizinorg/cutter | 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 dev exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 37 days ago | Catches sudden abandonment since generation |

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

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "rizinorg/cutter(\\.git)?\\b" \\
  && ok "origin remote is rizinorg/cutter" \\
  || miss "origin remote is not rizinorg/cutter (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 dev >/dev/null 2>&1 \\
  && ok "default branch dev exists" \\
  || miss "default branch dev no longer exists"

# 4. Critical files exist
test -f "CMakeLists.txt" \\
  && ok "CMakeLists.txt" \\
  || miss "missing critical file: CMakeLists.txt"
test -f "src/main.cpp" \\
  && ok "src/main.cpp" \\
  || miss "missing critical file: src/main.cpp"
test -f "cmake/CutterConfig.cmake.in" \\
  && ok "cmake/CutterConfig.cmake.in" \\
  || miss "missing critical file: cmake/CutterConfig.cmake.in"
test -f "cmake/FindPySide6.cmake" \\
  && ok "cmake/FindPySide6.cmake" \\
  || miss "missing critical file: cmake/FindPySide6.cmake"
test -f ".github/workflows/ci.yml" \\
  && ok ".github/workflows/ci.yml" \\
  || miss "missing critical file: .github/workflows/ci.yml"

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

Cutter is a free, open-source reverse engineering GUI powered by rizin, the modern successor to radare2. It provides a customizable graphical interface for binary analysis, disassembly, debugging, and decompilation across Linux, macOS, and Windows, with native support for both Python and C++ plugins. Monolithic Qt/C++ GUI application: src/ contains the main application code (likely organized by feature UI components), cmake/ handles cross-platform build configuration with modularity for optional features (PySide2/PySide6 bindings, bundled rizin). dist/ contains platform-specific packaging (macOS bundle, Windows bundler scripts, Docker). Plugins live as loadable modules.

Security researchers, reverse engineers, malware analysts, and CTF competitors who need a user-friendly alternative to IDA Pro or Ghidra for analyzing binaries, understanding code flow, and writing custom analysis plugins without leaving the GUI.

Actively developed and production-ready. The project has comprehensive CI/CD (GitHub Actions, AppVeyor, Coverity), multiple distribution channels (AppImage, DMG, native packages via OBS), and is maintained by the rizinorg community. Latest commits visible in workflows suggest ongoing development, not abandoned.

Moderate risk: depends on rizin (external binary analysis engine) as a critical dependency, so breakages in rizin can impact Cutter. Complexity of C++ GUI + Python bindings increases maintenance surface. No obvious single-maintainer bottleneck given organizational structure (rizinorg), but large codebase (1.9M C++ LOC) means onboarding friction.

Active CI/CD pipeline (GitHub Actions workflows in .github/workflows/) running linting, building on Linux (including legacy old-glibc builds), documentation generation, and Coverity static analysis scans. Support for both PySide2 and PySide6 (FindPySide2.cmake and FindPySide6.cmake) suggests ongoing modernization of Python bindings.

git clone https://github.com/rizinorg/cutter.git
cd cutter
mkdir build && cd build
cmake ..
make -j$(nproc)
./bin/cutter

Refer to CMakeLists.txt root config and CONTRIBUTING.md for platform-specific dependencies (Qt, Python, rizin).

Daily commands: After building: ./bin/cutter (from build directory) or install via system package manager. For development, configure CMake with -DCUTTER_ENABLE_PYTHON=ON and ensure rizin is discoverable. macOS users can brew install --cask cutter post-release.

• CMakeLists.txt — Root build configuration; defines how Cutter is compiled, dependencies resolved, and platform-specific setup (Qt, Python, Rizin) is orchestrated
• src/main.cpp — Application entry point; initializes the Qt application, loads the main window, and bootstraps Rizin integration
• cmake/CutterConfig.cmake.in — CMake package configuration template; critical for downstream projects linking Cutter as a library and locating its headers/libraries
• cmake/FindPySide6.cmake — Python/PySide6 discovery module; essential for Python plugin support and scripting integration in the reverse engineering workflow
• .github/workflows/ci.yml — CI/CD pipeline definition; controls automated builds, tests, and releases across Linux, macOS, and Windows platforms
• CONTRIBUTING.md — Contribution guidelines; establishes coding standards, PR process, and architectural expectations for all contributors
• cmake/BundledRizin.cmake — Rizin dependency bundling strategy; defines how the core reverse engineering engine is linked and versioned

Add a New Reverse Engineering Plugin

1. Create a new Python plugin directory with init.py and register it in the plugin manager (docs/source/contributing/plugins/getting-started.rst)
2. Reference PySide6 bindings from cmake/FindPySide6.cmake for UI components (cmake/FindPySide6.cmake)
3. Call Rizin APIs exposed via python bindings (initialized in build configuration) (cmake/BundledRizin.cmake)

Add a New Build Target or Platform Support

1. Extend CMakeLists.txt with platform-specific conditionals and target definitions (CMakeLists.txt)
2. Create corresponding platform bundling script in dist/ directory (e.g., dist/WindowsBundleQt.cmake) (dist/CMakeLists.txt)
3. Add CI job to .github/workflows/ci.yml for automated testing on the new platform (.github/workflows/ci.yml)

Contribute Documentation or Translations

1. Write reStructuredText (.rst) docs in docs/source/ following the structure in docs/source/user-docs/ (docs/source/contributing/docs/getting-started.rst)
2. Ensure Sphinx configuration in docs/source/conf.py includes your new doc file (docs/source/conf.py)
3. For translations, integrate your .po files via cmake/Translations.cmake (cmake/Translations.cmake)

Modify or Extend the Build System

1. Edit cmake/Utils.cmake to add reusable build utilities or update cmake/CutterInstallDirs.cmake for install paths (cmake/Utils.cmake)
2. Test changes in CMakeLists.txt; verify platform-specific logic via cmake/FindGraphviz.cmake or similar finders (CMakeLists.txt)
3. Commit cmake changes and verify CI passes in .github/workflows/ci.yml (.github/workflows/ci.yml)

• Qt6 / Qt5 — Cross-platform GUI framework providing native look-and-feel on Windows, macOS, and Linux; essential for a desktop reverse engineering tool
• Rizin — Core reverse engineering engine handling binary analysis, disassembly, and program semantics; Cutter is built as a frontend to Rizin
• Python / PySide6 — Enables extensibility via plugins and scripting; allows users to automate analysis tasks and build custom tools
• CMake — Provides portable, cross-platform build system with modular configuration; simplifies dependency resolution on diverse platforms
• Docker — Ensures reproducible build environments and simplifies CI/CD on multiple platforms
• Sphinx / Doxygen — Generates user documentation and C++ API reference; facilitates contributor onboarding and project understanding

• Bundled Rizin vs. system Rizin

  • Why: Bundling ensures consistent behavior and reduces dependency management complexity, but increases binary size
  • Consequence: Users get a self-contained tool; developers must manage Rizin version upgrades centrally

• Qt-based UI over web-based (Electron)

  • Why: Native Qt provides better performance and lower memory footprint for a data-heavy reverse engineering platform
  • Consequence: Platform-specific UI code increases maintenance; but delivers snappier, more responsive experience

• Python plugins via PySide6 vs. pure C++ plugins

  • Why: Python lowers barrier to entry for community contributions and rapid scripting
  • Consequence: Slight runtime overhead; but dramatically increases ecosystem and customization potential

• CMake + platform-specific bundling scripts vs. unified packaging tool

  • Why: Fine-grained control over macOS .app, Windows .msi, and Linux .deb packaging; respects platform conventions
  • Consequence: More build logic to maintain; but delivers native, professional installers

• Real-time collaborative reverse engineering (single-user focus)
• Network-based analysis or cloud-based backend (local binary analysis only)
• Automated exploit generation or vulnerability patching
• Support for mobile binary analysis frameworks (desktop executables focus)
• Built-in malware sandboxing or dynamic execution monitoring

rizin must be available (either system-installed or bundled via BundledRizin.cmake); CMake will fail cryptically if missing. PySide2 vs PySide6 selection affects Python plugin compatibility—clarify which version is stable for your target Qt version. macOS builds require code-signing entitlements (Entitlements.plist) for notarization. Windows builds need PowerShell execution policy allowing unsigned scripts (bundle_*.ps1). AppImage builds have glibc version constraints—see build-linux-old action. Graphviz is optional but graph rendering features depend on it.

• Binary analysis and disassembly — Core purpose of Cutter—understanding how the rizin backend parses binaries, lifts machine code to intermediate representations, and renders assembly is essential for debugging analysis issues
• Control flow graphs (CFG) — Cutter renders CFGs via Graphviz; understanding CFG construction and visualization helps when modifying the graph UI or analyzing complex functions
• Plugin architecture and dynamic loading — Cutter's extensibility via Python and C++ plugins relies on runtime module discovery and symbol binding; key to understanding how features are decoupled and how to develop extensions
• Cross-platform GUI deployment (Qt, PySide, bundling) — Cutter targets Linux, macOS, and Windows with unified C++/Qt code; CMake configuration and dist/ scripts show practical techniques for managing platform differences in GUI frameworks, Python runtime embedding, and code signing
• Intermediate representation (IR) and lifting — Rizin (and Cutter) lift binaries to IL for analysis; understanding IR abstractions helps interpret Cutter's analysis output and extend analysis passes
• AppImage and containerized Linux distribution — Cutter uses AppImage for Linux distribution to avoid glibc fragmentation (see build-linux-old action); important for understanding how to package complex GUI apps for reproducible Linux deployment
• Symbol resolution and type reconstruction — Reverse engineering heavily relies on recovering function signatures and type information from binaries; Cutter's UI surfaces these capabilities, and understanding how rizin performs symbol and type analysis informs plugin development

• rizinorg/rizin — The core binary analysis engine powering Cutter; essential for understanding Cutter's analysis capabilities and contributing to the backend
• NationalSecurityAgency/ghidra — Alternative free reverse engineering platform with built-in decompiler; Cutter integrates Ghidra's decompiler as an optional plugin
• radareorg/radare2 — Predecessor to rizin (original binary analysis framework); architectural inspiration and historical context for Cutter's design
• rizinorg/cutter-plugins — Official repository hosting community-contributed Cutter plugins for extending functionality without modifying the core GUI
• x64dbg/x64dbg — Complementary debugger for Windows; Cutter and x64dbg are often used together for live and static analysis workflows

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 GitHub Actions workflow for building macOS releases with code signing

The repo has .github/workflows/ci.yml for general CI and .github/workflows/docs.yml for documentation, but no dedicated workflow for macOS builds with code signing/notarization. Given the presence of dist/macos/Entitlements.plist, dist/macos/Info.plist.in, and dist/MacOSSetupBundle.cmake.in, there's clear infrastructure for macOS distribution that isn't being tested in CI. This would ensure macOS releases are properly signed and notarized before distribution.

• [ ] Create .github/workflows/macos-release.yml workflow file
• [ ] Add steps to build macOS app using dist/MacOSSetupBundle.cmake.in
• [ ] Integrate code signing using GitHub's native code signing secrets
• [ ] Add notarization step using dist/macos/Entitlements.plist
• [ ] Test with dist/macos/cutter.icns asset inclusion

Add linter workflow for CMake files to .github/workflows/

The repo has .github/workflows/linter.yml configured, but inspecting the file structure reveals multiple CMake files (CMakeLists.txt, cmake/*.cmake) that likely aren't being linted. Adding CMake linting (via cmake-lint or cmakelint) would catch issues early and ensure consistency across build configuration files like cmake/CutterConfig.cmake.in, cmake/FindPySide2.cmake, and dist/CMakeLists.txt.

• [ ] Extend .github/workflows/linter.yml to include CMake linting step
• [ ] Configure linter for all *.cmake files and CMakeLists.txt
• [ ] Reference .lgtm.yml configuration to align with existing linting setup
• [ ] Test against existing CMake files: cmake/BundledRizin.cmake, cmake/Utils.cmake, dist/WindowsBundleQt.cmake

Create comprehensive build documentation for Windows bundling in docs/

The repo has extensive Windows bundling scripts (dist/bundle_python.ps1, dist/bundle_qt.cmake, dist/WindowsBundlePython.cmake) but no corresponding documentation in the docs/ directory explaining the bundling process. This creates friction for contributors trying to understand or modify Windows builds. Documentation should explain the purpose of each script and how they interact.

• [ ] Create docs/source/development/windows-build.md documenting Windows-specific build steps
• [ ] Document the purpose and interdependencies of dist/bundle_python.ps1, dist/bundle_qt.cmake, dist/WindowsBundleQt.cmake, and dist/WindowsBundlePython.cmake
• [ ] Add troubleshooting section referencing .appveyor.yml CI configuration
• [ ] Include references to cmake/CutterConfig.cmake.in for build configuration options
• [ ] Cross-reference with existing CONTRIBUTING.md guidelines

• Add unit tests for src/core/ or src/plugins/ modules: large C++ codebase with minimal visible test fixtures; propose a test suite for a single feature class using a standard C++ testing framework (GoogleTest, Catch2).
• Document the Python plugin API with code examples: CONTRIBUTING.md references Python plugins, but there is no example plugin or API reference in the file list—create dist/plugin-examples/ with a hello-world Python plugin and update docs/contributing/code.html.
• Improve CMake error messages for missing dependencies: add human-readable diagnostics in cmake/Utils.cmake or cmake/CutterConfig.cmake.in when rizin, PySide, or Graphviz are not found, instead of cryptic CMake failures.

The Cutter reverse engineering platform demonstrates a reasonable security posture with established security reporting channels and security policy documentation. However, there are opportunities for improvement: (1) the version support policy is quite restrictive and should be clarified, (2) Docker and CI/CD configurations need review to ensure secure practices, (3) dependency management through submodules requires ongoing vigilance for supply chain risks. No obvious hardcoded secrets, injection vulnerabilities, or critical misconfigurations are evident from the provided file structure, but a deeper code review would be necessary to identify runtime vulnerabilities.

• Medium · Incomplete Security Policy - Limited Version Support — SECURITY.md. The SECURITY.md file indicates that only the 'latest-release' version is supported, with all other versions marked as unsupported (:x:). This narrow support window may leave users of older versions vulnerable to known security issues without guidance on patching. Fix: Define a clearer security support policy (e.g., LTS versions, rolling window support). Provide security backports for at least 2-3 previous major versions or clearly communicate the maintenance timeline.
• Medium · Incomplete Security Contact Information — SECURITY.md. The SECURITY.md file references a direct contact (Itay Cohen) for security escalation but the contact information appears truncated/incomplete in the provided snippet, making it unclear how to reach the security team as an alternative escalation path. Fix: Complete and clearly document all alternative security contact methods, including PGP keys for encrypted communication if available.
• Low · Docker Configuration Present Without Explicit Security Review — docker/. The repository contains Docker configuration files (docker/Dockerfile, docker/Makefile) but the content is not provided for analysis. Docker images can introduce supply chain risks if base images are not properly pinned or reviewed. Fix: Ensure Docker base images are from official sources, pinned to specific versions (not 'latest'), and regularly scanned for vulnerabilities using tools like Trivy or Snyk.
• Low · CI/CD Pipeline Security Configuration Not Fully Visible — .github/workflows/. GitHub Actions workflows are present (.github/workflows/) including a Coverity Scan workflow. While this is good practice, the full configuration details are not provided for review of potential security risks (e.g., exposed secrets, overly permissive workflow permissions). Fix: Review GitHub Actions workflows to ensure: (1) Secrets are never logged, (2) OIDC tokens have minimal permissions, (3) Third-party actions are from trusted sources, (4) Dependency pinning is used.
• Low · Submodules Present - Dependency Chain Risk — .gitmodules. The .gitmodules file indicates the project uses git submodules for dependencies. Submodules can introduce supply chain risks if not properly maintained or if upstream repositories are compromised. Fix: Regularly audit submodule dependencies, pin them to specific commit hashes (not branches), and consider using dependency scanning tools to detect vulnerabilities in transitive dependencies.

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.