WELCOME TO CRACKMY.APP

Windows x64 native license-key crackme with layered LLVM-based obfuscation. Goal: find a key that makes the program print "license accepted" and exit with code 0. Run: crackmy_license_challenge.exe KEY Notes: - Windows x64 native console challenge. - No network checks. - No external loader. - Submit the accepted key as the solution.

**Platform:** Windows (x86_64), Linux (x86_64) **Difficulty:** Insane --- ## Description ShadowCrack is a multi-platform, multi-layered crackme designed to push reverse engineering skills to the absolute limit. It is not just a simple serial checker; it is an entire ecosystem of anti-analysis, cryptographic packing, and runtime virtualization. The challenge runs through a stub packer that decrypts an internal payload directly into memory (never touching disk), which then executes a custom 150-opcode Virtual Machine to validate the serial key. The same source tree compiles to native binaries for both Windows and Linux, sharing identical challenge logic but utilizing platform-specific anti-tampering and anti-debugging primitives. ## Protections Implemented The following protections are present in the binary. Figure them out yourself. ### 1. Cryptographic Packing (5-Layer Stub) The inner payload is never written to disk in plaintext. It is encrypted with 5 layers of ciphers and decrypted directly into RW memory, which is then transitioned to RX. - **Layers:** Salsa20 → XTEA → Speck64/128 → RC4 (drop-1024) → ChaCha20. - **Extraction Prevention (Linux):** Uses `memfd_create` with `MFD_CLOEXEC`. Memory is `secure_zero`'d, set to `PROT_NONE`, and `munmap`'d before the child process is even executed. - **Extraction Prevention (Windows):** Uses temporary files with `FILE_FLAG_DELETE_ON_CLOSE` and `FILE_SHARE_READ` only. Memory buffers are securely freed immediately after writing. - **Anti-Dump:** The memfd is closed in the parent process *before* `wait4` completes, closing the window for `/proc/PID/mem` dumps. ### 2. Custom Virtual Machine (150 Opcodes) Serial validation does not happen in native code. It is executed inside a custom VM. - **Architecture:** 16 64-bit registers, custom stack, call stack, and built-in SHA-256 state. - **Control Flow:** Control-flow-flattened dispatcher with polymorphic dispatch tables. - **Self-Modifying Code (SMC):** The VM periodically rotates its own dispatch table during execution. - **VMProtect-style Mutation:** Bytecode is mutated at compile-time with dead-code sequences and NOP sleds, and at runtime using `OP_MUTATE`, `OP_PERM_REG`, and `OP_JUNK_INSERT`. - **Anti-Patching:** There are no `je fail` / `jne fail` branches. Tamper checks are woven directly into the VM's key schedule using XOR operations. Patching a check silently corrupts the serial validation logic. ### 3. External DRM Daemon (16-Layer Watchdog) The main binary is accompanied by an external DRM daemon (`opress_drm` / `opress_drm.exe`) that acts as an aggressive watchdog. - **Process Surveillance:** Deep scans of `/proc/PID/maps`, `/proc/PID/fd/*`, and `cmdline` (Linux) or `EnumProcessModules` / `VirtualQueryEx` (Windows). - **Anti-Debugger on itself:** Checks `TracerPid`, `PTRACE_TRACEME`, `IsDebuggerPresent`, `NtQueryInformationProcess`, and hardware breakpoints (Dr0-Dr7). - **Watchdog Child:** Forks/Creates a detached process that kills the target if the DRM daemon dies. - **Response:** Any detection sends a `SIGUSR1` / `SetEvent` to the target to corrupt the VM. Sustained detections result in immediate `SIGKILL` / `TerminateProcess(0xDEADBEEF)`. ### 4. Embedded Anti-Analysis (Payload) Even if the inner payload is extracted, it is heavily trapped. - **Anti-Debug:** RDTSC timing checks, multi-region CRC32 integrity canaries, HMAC-SHA256 integrity, `LD_PRELOAD` detection, and parent process name fingerprinting. - **Anti-VM:** CPUID hypervisor bit, cache timing, DMI/MAC string scanning, VM-specific files/registry keys, and kernel module checks. - **Anti-Emulation:** Detects Unicorn Engine via RDTSC delta analysis. Detects Bochs via RDRAND support mismatch. - **Launch Verification:** The payload verifies it was launched by the stub (via argv[0] token on Linux / environment on Windows). If run standalone, the tamper logic triggers and validation silently fails. ### 5. Obfuscation & Hardening - **String Encryption:** All UI strings are encrypted with ChaCha20 and decrypted on the stack at runtime. `strings` yields nothing useful. - **MBA Obfuscation:** Cryptographic constants (like ChaCha20's "expand 32-byte k" and XTEA's delta) are reconstructed at runtime using Mixed Boolean-Arithmetic (MBA) XOR splits. - **Junk Code:** Volatile sink macros insert junk operations throughout the binary to break static analysis and pattern matching. - **Hardware Binding:** Serial validation is tied to a CPUID-based hardware fingerprint. ## Rules - **No patching** of the binary, the VM bytecode, or the DRM. - **No internet / no network** required. - **Valid serial required** — a keygen or a valid key is the only accepted solution. - Patching anti-debug routines, killing the DRM daemon, or using loaders to bypass the stub is considered cheating and NOT accepted. - The serial is hardware-bound in the full build; a bypass build is provided for testing if you manage to get past the packer.

Nebulua Lua Obfuscator Challenge Objective The goal of this CrackMe is to recover the original Lua source code before obfuscation. This is not a password-finding challenge. The real task is to analyze and restore the original logic. How to Run lua Obfuscator-code.lua The script will prompt for a password (any input works), but that is not the focus. The real challenge lies in analyzing the code structure. Compatible with: Lua 5.1 ~ 5.4 / LuaJIT Protections Applied Outer Shell - Anti-debug (hook detection, timing checks, environment variable scanning) - Runtime dynamic key generation - Multi-layer encryption (XOR + Feistel + RC4) - Integrity verification Custom VM - User code is NOT loaded via loadstring; everything is compiled into custom bytecode - Full VM with registers, stack, memory, 50+ instructions - Instruction set is unique per build - Keys rotate over time Control Flow - Control flow flattening - Opaque predicates - Random dead code - Fake branches Anti-Analysis - Polymorphic IR (different per build) - Self-modifying interpreter - Shadow stack integrity - Honeypot traps - Symbolic execution traps (against Z3/Angr) Encryption - 7-layer nested encryption - String encoding - Lazy decoding Rules - Goal: Recover the original Lua source code (or equivalent readable code) - Allowed: Any debugger, analysis tool, runtime environment - Submission: Share your approach and the recovered code Files - Obfuscator-code.lua — Obfuscated script Hints - The outer shell is just the first layer - The real VM is inside the decrypted payload - The instruction set is dynamically generated Welcome to try it out. Feel free to share your approach and insights. Questions are welcome!