Framework hardening: Crab Directed Hardening (IR-level, OLLVM-like)

Framework hardening

Crab Directed Hardening (小蟹定向加固) is an IR-level hardening path for iOS Frameworks and SDKs. It sits in the same family as OLLVM: passes run on LLVM IR, not on a renamed Xcode source tree and not on a packed IPA. Control-flow flattening, bogus control flow, and instruction substitution happen while the Framework still has IR, so the shipped Mach-O is harder to reverse without turning the host app into a full confuse project.

When this path is the right one

You ship a .framework (or a static library that will become one) to other apps, or you keep a self-built SDK inside your own product and need that binary protected on its own. You can still compile the Framework through Clang/LLVM. You do not want to run language-level renaming on the host app just to hide the SDK. To harden the host App binary itself at IR, use App hardening.

How it differs from the other two entries

Xcode-project obfuscation (Unity, Flutter, Cocos, native) changes symbols, resources, and call-stack shape for an app you will archive and submit. Uni-app IPA hardening works on an already packed IPA. Directed Hardening targets the Framework at IR, in the OLLVM style. Mixing the three entries is the usual mistake: dropping a prebuilt Dynamic Mach-O into the confuse flow, or feeding a Framework project into IPA hardening, both miss the IR.

What you still cannot skip

IR hardening raises reverse-engineering cost. It does not invent a new App Review fingerprint by itself, and it does not hide features from review. If two host apps look related, you still need the compile-level confuse path and honest listing metadata; see 4.3 and obfuscation vs hardening. A Framework that has already been stripped to a Dynamic Mach-O with no IR left is out of scope here, same as the confuse FAQ.

Request a trial with the Framework’s bundle id (or the host Bundle Id plus the SDK name) and write 「Framework hardening」. Detail on the IR passes: Framework IR hardening and OLLVM.