views:

179

answers:

6

Disclaimer: I'm not sure if this is for a programming or startup forum, anyway...

Hello, I'm building a software (a concept-mind-mapping/diagramming product in .NET) and seeing trouble with obfuscation (alteration of deliverable code to difficult decompilation): It cost money and time to make it work ok, and I think hackers will break it anyway, so...

It would be so damaging not to obfuscate it? Maybe somebody here had the bad experience of being hacked and found a clone of his product?

+1  A: 

If my product is being hacked or pirated, I must have built a good/useful one. :P

You do not need to obfuscate the entire application, perhaps only those aspect where your business core intellectual property (IP) lies.

I found pain in obfuscation of one of my products in my previous job, but it's a learning process. You will find an easier way to do it eventually.

Of course it is not 100% foolproof, but if it be 99.9%, it can be a viable business decision.

o.k.w
+10  A: 

One question to ask yourself is, what is my intellectual property? If it's a custom algorithm, follow o.k.w's advice. But if the idea is inherently visible, obfuscation isn't going to buy you much.

For example, let's say you invented the first spreadsheet software. A skilled developer or team could create a copy without ever seeing the source code. The idea of rows and columns with embedded calculations is the intellectual property.

If you believe that other developers could clone your program after external inspection without disassembly, then obfuscation may not provide significant protection.

TrueWill
Good point you have there TrueWill, a different perspective from mine. Or rather a fresh one. :P +1
o.k.w
Interesting point of view.Still... the problem is that, with Reflector alike easy decompilation, a hacker could almost only change the company and product names, plus logos, some fonts and styles/themes to make a "new" thing.
Néstor Sánchez A.
@Néstor: That's true. At that point the courts may be your best weapon. I'd check with an attorney experienced in software copyright/patent law. Find out what you need to file (partial source code plus screen shots, perhaps) before releasing the product in order to protect your IP. You might also consider a reasonable support/upgrade policy as an incentive for legitimate purchasers.
TrueWill
+1  A: 

I agree with TrueWill.

It's also important to notice that most of the time, spending your time improving your application and staying ahead of the competition will yield better results.

There is hardly something which is unbreakable.
If you just want to prevent the average programmer from disassembling, you're much better spending your time in improvements of your product.

OTOH, if you're worried about very talented people with lots of time, they are most guaranteed to be able to break it one way or another, so you might not spend much time here neither :)

In general, having a good product that's able to attract enough clients to be profitable is a much more important issue than obfuscation/piracy/IP.

Carlos Lima
+1 for good advice (not just for agreeing with me!) ;)
TrueWill
+5  A: 

One reason not to obfuscate is that you then have a hell of a time dealing with crash reports (think call stacks and dumps), because then you're in a position of the "hacker".

Pavel Minaev
Good point.I'm also considering that strategy of some products sold with source code as a plus.
Néstor Sánchez A.
A: 

Obfuscation also makes it harder to tweek the performance of you application ... since the obfuscator will rewrite the IL (especially if you use some sort of flow obfuscation)

Jason Haley
A: 

This question sort of falls under the basic question of

"How much security should I incorporate in my product?"

There are many ways you can secure a product but I think that the general approach is to layer enough security such that the economics of buying the product are cheaper than the economics of breaking the security of that product.

Thus if you are selling a product worth $10 then you only need to incorporate a security system that would "cost" the hacker $15 and the incentive will be to buy the product rather than hack. Likewise for a product that costs $10,000 you could spend resources to ensure that the hacking "cost" was well over $10,000. However you would also need to factor in things such as the likelyhood of your broken product being served up on the Internet.

As long as the breaking costs are less than the product cost there will always be financial incentive to break your program. (So part of your development should be playing hacker and trying to figure out how easy it would be to break your own security)

But to play Devil's advocate, the people trying to break your program may be interested in the challenge and not be interested in economics, in which case it doesn't really matter how much security you layer on your product as eventually it will be hacked.

Peter M