• Security is not now, and will never be based purely on Obscurity.The "Security Companies" might say so to sell more of their products. But no,binary obfuscation won't magically fix all your exploits and bugs,(If not introducing more)
• Designing an Obfuscator is hard, and keeping the source open definitely leak the pattern to crackers which could potentially made the crackers's life easier if they have the right skillset. While every reasonable attempt has been made in Hikari to reduce such pattern from appearing, however, with overkill weapons like symbolic execution, binary obfuscation can still be defeated much easier, even so called VM-based obfuscation. DOI 10.1145/2991079.2991114 explained this in great detail. I would implement a few anti-SE mechanism in the future in an attempt to cause (even) more trouble to attackers, though.

Hikari is an improvement over Obfuscator-LLVM with a few extra custom built passes and (hopefully not) bugs. Testing is done through running Hikari on my own project WallpaperKit. You can find an obfuscated version of WallpaperKit.framework Here.Built on 2018/03/12

• Minimal Impact. That is to say, the core of Hikari should be easily portable to any new compiler using LLVM as its backend.
• Focus on the compiler. That is to say, we tend not to add features that requires external libraries. For example, class/method name obfuscation in Objective-C, which is best to be handled at frontend or external libClang-based tools
• Keep it abstract. That is to say, we tend to do the Obfuscation at IR stage instead of backend which (most of the time) is platform-specific.Unless there is valid reason to do so.

Set up the toolchain according to the wiki page Compile & Install.

All obfuscation passes are recorded in the seperate Usage wiki page.