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/Lessica/TrollFools 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 — Single-maintainer risk — review before adopting

• Last commit 2w ago
• 6 active contributors
• MIT licensed
• CI configured
• ⚠ Single-maintainer risk — top contributor 93% of recent commits
• ⚠ 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 Lessica/TrollFools repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/Lessica/TrollFools.

What it runs against: a local clone of Lessica/TrollFools — 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 Lessica/TrollFools | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | Last commit ≤ 47 days ago | Catches sudden abandonment since generation |

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

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

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

TrollFools is a SwiftUI-based iOS tweak injection tool that uses ChOma (for Mach-O binary patching) and insert_dylib to inject dynamic libraries into both decrypted and encrypted App Store applications, as well as removable system apps, without decryption or re-signing. It supports iOS 14.0–17.0 and operates entirely in-place on the target application. Single-target Xcode project (TrollFools.xcodeproj) containing a SwiftUI app and CLI tool. Core logic is split: App.swift + App+Ads.swift contain the main UI, CLI/ subdirectory (CmdInject.swift, CmdEject.swift) wraps injection commands, AuxiliaryExecute*.swift handles subprocess spawning, and AppListModel.swift manages app enumeration. Assets and localization (bartycrouch) are in standard Xcode locations.

iOS developers and jailbreak/TrollStore users who want to inject tweaks or patches into existing apps (especially App Store apps) without building modified IPAs from source. Contributors are typically low-level iOS tooling developers familiar with Mach-O binaries and dylib injection.

Actively developed and relatively mature: the project has a working Xcode build setup (TrollFools.xcodeproj), GitHub Actions CI/CD (compile.yml, release.yml), and clear versioning (CHANGELOG.md). It's published on Havoc package manager and supports multiple iOS versions, indicating production use. However, no test suite is evident in the file structure, which is typical for iOS tweak tools.

Moderate risk: the codebase directly manipulates binary formats (Mach-O) and handles encrypted App Store binaries, both error-prone operations. Dependencies on external C tools (insert_dylib, ChOma, llvm-install-name-tool) introduce supply-chain risk, and a single maintainer (Lessica) means no backup if they become unavailable. The project explicitly targets jailbroken/TrollStore environments, limiting its mainstream adoption and support surface.

The project maintains active CI/CD workflows (GitHub Actions), has a release pipeline, and tracks localization with bartycrouch. The milestones show completed work on static-linked tool compilation and .deb/.zip support packaging, suggesting the focus is now on stability and distribution rather than new major features.

Clone the repo: git clone https://github.com/Lessica/TrollFools.git && cd TrollFools. Open the Xcode project: open TrollFools.xcodeproj. Build via Xcode (Cmd+B) or the Makefile: make build. Ensure Xcode 14+ and iOS SDK 16+ are installed.

Daily commands: Dev build: Open TrollFools.xcodeproj, select the 'trollfoolscli' scheme, press Cmd+R to run on a connected device. Release build: make release (see Makefile for details). CLI usage (after deployment): Run the injector binary directly with inject/eject subcommands as defined in CmdInject.swift and CmdEject.swift.

• TrollFools/CLI/CmdInject.swift: Core injection logic that orchestrates dylib insertion into target applications using ChOma and insert_dylib
• TrollFools/CLI/CmdEject.swift: Reverses injection by removing injected dylibs from applications, essential for cleanup and testing
• TrollFools/AuxiliaryExecute.swift: Subprocess spawning and execution wrapper that invokes low-level tools (install_name_tool, ChOma) with proper error handling
• TrollFools/AppListModel.swift: Enumerates installed applications and tracks injection state, bridges UI to underlying binary operations
• TrollFools.xcodeproj/project.pbxproj: Xcode project configuration including static library linking and build phases for bundled tools
• Makefile: Build orchestration for cross-platform compilation, tool embedding, and release artifact generation

New injection logic: Modify TrollFools/CLI/CmdInject.swift and core binary manipulation in TrollFools/AuxiliaryExecute.swift. New UI features: Edit TrollFools/AppListView.swift and TrollFools/AppListModel.swift. Localization strings: Update TrollFools/BartyCrouch.swift and run bartycrouch (defined in .bartycrouch.toml). Build system changes: Edit Makefile and TrollFools.xcodeproj/project.pbxproj.

Mach-O format sensitivity: ChOma and insert_dylib are brittle with non-standard binaries; test on real iOS devices, not simulators (which use different Mach-O formats). Encryption handling: Works with decrypted App Store binaries only (TrollStore users have pre-decrypted apps); on-device decryption is not supported. Code signature invalidation: Injection breaks the original code signature; the app must be resigned or run in TrollStore context where signatures are bypassed. No sandboxed execution: CLI tool requires root or entitlements to modify system apps; run only in jailbreak/TrollStore environments. Dylib search paths: Injected dylibs must be reachable at runtime via rpath or absolute paths, configured in CmdInject.swift.

• Mach-O Binary Format — TrollFools directly manipulates Mach-O headers, load commands, and segments; understanding the format is essential to debug injection failures and compatibility issues
• Dynamic Library (dylib) Injection — The core mechanism: injecting DYLIB_LOAD or DYLIB_LOAD_WEAK load commands to hook a library into the app's runtime; critical to understand linking and symbol resolution
• Code Signing and Entitlements — Injection breaks the original app's code signature; TrollStore's ability to bypass signature verification is why injection works, and understanding this is key to deployment
• rpath (Relative Library Path) — Injected dylibs use rpath to locate dependencies at runtime; misconfiguration here is a common cause of 'dylib not found' crashes
• iOS App Encryption (FairPlay) — TrollFools only works with decrypted binaries (provided by TrollStore); understanding FairPlay and why decryption is needed informs feature scope and limitations
• Process Forking and Subprocess Management — AuxiliaryExecute.swift spawns external tools (ChOma, insert_dylib) and captures output; robust process handling is critical for reliability

• opa334/ChOma — Core dependency providing Mach-O binary parsing and modification; understand this to debug injection failures
• tyilo/insert_dylib — Companion tool that physically injects dylib load commands into Mach-O binaries; TrollFools orchestrates this
• p-x9/MachOKit — Swift library for Mach-O introspection used by TrollFools for binary analysis and validation
• 34306/Patched-TS-App — Direct predecessor and inspiration for TrollFools; reference for alternative injection strategies on TrollStore
• EthanArbuckle/Apollo — Similar tweak injection framework; compare approaches for compatibility with newer iOS versions

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 InjectorV3+Backup.swift and injection core logic

The repo handles critical operations like dylib injection, app backup, and binary patching through InjectorV3+Backup.swift and related injection files. Currently there are no visible test files in the repository. Adding unit tests for the injection pipeline (especially backup/restore and binary modification) would catch regressions early and make the codebase more maintainable for contributors working on core injection logic.

• [ ] Create TrollFoolsTests/ directory with XCTest target in TrollFools.xcodeproj
• [ ] Add tests for InjectorV3+Backup.swift covering backup creation, restoration, and cleanup scenarios
• [ ] Add tests for CmdInject.swift and CmdEject.swift CLI commands with mock app scenarios
• [ ] Add tests for binary patching operations in Execute.swift and AuxiliaryExecute.swift to verify install_name_tool behavior

Add GitHub Action workflow to verify CLI binary compatibility across iOS versions

The README claims support for iOS 14.0-17.0, and the project includes CLI commands (CmdInject.swift, CmdEject.swift, CmdList.swift, CmdView.swift). However, there's no automated verification that the compiled CLI binary works correctly on different iOS versions or that the dylib injection logic handles version-specific quirks. A specialized workflow could simulate or document these compatibility checks.

• [ ] Review existing .github/workflows/compile.yml and .github/workflows/release.yml to understand current build process
• [ ] Create .github/workflows/compat-test.yml that validates CLI binary structure and embedded dependencies across iOS SDK versions (14.0, 15.0, 16.0, 17.0)
• [ ] Add build matrix to ensure install_name_tool and ChOma integration points are tested per iOS version
• [ ] Document iOS version-specific limitations in README.md based on workflow findings

Refactor and document FilterOptions.swift and related filtering logic across AppListModel and EjectListModel

The repo has FilterOptions.swift but filtering logic appears duplicated across AppListModel.swift, AppListSearchModel.swift, EjectListModel.swift, and EjectListSearchModel.swift. This creates maintenance burden when filter behavior needs updates. Consolidating and documenting the filtering strategy would improve code clarity and reduce bugs.

• [ ] Analyze FilterOptions.swift and create a shared FilteringStrategy protocol/class to handle common filtering logic
• [ ] Refactor AppListModel.swift and EjectListModel.swift to use the new shared filtering abstraction
• [ ] Consolidate AppListSearchModel.swift and EjectListSearchModel.swift into a reusable SearchableListModel generic
• [ ] Add documentation to TrollFools/ explaining the filtering architecture and how to add new filter types (e.g. injection status filters)

• Add unit tests for AuxiliaryExecute.swift process spawning and error cases (currently untested); mock ChOma/insert_dylib calls to verify injection logic without device access.
• Expand AppListModel.swift to detect and warn about incompatible binaries (e.g., ARM32, old Mach-O versions) before injection; document supported architectures in the UI.
• Create documentation in README.md with step-by-step examples of injecting a simple test dylib into a real app on TrollStore; include troubleshooting for common rpath/dylib not found errors.

• High · Arbitrary Code Execution through Dylib Injection — TrollFools/InjectorV3+Inject.swift, TrollFools/InjectorV3+MachO.swift. The application performs in-place tweak injection using insert_dylib and ChOma. This mechanism allows loading arbitrary dynamic libraries into application processes. Without proper validation of dylib sources and signing, this could enable arbitrary code execution if an attacker can supply malicious dylibs. Fix: Implement strict validation of dylib sources, verify code signatures, maintain a whitelist of approved dylibs, and log all injection activities. Consider implementing sandbox restrictions.
• High · Privilege Escalation Risk via Auxiliary Execute — TrollFools/AuxiliaryExecute.swift, TrollFools/AuxiliaryExecute+Spawn.swift. The AuxiliaryExecute and AuxiliaryExecute+Spawn modules spawn processes with elevated privileges. Without proper input validation and authorization checks, this could be exploited for privilege escalation attacks. Fix: Implement strict input validation for all spawned processes, use allowlists for permitted commands, verify user authorization before privilege escalation, and log all privileged operations.
• High · Insufficient Input Validation in CLI Commands — TrollFools/CLI/CmdInject.swift, TrollFools/CLI/CmdEject.swift, TrollFools/CLI/CmdList.swift, TrollFools/CLI/CmdView.swift. The CLI module contains multiple command handlers (CmdInject, CmdEject, CmdList, CmdView) that process user input without apparent sanitization. Malicious inputs could lead to command injection or file path traversal attacks. Fix: Implement comprehensive input validation, use parameterized operations instead of string concatenation, validate file paths against a whitelist, and reject suspicious input patterns.
• Medium · Potential Path Traversal Vulnerabilities — TrollFools/InjectorV3+Bundle.swift, TrollFools/InjectorV3+Backup.swift. The application manipulates file paths for bundle operations and backup mechanisms. Insufficient path validation could allow attackers to access or modify files outside intended directories. Fix: Canonicalize all file paths, validate against path traversal patterns (../, etc.), use secure APIs for path operations, and implement strict access controls on file operations.
• Medium · Insecure Storage of Configuration and Metadata — TrollFools/CodableStorage.swift, TrollFools/InjectorV3+Metadata.swift, TrollFools/InjectorV3+Persistent.swift. The CodableStorage module stores application data, potentially including sensitive metadata about injected dylibs and application configurations. Storage may lack encryption or access controls. Fix: Encrypt sensitive data at rest using platform-provided encryption (e.g., iOS Keychain for credentials), implement file-level access controls, and avoid storing sensitive information in plaintext.
• Medium · Binary Manipulation Without Integrity Verification — TrollFools/InjectorV3+MachO.swift. The application modifies Mach-O binaries (TrollFools/InjectorV3+MachO.swift) without apparent integrity checks or signature re-validation after modification. This could allow tampering with critical application binaries. Fix: Implement integrity verification before and after binary modifications, re-sign modified binaries with proper code signatures, and validate modifications against expected behavior.
• Medium · Missing Security Headers and Transport Security — TrollFools/CheckUpdateManager.swift. The CheckUpdateManager likely performs network requests for update checks without visible transport security validation or certificate pinning mechanisms. Fix: Implement certificate pinning for update checks, enforce TLS 1.2+, validate server certificates, and use HTTPS exclusively for all network communications.
• Low · Potential Information Disclosure through Logs — TrollFools/LogsView.swift. The application includes logging functionality (LogsView.swift) that may expose sensitive information about injected applications, dylib paths, or system modifications to local log files or debuggers. Fix: Implement log rotation and retention policies, redact sensitive information from logs, restrict log file permissions,

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.