3

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?

Gautam Jain
  • 6,789
  • 10
  • 48
  • 67
  • 3
    If someone is *really* willing to hack / modify your resource, you won't be able to avoid it. I'd suggest just accept the fact that if your product is good enough, someone will hack it. Think as this like a compliment : if you find some of your resource in another place than in your dlls, this would mean your program is considered having a very good design ! In short, from my point of view : the time you'll spend trying to protect your program against thieves is a pure loss of time. – Olivier Pons Jun 05 '09 at 07:13
  • 1
    @Olivier Pons, this is only true if your protection is ineffective, and you spend alot of time putting it in place. If you can do something quickly that will hamper inexpert hackers, it is probably worthwhile. – SmacL Jun 05 '09 at 07:22
  • @Olivier, every common door lock can be picked in minutes, even seconds. Still, most people use them,. – peterchen Jun 05 '09 at 09:32

8 Answers8

4

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.

roalz
  • 2,699
  • 3
  • 25
  • 42
Shane Powell
  • 13,698
  • 2
  • 49
  • 61
  • 1
    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 Jun 05 '09 at 07:00
1

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

Alexander Torstling
  • 18,552
  • 7
  • 62
  • 74
  • That doesn't solve anything. Someone can just hack out the code that checks the resources. – Matthew Flaschen Jun 05 '09 at 06:51
  • Well in that case they can just make any modifications. My assumption was that you trust the application. – Alexander Torstling Jun 05 '09 at 06:56
  • If someone is willing to illegally copy your dll, why wouldn't they illegally copy (and modify) the executable? – Matthew Flaschen Jun 05 '09 at 07:25
  • 2
    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 Jun 05 '09 at 07:45
  • You could use this hash check as part of an algorithm your application requires. That way if it is altered, your functionality breaks. Xor can be your friend here. Have a constant number your application need and xor with the hash on a calculator. Then every place you need that number, xor that computed xor'd number with the hash, and out pops your constant. Do this with several constants, and it becomes several times harder. But there are better algorithms than xor. Be creative! – TamusJRoyce May 08 '12 at 04:11
0

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
  • 278,309
  • 50
  • 514
  • 539
  • 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 Jun 05 '09 at 07:01
  • 1
    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. – SmacL Jun 05 '09 at 07:12
  • 1
    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 Jun 05 '09 at 07:22
  • 1
    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 Jun 05 '09 at 07:24
  • 1
    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 Jun 05 '09 at 07:25
  • @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. – SmacL Jun 05 '09 at 10:45
  • What is a "technical license protection mechanism", if not DRM? – Matthew Flaschen Jun 05 '09 at 11:03
0

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
  • 5,804
  • 5
  • 28
  • 33
0

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
  • 8,175
  • 7
  • 56
  • 72
0

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
  • 3,928
  • 4
  • 29
  • 35
0

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
  • 10,798
  • 3
  • 37
  • 41
  • Shareware? That brings up the question why does shareware exist for free, but not disclose its source-code? Also, the more known the commercial encryption software you use is, the more likely someone has hacked that software. Then they only have to reproduce the steps on your program, rather than use custom-reverse engineering. So it could be that what looks like more secure solution is really less secure. Especially if that hack gets distributed. Commercial can be good sometimes, but avoid popularity. – TamusJRoyce May 08 '12 at 04:34
-1

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

SmacL
  • 22,555
  • 12
  • 95
  • 149
  • 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 Jun 05 '09 at 06:51
  • 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. – SmacL Jun 05 '09 at 07:18
  • 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 Jun 05 '09 at 07:34
  • 1
    @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. – SmacL Jun 05 '09 at 10:32
  • 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 Jun 05 '09 at 10:43
  • 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. – SmacL Jun 05 '09 at 10:53
  • -1 @Shane, you have only harmed yourself in replying back so many times. You may be going off of the fact that your security scheme is easy to break and therefore hackers won't have fun hacking it. Or it may be another reason you believe they won't hack it. But try and stay with facts. Humble opinions may be humble, but they don't help your rebute. – TamusJRoyce May 08 '12 at 04:03
  • @TamusJRoyce, the simple fact is the security I use works well for me, and I know similar mechanisms work well for others. No security isn't a viable commercial solution for me, and more complex solutions aren't warranted. That's not a matter of opinion, unlike you're comment which doesn't appear to contain any worthwhile content. – SmacL May 08 '12 at 07:38