A regular breakpoint won't fire because they've re-routed 
the interrupt.  No problem.  This has always seemed more of 
a minor nuisance than anything else because all you have to 
do is set a debug register breakpoint.  
So, 'bpmb CallHasp x' does the trick.  The x indicates that 
it will break if the execution reaches that address.  
In other words, it's functionally equivalent to a regular 
bpx, but invisible to any anti-SoftICE tricks.  
Of course, you only get four debug register bps at a time, 
but I've always found that to be plenty.

I'm a fan of good digital audio software. SoundForge is a nice example of such software, but it's been cracked black and blue. However, SoundForge takes plugins and there are some great plugins for it out there, most notably, those made by the waves corporation under the name Native Power Pack. The folks at waves have a demo version on their web site, but they also have an update to version 2.3. I thought I'd get the update and see how hard it would be to make it work. This was done as a casual thing. Little did I know what would come of it.

Well, the interesting thing here is that we're not actually going to crack this target. It would be very time consuming, it turns out, without the dongle (and what I hope to show in this essay is that there is a lot more cracking that can be done without a dongle than people think). The dongle used by waves is a HASP dongle (a MemoHASP in particular) and I recommend taking a look at the essay by zafer on these dongles as well as getting some info from HASP's ftp site, which I'll explain in a moment. Rather than cracking this target, we're going to learn a lot about how HASP implements various aspects of their protection scheme and how, in particular, to break their envelope protection scheme, which is a full blown exe encryptor for Win32 that relies on the dongle for the decryption codes. The accomplishment of this essay will ultimately be a decryptor that works for *most* envelope protected files. The target itself, Native Power Pack (NPP), has already been cracked by one of those "warez" groups that call themselves Radium. They have done a good job, but they had the dongle (that takes away all of the fun....). However, having their crack enabled me to verify some hypotheses that otherwise would have been quite tedious to test. In no way have I copied their crack nor has it really even been relevant to what I'm doing here. The only thing I benefitted from in having their version was the ability to compare the encrypted code with the unecrypted code to see if I was getting it right. I'll point out where this happens along the way (actually, reading over this, I realize that I won't, but you can figure it out). If you're looking for Radium's version, well, don't ask me (or fravia+) but it's not that hard to find.

I think that takes care of the preliminaries, so let's start cracking. The NPP update is an InstallShield packaged for the web file. Running it you either get the message that you don't have the dongle installed or that you don't have the dongle drivers installed (you should download the drivers from waves' site and install them). Getting the installation to run successfully is not that hard and involves techniques that have been discussed extensively on this site, so I'll be brief. The trick is to find where the message box with the bad guy message comes from. One might guess that it's in the InstallShield script file, setup.ins (on this topic see the absolutely spectacular essay by natzgul on decompiling InstallShield scripts), but a quick search through that file doesn't turn up anything....

Well, Waves Native Power Pack would take a long time to crack without the dongle, but this may have just been dumb luck on their part. On the other hand, I got a lot farther cracking dongle protection without having the dongle than I thought possible. That was all I wanted anyway. I should mention now that there is still more work to be done with hasp envelope protection. I have not even looked at version 5 yet. Perhaps they have increased the length of the key, but I doubt it. Furthermore, it is not absolutely essential that the target link hasp32b.obj. It is possible, although my guess is that it would take a couple of weeks, to determine the key by hand. Between the highly predictable nature of the relocation table, the function names in the import table, the library routines and the fact that the code has to make sense, it would not be too hard (just very time consuming) to reconstruct the key. I suppose it's up to you to decide whether this is worth it. Also, there are three more functions called after the decryption is complete. These deal with fixing the relocation table (this is not necessary if you patch the PE header appropriately) and inserting dongle checks at appropriate places (again, my method wipes these out altogether) among other things. The only thing that's holding me back is that I'm having a hard time getting ahold of any other envelope protected programs. I fanyone knows where to get any on the web, please let me know. I'm dying to see how well the decryptor works. Only one test target is not enough.