---

Warum scLock?

Standard-macOS-Mach-O-Binaries (arm64), die aus C, C++, Rust, Swift oder Objective-C kompiliert wurden, legen in Ghidra, IDA Pro und Binary Ninja innerhalb von Sekunden saubere Kontrollflussgraphen und Klartext-Konstanten offen. Herkömmliche Software-Obfuskatoren setzen auf einen einzelnen statischen Schlüssel oder einen zentralen switch(opcode)-Dispatcher, bei dem die Wiederherstellung eines einzigen Schlüssels den gesamten Bytecode-Stream preisgibt.

scLock (Supercluster Lock) kombiniert compile-time 256-Slot-polymorphe Virtualisierung, MBA-Key-Shattering pro Handler und zweistufige Bindung an die Apple Silicon Secure Enclave (SEP):

1. Pro-Build 256-Slot-polymorphe ISA + 84 Chaff-Fallen: Jede Kompilierung (sclock compile) synthetisiert aus einem 64-Bit-polymorphen Seed einen brandneuen 256-Einträge-Instruktionssatz (172 aktive Mikro-Ops + 84 zustandskorruptierende Chaff-Handler). Keine zwei Builds teilen jemals dieselbe Bytecode-Kodierung oder Handler-Tabelle.
2. Pro-Handler-Laufzeit-verschränktes (black_box + vm.anchor) MBA-Salt-Shattering: Selbst wenn ein Analyst die äußeren Sponge-Schlüssel (k0, k1) im Portable-Modus berechnet, können Bytecode-Pakete nicht aus statischen Tabellen oder unmittelbaren Konstanten entschlüsselt werden. Rohe Handler-Salts (op_secret_salt) werden aus statischen Datensektionen weggelassen (ersetzt durch Einweg-Davies-Meyer-ANCHOR_SHARDS) und gegen den Code-Integritäts-Anker vorab maskiert. Innerhalb jedes der 256 kompilierten ARM64-Handler (__sc_lut_op_000..255) werden h_salt und Operanden-Masken (hm1, hm2, hm3) zur Laufzeit rekonstruiert, indem std::hint::black_box-geschützte affine Parameter mit dem Live-vm.anchor ([x0, #0xa0]) durch nichtlineare MBA-Polynome kombiniert werden – was LLVM (-C opt-level=3) Constant Folding und InstCombine-Vereinfachung besiegt.
3. Nichtlineare gemischte boolesche Arithmetik ($\mathbb{Z}_{2^{64}}$) & 2-adische Bijektionen: Arithmetik, Multiplikation, Konstanten und Kontrollfluss-Übergänge werden in nichtlineare MBA-Identitäten vom Grad 2/3 über $\mathbb{Z}_{2^{64}}$ gehoben, gekoppelt mit zahlentheoretischen 2-adischen opaken Prädikaten ($7x^2 - 1 \neq y^2 \pmod{2^{64}}$).
4. Zweistufige Apple Secure Enclave (SEP)-Architektur:
   • Portable Multi-Mac-Modus (Standard, SCP1): Entwickelt für universelle Endbenutzer-macOS-Verteilung und das öffentliche CrackMe, damit die Binärdatei offline auf jedem Apple Silicon Mac (M1 / M2 / M3 / M4) läuft. Leitet die äußeren Sponge-Schlüssel (k0, k1) über eine 1.024-Runden-SHA-256-Code-Anchor-White-Box-KDF ab, gepaart mit einem Live-SEP-kommutativen P-256-Double-ECDH-Anti-Emulations-/Anti-Hooking-Gate ($d_{\text{SEP}} \cdot Q_P \stackrel{?}{=} d_P \cdot Q_{\text{SEP}}$, ausgeführt auf der Secure Enclave, um die Ausführung unter Nicht-SEP-Emulatoren oder API-Hooks zu vergiften). Da die Offline-Ausführung auf allen Macs eine deterministische Schlüsselableitung erfordert, wird die statische Extraktionsabwehr in SCP1 durch pro-Handler-Laufzeit-verschränktes (vm.anchor + black_box) MBA-Salt-Shattering und zustandsabhängige Sponge-Verkettung über alle 256 Handler bereitgestellt.
   • Hardware-UID-Node-Locked-Modus (--sep-lock / --host-sep-lock): Versiegelt den P-256-Privatschlüssel direkt in der physischen Secure Enclave UID des Ziel-Macs (hardware-umhüllter kSecAttrTokenIDSecureEnclave-rk1/dacl-Blob). Es existiert keinerlei entsiegelbares Schlüsselmaterial irgendwo in der Mach-O-Binärdatei – eine Offline-Schlüsselableitung ist ohne das Secure-Enclave-Silizium des Ziel-Macs physisch unmöglich.
5. Zweiglose Anti-Debug-Zustandsverschränkung & Zero-Leak-Tarnung: Anstatt patchbarer if (is_debugged) exit()-Verzweigungen mischt scLock das Kernel-sysctl-P_TRACED-Bit und ARM64-Prolog-BRK- (0xD4200000) Scans direkt in den 256-Bit-Sponge-Zustandsakkumulator, mit automatischer Bereinigung von Symbol- und Toolchain-Pfaden (sclock protect-app).

---

Öffentliche Reverse-Engineering-Herausforderung (CrackMe)

Verlassen Sie sich nicht auf unser Wort – testen Sie scLock jetzt in Ihrem eigenen Disassembler und Debugger.

Dieses Repository enthält eine eigenständige Mach-O-arm64-Binärdatei, die durch scLock geschützt ist (v1.0.0, kompiliert im Portable-SCP1-Modus, sodass sie auf jedem Apple Silicon Mac läuft):

• Binärpfad: crackme/challenge_protected (oder laden Sie scLock-CrackMe-Challenge-macOS-arm64.zip herunter)
• Architektur: Mach-O 64-bit executable arm64 (Apple Silicon M1 / M2 / M3 / M4)

Führen Sie es aus & prüfen Sie es selbst

# 1. Clone this repository (or unzip the release archive)
git clone https://github.com/planners1490/sclock.git
cd sclock/crackme

# 2. Clear macOS Gatekeeper quarantine (if downloaded via browser) & make executable
xattr -cr ./challenge_protected
chmod +x ./challenge_protected

# 3. Inspect symbol table & strings (Zero VM/Obfuscator leaks)
nm -gU ./challenge_protected
strings ./challenge_protected | grep -iE "sclock|vm|opcode|mba|chaff" || echo "0 leaks found"

# 4. Execute the protected binary on any Apple Silicon Mac
./challenge_protected            # Runs built-in self-test (seats=20, pin=1234 -> 83300)
./challenge_protected 20 1234    # Pass custom <seats> <unlock_pin>

Das Ziel der Challenge

Öffne crackme/challenge_protected in Ghidra, IDA Pro, Binary Ninja oder LLDB und versuche:

1. Alle 256 MBA-Salts pro Handler (h_salt) wiederherzustellen und die virtualisierte Preis-/Verifikationsroutine zu dekompilieren, ohne Ghidras Decompiler-Timeout (>330s) auszulösen.
2. lldb anzuhängen und die virtualisierte Dispatch-Schleife schrittweise zu durchlaufen, ohne den mit P_TRACED verschränkten Sponge-Zustand zu beschädigen.
3. Die versteckte sekundäre 4-stellige Master-PIN (arg2 != 1234) und die exakten 64-Bit algebraischen Mischkonstanten innerhalb der virtualisierten Routine zu finden.

Eine interessante Analyse oder einen Write-up gefunden? Poste ihn in Issue #1 (Offizieller CrackMe-Challenge-Thread)!

---

Empirische Benchmarks