I'm new to this forum and to cracking in general. However, I took some 8088 assembly in college about 10 years ago so while I do have a background in this, I'm a little rusty.

I'm using OllyDBG to create a workaround for a program. I was able to successfully jump over the part that checks the license. I celebrated pretty early. However, upon using the program for awhile, I noticed that at random intervals it will do a secondary check somewhere. If there is an issue, the program will display a message (using WM_PAINT) on the screen and it will stop processing data. The program doesn't crash though. When I pause and step through the program it runs in a loop constantly calling subroutines in itself, NTDLL, User32, etc. Even worse, the text string that displays that the license is invalid isn't anywhere when I search for text strings. The error message will show up in memory after it's been displayed, but I can't figure out where it was called from.

I took a different route and tried to crack the license key, but this thing runs through so many subroutines that my expertise isn't there yet. So I decided to focus on my little win and see if I can complete it.

So, my question...where do I go to find that string? Or, if it's already in memory, how to I trace it back to where it originated from so I can find a clue on how to prevent it from stopping the program?

Thanks so much for any advice.

A run trace might help you with tracking this down through looking at code(long route), I would searched for a DialogBox call or MessageBox rather then the message..

If the executable has a relocation section you could parse out all the data points of a 'known working' implementation at runtime and then monitor the locations for changes after the error occurs, possibly longer route.. The quickest method I can think of is using a memory protection lock to track the write to memory down back to the writer,

I tried doing a run trace but I wasn't really able to follow since it jumps so much between NTDLL, USER32, IMM32.

After the license message shows up, I'm not able to find any reference to it in the program. However, I see the ASCII string sitting in memory. I used OLLYDBG, selected the string (ASCII), and changed it to DISASSEMBLE. This is the resulting code that is writing that text:



I tried to search within the main EXE to find any of the more complex commands and didn't have any luck. Obviously the jumps in here just jump to addresses in memory. Am I on the correct path or am I just barking up the wrong tree?

changing the string to instructions wont help you because strings are made of ascii which falls in the range of operable code instructions(see ascii shellcode). But the address of the string might help.

I would run 10 different times your program and note which address the string pops up in, if it is alway 002bA000 - 002bb000 then that range of memory's protection lvl could be changed to no-access to cause a exception on read write and lead back to the caller through use of the exception information.

Unfortunately, it's always putting it in a different memory address. I tried to guess and set one of the locations to no-access to see what happened. Once it did hit, the program crashed.

I think I may need to brush up on my assembly skills a bit and tackle this later on. I would ultimately like to crack the license key (the program generates a computer ID). But it's pretty complicated for me at this point in my skill-set.

Plus, I've been focusing on this instead of my actual work that pays me and I'm falling behind at that. But this is more fun!

my guess is there is a wait routine that does some kind of check and allocates memory and writes a bunch of stuff to it, one of them being the error string.

I would log the memory map of a running app and check the map again for changes after if your string shows up in a new block of memory it should be easy to associate which module the function that is doing this to you is, and you could then look for cross references to the modules functions of interest. Its a not all about assembly knowledge

I tried searching for break on memory allocation for ollydbg, but I didn't find much of interest yet. I will have to refine my search terms to be more specific..

I reread you initial post, and if you can jump over the part that checks the license then you know which part to focus on. I would focus on the conditions involved in triggering the bad behavior. anyway.. to track down the culprit that calls the routine you jump over after you jump over it simply place a break point on the function you jump over and not where it is called, but on the functions code itself(ie follow the call and breakpoint there.) at some point you should get a hit and then what you do from there is up to you.

regards.

I tried a different approach.

This thing has a built in counter. It will let you use the program for x number of turns. Once you have reached that limit, it stops working. It's doing a TEST EAX,EAX. If EAX =0 it jumps to the part that displays the over the limit. I injected the code to always set EAX to 1 before the check (instead of just doing a jump). It worked, but after a few turns I get the same error. I'm having a tough time figuring out what this thing is checking for.

Is it possible that this program would be checking the Checksum of the program or some static item? I looked up the checksum (CRC, MD5, etc) of the original program and did some searches inside to see if those strings exist, but had no matches. Is there a way to figure out if it's using a checksum or something like that to check.

I would like to take a look at the program you are attempting to reverse, maybe I could help. PM me.

PM Sent

Pm received. I am looking into it now, first thing I notice is a call to killTimer.

I saw that too. However, I looked up the KillTimer function at MSDN and wasn't sure how relevant it was. The interesting thing about this program is that it will continue to loop even after the license error shows up. The program is waiting from input from another program so I assume that's why the loop is constantly happening. However, once that license error shows, it still loops, but the program stops looking (or maybe processing) the input.

https://msdn.microsoft.com/en-us/library/windows/desktop/ms644901(v=vs.85).aspx#destroying