Crackme: LAG's crack me test

Download here: https://crackmes.one/crackme/68c8f641224c0ec5dcedc044
MD5: c73e472c7762fce291af0aec40bc67be
Sha1: 22adcf120b680d8cb916de201b272c12c4aef6fa
Sha256: d7e62af3e23649224c6d9481deab9bef13de041eafb243098f41e1a008335376

This is listed as C/C++ x64 executable with a difficulty rating of 2.2. The author is LAG and the executable is written for Windows.

The authors description:

this is a file I've worked on for a couple of hours i'm just wanting to see how well my security is I couldn't crack it myself so if you guys can good job and I've probably done a really bad job but just wonder if anybody could do it it should be pretty hard but I could be wrong it's just a simple password thing you have to put the password in and if you get it right it sounds good

If you fire up Detect it Easy and analyze the executable, everything checks out. Note that this is a console application.

Taking a look at the strings, we can begin to make some assumptions. We can assume that this program checks if certain applications are running... and that LAG's real name is Nathan.

This becomes more apparent when you take a gander at the function import strings. Primarily the use of CreateToolhelp32 snapshot. I'm seeing a little bit of process enumeration and a little bit of anti-debugging. Let's get it.

So at this point I began trying to analyze the executable using just static analysis and quickly realized that it was obfuscated. At least more so than I cared to wrestle with.

I loaded the executable in my malware analysis VM and executed it but nothing happened. Weird. Okay, let's run it inside of x64dbg and see what happens. I kept hitting exceptions. Well played, well played. At this point I checked the call stack and traced back to before the program hit the exception. I was seeing a lot of CPUID instructions. It looks as though this program checks to see if it is running inside of a VM and refuses to execute. A google search later led me to this really good blog post on VM detection and anti-debugging techniques: https://medium.com/@exploitdevvv/malware-101-anti-virtualization-anti-debugging-methods-04353f0a9407.

One knowledge detour later, I came back to ghidra and used the memory map to rebase the executable to match where x64dbg was loading the binary. I began tracing up the function calls to try and find where our input was actually obtained. On my way up, I found timing related anti-debugging techniques, anti-vm techniques, running process checks and good old debugger checks. But eventually, I arrived here where it appears as though a simple NOP and patch could lead me to where I want to be.

I NOPed out that function call, set a breakpoint on the test after the call to ensure the jump would be taken, and hit run. Yes, I could just patch the conditional jump to always jump but I like working in baby steps and making sure I get what I expect to see. It makes troubleshooting easier. And wala! My console came to life and greeted me with the most glorious thing I have ever seen. "Enter password: ". Alright, the actual password would have been better but we defeated the the anti-analysis stuff. Now we can dig in and see what is going on and maybe, just maybe, we can find that password.

Setting a breakpoint at the conditional jump right after the call for our input and single stepping a few times revealed something interesting. Do you see what I see? The password that I entered was "1234". Where is Gh0st_Hunt3r_2025 coming from? Do you smell a password? I smell a password.

Let's plug it in and see what we get! *mic drop*

And for safe measure, I made the following patches and saved the new executable as unsecureloader.exe.

 
All's well that ends well.