views:

282

answers:

8

I develop in C++/MFC and have placed all the resources in a separate DLL.

I have seen cases where the resource DLL is modified and the product is sold illegally with different name, graphics etc.

How do I prevent the resource DLL from being modified/hacked?

A: 

You could zip it with an encrypted password and unzip it into a temporary location before reloading it. Something like

BOOL CMyApp::InitInstance()
{   
   CString  TempName = TempFileName();
   Unzip("MyZippedResources.Zip",TempName,Password);
   HINSTANCE hInst = LoadLibrary(TempName);
}

There are a number of free zip libraries that can cover the unzipping and password protection abovw

Shane MacLaughlin
If someone is serious about violating the license, I don't think a password embedded in the dll is going to stop them. This is the fallacy of DRM.
Matthew Flaschen
These mechanisms are designed to hamper rather than provide 100% effective protection. If you can discourage 90% of those that would try to hack you application, without spending to much time or effort, it is well worthwhile.
Shane MacLaughlin
As pointed out in my comment on Matthew's post - the more tricky your protection is, the more fun hackers will have hacking it. Yes, you can prevent a few noob hackers from succeeding, but those noobs will most likely consult more experienced ones (there are plenty of hack-forums out there). And the experienced hackers might actually think it's FUN to hack your code. So yes, you prevent some people from hacking it, but you increase the chance that it WILL eventually be hacked (because it's fun!)
Paulius Maruška
@Paulius, it depends very much on the type of application and size of user base. If it is a popular game, or any low cost widely used application, your argument probably holds true. If it's a niche vertical market application, it is much less likely to be exposed to that many hackers and relatively simplistic license protection mechanisms are beneficial. Basically, the professional pirates don't bother because of limited revenue, and the many amateurs simply aren't interested in these types of application.
Shane MacLaughlin
No matter what niche you're in, if you use a interesting, smart and innovative protection - hackers will sooner or later get interested in it. If it's interesting enough - they'll even write articles/guides/notes about how to hack such things. On the other hand, if your market is small - then you don't have much competition anyway, and basically, everyone knows each other in that market. So it is very unlikely, that someone would try to "change resources and sell the application as their own".
Paulius Maruška
Not in my experience. I, like many smaller software houses, sell through agents world wide. It is very difficult to assert your license conditions through a third party in a different country, and there is clear financial gain if they can easily pirate the software. This has actually been a problem for me on occasion in the past. IMHO, you get two types of hacker; those that do it for fun, and those that do it for commericial gain. I suspect most of the ability lies with the former, and the latter are only successful when they hire this skill in.
Shane MacLaughlin
+1  A: 

If you trust your app you could just calculate a hash on your resource dll before shipping and reject dll:s with other hashes.

disown
That doesn't solve anything. Someone can just hack out the code that checks the resources.
Matthew Flaschen
Well in that case they can just make any modifications. My assumption was that you trust the application.
disown
If someone is willing to illegally copy your dll, why wouldn't they illegally copy (and modify) the executable?
Matthew Flaschen
The point is, it's easy to add the hash check and it makes it harder to hack the app because now they have to hack the exe as well. Of course if somebody is determined enough they will crack it but that doesn't mean you should make it easy.
markh44
+4  A: 

Sign it and then check the signature is valid and there. I would use some sort of offical certificate for the company but a self-signed will do.

A quick google turned up:

Digital Code Signing Step-by-Step Guide (altho it looks like it's for Office XP)

Prevent DLL Tampering on Windows Apps

UPDATE:

It also pays to sign the EXE as well.

As pointed out in the comment, there is no way you can stop someone with enough skill from tampering with your application. It's all about risk management. How much to you want to 'risk' someone tampering with your application. Is it worth the time and effort to rise the bar so that you need a more highly skilled person to temper with your application? That's up to you.

I would at least sign all your code files that you release anyway. It verifies that those files come from you and have not been tampered with.

Shane Powell
Except someone can just hack out the sig verification code...
Matthew Flaschen
Yes, that is true. It's all about risk management, your just rising the bar (so to speak). Anything you do in software can be broken one way or another. If you sign the EXE as well then you rise the bar a little more as well. If your a big enough target then no matter what you do, people will/can hack.
Shane Powell
+1  A: 

You can't. Such issues have to be dealt with through the law, not code. Also note any such "solution" would likely violate user's fair use rights. I have often played around with modifying program resources for fun (e.g. putting a Tux on the Windows login page). I wasn't out to deceive anyone and didn't even distribute the result.

Matthew Flaschen
Totally agree. Worry about making customers happy. If they will love your application - they will report to you as soon as they find a rip off of your app. Then you can go to your lawer, sue, get millions for copyright violation, sit back near the big pool with half naked girls in it and enjoy your drink.
Paulius Maruška
This simply isn't true in many situations. In the states, big software houses resort to using lawyers on a regular basis. Elsewhere, small software houses have to use less expensive means to avoid getting ripped off. If you run a small software house, such as I do, in a niche vertical market where you are selling few expensive licenses rather than many cheap ones, this argument does not hold.
Shane MacLaughlin
Yes it does. Besides, if you get too tricky with your protection - antiviruses and firewalls might prevent your app from running completely (they might recognize the _protection_ code as a possible threat). Also, if you're only selling a few expensive licenses, how will the _hacker_ get your app? Or do you think your clients, the ones that already bought the licenses, will go ahead and hack it?
Paulius Maruška
smacl, sorry but that doesn't make sense. Yes, lawyers are expensive. However, technical solutions simply do not work here. If huge companies can't get DRM working, you're not going to be able to either. It's just not theoretically sound.
Matthew Flaschen
Oh and one more thing. Most hackers hack applications for fun. The more tricky and interesting your protection is - the more chances are that it will be FUN for them to hack it and they will invest more time in it, because it's fun. If you have no protection at all or the protection is a simple if - your app will simply be of no interest to them. Just a thought.
Paulius Maruška
@Paulius, yes clients that have already bought some licenses are one of the most significant sources of piracy for high end applications. Buy one license, use ten. Look at court cases AutoDesk have brought in recent years for evidence of this.@Matthew, DRM is largely an attempt to protect low cost, high volume, data based products. High cost, low volume software products are considerably easier. I've been in business on this basis for over 20 years; I doubt my business would have been viable without technical license protection mechanisms.
Shane MacLaughlin
What is a "technical license protection mechanism", if not DRM?
Matthew Flaschen
A: 

You could checksum the dll binary, check it from the main program and quit / disable features if it's different. It won't stop someone hell bent on ripping off your stuff since they could hack out the checking code in your exe but at least it won't be so easy.

markh44
A: 

As everyone is saying you can only raise the bar to make it more difficult to hack, I wouldn't spend more time on it than having a hash as disown suggests. An alternate way of thinking about this (if you software allows it) is to make your software attractive in the long term with updates etc. That way people will want an account with you rather than a hacked version.

Patrick
A: 

You can't prevent your application from being hacked any more than you can't prevent your car from being stolen, sure, you can have state of the art alarm system and have it blow fire if it detects it's not the owner, but someone could just break the glass or wear fire-proof suit. In short, you can't.

Hao Wooi Lim
A: 

If this is commercial software and you are worried about theft then you should look at third party solutions. There is plenty of software designed to protect from shareware up. They are different prices with different features.

As others have said no pure software solution is completely safe. But I would recommend outsourcing this and concentrate on the business value your application provides.

iain