| Obfuscated Crackme |
[Click to reveal]flag is LEET_FLAG{D-Did_You_Just_Crack_Me!?!?} i submit a writeup
|
2026-08-25 19:30 |
| Obfuscated Crackme |
[Click to reveal]Amazing challenge. The 5.5/6 difficulty is spot on. Combining self-tracing (fork + PTRACE_TRACEME) with runtime string encryption just kills standard gdb/ptrace analysis.
Mapping the statically linked ELF revealed the core logic is hidden behind a custom int3 (SIGTRAP) VM. I reversed the SIGTRAP handler statically to map out the architecture:
Block format: CC [3 bytes] [4-byte key] [1-byte type]
Dispatch: The handler grabs the faulting RIP (saved by the kernel as CC_addr + 1), pulls the key, and checks a linked list of 6 dispatch tables—660 entries total—to find the target address.
CALL/RETURN: For type=0x01, it pushes the return address (CC_addr + 9) to a custom TLS stack (fs:[...]) and jumps to the routine. The magic key=0xb16b00b5 acts as RETURN, popping that stack.
Because self-tracing blocks external ptrace, I had to build a custom VM tracer using Unicorn Engine. Bypassed the rdtsc anti-debugging, emulated the IRELATIVE PLT resolvers, and got the execution flow tracing cleanly.
The VM initializes its state with two perm_gen (Fisher-Yates shuffle) calls before jumping into the core validation logic. I'm currently tracing the VM call graph after user input to pull out the algorithm.
Overlapping instructions, anti-disassembly padding (byte[7]==0), and fake red herrings like the base64 "FUCK YOU" are a great touch. This is a masterpiece of Linux RE. Thanks for posting!
|
2026-08-24 21:58 |
| Fsoecity key checker (very hard to reverse) |
[Click to reveal]Challenge accepted! This multi-layered structure is awesome — the MethodPtr redirection, custom opcodes (0xD0-0xD5) and protection against tampering using IL introspection (GetILAsByteArray + GetHINSTANCE) form quite a nice cognitive puzzle.
Spent some time reverse-engineering this and finally found all parts of the protection scheme:
Found the 3 decoy functions (ΙxHАаCBoΚYВΜΡІTΕ, КxOАІΑoAeр9c6, scope0IoyIl0MWorkspaceOrbit) — they return constants, regardless of input parameters
Discovered the real validator code flow: Main -> Policyo1IO1lZFeatureNode (Method 162) -> inner VM dispatcher
Decrypted VM opcode table: 1064 entries, 18 of them real (the rest are NOP instructions). Supported operations are ==, <, +, *, &, dup
Obtained the values array (C6-41-E9-16-57-53-FB-71-6F-BF-24-67-8D-59) and two permutations (F26, F28)
Found the coolest thing: there are no if/else branches based on the password — the output string ("fsociety // access" vs "[ access denied ]") is constructed symbol by symbol, using formula char[i] = num25 ^ num34 ^ ((i+1) * 2446251), where num34 is a function of password bytes through VM operations
Right now busy trying to invert this transformation using algebraic techniques. The non-linear cross-position dependencies complicate things a bit, but the structure of this obfusc
|
2026-08-24 13:35 |