DEV Community: lich0

SLLVM - A unique OLLVM-based obfuscator

lich0 — Mon, 16 Mar 2026 08:39:45 +0000

Supported Systems and Architectures

Host Systems: Planned support for macOS/Linux; no current plans for Windows.
Target Systems: Planned support for macOS/iOS/Android.
Architectures: Both Host and Target support X64 and ARM64.
Languages: Supports C, C++, Objective-C, Objective-C++, Swift, Rust, Golang, etc.

Obfuscation Capabilities

Data Encryption
- CE Constant Encryption (String obfuscation).
Control Flow Obfuscation
- FLA Control Flow Flattening.
- BCF Bogus Control Flow.
- ECF Novel Control Flow obfuscation.
Function-Level Obfuscation
- FW Function Wrapper (Function nesting).
- FCC Function Calling Convention obfuscation.
Instruction-Level Obfuscation
- IBR Indirect Branch.
- ICALL Indirect Call.
- IGV Indirect Global Variable reference.
- SVC Supervisor Call (System call) obfuscation.
- SPLIT Instruction Splitting.
其他
- INLINE Function Inlining.
- SEC Anti-debugging/Security protection.

SLLVM Features

SLLVM was developed to address limitations in the OLLVM lineage (Hikari, Hikari-LLVM15, Pluto, Polaris-Obfuscator, goron, Arkari, o-mvll, etc.):

Release Compatibility: Obfuscation is not reverted by the compiler during Release builds.
Anti-Analysis: Resists "Read-Only Data Segment" attacks in IDA Pro; if data segments are marked read-only, obfuscation remains intact.
Hardening: Removes common OLLVM signatures to resist specialized scripts, symbolic execution (Angr), and AI-based deobfuscation.
Stability: Avoids compilation hangs and memory exhaustion often seen in other variants when processing large header-only libraries.

Configuration

In many real-world projects, fully obfuscating the entire codebase is often impractical due to the following reasons:

Project Scale and Dependencies: Large projects or those utilizing numerous header-only libraries may end up obfuscating unnecessary code, resulting in excessively large binary sizes.
Compilation Overhead: For massive projects with complex dependencies, applying flattening (or other methods) to unnecessary code can lead to extremely long compilation times or even system hangs.
Performance Impact: Obfuscating complex algorithms can significantly increase runtime latency; typically, control flow flattening adds over 10% to execution time.
Compliance Issues: Excessive obfuscation may violate the submission policies of platforms like the AppStore or GooglePlay.

In practice, it is often necessary to apply different levels of obfuscation based on the importance of specific modules or functions. This requires a configuration strategy to specify which targets receive which type of obfuscation. Traditional open-source OLLVM implementations usually manage strategies through the following methods:

Command-line Arguments: Specifying parameters for specific modules (e.g., -llvm -fla), which is compatible with all compiler front-ends supporting LLVM flags.
Environment Variables: Defining obfuscation parameters via the system environment.
Function Annotations: Using attributes like __attribute((__annotate__(("fla")))) (or the modern syntax [[clang::annotate("fla")]]); however, this is restricted to C/C++ and is not supported by Objective-C or other languages.
Marker Functions: Designating specific functions as markers, as shown below; this method provides support for Objective-C.

All of the aforementioned methods have their limitations—they either require intrusive code changes, fail to provide control at the function level, or are restricted to specific languages. This project utilizes a configuration file (sllvm.json) to define which functions and modules should be obfuscated, ensuring compatibility with the majority of compiler frontends and programming languages.

Primary/Secondary Fields

log_level Global logging level. String type, optional. Defaults to no logging. Possible values: info | debug
src_root Source file root path. String type, optional. Defaults to the current directory; typically does not need to be specified.
policies A list of strategies, divided into Module-level and Function-level policies. Module-level policies contain module and policy fields but no func field. Function-level policies include module, func, and policy fields.
- module A regular expression used to match module paths.
- func regular expression used to match function names. C++ functions are demangled before matching.
- policy String type; must correspond to a key defined in policy_map.
policy_map A strategy index referenced by policies. Each strategy name maps to a dictionary containing the following fields:
- base The name of a base policy to inherit from (module or function level). String type, optional. Value must be a key in policy_map.
- dump Types of intermediate code to output (saved in the sllvm_dump directory). Applies to module or function levels. String array, defaults to empty. Possible values: ir, mmd, asm.
- enable_std Enables obfuscation for C++ standard library functions. Module-level policy. Boolean type, optional. Disabled by default to minimize compatibility issues.

Function-level Policy

enable_ce Enables CE obfuscation.
- ce_size_min Minimum string length.
- ce_size_max Maximum string length.
- ce_algo Encryption/decryption algorithm.
- ce_mode_stack Enables stack-based string decryption.
enable_fla Enables FLA obfuscation.
- fla_prob Obfuscation probability for BasicBlocks.
- fla_force_reg Increases obfuscation strength.
- fla_use_igv Increases obfuscation strength.
- fla_use_dyn Increases obfuscation strength.
- fla_use_rcf Increases obfuscation strength.
- fla_blk_size Increases obfuscation strength.
- fla_invoke_op Compatibility for exception handling.
enable_bcf Enables BCF obfuscation.
- bcf_prob Obfuscation probability for BasicBlocks.
- bcf_complex Expression complexity.
- bcf_use_var Uses variables to construct expressions.
enable_ecf Enables ECF obfuscation.
- ecf_prob Obfuscation probability for BasicBlocks.
enable_fw Enables FW obfuscation.
- fw_loop_min Minimum number of function nesting layers.
- fw_loop_max Maximum number of function nesting layers.
- fw_exclude Sub-functions to exclude.
enable_fcc Enables FCC obfuscation.
- fcc_num Number of randomized calling conventions (Module-level).
- fcc_type Type of customized calling convention (Module-level).
- fcc_narg_reg Maximum number of parameters passed via registers (Module-level).
enable_ibr Enables IBR obfuscation.
- ibr_prob Obfuscation probability for BasicBlocks.
- ibr_use_igv Increases obfuscation strength.
- ibr_use_dyn Increases obfuscation strength.
enable_icall Enables ICALL obfuscation.
- icall_use_igv Increases obfuscation strength (Enabled by default).
- icall_use_dyn Increases obfuscation strength.
enable_igv Enables IGV obfuscation.
- igv_use_dyn Increases obfuscation strength.
enable_svc Enables SVC obfuscation.
- svc_usr_ir Increases obfuscation strength.
enable_split Enables SPLIT obfuscation.
- split_maxsize Maximum number of instructions per split segment.
enable_inline Enables INLINE obfuscation.
enable_sec Enables SEC obfuscation.
- sec_ad_prob Insertion probability for function anti-debugging logic.
- sec_usr_ir Increases obfuscation strength.

A typical SLLVM configuration file sllvm.json is as follows::

{
    "log_level": "info",
    "policy_map": {
        "mod_pol": {               
            "dump": ["ir"],
        },
        "func_pol": {               
            "enable_ce": true,
            "ce_size_min": 5,
            "ce_size_max": 128,
            "ce_algo": 0
        }
    },
    "policies": [
        {
            "desc": "Module-level policy",
            "module": ".*",
            "policy": "mod_pol"
        },
        {
            "desc": "Function-level policy",
            "module": ".*",
            "func": ".*",
            "policy": "func_pol"
        }
    ]
}

Supported Obfuscation Methods

String Encryption

Currently, SLLVM's CE supports arm64/arm64e, Objective-C constant strings, and stack-based decryption via ce_mode_stack. Unlike Hikari, which performs module-level obfuscation, SLLVM operates at the function level. This allows users to obfuscate all strings within specific functions, which is particularly useful for handling header-onlylibraries.

Key differences from Hikari:

Supports encryption algorithms beyond simple XOR.
Supports stack-based decryption(ce_mode_stack)

`ce_algo`

Used to configure the encryption/decryption algorithm. SLLVM currently supports 30 algorithms with complexity ranging from XOR to AES-level. Setting this value to 100 will select a random algorithm.

`ce_mode_stack`

This setting controls whether strings are decrypted on the stack. If ce_mode_stack is disabled, SLLVM utilizes the same approach as Hikari. The table below compares Hikari's method, SLLVM's S-mode (stack), and C++ template metaprogramming-based string obfuscation:

	`Hikari`	`SLLVM`S-Mode	C++ Template Metaprogramming
Encryption Location	Static Area	Static Area	Static Area / Immediate
Decryption Timing	Function Prologue	Function Prologue	Before Reference
Decryption Location	Static Area	Stack Area	Stack Area
Requires Source Change	N	N	Y
Complex Algorithms	Supported	Supported	Not Suitable

Notes:

Decryption Timing: Hikari decrypts once at the function prologue. While some other OLLVM-based projects decrypt in an initialization function, that method has the disadvantage of plaintext appearing in the static area immediately after decryption.
Language Support: C++ template methods are limited to C++. While languages like Rust have third-party libraries for similar results, all such methods require manual changes to the source code.

Important: Most OLLVM variants do not implement stack-based decryption because string constants are static data, making it difficult for the IR layer to determine if a string might "escape." In SLLVM, enabling ce_mode_stack demotes strings from static data to stack data, which requires specific handling.

Showcase

int main(int argc, char** argv) {
    printf("hello sllvm\n");
    return 0;
}

CE Static Area

CE Stack Area

Control Flow Flattening

Transforms control flow from sequential execution into a switch-case loop structure. Key differences from Hikari include:

Signature Weakening: Significantly reduces common FLA patterns, such as state variables, in-degrees, dispatcher blocks, and single-loop structures.
Exception Handling: While Hikari cannot handle functions with exception handling, SLLVM allows you to choose a specific handling method via the fla_invoke_op parameter.

展示

int main(int argc, char** argv) {
    if (argc <= 0) {
        printf("not possible\n");
    } else if (argc == 1) {
        printf("no args\n");
    } else {
        printf("%d args\n", argc - 1);
    }
    return 0;
}

FLA Full

Bogus Control Flow

Inserts "always-false" conditional branches into the sequential control flow. Key differences from Hikari include:

Release Stability: The obfuscation is not reverted or optimized away by the compiler during Release builds.
Resilience to Static Analysis: Resists "read-only data segment" attacks; the obfuscation remains intact even if the data segment is set to read-only in IDA Pro (this feature relies on bcf_use_var).

Showcase

int main(int argc, char** argv) {
    if (argc <= 0) {
        printf("not possible\n");
    } else if (argc == 1) {
        printf("no args\n");
    } else {
        printf("%d args\n", argc - 1);
    }
    return 0;
}

BCF Constant

BCF Variable

Novel Control Flow

A brand-new obfuscation approach designed to counter tracing and symbolic execution by tools like Angr.

Function Wrapper

Performs nesting on sub-functions directly called by the designated function. Key difference from Hikari:

The obfuscation is not reverted or optimized away by the compiler during Release builds.

Calling Convention Obfuscation

Converts standard C calling conventions into randomized ones, altering the registers used for parameters and return values. Currently, this is partially implemented for ARM64.

fcc_num Specifies the number of randomized calling conventions.
fcc_type Specifies the type of customized calling convention, with the following values:
- 0 Uses only registers X0~X8
- 1 Uses only integer registers.
- 2 Uses only floating-point registers.
- 10 Uses any available registers.
fcc_narg_reg Specifies the maximum number of parameters passed via registers; remaining parameters are passed via the stack.

Showcase

static int test(int a0, int a1, int a2, int a3, int a4) {
    printf("a0=%d\n", a0);
    printf("a1=%d\n", a1);
    printf("a2=%d\n", a2);
    printf("a3=%d\n", a3);
    printf("a4=%d\n", a4);
    return a0 + a1 + a2 + a3 + a4;
}

int main(int argc, char** argv) {
    test(argv[0][0], argv[0][1], argv[0][2], argv[0][3], argv[0][4]);
    return 0;
}

FCC usingX8(X8,X1,X6,...)

FCC usingD26(D26,D2,X15,...)

Indirect Branch

Key differences from Hikari:

The obfuscation is not reverted by the compiler when compiling in Release mode.
ibr_use_igv is similar to Hikari's indibran-enc-jump-target. When combined with ibr_use_dyn, it further enhances the obfuscation strength.

Showcase

int main(int argc, char** argv) {
    if (argc <= 0) {
        printf("not possible\n");
    } else if (argc == 1) {
        printf("no args\n");
    } else {
        printf("%d args\n", argc - 1);
    }
    return 0;
}

IBR Full

System Call Obfuscation

Converts standard system call functions into direct SVC (Supervisor Call) instructions.

Showcase

int main(int argc, char** argv) {
    int r = access("/tmp/1.txt", 0);
    printf("r=%d\n", r);
    return 0;
}

SVC Base

SVC Custom1

Instruction Splitting

Splits a function's instructions and scatters them across random addresses throughout the entire module.

Showcase

void test(int argc) {
    if (argc <= 0) {
        printf("not possible\n");
    } else if (argc == 1) {
        printf("no arg\n");
    } else {
        printf("%d args\n", argc - 1);
    }
}

int main(int argc, const char** argv) {
    if (argc <= 0) {
        printf("not possible\n");
    } else if (argc == 1) {
        printf("no arg\n");
    } else if (argc == 2) {
        printf("1 arg\n");
    } else {
        printf("%d args\n", argc - 1);
    }
    return 0;
}

SPLIT Full

Function Inlining

Inlines all sub-functions called by a specified function into the current function's body.

Security Protection

Inserts anti-debugging logic directly into the specified functions.

Implement ollvm with llvm pass

lich0 — Sat, 14 Feb 2026 04:14:57 +0000

Why `lich4/ollvm-pass` is worth attention among “hundreds of OLLVM open-source projects”

GitHub - lich4/ollvm-pass: Independent hikari

If you’ve been looking for OLLVM (Obfuscator-LLVM) related projects recently, you’ve probably run into a reality: there are tons of open-source repos, but not many that actually bring something new. Many projects mainly port classic implementations to newer LLVM/Clang versions—useful, but limited when it comes to real-world engineering adoption and controllable obfuscation.

lich4/ollvm-pass, however, has a very clear positioning: based on LLVM NewPassManager, it turns original OLLVM + Hikari-style implementations into standalone “passes,” and fills in what production use most often lacks— a policy system and Xcode integration.

1) Most mainstream OLLVM projects focus on “version compatibility,” not “engineering enhancements”

Common open-source OLLVM projects include:

obfuscator-llvm/obfuscator: the earliest public Obfuscator-LLVM, implementing classic features such as substitution / bogus control flow / flattening.
HikariObfuscator/Hikari: extends Obfuscator with string encryption, split basic blocks, function wrapping / call obfuscation, etc.
KomiMoe/Arkari (goron family): more focused on indirect calls/branches and adapts to newer LLVM.
za233/Polaris-Obfuscator: adds some MIR-level obfuscation beyond IR (e.g., dirty bytes, MIR instruction substitution).
open-obfuscator/o-mvll: emphasizes “Python-driven + pass manager,” with broad feature coverage.

The issue is: many derivative repos mainly add “compatibility with newer LLVM versions.” But in real engineering scenarios—“obfuscate only key modules/functions,” “don’t explode build time,” “don’t increase app store release risk”—they often don’t provide a systematic solution.

2) From “patching LLVM source” to “dynamic passes”: the modern way to do OLLVM

In the early days (LLVM 3.x era), OLLVM often meant directly modifying LLVM’s source, largely because the ecosystem and mechanisms weren’t mature. Today, most IR-level obfuscation can be done via pass plugins.

A simplified evolution of LLVM’s pass mechanism:

LLVM 5–12: primarily LegacyPassManager
LLVM 13–14: Legacy by default, also supports NewPassManager
LLVM 15–present: NewPassManager by default

Engineering advantages of dynamic passes (pass plugins)

This is one of the core values emphasized by lich4/ollvm-pass:

Avoid the massive cost of building LLVM/Clang: you can use the LLVM already installed on your system (Homebrew/apt, etc.) as long as the major Clang version matches.
Fast build and iteration: the output is typically just a few-MB dynamic library, not a hundreds-of-MB clang binary or multi-GB toolchain.
Better developer experience: writing passes, running them, validating IR output—iteration is faster and the barrier is lower.

That said, it’s important to acknowledge the boundaries: passes are hard to cover MIR/MC-level obfuscation (which is why projects like Polaris add MIR-level enhancements).

3) What `lich4/ollvm-pass` does: not “yet another port,” but a production-usable pass-based solution

The project description is straightforward: based on LLVM NewPassManager, it turns original OLLVM + Hikari into independent passes, verifying that “IR-level obfuscation can be implemented as standalone passes,” and it’s tested on macOS 15 + LLVM 15–19.

More importantly, it completes two capabilities that matter a lot for real adoption:

a) A “policy syntax”: precisely control obfuscation down to module/function via `policy.json`

In real projects, many teams aren’t unwilling to obfuscate everything—they can’t:

The project/dependencies are huge; obfuscating irrelevant code bloats artifacts
Heavy obfuscation (like flattening) slows builds drastically or even causes stalls
After obfuscation, runtime overhead can become obvious for complex algorithms (flattening often causes ~10% level overhead)
Over-obfuscation may increase compliance/review risk for App Store / Google Play (these points are explicitly mentioned in the README)

So in practice, “controllable obfuscation” matters more than “obfuscation exists.” Traditional open-source OLLVM controls are often either too coarse (module-only), too intrusive (requires code changes), or limited by language (e.g., annotations that mainly work for C/C++).

ollvm-pass’s approach: use a policy.json in the working directory to declare rules—compatible with most frontends and languages—distinguishing module-level and function-level strategies; also supports “forward override,” optional field comments, IR dump, and other engineering features.

You can think of it as: upgrading obfuscation switches from compiler flags / code intrusion to an auditable, reusable, version-controllable policy configuration—critical for large, multi-module, multi-language builds (especially on mobile).

b) Xcode integration: a realistic integration path for iOS/macOS projects

Many people hit the same pitfall: open-source clang ≠ Apple clang shipped with Xcode; pass plugins don’t always “just work” inside Xcode. ollvm-pass provides three practical routes in its README:

In Xcode, set CC to open-source clang and add -fpass-plugin in Other C Flags
In Xcode, set CC to a script: first clang -emit-llvm to produce bitcode, then run passes with opt, then clang -c to output an object file (the repo provides the author’s script xcode_cc.sh), and notes this is more friendly for arm64e compatibility
Build a dynamic pass specifically for Apple clang (hard: must handle symbol conflicts; better for LLVM experts)

The value here is: it doesn’t just say “it’s theoretically possible”—it lays out real, workable engineering integration paths, including ready-to-use scaffolding (scripts).

Who is this for?

You don’t want to build a multi-GB toolchain just for one OLLVM setup, and you want “compile the pass in minutes, validate immediately.”
You need “obfuscate only key modules/functions” in a real production codebase, and you want policies that are versioned and auditable
You target iOS/macOS (Xcode / Apple clang ecosystem) and want a practical integration path

If OLLVM is “just for running a demo,” then many porting repos are enough. But if you want it in production—controllable and maintainable—then the direction of pass-based + policy-based + Xcode-adapted like lich4/ollvm-pass is much closer to an engineering-grade answer.

DEV Community: lich0

SLLVM - A unique OLLVM-based obfuscator

Supported Systems and Architectures

Obfuscation Capabilities

SLLVM Features

Configuration

Primary/Secondary Fields

Function-level Policy

Supported Obfuscation Methods

String Encryption

ce_algo

ce_mode_stack

Showcase

Control Flow Flattening

展示

Bogus Control Flow

Showcase

Novel Control Flow

Function Wrapper

Calling Convention Obfuscation

Showcase

Indirect Branch

Showcase

System Call Obfuscation

Showcase

Instruction Splitting

Showcase

Function Inlining

Security Protection

Implement ollvm with llvm pass

Why lich4/ollvm-pass is worth attention among “hundreds of OLLVM open-source projects”

1) Most mainstream OLLVM projects focus on “version compatibility,” not “engineering enhancements”

2) From “patching LLVM source” to “dynamic passes”: the modern way to do OLLVM

Engineering advantages of dynamic passes (pass plugins)

3) What lich4/ollvm-pass does: not “yet another port,” but a production-usable pass-based solution

a) A “policy syntax”: precisely control obfuscation down to module/function via policy.json

b) Xcode integration: a realistic integration path for iOS/macOS projects

Who is this for?

References

`ce_algo`

`ce_mode_stack`

Why `lich4/ollvm-pass` is worth attention among “hundreds of OLLVM open-source projects”

3) What `lich4/ollvm-pass` does: not “yet another port,” but a production-usable pass-based solution

a) A “policy syntax”: precisely control obfuscation down to module/function via `policy.json`