pin.exe — Recovering a Runtime-Decrypted Password

Objective

The pin.exe CrackMe asks for a password. My objective was to recover the accepted plaintext password by locating the program's input-validation logic and observing the value after decryption but before comparison.

Static analysis: find the validation boundary

I loaded the executable into Ghidra and followed main. A function labeled decrypt wrote a decoded value into a stack buffer. The program read the supplied password and passed the two buffers to msvcrt.strncmp.

decrypt(local_37, &local_2f, 0x2a, 7);
__mingw_printf("Enter password: ");
__mingw_scanf("%31s", local_28);
iVar1 = strncmp(local_28, local_37, 0x20);
if (iVar1 == 0) {
    puts("Access granted!");
} else {
    puts("Access denied!");
}

This established a useful observation point. At the comparison call, the program must have both the user input and the decoded reference value available in memory.

Dynamic analysis: inspect function arguments

In x64dbg, I placed a breakpoint immediately before the call to strncmp. The Windows x64 calling convention passes the first three integer or pointer arguments in RCX, RDX, and R8. The instruction sequence identified which buffer held the supplied input and which held the already-decrypted expected password.

lea rcx, [rbp-30h]   ; first argument: user input
lea rdx, [rbp-70h]   ; second argument: expected password
mov r8d, 20h         ; compare up to 32 bytes
call msvcrt.strncmp

I followed the pointer in RDX in the debugger's dump view and inspected the plaintext string. The original report's register capture records the recovered value easi123.

Verification

After restarting the executable outside the debugger and submitting the recovered password, the program printed Access granted!. This confirmed the observation against normal program behavior rather than relying on a register snapshot alone.

Security lesson

Encrypting a hard-coded credential does not protect a locally enforced check once the application must decrypt that credential to compare it with user input. A determined analyst can often observe sensitive material at the boundary where it is used. For meaningful authentication, server-side validation and appropriately designed credential verification are stronger than hiding a reusable plaintext secret in a client binary.

Scope: publicly discussed CrackMe exercise. No third-party authentication service, user account, or production application was targeted.

Technical toolkit