Program crashes after resuming from breakpoint

Question

After solving few crackmes I tried to take one step further and move on "real life" reversing tasks, targeting a known win7 program's password check feature.

The program in question obviously doesn't store interesting strings in memory, so I tried another approach, that so far worked well in test-scenarios and in crackmes. The prompt for the password itself uses a simple edit control, so I instantly looked for executable modules -> USER32.dll and found the GetWindowTextW offset (I know it may be using alternative ways to retrieve text, but that was not the problem) Setting a breakpoint there and trying to f9-run the program causes it to crash.

I'm new in reversing and debuggers, and I don't really know what may be causing the issue, or where should I look to solve it.

PS: could this be a good approach for the task ?

Answer 1

Basically, your approach is a good first approach. Programs used to be easily crackable using it 10 years ago. But times have changed, and many programs try to detect if they are being cracked and implement countermeasures.

There's lots of things that could be happening. The program might use IsDebuggerPresent(). It may use other methods to detect a debugger. It might generate a checksum over its own memory and check that against a known value (setting the breakpoint modifies the instruction to INT 3 unless you use a hardware/memory breakpoint, but if you put the breakpoint on a function in user.dll, you won't change the executable's checksum). The program might check the functions it calls if one of them begins with an INT 3 instruction (but i'd assume this not to be the case for a mere GetWindowTextW). If the program crashes on a resume F9, not the first run-F9, it might be timing how long checking the password takes, and if it's more than 0.1 seconds, it assumes it was interrupted and crash.

There's literally dozens of possibilities, and you'd have to trace your way through the program to find out which is used - this is where experience kicks in.

You could try if the program works if you just load and run it - if it doesn't, it detects your debugger. There are stealth plugins to ollydbg that you might want to try.

A different approach that has sometimes worked for me is running Process Monitor to see where the program accesses its (file or registry-based) registration key; check the stack to see which function is calling that access, and statically analyze the program from there.