Preventing Resource DLLs from being hacked - c++

Question

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?

Answer 1

Sign it and then check thef signature is valid and there. I would use some sort of official 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.

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.

Answer 7

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.

Answer 8

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