Ok...in order to prevent myself from getting the "lamer" label, I will describe my progress on a target I have been fiddling with for a while now. To start with, the program states: "Attention Demo Users: The software downloads are the same for demo and licensed users. Licensed users have a hardware key that allows them to read their own data files. Demo users may only read data files supplied by X-XXXX (they are password protected files). Without a hardware key (or floating license), the software will start and identify that it is running in DEMO mode." Actually, there are many modes such as standard, pro, even-more-pro, etc. that the program can switch to depending on the read dongle.

Step 1: I poked it in its eye to see if it blinks - lovely messagebox when a file is read in demo mode (with password removed) that says....buy the damn software! and then program quits. A few little changes (jne -> je)from the bad message to a good one gets us lost in an endlessly repetitive loop....hmmm...bad choice, most likely missed flag(s), but it does get us close to some code that must determine if the password is correct.

Step2: I cut it open and look at its innards - deadlisting gives sooo many good strings that I feel there should be no problem tracing the path, as every wrong turn SHOUTS error messages. Ahh...hey now I can see some references to sentinal rainbow pro dongle...a few more seemingly random eye pokes gets me nowhere, but the spalsh screen now proudly states that that the version is "CRACKED" (ok...it isn't really, this is just a pathetic attempt to boost my morale and was done by a little hex editing) I trace into the belly and find the switch that selects mode...I point it to ultra-supreme-maximum-pro...and it starts...ahhh there is my splash screen again...now it says that the program is entering god-mode...yay! Lets load a file without a password...death! bummer...ok restart and try one with a password...death! double bummer...probably more flags missed....hmmm ok now lets go back a bit and try..

Step3: Study all info I can about rainbow superpro dongles...got the sentinal SDK and read every dang tutorial on dongle bashing and have decided that this bugger is gonna get beat eventually. However, it seems that the only dongle bashing I'm doing is against my brain...due to space limitations and for the sake of the moderator's sanity I will end this rambling for the time being.
End.

For those who are curious, I will provide additional information regarding this target if asked. I do want to defeat this puppy eventually, but I am in no hurry. This is not the most recent version of this software, and I have not checked to see if current version uses same protection(s).

The purpose of this thread is to vent and provide others with some insight as to how tenacity and stubborn pride can assist in the difficult projects. Don't forget the humor as well.

Rackmount, I assume you have IDA, with the appropriate pluggins.

I suggest the following strategy (you almost have it).

1. Find the read dongle call. (which you have, NOTE this is called virtually all the time by most programmers who are lame).

2. Back track up 1 to several calls. If this routine is called only once you are in luck. This is the routine to brute force / patch.

3. IF Step 2 isn't a good choice, now the hard part. Find ALL the calls to the read dongle in your IDA listing. Check to see if they do the same checking, patch as necessary.

AKA brute forcing (it always works).

Your other option in IDA.

Find the "Buzz of dongle not found messages" then fix those jumps. Note if it checks a word / flag search for that flag EVERYWHERE in the code, sometimes (not often, programmers are lazy) they will put in a check and dump you out WITHOUT printing a message.

See the links on this web site to crackz's archieved site.

This can be done with W32dasm but IDA's easier.

Best of luck

MTB

Find the read dongle calls? Do you mean the RNBOsproRead call?
I have found the RNBOsproFindFirstUnit and can break on it in SICE and the IDA sigs for sentinal have nicely labled dongle calls...only a few hundred that I have seen so far...oh...did I forget to mention this is a rather large program? I tried creating a symbol map file for SICE and it whimpered patheticly when I tried to load it, "out of memory space for symbols." I have alot of memory allocated for backtrace and symbols for SICE but I have to leave some resources available for my lil-ole-comp to run...Hey a question to those who might know...I have seen alot of comments from one of the IDA sig files in my proggie such as _I386SPRO551MSOFTCD@4 what the heck is this telling me? The I386 seems to say intel, SPRO is easy, MSOFT...yea ok so its a windows proggie, CD@4 ...?? This seems to be something I may want/need to know. Thanks MTB for the comments...it seems there has been some new stuff added to the dongle section at Crackz archived site...I haven't been there in too long I guess.

Hiya,

For the @ part, consider the number of parameters passed through the stack for each of the Sentinel functions you have identified and therefore how much is required to correct it ;-).

Regards

CrackZ.

Hello Rackmount

If u have experience in emulating super pro you can skip this post.

If not i'll advice you to solve CrackMe by CyberHeg (http://www.woodmann.net/crackz/Tools/Dongles/Spcrkme.zip)
its *worth* solving to understand super pro dongles.

It's a small file not at all hard, implementation of functions,
storing return values & activating algorithm cell is extremely well done.

Once you finish solving it try with the target you have, things will be
much more easier to understand, you will definately know which part
you have to emulate & how it should be emulated.

Good Luck.
Sope!

Thank you Crackz and Sope for your responses...Sope...I appreciate the link...however, you assume alot by saying when you solve this...lol...true...I have done several intermediate range type reverses...however...there is so much to learn...and that is in constant flux...I have added code to reenable missing / restricted menu functions in a few proggies (felt mighty good after those worked) so I thought...hey I should do dongles...they should be a kick! I will now refocus my time on this crackme until I have it mastered (however long it takes) so my next posts will be in new thread as I require hints/help during this learning excursion. We shall soon see if dongles are a kick, or how hard they can kick. Later all....Rackmount

Dongles can indeed be fun - specially when the author decides to check the result of one dongle result, and then passes another value to the dongle, uses that result as a critical value of the application. Naturally, the second one should never be executed if the first one fails, but if you hack the first one out, the incorrect code of the second simply crashes the program.

Other fun projects are license managers - some of them (eg. Sentinel LM), when implemented properly, use the license managers challenge/response feature, but only check parts of the return code (which is normally a 16 byte value) after the call, and check various other parts of it at other parts of the program. Only problem with this is that the challenge/response algorithm is normally quite easy to get a hold of (well, it is in the latest Sentinel LM), and the secret keys are far too easy to decrypt. It ends up you creating the code that does calling part of the challenge response routine in the LM and passing back exactly what the application was looking for, rather than trying to kill jumps. I like these as they make you use your brain slightly.

If you want to play with license managers, I can recommend IAR's C Compiler for AVR Micro's. You can download a 30 day demo protected with the above LM. It uses a challenge/response algorithm, and there's no instant dialogs when one of the LM routines fails.