Since Apple’s Development Tools contains a bunch of modifications that will probably never see its day in LLVM upstream and Swift contains the latest open-source Apple fork of LLVM at the moment. It’s probably wise to port Hikari to Swift instead of using the upstream.

@Ouroburos sent me a IR which crashes Obfuscator-LLVM. So the investigation begin.

I’m preparing a new StringEncryption pass for Hikari, aim to fix various drawbacks from previous implementations.
The most famous one among those implementations would be GoSSIP-SJTU/Armariris
You can read the pass’s full source HERE

The current implementation of AntiDebugging is simply inject Inline Assemblies at function start and only works on iOS.
Since it’s now possible to do sysent hook on (certain versions of) iOS. Inline ptrace() alone is no longer safe.
Here is a few more ideas to be implemented.

By design,Function CallSite Obfuscation aims to replace direct call/invoke instructions with dlsym() equivalents at IR Level.
Symbol Obfuscation also suffers from the exact same issues

The core idea of acd is to extract ObjC class informations and create everything at a program-controlled stage instead of letting libObjC do the initialization for us.

For all Neowiz games. A similar API protocol is used.

During my random browsing of PPHelper, China’s largest “assistant” that provids download of cracked softwares as well as serving
as a 2nd AppStore itself, we found one of the games contains a strange Adware not seen in its AppStore Version.

Overall it’s a pretty boring case since the native calls are not obfuscated

So recently I was researching a method regarding a better binary protection technique on iOS. Ideally VMProtect-like.

This is a note following my post back in april regarding short function hooking.