Hi,

I am new to reverse engineering but have decided to give it a go and try to crack the dongle protection of a program I have. I have an original dongle if that makes things any easier?? but from what I've read online its not possible to just make an emulator for this as its a DK2 Deskey dongle.

Anyway.... so far using Ollydbg and going through the program comparing what it does with and then without the dongle installed I have managed to get the program to start by removing 3 JNZ commands, the problem I have now come up against is the program also checks every 60 seconds and closes if the dongle is missing. This is where I am stuck now because running the program and going through step by step doesn't seem to help as it sits in a loop of about 20 lines constantly and I can't actually see any difference in this loop to see where it checks for the dongle and closes the program.

Is it possible the dongle check runs in a seperate background thread? if so how can I find this?

I have also tried searching the whole program to see where it is getting the dongle error message that it displays from and can't find a thing!

And I also checked the dk2win32.dll, couldn't find the error message in that and it seems that only 1 function from this file is imported to the program so I am having trouble understanding how it works exactly. Is it possible the programmers did something clever to hide how the program is interacting with the dongle software?

If anyone could help me out with this I would appreciate it.
Thanks

If you still want to know... If I were going to check a dongle every minute, I would use a timer object. Every minute my program would get an event when the timer fired. So, if you can find the event handler for that timer (assuming that is how they did it), you should find a protection check in there.

Whether or not that will complete the de-dongle process I can't say.

nutjob

The error message is probably, issued by the driver located in win32, you might be able to recognize it if you're familiar with the normal files invoked when a proggie is loaded and runs, if you find it set a break point in the memory window on the text/code portion and it should break when your app goes to issue the error message, it's really very easy to defeat this type of check but I'll let you figure it out, just make it think that when it returns from the check it thinks what it expects to see as a good check is returned. If you have a hard time finding the driver, wait for the error - break the prog. search in the memory window for the message and set a hardware, (or memory if the app doesn't quit after the message), breakpoint on the first part of it.

SiGiNT

"but from what I've read online its not possible to just make an emulator for this as its a DK2 Deskey dongle."
I posted a full write up and its internal algorithm (as deduced as much as possible) on this forum. Regarding your checks, if its time based, look up timing apis and hook them. If you have softice, set breakpoint on the driver memory for dk2 and then backtrace back to the executable. if none of the above makes sense, find my article on this forum for dk2 and try getting the flair signatures from crackz site and using them with ida to detect all api calls from the app.

Sab,
we are waiting for 'DK2Direct_v7.zip' file, didn't you find it yet?

I will fight the lazyness and dig it up tonight.