TrollFools: in-place tweak injection for TrollStore apps

What TrollFools injects and who it injects into

TrollFools adds a dynamic library to an iOS application that is already installed on the device. The README calls this "in-place tweak injection", which is the whole design: instead of hooking a process at runtime, the tool edits the app's Mach-O binary so the loader pulls the dylib in when the app launches. The repository description names the two pieces doing that work, insert_dylib and ChOma.

The audience is narrow by construction. The README says the project is "Expected to work on all iOS versions supported by opa334's TrollStore (i.e. iOS 14.0 - 17.0)". That sentence is a boundary, not a marketing claim. If your device is not running TrollStore, or runs an iOS version outside that range, TrollFools has no supported path. The topics list on the repository includes jailbreak, but the README never claims to be one; it depends on TrollStore's per-app permissions rather than on a jailbroken system.

The three limitation entries in the README double as the supported target list: removable system applications, decrypted App Store applications (which the README calls TrollStore applications), and encrypted App Store applications with a bare dynamic library. That third category is the interesting one. It says an encrypted binary can still take an injected library as long as the library itself is bare, which is a real constraint on which tweaks will work rather than a footnote.

The injection mechanism: insert_dylib and ChOma

The data flow is a binary edit, not a runtime hook. TrollFools loads the target app's Mach-O executable, uses ChOma to parse and rewrite the load commands, and adds a load command that points at the dylib. insert_dylib is the upstream tool that performs this kind of load-command insertion. Once the command is present, the dynamic loader maps the library when the app starts, before the app's own code runs. Nothing needs to stay resident for the injection to take effect, which is why the modification survives a reboot.

ChOma comes from opa334 and alfiecg24 and is the same codebase used across TrollStore-adjacent tooling, so the Mach-O handling is not bespoke. MachOKit by p-x9 appears in the credits as well. The README also records a milestone that explains a packaging decision: "optool is buggy so we need to compile a statically linked install_name_tool or llvm-install-name-tool on iOS to achieve a smaller package size". That is a concrete trade-off. Rather than ship a separate install-name tool, the project compiles a static one so the package stays smaller.

The UI layer is SwiftUI, stated in the README as "Proudly written in SwiftUI". The Makefile shows the build target as iphone:clang:latest:14.0 with ARCHS set to arm64, and it installs two processes, TrollFools and trollfoolscli. That second binary matters: there is a command-line side to the tool, not only the SwiftUI app, though the README does not document its flags or usage.

Installing TrollFools and injecting a first dylib

The README points at a single distribution channel. The badge at the top links to https://havoc.app/package/trollfools, and the milestones list records "Support for .deb or .zip", so the package arrives either as a Debian package or as a zip. The README does not give installation steps beyond that link, and it does not document a repository URL for adding to a package manager. Get it from the Havoc package page.

Because the README is silent on the exact UI flow, the honest description is what the repository layout and the Makefile show. The build produces TrollFools.app under Applications and trollfoolscli under /usr/local/bin, and the after-package step runs devkit/tipa.sh, which is the packaging script for the release artifact. Building it yourself requires Theos plus an Xcode project, since the Makefile includes xcodeproj.mk and names the TrollFools scheme:

make before-all
make package

The before-all target runs devkit/standardize-entitlements.sh, and before-package signs both binaries with ldid using TrollFools/TrollFools.entitlements. If you build from source, those two steps are not optional; skipping the entitlement standardization produces a binary that will not behave the same on device. The Makefile also declares INSTALL_TARGET_PROCESSES for both TrollFools and trollfoolscli, meaning the package tells the system to restart those processes after installation.

On the device side, the workflow the README implies is: open the app, choose an installed application from the supported categories, and attach a dylib. The README does not document where the dylib must live, what file picker is used, or whether a respring is required. Treat the first injection as a test on a reinstallable app rather than on something you cannot restore.

The encrypted-app case and what "bare dynamic library" costs you

The README's third supported category is the one most likely to surprise people. Encrypted App Store applications work "with bare dynamic library". App Store binaries are encrypted on disk, and the README's phrasing says the injected library must be bare for that case to hold. A tweak that depends on other frameworks, on a specific load order, or on symbols resolved at a particular point may not qualify. The README does not enumerate what makes a library bare, and it does not list which tweaks are known to work.

This is the main reason to be careful about the phrase "tweak injection". The repository topics include tweak and dylib-injection, and the community framing around TrollStore tends to treat those as interchangeable. They are not. TrollFools injects a library into an app bundle. A jailbreak tweak system hooks processes system-wide and can affect apps you never touched. If your goal is a system-wide hook, TrollFools is the wrong tool and the README never suggests otherwise.

The second real limitation is reversibility. The README documents no uninstall or restore path for an injected app. Because the edit is written into the app's own binary, the original state is not preserved by the tool as far as the documentation shows. Reinstalling the app from its original source is the obvious recovery route, which is why removable system applications and reinstallable App Store apps are the sensible first targets.

Patched-TS-App and the difference in approach

The README credits Patched-TS-App by Huy Nguyen and Nathan as the inspiration, and the difference between the two is worth stating plainly. Patched-TS-App is a packaging approach: you take a TrollStore app, apply the patch as part of producing a modified build, and install that result. The modification is part of the artifact you install.

TrollFools moves that step onto the device and onto an already-installed app. The README's phrase "in-place" is the distinction. You are not producing a new IPA and installing it; you are editing the bundle that is already there. That is more convenient when the app is already installed and harder to reason about when something goes wrong, because there is no separate patched artifact to fall back to. The two projects share the underlying idea of inserting a dylib into a TrollStore application; they differ in when and where the insertion happens.

If your workflow already involves building IPAs on a computer and sideloading them, Patched-TS-App's model fits that pipeline. TrollFools fits a device-only workflow where the app is already present and you want the library attached without a round trip through a desktop.

Maintenance, licence and upgrade cost

The last push to the repository was on 2026-04-23, which is the same timestamp as the v4.3-253 release. The repository is not archived. The release history shows v4.2-227 on 2025-09-11, then a gap to v4.3-246 on 2026-04-16 and v4.3-253 a week later, so the 4.3 line arrived as a burst of releases in April 2026. There is no stated support window, and the README does not promise compatibility beyond the iOS 14.0 to 17.0 range it names.

Upgrade cost is tied to how the tool is distributed. The package is a .deb or .zip from Havoc, and the Makefile signs the app and the CLI with ldid against TrollFools/TrollFools.entitlements at package time. An upgrade therefore replaces both binaries and re-signs them. Because injection edits target app binaries rather than TrollFools itself, upgrading TrollFools does not by itself undo or redo an injection; the README does not document any migration step for previously patched apps, and that silence is the thing to plan around.

The licence is MIT, per the repository metadata, and the README defers to the LICENSE file. MIT is permissive and permits redistribution and modification with the copyright notice retained. That is the extent of what the repository states; the LICENSE file is the authoritative text and the README does not restate it.

One dependency worth naming: the project credits ChOma, MachOKit and insert_dylib as external components. Those carry their own licences, and the README does not reproduce them. If you plan to redistribute a build, check each upstream licence separately rather than assuming MIT covers everything in the package.

What the README leaves undocumented

Several things a prospective user would want are simply absent. There is no install walkthrough beyond the Havoc link, no description of the SwiftUI screens, no list of supported dylib formats, no explanation of what "bare dynamic library" means in practice, and no uninstall instructions. The milestones section is a checklist of completed internal work, not user documentation.

The CLI is the clearest gap. The Makefile installs trollfoolscli to /usr/local/bin and the README never mentions it. A command-line injector would be the natural fit for scripted or repeated work, and the repository does not say what subcommands it accepts, what arguments it takes, or whether it can list already-injected apps. Anyone who needs automation should treat that binary as undocumented until they read its source under TrollFools/.

There is also no compatibility matrix for tweaks. The README names three app categories, not the libraries that work inside them. That is the question users will actually ask, and the repository does not answer it.

Editorial conclusion

TrollFools suits TrollStore users on iOS 14.0 to 17.0 who want a dylib inside a removable system app, a decrypted App Store app, or an encrypted App Store app with a bare dynamic library, and who accept that the modification is written into the app bundle itself. It does not suit anyone outside the TrollStore version range, anyone expecting a jailbreak-grade tweak loader, or anyone who needs a documented way back to the original binary. Before adopting it, confirm that TrollStore supports your iOS version, check the repository's LICENSE file for the exact MIT terms, and verify that your target app falls into one of the three limitation categories the README lists.

Frequently asked questions

Official sources

1. Lessica/TrollFools on GitHub
2. License: MIT
3. Project website
4. README
5. Releases