All Activity

Good job kao, would you like to share some details about what have you done ?

You could still tell us how you solved it. There's always something to learn..

Damn it! You beat me by 20 minutes!

There's too much junk code and it's located in the wrong places. IDA ignores most of it and the rest can be NOP-ped out in huge blocks. The crackme would be much harder, if the useful VM handler instructions were placed in between the junk code.

View File VSEC Hyper Crackme Brief and useful Find correct license key, don't try to patch file. What comes within this crackme : + Code Virtualization + Unique Junkcode Generation + Control-Flow Obfuscation Submitter Gladiator Submitted 03/06/2025 Category CrackMe  

I can't remember anything about this, it was so long time ago. From what I could see it has bugs: private static string #l(string A_0, uint A_1, uint A_2) { ... StringBuilder stringBuilder = new StringBuilder { Length = 12 }; for (int j = 0; j < 11; j++) { int num2 = (int)(((long)(10 - j + 1) * (long)((ulong)A_1) * (long)((ulong)A_2) + (long)((ulong)num)) % (long)length); stringBuilder[j] = (char)((byte)((long)((int)(A_0[num2] + A_0[j % length] + A_0[(int)((long)j * (long)((ulong)num) % (long)length)]) + j) + (long)((ulong)num))); } stringBuilder[11] = '\0'; text = stringBuilder.ToString(); num2 = 0xFFFFFFFC so will thrown an error!

@CodeExplorerHey is this your work? Seems like a really nice KeygenMe.

I can only wish you luck in your search 😄

plz help i need protector for macOS

Touché! 😆 While I would have loved to see a full function rebuilder in action, I did basically say/hint at by any means necessary, so fair play on taking the most efficient route. This runtime obfuscation was really just meant to be a cool PoC for runtime-based protection, rather than an impenetrable shield. The idea was to make static analysis a pain and force dynamic reversing, but yeah—if the code exists in a readable state, even for a moment, it’s game over. Still, I appreciate you taking a look at it. If I ever cook up something more annoying, I’ll be sure to let you know. 😈

You actually solved it for me - see the quote in my previous post. The protection is pointless if the original code is present in it's original place even for a short period of time. I just needed to dump the process memory at the right time. Could I make a tool to rebuild relocated functions? Sure, I'd need to find num_ObfuscatedFunctions and ObfuscatedFunctions and then do the reverse of RelocateFunction for each of them. But I'm lazy.

Bravo! 🎉 Impressive work reversing through the layers and pulling out the password check routine so cleanly. I’m curious—how did you approach it? Did you focus on bypassing VEH handling and dumping the relocated functions, or did you go straight for unpacking it statically rather than dumping it? Also, any pain points, or was it a straightforward crack? Really appreciate you taking the time to check it out! Looking forward to your breakdown. 🔥

I suggest you think about this long and hard. What could possibly go wrong? I'll take the bonus points..

The reason for using VMProtect here isn’t to add another layer of security to the challenge itself—it’s because Eclipse's runtime obfuscation relies on the code being packed for the protection to be effective. Without a packer, the original function code would still exist in the .text section before it gets relocated at runtime, making it trivial to extract before the obfuscation even kicks in. By applying VMProtect’s basic packing, the goal is to ensure that the original function never exists in its true form inside the executable from the start, forcing analysis to focus on runtime deobfuscation rather than simple static extraction. I get that VMProtect’s anti-debug and import protection have been solved countless times, and I agree that’s not the interesting part of the challenge. The real focus here is on defeating Eclipse’s VEH-based execution redirection and function relocation, which is what I’d love to see people tackle. Furthermore, I could have made my own custom anti-debugger, packer, and IAT obfuscation, but honestly, I was lazy and didn't have much time to do so, and just decided to use VMProtect instead. It served the purpose of keeping the function code from being analyzed statically, which is all I needed it for. That said, I totally understand if dealing with VMProtect is a dealbreaker for you.

What's the point of applying VMProtect over your supposedly secure protection? I'd love to look at your obfuscator but I have zero interest in wasting my time on bypassing VMProtect anti-debug or import rebuilding - that's been done hundreds of times before and adds absolutely no value to the challenge at hand.

I want it to be like Enigma or Win License and be free Also, I don't have access to the program source.

vmpsoft.com/vmprotect/overview supports macOS u want the Ultimate Edition to has the License System.

View File Eclipse Runtime Obfuscator Hey everyone, I’m sharing an UnpackMe challenge that combines VMProtect packing with runtime function obfuscation using Eclipse Runtime Obfuscator. This should be an interesting challenge for those who enjoy working with dynamic obfuscation and anti-debugging techniques. Protection Details: VMProtect is used for basic packing, with import protection and anti-debug enabled. Eclipse Runtime Obfuscator dynamically obfuscates function execution, making dumped analysis and debugging difficult. Function code is relocated to a new memory region at runtime and accessed through vectored exception handling (VEH) instead of direct execution. Eclipse Runtime Obfuscation Features in this UnpackMe: Exception-Based Execution Handling – Execution is redirected via VEH, preventing direct tracing. Junk Code Injection – Adds meaningless instructions to mislead disassembly and make static analysis harder. Dynamic Function Relocation – Functions are moved at runtime, disrupting predictable memory access. Control Flow Obfuscation – Execution flow is broken up and redirected via exception handling. Anti-Debugging Protection – The binary throws access violations and illegal instructions to interfere with debuggers. Goals: Unpack the binary (remove VMProtect and restore the original imports). Defeat runtime function relocation and deobfuscate the function logic by resorting the original function code. Reconstruct a clean, runnable (optional) version of the executable with original control flow. Explain how you unpacked and fixed the program, detailing the approach to defeating VEH-based execution and restoring the function code. Bonus points if you can crack the password in the console application demo code. Notes: VMProtect is only used for packing, not virtualization. The main challenge comes from Eclipse’s runtime function relocation and exception-based redirections. Dumping the process isn’t enough, as function code is dynamically obfuscated in memory. Would love to see a write-up on defeating the VEH-based execution and restoring the original function code! More information can be found about the Eclipse Runtime Obfuscator project on GitHub. Looking forward to seeing your approaches. Good luck and happy reversing! Submitter C5Hackr Submitted 03/03/2025 Category UnPackMe  

By the way .... we can reduce the size by removing the SysUtils and resource (no need for that) : SysUtils; {$R *.res}

I want a software protector to programs on Mac, similar to WinLicense or Enigma. i want protect mac OS application with license or key plz help

https://winscp.net/eng/download.php https://eddynet.cz:9865 u: learn p: 4EKS9umUYme3WAZrC /Courses/ReverseEngineering This is the only guy who backup my collections

Example of how to use it: ASProtect SKE 2.56 SDK Sample (x32)

https://forum.tuts4you.com/topic/45127-asprotect-ske-256-sdk-sample-x32/#findComment-223076 https://forum.tuts4you.com/topic/45127-asprotect-ske-256-sdk-sample-x32/#findComment-223157