Hi Kayaker,
First of all thanks for this learning opportunity. Now the question:
I started to look at HappyIcon using softice from the beginning. After setting a nice (I think) bpoint I traced through what I believe is a registration routine. Looking at the code I forced a jump where I thought the prog should do so. After few more calls I was kicked back to HappyIcon and it was registered all right! In the "About" menu I got the following:
License: (My code)
Granted to: (My name, name).
Ok, I said, I'm on the right track. I restarted the prog to work more on it but it was still registered! I restarted my computer and it is still registered!
I have to say I'm a bit lost now. Not only I don't know how to unregister it but also I don't understand why a small cheat with the zero flag became a permanent patch.
May be you or someone can give me a hint.

Thanks
JaneK

Good work JaneK, you figured out the trick

That's exactly what happens, the s/n is only checked once, if it passes (by R FL Zing that jump), then the reg info is written somewhere and as long as that info remains intact, you're still registered.

By using Filemon or looking in the program directory you should be able to find where the info is written. You can just delete/rename the file and you're no longer registered and you're back to square one.

What I wanted in Task 2d was for people to trace immediately after doing the R FL Z just to see the API calls used to write that info and how it's done.

The problem is if you change a byte in the file created. That's where the CRC check lies. When this file is read in on the next startup it goes through a CRC routine and if it doesn't match the value that was initially calculated after you did the R FL Z and written into the file, you get an error message.

The CRC calculation routine itself is quite complicated (lots of FPU register activity) but if you can ignore the forest for the trees, the actual final check is simply a small byte for byte CMP comparing the CRC value written in the file and the one just calculated.

While some CRC checks can be tough (CRC is used here interchangably with Checksum since it may not be a true CRC-type check), many still seem to boil down to a black box kind of thing where there's a simple compare no different from any other.

If you change the file structure TOO much however then it may crash out earlier than the CRC nag, but changing a byte or two will be OK to try to trace it.

Regards,