MugoSquero on 2024-04-23 17:25:
Seems impossible without patching, because the algorithm includes some checks based on the effective address of a value on the stack. This means it changes every time. I hope I am wrong because it will teach me a lot.
majorsopa on 2024-04-23 17:51:
Mugo- correct(ish), however for whatever reason this effective address didn't change between runs on Windows, only compiles. On Linux it changed every run.
I do absolutely think the only practical approach would use patching to bypass the antidebug and derive a password from that, which you can then use on the original binary.
If my observations about effective addresses were incorrect and an artifact of my development environment, then I will remove the crackme. However I do not believe this is the case.
note- patching the binary will change the effective address, so it's not as simple as printf'ing the effective address.
nnxstnt on 2024-04-24 11:23:
The answer is clearly runtime dependant. Check out ASLR and how virtual memory works.
Apart from the some anti-debug shenanigans at the start, the algorithm is pretty straigth forward.
majorsopa on 2024-04-24 12:42:
it isn't runtime dependent. i have a text file on my pc which gives a correct answer. don't be mad if you can't solve it lol
nnxstnt on 2024-04-24 14:23:
Uhh, I patched too much in the anti-debug part, you are correct, my bad
MugoSquero on 2024-04-24 16:30:
Every time I hit restart on the original binary in x64dbg, the effective address of the top of the stack changes. What am I missing?
Mirion on 2024-05-07 11:41:
int __stdcall getPassword()
{
int v1; // [esp+0h] [ebp-4h] BYREF
v1 = 1986487925;
return (int)&v1;
}
The returned value seems dynamic to me. I don't know how to do next.
cnathansmith on 2024-05-11 04:48:
@majorsopa you can calculate the password from just the base address of the main module, which you can obtain via CreateToolhelp32Snapshot without attaching to it or modifying anything.
checksum = ((base + 0x27f18) ^ 0x80000103) * -1
Then the password is the checksum spelled out backwards (LSB first) in binary. (The password will be 32 '1's and '0's)
cnathansmith on 2024-05-11 07:31:
@majorsopa Windows ASLR isn't really randomized for the same module during a single boot. If you rename or copy the exe it's layout will change, but if you keep executing it from the same location, it will be mapped the same every time at least until a reboot.
cnathansmith on 2024-05-13 18:23:
Also, the exe image stays together. So an address in .text or .data will always be the same offset from the base address, though the base address might be random (-ish.. there's only 12 bits of entropy for a 32-bit ASLR).
The stack and external DLLs could theoretically be mapped anywhere, though that isn't quite true with DLLs because Windows tries to load them to the same address in every process. Kernel32.dll in particular is unofficially guaranteed to be in the same location for every process (Microsoft won't claim so in official documentation, but Windows Internals and other sources they semi-endorse do)
Consequently, if you keep running a program from the same location, it will keep getting the same base address, but renaming it will randomize it again.