Just-in-time Optimized Compiler Kernel for sYstems

The forensic-first systems programming language.

JOCKY is a programming language and compiler ecosystem built for low-level control, security and traceability, with first-class support for practical digital-forensics workflows.

Checking GitHub for the latest release…

The obfuscator is not a plugin — it's the heart of the compiler.

jocky · compiler pipeline
  1. Lexersource → tokens
  2. Parsertokens → AST
  3. Semantic analysisnames, scopes
  4. Type checkingtyped AST
  5. LLVM IR generationAST → IR
  6. Combined ObfuscationIR → polymorphic IR
  7. Optimization passesobfuscated IR → optimized
  8. Machine codevia LLVM
8-layer obfuscation runs simultaneously after LLVM IR generation — before optimization. How the compiler works →

Get Started

Get the toolchain, build it, and find your way around the language documentation.

Start here

Download

Release builds are published on GitHub. You can also build JOCKY from source.

Downloads

Docs

The language guide, compiler internals and contributor documentation.

Read the docs

Discussions

Ask questions, propose language features and share what you're building.

Join the conversation
What JOCKY is for

Systems programming with forensics in mind

Most languages treat investigation and traceability as someone else's problem. JOCKY builds them into the language, the compiler and the tooling.

Low-level control

Write code that sits close to the machine, with direct control over how your program is laid out and runs.

Security

Security is a design goal of the language and compiler from the start, not a layer added afterwards.

Traceability

Understand what your code became, from source through each compiler stage to the final binary.

Forensic workflows

Language features and tooling aimed at practical digital-forensics work.

LLVM backend

JOCKY generates LLVM IR and runs its own optimization passes before producing machine code.

The Obfuscator

8 simultaneous layers. Every build looks like a different program.

The JOCKYShield Obfuscator doesn't just pack the binary — it transforms it at the IR level. Eight independent obfuscation passes run simultaneously after LLVM IR generation, each making the next harder to analyze. By the time LLVM optimization sees the IR, it's already unrecognizable.

combined obfuscation — 8 layers
  1. CMOV control flowno branching — flat CFG
  2. Runtime-derived keysBLAKE2b XOR · no static blobs
  3. Opaque predicate gatesmathematical routing · no junk
  4. Decoy function chainslegit-looking · real dead ends
  5. Polymorphic symbolsdictionary-driven · no hex prefixes
  6. Dispatch type rotationper-build dispatcher selection
  7. Synthetic call graphpoisoned · looks real
  8. Stack frame randomizationshifting offsets · no fixed layout
Each pass runs simultaneously — not sequentially. The layers compound to create high LLM resistance against static analysis.

Why simultaneous, not sequential?

Research into LLM-powered deobfuscation shows that single-layer obfuscation is progressively transparent — modern AI models can deobfuscate CFG flattening, string XOR, and polymorphic symbols individually. But the research consistently finds universal failure against combined techniques.

By applying all 8 layers at once — each layer obscuring a different detection vector — the obfuscator defeats:

  • Static analysis — encrypted strings, no plaintext .rdata, unique hash per build
  • YARA rules — no fixed byte patterns, polymorphic symbols each build
  • Behavioral telemetry — decoy functions, legitimate API patterns
  • LLM deobfuscation — combined techniques create high resistance
  • Kernel callbacks — indirect syscalls, ETW layering

Latest Releases

All news

Loading releases from GitHub…

Community

More

Help build JOCKY

You don't need to be a compiler engineer. Fix a bug, improve the docs, add tests or propose a language feature. Contributors of every experience level are welcome.

Ways to contribute Source on GitHub