| Obfuscated Crackme |
@Zydak I've submitted the completed version of the writeup now. Thanks again for the help, @Elvis!
|
2026-08-28 11:31 |
| Obfuscated Crackme |
@Elvis Oh, that would be great. I also emailed the admins, and Xusheng replied with the same deletion/resubmission path. I’ve saved a local copy of the current writeup, so it’s safe to delete. Once it’s removed, I’ll resubmit the revised version. Thanks for the help, and sorry if I caused any inconvenience for you guys!
|
2026-08-28 09:28 |
| Obfuscated Crackme |
Ah, it's restricted to one writeup per account/person... no edits.
|
2026-08-27 20:28 |
| Obfuscated Crackme |
[Click to reveal]@Zydak, my writeup was accepted, but I’ve since realized the solution can be made more complete. In the submitted version, I hardcoded the remaining flag hex values (?!}) in the solver after recovering the truncated output. I’ve now revised the solver so those bytes are derived directly from the in-memory cryptographic/table passes instead.
It's okay if I submit a second, more complete writeup documenting that full derivation, yes?
|
2026-08-27 18:49 |
| Obfuscated Crackme |
[Click to reveal]Okay... I figured out why my original flag was wrong. I mean, I had submitted a writeup, but it was rejected... no hard feelings. I could understand why. ",gTñ+°ÏF5Û,P®Q«þt´ÇÊ]Eßx3qÉ6ú" was certainly NOT the flag, lol.
My initial deobfuscation was largely correct, the nanomite engine, anti-debugging layer, and SSE alignment issues were dealt with successfully. The mistake was in my interpretation of the remaining CFF state machine.
After going back through the dynamic trace (and following the approach hinted at by @stels(thanks for the hint btw)), I realized that the vanilla dispatcher itself contains the pointers/state required for the correct un-permutation and decryption flow. I had incorrectly treated that part as already reconstructed after removing the nanomite layer.
So the garbage byte string I originally submitted wasn't caused by a broken deobfuscation or bad XTEA recovery. I was simply applying the final transformation with the wrong model of the CFF.
The challenge is definitely closer to a true 6/6 for me than I initially gave it credit for. The individual techniques were what the description had already said, but the CFF is a nasty final layer after I've already spent a considerable amount of effort defeating the anti-debugging and nanomite machinery.
I'll submit a writeup to the corrected solution later...
|
2026-08-26 18:41 |
| Obfuscated Crackme |
[Click to reveal]This challenge was pure hell... but absolutely brilliant and so much fun to break down! The binary is completely untraceable dynamically out of the box because the supervisor catches every single trap and fights debuggers like it's the end of the world...
I ended up writing a Python script to statically de-obfuscate the entire binary... here's how I solved this thing:
1. Mapped all the internal relocation tables to recover the true control flow and strip out the nanomite engine completely.
2. Bypassed the watchdog/ptrace traps and used a string-poisoning trick to satisfy the inverted branch checks across all the process scanners at once.
3. Ran into mysterious #GP segfaults in the flattened dispatchers until I realized the unaligned stack frames were breaking SSE instructions, which I patched to unaligned equivalents.
4. Finally patched the comparison routine to achieve a clean standalone binary.
My head hurts, and I definitely need some rest now. And probably bang my head on a wall. 5.8/6
|
2026-08-25 16:46 |