Framework IR hardening, Crab Directed Hardening, and OLLVM

Teams that already use Crab’s Xcode-project confuse sometimes still need to protect a Framework they ship to other apps. That job is Crab Directed Hardening (小蟹定向加固): an IR-level pass on the Framework, in the same family as OLLVM. It is not a fork of the public OLLVM tree, and it is not the same button as language obfuscation or IPA hardening. Overview: Framework hardening. The same passes on the App binary are App hardening.

Why IR, and why OLLVM is the analogy

OLLVM (Obfuscator-LLVM) is known for transforming LLVM IR before codegen: control-flow flattening, bogus control flow, instruction substitution. Directed Hardening uses that same layer. While the Framework still has IR, the compiler can rewrite blocks and instructions without you maintaining a hand-garbled source tree. After object code is emitted, those passes no longer apply. That is why a stripped Dynamic Mach-O with no IR left cannot go through this entry—the same limit the FAQ states for confuse on Dynamic Mach-O.

What “directed” means

You point the pass at a Framework / SDK target, not at the whole host app. Host UI, plugins, and store resources stay on their own confuse or IPA path if you need fingerprint isolation. The SDK binary gets IR-level control-flow protection. Mixing the two without saying so in the trial request is how people get the wrong installer.

What it does not replace

IR hardening is the reverse-engineering layer. Compile-level obfuscation is the fingerprint layer (names, resources, call stacks). IPA hardening is for packages that never had a maintainable Xcode tree, such as uni-app. App Review still requires the listing to match the binary; see 2.3.1. If two host apps look related, start with 4.3 and the confuse flow, not with Framework IR alone.

Apply with the Framework bundle id or host Bundle Id + SDK name, and write 「Framework hardening」. Operator docs stay on the docs site.