Obfuscation

re: Obfuscation

denny — Sat, 10 Jul 2004 04:22:00 GMT

In the end In see all forms of "copy protection" and the like as silly ...

in the end If someone wants to work out how you did "it" they can and will.

all we are doing is making it more difficult to get back the source lines and comments.

IMHO way to often developers and businesses spend way to much cash on the effort with minimal returns...

if a class library is good and at a fair price folks will buy it rather than spend the time decompiling it... most software sold to the "average consumer" will never be decompiled by the user.

so I'd say study how much cash you spend for how much benefit... and include the hassles that come with over protecting things....

I have seen more than one time where games would not run on some systems due to the cd protection code trying to access for example data at > 600 megs .... older cd rom drives cant go there, why should the user have to go buy a new drive for the benifit of the publishers ??
other times CD-RW drives have had issues with some disks....

I could give many other examples where the legal licensee is ready to chuck the software due to over zelous use of protection....

re: Obfuscation

Balaji — Sat, 10 Jul 2004 06:10:00 GMT

In the end, it appears that MS did not put in adequate thought about decompiling when they designed .Net framework. Let's face it. Almost the whole of .Net source can be viewed using the .Net Reflector tool. This should definitely be a boon to those hackers out there who want to exploit every little MS vulnerability.. Even thought MS seems to be underplaying the effect of decompiling, I think it's malicious potential is far more that what is being said. At least lot of MS .Net code will be "open source" whether by intent or not.

re: Obfuscation

Steve Hurst — Tue, 13 Jul 2004 19:16:00 GMT

I agree I feel Microsoft did not put enough thought into this area. I fell it has been an after thought to put the obsfucator in and it is seen as an achillies heel.

I understand the problems of encryption but I really think there needs to be something.
Partiulary with people trying to develop smart clients, they are fighting an upward battle against normal web pages for managing data,in the area of security. What will it take for somebody to sit ,track and then find ways to skip the security modules within a smart client, something you can't do with Web pages.

No, having assemblies that have fixed lifetime where the private keys regualry change and the users having to down load a new security assembly is really the only way.

If you want to use anologies we do it for passwords and I think the same should be appplied to application in which the pasword is being used.

re: Obfuscation

Nigel Watson — Wed, 14 Jul 2004 09:01:00 GMT

This is a challenge that applies to all platforms, not just .NET.

At the end of the day, any kind of code protection mechanism can be defeated, given an attacker who is sufficiently determined, skilled and tooled up.

Obsfucation/encryption techniques work on the principle of 'raising the bar' so that the cost of cracking your code exceeds the likely value to be gained from doing so. But these techniques are not fullproof, and in some cases actually decrease your security by giving you a false sense of protection against people looking at your code.

This is an old argument. For instance, I remember the enormous amount of work that some game development houses put into protecting Amiga code via various encryption/code permutation/loader hacks. And at the end of the day, their code was still generally as widely pirated as anyone elses.

If you are trying to protect against exploitation of security vulnerabilities in your code, you are better off building for security from the ground up (secure by design, default and deployment) - and avoiding code vulnerabilities in the first place - rather than applying obsfucation or encryption techniques to protect your cock-ups from prying eyes. Good security should withstand examination of the code.

If you are trying to protect some IP that is embodied in your code, then you need to decide whether you actually want to deploy that code onto client machines. If you really, really really care about this IP, then you wont. You'll stick it in a web service somewhere, and make clients connect to it via a network. No code deployed to client means no code running on the client means no files or in-memory images of your IP. Period. Maybe this is feasible, maybe not, but you have to decide whether the value of your IP is enough to warrent this approach.

re: Obfuscation

Brian Duffy — Wed, 14 Jul 2004 21:45:00 GMT

I tend to agree with the other posters... obfuscation is often a waste, as it doesn't buy you much.

Whenever I have dealt with vendors who spent alot of time obfuscating code, the obfuscation was more about covering up cob-job work than "protecting" IP.

Value is all about perception. If you are creating something that adds value to someone else's work, they generally license it. That's why some web people use IIS, even in the face of excellent & free competitors like Apache.