Anti Piracy Techniques Questions

[cmmorris1]

Do you know if it's possible to fake the pe header to look like it was compiled using a different language and still have it run correctly? For example, if I coded this in vb6, is there a way to make it look like Delphi or c# .net etc?

[smUX]

Do you know if it's possible to fake the pe header to look like it was compiled using a different language and still have it run correctly? For example, if I coded this in vb6, is there a way to make it look like Delphi or c# .net etc?

There's ofuscators out there which rebuild the whole EXE and scramble the data which do pretty much that, no way to tell what it was coded in...but AFAIK there's no point in changing the header if you're not going to be using other techniques anyway as the required DLLs and such needed to run it will give the game away about what language was used :-)

[cmmorris1]

He's currently using WinLicense, I felt that was the best obfuscator out there but they cracked that in a matter of an hour I guess. Sucks. So we'll still use that along with internal measures to make it not worth their time.

Once they bypass WinLicense it starts all over again and will make them tired of trying hopefully and move on.

[LaVolpe]

The url thing was an example of what I'd like encrypted but I know there is a way to decode that. I was more concerned with strings like "Wrong Serial, Try Again!" And they'd know where the check is made and patch it.

There are more than a few ideas about this problem:

1. Use a randomly timed message that is displayed later vs right away. If no message, then simply unload.

2. Allow the program to run anyway and write a value to registry or disk hiding it the best you can. In a week or so, check that value. If it indicates unlicensed copy, popup message box or simply unload right away. Though you are "giving it away" for a week or so, the logic is this... A hacker spent time on your app and for a week people think they have the free app, but later it stops working -- annoyance to the theives and to the hacker: demotes their reputation. The annoyance part: the hacker will have to re-hack your app to figure out why it stopped working, if they so incline.

[cmmorris1]

Yeah, that is a good idea. Tricking them into thinking it's cracked is cool. In conjunction with these other ideas it may just do the trick. I'm waiting to hear back from the developer on his skills on getting this done. Thanks for the tips though everyone!!

[isnoend07]

Yeah, that is a good idea. Tricking them into thinking it's cracked is cool. In conjunction with these other ideas it may just do the trick. I'm waiting to hear back from the developer on his skills on getting this done. Thanks for the tips though everyone!!

Another consideration, How will you handle refunds after a customer has registered your software ?
I have done this: I have a secret invisible label that when clicked that displays a dialog to enter numbers into which produces some more numbers to be emailed to me. This writes a value to a encrypted file that will not allow the program to run. After selling 100's of app's i have ran into a lot of different scenarios eg;
Husband bought app and registered it. Wife demanded a refund and followed the steps to unregister it. Funds were refunded Husband came home and was prompted with a Message " This program has been refunded and disabled"
Husband bought program again. I had to create and send him a file to kill the hidden encrypted file. Then there are the people who claim to have purchased the software and want the reg number emailed. Some get real angry even when not being able to prove any part of the purchase.

[cmmorris1]

Refunds? It's a monthly subscription to use it, if they refund it's no good anyhow as we do online activation checks and don't store any hidden files to activate offline anyhow. They need to be online to use it so that's not the issue.

The software only becomes licensed temporarily while in use and then deactivates upon exit.

[smUX]

Is it a large file? Not that it matters TOO much with what I am going to suggest anyway :-)

If it's a monthly subscription, is it calendar month (some being 30, some 31, one 28 or 29) or specific number of days? If it's calendar month, how about having each program locked to a specific month so the month becomes part of the key for the security. If they get a key for January it runs out when February starts (so obviously you'd sell a partial month if that is possible). Couple that with an online date check using some sort of time server (probably backed up by a server check) and it's more and more secure. At the end of the month and when they get a new subscription, a new locked program is downloaded locked to the new month, complete with any updates to the code you've made since then (possibly hidden as a monthly update).

If it IS a large file, then perhaps the injection system I mentioned before might be required...it just injects the changes between the two programs into the EXE and the program should be good to go :-)

Downside to the injection method is if not too much in the code changes then hackers will find it easier to circumvent the security because they have a better idea of where to look...but if you make enough minor changes in the code (enough to warrant an update rather than injection, and enough to change the code substantially in the eyes of a hacker...maybe with the encrypted data changing?) then people will be none the wiser.

Of course, we're all just giving ideas, we don't know what it is exactly you're offering so couldn't tailor the suggestions to your specific setup, but I'm sure you've got enough ideas to work with anyway :-P

I assume that, as you said the program is activated online and you said before that you have to be online to use it, you're using some sort of custom session-based activation system...the session ID could probably be linked into server/client encryption (always handy to combat the packet sniffers) and possibly form part of the EXE encryption data.

Have you identified any particular weak spots in the process that you need the most security in?

[cmmorris1]

The software does require multiple updates each month which is why we have to charge a monthly subscription. It really takes a lot of time to add in the fixes across the software. Sometimes we've seen multiple daily updates.

The software is on monthly subscription but not month by month but 30 days from the date the subscription starts. So one member could come in the middle of the month and be ending middle of the following month.

I don't like the injection idea as much as the others but thinking out loud that is a good idea. We just need to come up with an idea that suits our needs and makes trying to crack the software not worth while to crackers.

The session id I guess could be used as you suggested. I am still waiting to hear back from my developer to see if he's able to implement these suggestions.

[smUX]

Injection is useful for updates if you have a competent enough programmer doing the work...you'd only have to update the changed data, but then comparisons would have to be made between the old and the new EXE...it's a lot of work and if the EXE isn't that large it's not much of a worry if you have the available bandwidth to provide the file.

However, the way injection would mess with the hackers is that it'd make changes to YOUR original EXE so if THEY have made any changes it may totally kill the application and require a full re-download...although updates would require patching if you updated anyway, but if they were smart they'd have some sort of unpatch feature which removes their changes so it can be updated.

What you COULD also consider doing, while on the subject of updates, is have a different revision number with each update and use that to encrypt data too...every time you update you just have to run a program on the source code to generate the encrypted version then when they go to re-patch it they have to work out the new data to use for the patch to work...if you update it regularly, it'll be very cat-and-mouse but the person doing the most work (as you're already updating regularly) is the hacker...eventually they will give up trying :-)

[cmmorris1]

Awesome smUX..you've given us a lot to work with buddy! I appreciate all your help!

-Chris