- Patching Security Holes With OllyDbg (Part 1/3)
- Patching Security Holes With OllyDbg (Part 2/3)
- Patching Security Holes With OllyDbg (Part 3/3)
Tutorial 2 – Finding generated key at runtime
Enter any test data and observe the error message displayed.

Search for referenced text strings as mentioned in Tutorial-1. Scroll to the location shown below.

Notice the 2 ‘Key like’ strings in the text strings referenced. If you think that one of them is valid, then you are wrong, but then why and where is it used? And what is the correct key? We can find that out soon.
Double click the message ‘The serial you entered is not correct’ to reach the instruction location in the CPU window. When we analyze the code we come across a few concatenations operations. But unfortunately the keys are concatenated with blanks and finally compared with the user input.
The blank values you see in the comments are not really blank ones. They values are assigned on runtime. We have to set a breakpoint to obtain the dynamic assigned value.
To set a breakpoint, select the instruction and press ‘F2′. Breakpoints highlighted in red over the memory location.
Press the ‘Play’ button to run the crackme application. Enter any random data and click the ‘Check’ button. The application pauses at the breakpoint set in the previous step. Go to the same location where you saw the 2 suspicious ‘Key Like’ strings in the previous step.
Just before where the breakpoint was set we can find a new long string value displayed instead of blank strings which was displayed earlier. If you reverse engineer now, you can understand that the 2 Keys ‘L2C-5781‘ and ‘4562-ABEX‘ are static ones and are prefixed and suffixed, respectively, with a dynamically generated string. This is what we were looking for; the correct key to this app.
Video
Conclusion : Never hardcode even fragments of static keys which can be helpful to deduce the complete key. Use some kind of logic to generate a dynamic key value.











