Documentation

Protection, minus the complexity.

Obsidian is a software-protection suite for Windows (C++). Same engine, two front doors: a drop-in binary packer for finished executables, and a build-time SDK for deeper, per-function protection.

Last updated: October 2026 · Free tier available now · Pro coming soon

1. What Obsidian is

Obsidian protects software you own against casual copying, static inspection, and trivial patching. It is in the same legitimate category as VMProtect and commercial anti-tamper products.

Two integration models, one engine:

• A. The Protector (binary packer). A portable protector.exe. Point it at any compiled .exe, get one protected .exe back. No source changes, no recompile. Works on any finished binary because it operates on the finished file. This is the universal on-ramp and the showcase piece.
• B. The SDK / framework. A header-only C++ library plus a build step. One include, a generated config file, per-function protection levels. Deeper and context-aware: it understands your source, so it can do things a finished binary no longer allows (convincing decoys, control-flow flattening on chosen functions).

2. Quickstart (Free)

Packer (any compiled x64 PE)

build\protector.exe <input.exe> <output.exe> [keyhex]

Or use the desktop tool: drop an .exe in, keep Section Encryption checked, click Pack. The current engine encrypts .text (all) plus string-bearing gaps in .rdata with a per-build key, injects a small decrypt stub in a new .obx section, and redirects the entry point to it. At launch the stub decrypts in memory and jumps to the original entry point. The program runs identically.

Status: the v2 packer is built and verified on 20 real binaries (system utilities, Notepad, MSVC and Rust/Tauri targets, TLS binaries). Imports stay visible for now (the loader needs them); import hiding via runtime IAT rebuild is a later pass. ASLR is currently disabled on output (fixed base); a relocation-aware stub is planned.

SDK (compile-time string encryption, Step 1a)

#include "prot/obfuscate/string_encrypt.hpp"

auto key = OBFSTR("super-secret-api-key");
send(key.get());

OBFSTR(s) encrypts the literal at compile time; only ciphertext lands in the binary. The plaintext exists briefly in memory on .get() and is scrubbed when it leaves scope. Verified under /O2: control plaintext present, all secrets absent from the binary. Remaining SDK passes (API hashing, opaque predicates, stack strings, junk code) are next.

Runtime (statically linked, never a dropped DLL)

Basic anti-debug (IsDebuggerPresent, PEB BeingDebugged / NtGlobalFlag, timing) and CRC-32 .text integrity self-check are built and tested in isolation. They wire into packed output as the packer matures.

3. Protection levels and tiers

Per-function dial: none / low / medium / high / maximum. Free caps at medium. Pro unlocks high + maximum. Perf-critical code (render loops) should stay at none.

Free is genuinely solid commodity friction from public techniques: stops casual reversers cold, slows decent ones. Pro is the moat pieces - harder builds, server-tied features, and leak-tracing (per-license watermarking) that make cracks go stale and traceable.

4. How each piece works

Packer pipeline

Parse PE (headers, sections, imports, relocations, TLS) → encrypt sections → embed runtime + stub → rewrite headers + redirect entry → write protected output. The stub bootstraps without imports (PEB walk + API hashing), decrypts sections in memory, applies relocations, checks integrity, jumps to the original entry point. TLS binaries get the stub as the first TLS callback instead of an entry redirect.

Key-folded tamper response

The stub derives its decrypt key from the stored key plus a checksum of the encrypted .text plus a debugger term. A patched byte or a debugger at launch yields a wrong key and the process faults instead of leaking. The check cannot simply be NOP'd out - removing it still yields the wrong key.

VEH keystone (Pro, maximum)

Protected functions stay encrypted in memory behind NO_ACCESS pages. A call faults into a vectored exception handler that decrypts just that function, runs it, and re-encrypts after. One function decrypted at a time means a dump never catches the whole app. Slow by design - crown jewels only. The same handler plumbing also powers nanomites and guard pages.

5. Updates and backend

Free needs zero server contact: grab the packer or SDK, protect, done.

Pro tools and protected apps talk to a Cloudflare Worker + R2 + KV backend that serves signed, verified, atomic updates:

• Releases are hashed and signed offline with an Ed25519 key you hold. The server never holds signing secrets.
• Clients fetch the manifest envelope, verify the signature against the embedded public key, then check every artifact's SHA-256 before swapping anything in.
• Publishing is atomic: artifacts upload first, the current-version pointer flips last. A half-publish is never served.
• Any failure (network, bad signature, hash mismatch) keeps the last-known-good version and keeps running - updates never brick the app.

Online Pro features (license checks, server-side rotation seeds, metered storage) are cached client-side with a short TTL and degrade gracefully with a grace window when unreachable.

6. Antivirus and false positives

A from-scratch packer looks like malware to heuristic scanners - encrypted sections mean high entropy, and analysis resistance is the malware signature. Zero detections is not achievable; minimize plus remediate is the plan:

• Everything is signed from day one (reputation is time-based).
• Runtime is statically linked - never a dropped-and-injected DLL.
• Everything stays in the binary's own process. No remote injection, no disk drops.
• Customers sign their own protected output so it inherits their reputation.
• False-positive submission and allowlisting pipeline with major vendors, plus a known-issues note.
• Strict Terms plus key revocation keep the tool from becoming malware-associated - which is also AV-reputation defense.

7. Honest threat model

Every client-side method is friction, exposure-window shrinking, or cost-raising - not a wall. Code must materialize decrypted in memory to run, so reverse engineering is ultimately always possible. Static hiding forces attackers to dynamic analysis; a brief decryption window is defeated by freezing execution; a hypervisor below the OS beats all of it (elite, rare, and economically pointless against indie targets - not the threat model).

The real security is server-side authority (the one place code does not appear in front of the attacker) plus update cadence (being faster than attackers can analyze). Who Obsidian builds for: script kiddies stopped cold, decent reversers slowed and kept chasing updates, elite manual crackers slowed at real cost. Nothing here is or claims to be uncrackable - the public crackme/CTF is framed as “flag's inside, show us your writeup,” never “unbeatable.”

8. FAQ

Does Free phone home?

No. The free packer and SDK are fully offline. Zero server contact.

Will it break my app or tank performance?

Packed outputs are tested to behave identically to originals. Use per-function levels: none on hot loops, maximum only on crown jewels (license checks). Each level ships with a perf estimate.

What stops someone from patching out the license check?

Layering, not any single check: integrity self-checks, delayed/displaced tamper responses, and - for Pro - gated delivery, where never-paid bytes never reach the PC at all. A local patch cannot conjure bytes the server never sent.

What happens if I stop paying for Pro?

Perpetual fallback: existing builds keep working. No new builds, rotation goes stale, no new passes or updates until renewal.

Is there a trial?

A time- or feature-limited Pro evaluation key is planned. Not available yet.

← Back to Obsidian · Terms of Service · Privacy Policy