---

Por que scLock?

Binários macOS Mach-O (arm64) padrão compilados a partir de C, C++, Rust, Swift ou Objective-C expõem grafos de fluxo de controle limpos e constantes em texto claro no Ghidra, IDA Pro e Binary Ninja em questão de segundos. Obfuscadores de software convencionais dependem de uma única chave estática ou de um dispatcher central switch(opcode) onde a recuperação de uma chave despeja todo o fluxo de bytecode.

scLock (Supercluster Lock) combina virtualização polimórfica de 256 slots em tempo de compilação, fragmentação de chaves MBA por handler e vinculação em dois níveis ao Apple Silicon Secure Enclave (SEP):

1. ISA Polimórfica de 256 Slots por Build + 84 Armadilhas Chaff: Cada compilação (sclock compile) sintetiza um conjunto de instruções totalmente novo com 256 entradas (172 micro-ops ativas + 84 handlers chaff que corrompem o estado) a partir de uma seed polimórfica de 64 bits. Nunca duas builds compartilham a mesma codificação de bytecode ou tabela de handlers.
2. Fragmentação de Salt MBA com Entrelaçamento em Runtime por Handler (black_box + vm.anchor): Mesmo quando um analista calcula as chaves externas do sponge (k0, k1) no modo Portable, os pacotes de bytecode não podem ser descriptografados a partir de tabelas estáticas ou constantes imediatas. Os salts brutos dos handlers (op_secret_salt) são omitidos das seções de dados estáticos (substituídos por ANCHOR_SHARDS unidirecionais Davies-Meyer) e pré-mascarados contra a âncora de integridade de código. Dentro de cada um dos 256 handlers ARM64 compilados (__sc_lut_op_000..255), h_salt e as máscaras de operandos (hm1, hm2, hm3) são reconstruídos em runtime combinando parâmetros afins protegidos por std::hint::black_box com o vm.anchor ativo ([x0, #0xa0]) através de polinômios MBA não lineares—derrotando o constant folding do LLVM (-C opt-level=3) e a simplificação do InstCombine.
3. Aritmética Booleana Mista Não Linear ($\mathbb{Z}_{2^{64}}$) & Bijeções 2-ádicas: Aritmética, multiplicação, constantes e transições de fluxo de controle são elevadas a identidades MBA não lineares de grau 2/3 sobre $\mathbb{Z}_{2^{64}}$ acopladas a predicados opacos número-teóricos 2-ádicos ($7x^2 - 1 \neq y^2 \pmod{2^{64}}$).
4. Arquitetura Dual-Tier Apple Secure Enclave (SEP):
   • Modo Multi-Mac Portátil (Padrão, SCP1): Construído para distribuição universal de usuário final no macOS e para o CrackMe público, de modo que o binário roda offline em qualquer Mac Apple Silicon (M1 / M2 / M3 / M4). Deriva as chaves externas do sponge (k0, k1) via um KDF White-Box Code-Anchor SHA-256 de 1.024 rodadas emparelhado com um Gate Anti-Emulação / Anti-Hooking de Duplo-ECDH Comutativo P-256 com SEP Ativo ($d_{\text{SEP}} \cdot Q_P \stackrel{?}{=} d_P \cdot Q_{\text{SEP}}$ executado no Secure Enclave para envenenar a execução sob emuladores não-SEP ou hooks de API). Como a execução offline em todos os Macs exige derivação determinística de chaves, a defesa contra extração estática no SCP1 é fornecida pela fragmentação de salt MBA com entrelaçamento em runtime por handler (vm.anchor + black_box) e pelo encadeamento de sponge dependente de estado em todos os 256 handlers.
   • Modo Node-Locked por UID de Hardware (--sep-lock / --host-sep-lock): Sela a chave privada P-256 diretamente dentro do UID físico do Secure Enclave do Mac alvo (blob rk1/dacl encapsulado em hardware kSecAttrTokenIDSecureEnclave). Nenhum material de chave desselável existe em qualquer lugar do binário Mach-O—a derivação offline de chaves é fisicamente impossível sem o silício do Secure Enclave do Mac alvo.
5. Entrelaçamento de Estado Anti-Debug Sem Branches & Camuflagem Zero-Leak: Em vez de branches patcháveis if (is_debugged) exit(), o scLock mistura o bit P_TRACED do sysctl do kernel e varreduras de BRK (0xD4200000) do prólogo ARM64 diretamente no acumulador de estado do sponge de 256 bits, com limpeza automática de símbolos e caminhos de toolchain (sclock protect-app).

---

Desafio Público de Engenharia Reversa (CrackMe)

Não acredite apenas na nossa palavra—teste o scLock no seu próprio disassembler e debugger agora mesmo.

Este repositório inclui um binário Mach-O arm64 autônomo protegido pelo scLock (v1.0.0, compilado no modo Portable SCP1 para rodar em qualquer Mac Apple Silicon):

• Caminho do Binário: crackme/challenge_protected (ou baixe scLock-CrackMe-Challenge-macOS-arm64.zip)
• Arquitetura: Mach-O 64-bit executable arm64 (Apple Silicon M1 / M2 / M3 / M4)

Execute & Audite Você Mesmo

# 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>

O Objetivo do Desafio

Abra crackme/challenge_protected no Ghidra, IDA Pro, Binary Ninja ou LLDB e tente:

1. Recuperar todos os 256 sais MBA por handler (h_salt) e descompilar a rotina virtualizada de precificação/verificação sem acionar o timeout do descompilador do Ghidra (>330s).
2. Anexar o lldb e percorrer o loop de despacho virtualizado sem corromper o estado do sponge entrelaçado com P_TRACED.
3. Encontrar o PIN mestre secundário oculto de 4 dígitos (arg2 != 1234) e as constantes exatas de mistura algébrica de 64 bits dentro da rotina virtualizada.

Encontrou uma análise ou write-up interessante? Publique-a na Issue #1 (Tópico Oficial do Desafio CrackMe)!

---

Benchmarks Empíricos

Testado em Apple Silicon (macOS arm64, perfil Release):