I bought a program on a CD and this program is invaluable for me
I noticed that the program runs from the CD after I installed it
I tried to copy it to hard disk and install it from there when it gave me the message "Please insert the original CDROM in drive"
When I made any break point in softice it crashed
When I used the debug registers to break it made something so strange; it didn't break at all
In the CD I found a hidden folder called "laserlok" containing 4 files which can't be opened or read
I was able to find that the protection doesn't exist in the main exe but in a separate dll which is called by the exe (function is called "CallDLL"
I also tried to make my own dll with the same function but it crashed and gave me the message "Stack overflow"
Can any 1 help ?
At least I want it to not disable my breakpoints
Please be as simple as possible because I am a very newbie

Hiya,

This is more or less a statement of the obvious, but have you tried Icedump with /protect on or FrogsICE ? Your crashes on the bpxes may be due to the app trying to hook the int 3 . The int 3 is the interrupt SI uses to set its breakpoint on execution exceptions. Chances are good that your app will attempt to use the sidt command to modify the interrupt descriptor table directly and avoid chaining back to the original winice handler. This would account for your bpx crashes. FrogsICE, however, should detect and protect you from the IDT and debug register accesses in most cases.

Cheers,
Clandestiny

Hello Toto !

Try the ICEDump/FrogSICE combo.
But replacing the .DLL is also a good idea. The "Stack Overflow" error came because your "CallDLL" has to few or to many parameters. You should look how many parameters are passed to the function, either by doing "u @ss:esp" and seeing how many PUSHes are there or by tracing the function until a Ret ????.
The next step is to find out what parameters are passed to the function and what the function should return. I don't expect the protection to say just "0 = NoCD" or "1 = CD" and simply continue or not.
Probably the .DLL decrypts the main .EXE somehow, else this wouldn't be a comercial protection. If this is so, just replacing won't work and you need to patch the .DLL somehow. Do you know if there are any encrypted parts in the .EXE? (You can find that out by looking at the code. If not about 10% of all bytes are 00h, it is encrypted or packed in some way)
The question is, when does the .EXE call "CallDLL"? When loading (CallDLL is not actually called from the .EXE, but from the DLLs startup code), right after the high-level-language startup-code or somewhere in the program?

Dak

Be careful......

______________________________________
Try the ICEDump/FrogSICE combo.
______________________________________

I am sure you mean run *EITHER* IceDUMP *OR* FrogsICE one at a time without the other.

Definately ppl should KNOW that running an IceDUMP *AND* FrogsICE Combo in the same session is NOT a good idea.

Spl/\j

Hi +SplAj !

OK, I used the wrong word for describing the relationship.
Thanks for correcting me.

I didn't actually mean "Combination of ICEDump and FrogSICE running at the same time", but "Try both and see what you like more".

Qui tacet, consentire videtur. Sed, amicus, quis custodit custodes?

Hi Toto,

If you havent already guessed, this protection is called laserlok
it works by replacing all the IAT entries with a pointer to this
CallDLL function in a seperate dll, if you try tracing into the first
api you will see how it works but to keep it short and simple upon
the 32nd time, (i think its 32nd) this calldll function is called all the IAT entries are restored to their correct selves, from here you can dump the exe and thats it,

hope this helps,

regards,
yates.