Troubleshooting

ld: file not found: /Library/Developer/Toolchains/Hikari.xctoolchain/***

This is due to Xcode's Default Toolchain, located at /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/ contains stuff not packed into Hikari.Just copy corresponding directories over.I intentionally didn't copy those over for releases due to copyright reasons. You could also run rsync -ua /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/ ~/Library/Developer/Toolchains/Hikari.xctoolchain/ to achieve this

mismatched subprogram between llvm.dbg.declare variable and !dbg attachment

On Release Builds of LLVM this should be a warning and won't crash compiling. Do note, however, that all debugging information is messed up so you probably won't be able to debug your program using Hikari. To silence this warning/error, turn off generating debug information. If you are invoking clang from command-line, this should be the default behaviour. Currently there is no plan to fix this issue Fixed in a88945@develop

Android/ELF Linking Issues

Due to probably some issues with Android Toolchain's Link Time Optimizations, you will probably get an error message like the following:

Warning: relocation refers to discarded section

In which case just add the following to the project's Linker Flags:

-Wno-error=all -Wl,--no-fatal-warnings

If someone knows more about ELF/Android than I do please let me know.

Darwin(iOS/macOS/tvOS/watchOS)/MachO Issues

fatal error: error in backend: Section too large, can't encode r_address (0x100006a) into 24 bits of scattered relocation entry. The obfuscated LLVM IR is way too complicated for proper relocation encoding in MachO, try adjust the obfuscation arguments a bit. Reference: lib/Target/X86/MCTargetDesc/X86MachObjectWriter.cpp

Other Apple Compatibility Issues

Apple's Xcode uses a modified LLVM 6.0(~) to speed up build time and stuff. While Apple has stated they do plan to backport their changes back to the open-source LLVM, so far directly using LLVM upstream in Xcode still has some compatibility issues.

• -index-store-path can not specify -o when generating multiple output files These two issues can be solved by turning off Enable Index While Building ACROSS THE WHOLE PROJECT, INCLUDING SUB-PROJECTS Note that for whatever reason that I have no interest in figuring out, newer Xcode versions seems to be ignoring this setting and still pass that option back nevertheless. This is a known bug and I honestly don't have the mood or the interest to even attempt to fix it.

It's probably less troublesome to port Hikari back to Apple's SwiftLLVM, which you can find a simple tutorial on my blog, that being said setting the source up for the port is not for the faint-hearted and each compilation takes more than three hours.

Or alternatively, you could try using HikariObfuscator/Hanabi which injects the obfuscation code into Apple Clang, this is the least stable implementation but it at least works straight out of the box

AArch64e Support

Until Apple contributes their AArch64e LLVM backend back to LLVM upstream (Which to my best knowledge is something AAPL has decided to do so but hasn't done it yet), there is little that me (or anyone except ARM engineers) could do to add such support. You have two alternative approaches listed below

Noctilucence

You can use Noctilucence to emit the obfuscated LLVM Assembly and reuse Apple Clang to compile it back to object file.

• Use Hikari's branch that corresponds to your Xcode version (release_60 is the one you are looking for unless you are using some super old Xcode Installation)
• Follow the guide in Noctilucence to clone that component has well
• Compile the full tree
• Compile your project as usual with FULL BITCODE
• Invoke Noctilucence -i /PATH/TO/BINARY -o OUTPUT/PATH -dump-ir OTHER_OBFUSCATION_FLAGS
• The program might abort due to the lack of AArch64e backend, ignore the crash and find the file OUTPUT/PATH.ll
• Use Apple Clang to compile and link this file normally, note that you might need to manually setup target triple and SDKRoot and stuff. Google if you don't know how to. The command you are looking for is something like clang FLAGS_SETTING_TRIPLES_AND_STUFF -c -o /PATH/TO/COMPILED_OBJECT
• Link normally with all the link flags. The output from Noctilucence that begins with Extracted Linker Flags: serves as the base for the flags required, just add /PATH/TO/COMPILED_OBJECT -o /PATH/TO/LINKED/PRODUCT -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/" "iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk (or whatever SDKROOT you prefer)
• Done

Note that due to the version mismatch and many other small obscure issues this approach might fail. Keep reading

Hanabi

You can use Hanabi which injects Obfuscation into Apple Clang which should, in turn, provides maximum compatibility although some passes won't be usable, check the README of that repo.