Pros/Cons of Obfuscation ?

[Johnny Drama]

I was playing around with a free decompiler called "Reflector." I ran it
against a .NET assembly and was pretty amazed with how well it converted IL
back to C#. It got me thinking about obfuscation.

My limited understanding of obfuscation is that methods and variables
are renamed randomly. A property named 'Stagmire' might be renamed 'xdFd' or
a method named 'ComputeCorrelation()' might be renamed 'Fooodbone()'.
Although this technique certainly can't prevent reverse engineering, it at
least makes code theft and subsequent human interpretation a lot harder,
which is really all I'm trying to accomplish.

What are the drawbacks of obfuscation? In other words, why doesn't
VS2005 just obfuscate by default? There must be some drawbacks.

One thing I'm fond of doing when debugging beta apps is to catch
unhandled exceptions and then display the stack trace in a popup window. The
beta tester then copy/pastes the stack trace into an email to me so I can
track down the source of the problem. It seems to me that if the code were
obfuscated, the stack trace would be impossible to interpret because the
method names would be mangled, correct? That would be a problem for me.

Is the obfuscator that comes with VS2005 sufficient for most programmers
or do you recommend going with a 3rd party solution?

Thanks,

Johnny Drama

 

[Kevin Spencer]

IMHO, obfuscation is a waste of time. First, even native machine code can be
decompiled. Yes, it's more difficult, but who are you trying to protect
yourself against? If it's the average user, obfuscation is unnecessary. If
it's the shade-tree developer, it is possible that a shade-tree developer
could use the tools to get at your code, but what kind of a threat is a
shade-tree developer to you? If it's a professional, a good developer could,
in time, decompile anything you write in any manner. There are a lot of ways
to get at the inner workings of software without decompiling as well. But
this is something that takes a good investment of time, and unless your
software is very attractive and/or innovative, noboby's going to bother with
it.

Now, if you work for a large corporation, with a large team of developers
creating some highly-popular commerical software with innovative
technologies, it might be worth your while. On the other hand, you can get a
Patent for any new technologies you come up with. And if someone copies your
code, and they are big enough to notice, it isn't hard to identify them and
sue them for patent infrigement. If they're not big enough to notice, what
difference does it make to your business if they do?

Finally, the best way to compete is to stay ahead of the competition. It
takes months or even years to write software. By the time you release it,
you can move on to the next thing, and anyone copying you is already behind.
But if you waste too much time trying to make your software hard to copy,
that's time that could be spent moving ahead. In other words, we have
limited time resources. We should invest our time in activities that will be
the most profitable.

I could take the same attitude about helping people. Why, by helping them, I
suppose I could think of it as helping the competition. But as long as I'm
sharing what I already know, those who are behind me picking up my scraps of
information will remain behind me. It is simply not possible to get ahead of
someone you are following, by definition. OTOH, by helping others I benefit
as well. Sometimes I have to do research, and learn along the way. I am
accumulating good "karma" as a result of my good works. And I have made
quite a few friends that I can call on when I need help. So I share what I
know freely. And keep moving forward.

That's my 2 cents.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Chicken Salad Alchemist

What You Seek Is What You Get.

 

[Cor Ligthert [MVP]]

Well said Kevin,

Cor

IMHO, obfuscation is a waste of time. First, even native machine code can
be decompiled. Yes, it's more difficult, but who are you trying to protect
yourself against? If it's the average user, obfuscation is unnecessary. If
it's the shade-tree developer, it is possible that a shade-tree developer
could use the tools to get at your code, but what kind of a threat is a
shade-tree developer to you? If it's a professional, a good developer
could, in time, decompile anything you write in any manner. There are a
lot of ways to get at the inner workings of software without decompiling
as well. But this is something that takes a good investment of time, and
unless your software is very attractive and/or innovative, noboby's going
to bother with it.

Now, if you work for a large corporation, with a large team of developers
creating some highly-popular commerical software with innovative
technologies, it might be worth your while. On the other hand, you can get
a Patent for any new technologies you come up with. And if someone copies
your code, and they are big enough to notice, it isn't hard to identify
them and sue them for patent infrigement. If they're not big enough to
notice, what difference does it make to your business if they do?

Finally, the best way to compete is to stay ahead of the competition. It
takes months or even years to write software. By the time you release it,
you can move on to the next thing, and anyone copying you is already
behind. But if you waste too much time trying to make your software hard
to copy, that's time that could be spent moving ahead. In other words, we
have limited time resources. We should invest our time in activities that
will be the most profitable.

I could take the same attitude about helping people. Why, by helping them,
I suppose I could think of it as helping the competition. But as long as
I'm sharing what I already know, those who are behind me picking up my
scraps of information will remain behind me. It is simply not possible to
get ahead of someone you are following, by definition. OTOH, by helping
others I benefit as well. Sometimes I have to do research, and learn along
the way. I am accumulating good "karma" as a result of my good works. And
I have made quite a few friends that I can call on when I need help. So I
share what I know freely. And keep moving forward.

That's my 2 cents.

--
HTH,

Kevin Spencer
Microsoft MVP
Professional Chicken Salad Alchemist

What You Seek Is What You Get.

 

[Jim]

Hi Johnny,

This question pops up on here almost weekly.

You'll then get the response that you should not worry about obfuscating
your code, becuase its a waste of time, and that you must stay ahead of the
competition by working on the next version.

That's true to an extent. But if your current version of the software is
already good enough for most people's needs. depending on who your market
is, the "free" version that has had it's licensing scheme reversed, may be
good enough for too many people to use, which could loose you some revenue.

The key question is how much revenue will this loose you? This depends on
how honest you think your market is. In all markets you will almost
certainly loose some revenue to unlicensed versions being used. The question
is, do you think that your business model will still be viable with the
legitimate sales?

It may be the case that even if half of the users of your software product
are using a pirated version, you could still make a good return on the
legitimate versions being used.

Obfuscation does have a place if you want to make reverse engineering a
little harder. - Why hand c# code with descriptive names to your competition
on a plate? - I appreciate that many of these specialist pieces of software
created by small software houses are in very competive markets, and that
this may be a concern. - even if your code is not what people would call
groundbreaking.

The important thing is not to get too bogged down in code security, and find
the balance between protecting your revenue stream (either with license
protection or people being able to rip off your code very easily), and that
of being creative with your software's actual functionality.

Getting back to your question on obfuscated code debugging. I think most of
the pro level versions have features where they can map the obfuscated code
symbols for debugging etc.

HTH

Jim

 

[Guest]

Pesonally, I agree that obfuscation has limited use since it is possble to
extract and decompile the code from an "obfuscated" assembly right out of
memory, as Dr. Luo of Remotesoft has expertly shown.
Just my 2 cents.
Peter

 

[Mythran]

Well Said Cor.



Mythran

Well said Kevin,

Cor

 

[Jim]

Very true, but...

1) What looks easier to understand from memory? An assembly with a whole
load of overloaded variables and functions called "a, b, c" etc or an
assembly with the original descriptive names of every single part of the
project?

2) If you are having to decompile the code from memory, then it's another
step in the process of reversing the code. ( I think though you are refering
to 3rd party tools that "encrypt" the IL - which of course is quite useless,
when a decryptor is available)

As it stands an unobfuscated assembly can virtually reveal verbatim the
original source, in a nice high level language, by simply dragging and
dropping the file into the likes of Reflector.

This may not be a issue for many software projects. But for others, some
people may not want to make their source code directly available to the
competition, or have people see easily how a license scheme works.

For these people, then either code obfuscation or compiling to native code
(not encryption) makes the code less obvious from just performing simple
drag and drop operation.

I'm not suggesting obfuscators are wonderful and the whole answer. But they
do make things a less easy for prying eyes, and in my veiw, are not the
total waste of time that some people think they are.

Jim

 

[Rob R. Ainscough]

I rarely agree with you Kevin, but this time I do -- total waste of time and
lots of agro along the way.

Now, as far as protecting code, their should be a way, their isn't a simple
and reliable way -- thank you for Microsoft.

As far as staying ahead of the competition ... I can't think of anything in
..NET based projects that could be so innovative that it requires so much
protection of content. .NET is pretty much for the non-innovators. What
..NET should do is permit the most rapid, flexible, efficient production of
large scale useful applications (it fails in most cases).

If you want to stay ahead of the competition, don't code anything based on
..NET.

 

[Rob R. Ainscough]

or write extremely abstract code or write extremeley bad code, both will be
confusing enough in their own rights

But again, a 2005 development tool should have a secure means of code
distribution not this hokey obfuscation BS that was clearly a filler tool
from the Microsoft bone yard of vendor consumption. But as with all things
Microsoft, their committment to security is a joke.

Rob.

 

[Michael C]

Hi Johnny,

This question pops up on here almost weekly.

You'll then get the response that you should not worry about obfuscating
your code, becuase its a waste of time, and that you must stay ahead of
the competition by working on the next version.

That's true to an extent. But if your current version of the software is
already good enough for most people's needs. depending on who your market
is, the "free" version that has had it's licensing scheme reversed, may be
good enough for too many people to use, which could loose you some
revenue.

I can see the situation where you might have 2 or more similar niche market
companies and 1 might have a feature the other doesn't. For example my
software uses IMPAI to burn CDs which I don't think the others do. It would
be fairly easy for the other company to look at my software and see how I
did it. They might not copy it direct but take large chunks of code out. I
wouldn't have a hope in hell of suing them. In that case obfuscation could
be good, if there's no down side to obfuscation then why not?

Michael

 

[Jon Skeet [C# MVP]]

I can see the situation where you might have 2 or more similar niche market
companies and 1 might have a feature the other doesn't. For example my
software uses IMPAI to burn CDs which I don't think the others do. It would
be fairly easy for the other company to look at my software and see how I
did it. They might not copy it direct but take large chunks of code out. I
wouldn't have a hope in hell of suing them. In that case obfuscation could
be good, if there's no down side to obfuscation then why not?

Any additional process is a downside in and of itself. Then you need to
ask yourself how the developers will be running the software during
development. Unless they're obfuscating the whole time, you're one step
further away from running what the customer will see - and that can be
a cause of problems.

Finally, there's the stack trace issue - obfuscator software tends to
come with a way of deobfuscating stack traces (using a map which is
created during obfuscation) but it's extra work. Not a lot of extra
work, maybe, but extra work nonetheless.

 

[Frans Bouma [C# MVP]]

IMHO, obfuscation is a waste of time. First, even native machine code
can be decompiled. Yes, it's more difficult, but who are you trying
to protect yourself against? If it's the average user, obfuscation is
unnecessary. If it's the shade-tree developer, it is possible that a
shade-tree developer could use the tools to get at your code, but
what kind of a threat is a shade-tree developer to you? If it's a
professional, a good developer could, in time, decompile anything you
write in any manner. There are a lot of ways to get at the inner
workings of software without decompiling as well. But this is
something that takes a good investment of time, and unless your
software is very attractive and/or innovative, noboby's going to
bother with it.

I don't agree with the fact that it's a waste of time. Ok, you can't
protect your code against a person who has unlimited time. However,
that group is so incredibly small.

Back in the days when I was still a member of the demoscene, a Finnish
group called Komplex made a java XM music player for their java demos.
As that gave them a big advantage over competing groups in
competitions, the competing groups tried to re-use their XM player.
However it was obfuscated, with their own obfuscator. It was hardly
readable. For fun we tried for 2 days to get it cut out but failed
simply because it was too tiresome, even with countless renames and our
own tools to rework the obfuscation.

So I know from a fact that it's not a waste of time. Of course, this
was an experiment and when I asked Saviour, who wrote the routine, if
we could use it in our javademos, I got it in a heartbeat, but it did
proof obfuscation COULD work, however it has to be done properly.

I think your question: who are you protecting against, is actually
about: "WHat are you protecting?".

If it's all code in your application, it will also give a problem,
e.g. with customers reporting exceptions and weird stacktraces.

If it's protecting your application's copy protection method, it can
very well be worth the effort: as it keeps off the 'office hacker' as I
call them: the 'clever' guy of the team who volunteers to give the
protection a try during lunch.

Especially with trial versions it can be very well worth it: to
protect a trial version, you have to go an extra mile as it is time
limited, which is the weak spot, and trust me, NOTHING is more
frustrating than when you receive an email 2 days after you released
your hard work and it says "I managed to crack your app's protection in
1 minute, you might want to harden it a bit".

Perhaps you don't sell your own software, I don't know. But in case
you do, I fully recommend using obfuscation, at least in the trial
version.

Also to make obfuscation really work do:
- make all forms/classes in your .exe project internal
- make all methods of these classes at least internal
- if unsure, use ndepend to check which methods you can make
protected/private/internal. This will greatly enhance the obfuscation
output. You can then even achieve great results with the community
edition of dotfuscator.

Now, if you work for a large corporation, with a large team of
developers creating some highly-popular commerical software with
innovative technologies, it might be worth your while. On the other
hand, you can get a Patent for any new technologies you come up with.

1) Software patents suck. I can't believe someone who is writing
software for a living could ever advocate software patents.
2) Getting a patent is hard, costly and a gamble
3) Software patents are not legal in a lot of countries, like the EU,
india etc. Just because the US has a wacky patent system doesn't mean
the rest of the world has.
4) If I might add: patents in general don't really increase innovation.
That's not because of the core definition of a 'patent' but more of the
system who protects them: winner takes all is silly. For example there
are multiple companies who have a patent on O/R mapping (Firestar and
Microsoft to name a few)

And if someone copies your code, and they are big enough to notice,
it isn't hard to identify them and sue them for patent infrigement.

oh? A lawsuit is always uncertain: you might lose. And sueing a large
company with big pockets and expensive lawyers will bury you with
paperwork till doomsday. It will likely make you go belly up. Also,
this is curing symptoms, not the cause: you could perhaps solve this
after 10 years, but in those 10 years you have spend a lot of energy on
useless things: better spend that energy on writing good software.

Finally, the best way to compete is to stay ahead of the competition.
It takes months or even years to write software. By the time you
release it, you can move on to the next thing, and anyone copying you
is already behind. But if you waste too much time trying to make
your software hard to copy, that's time that could be spent moving
ahead. In other words, we have limited time resources. We should
invest our time in activities that will be the most profitable.

exactly. However if you could make it your competition even more
difficult by clicking a few buttons and spending 10 minutes of your
time in an obfuscator, what's lost? at most, 10 minutes.

FB, who uses an obfuscator to protect trial protection code.

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

 

[Frans Bouma [C# MVP]]

or write extremely abstract code or write extremeley bad code, both
will be confusing enough in their own rights

But again, a 2005 development tool should have a secure means of code
distribution not this hokey obfuscation BS that was clearly a filler
tool from the Microsoft bone yard of vendor consumption. But as with
all things Microsoft, their committment to security is a joke.

though what do you propose? Encrypted IL which is decrypted in-memory?
There's always a way to tap into the execution engine, as it runs in
userland.

if you use this:
- assembly signing, so modifying the code requires a new key
- checking the signature of the signed code regularly in your code
using obscure code so changing the signature will eventually cause a
problem
- obfuscate that code so finding the check code and other checks (on
the checks for example ) are _HARD_ to find

only the people with unlimited time on their hands will succeed. The
rest won't and give up.

decompiling the code in ildasm, changing strong name, compiling it
with ilasm won't help you there.

FB

Rob.

Very true, but...

1) What looks easier to understand from memory? An assembly with a
whole load of overloaded variables and functions called "a, b, c"
etc or an assembly with the original descriptive names of every
single part of the project?

2) If you are having to decompile the code from memory, then it's
another step in the process of reversing the code. ( I think though
you are refering to 3rd party tools that "encrypt" the IL - which
of course is quite useless, when a decryptor is available)

As it stands an unobfuscated assembly can virtually reveal verbatim
the original source, in a nice high level language, by simply
dragging and dropping the file into the likes of Reflector.

This may not be a issue for many software projects. But for others,
some people may not want to make their source code directly
available to the competition, or have people see easily how a
license scheme works.

For these people, then either code obfuscation or compiling to
native code (not encryption) makes the code less obvious from just
performing simple drag and drop operation.

I'm not suggesting obfuscators are wonderful and the whole answer.
But they do make things a less easy for prying eyes, and in my
veiw, are not the total waste of time that some people think they
are.

Jim

'Fooodbone()'. >>> Although this technique certainly can't prevent
reverse engineering, it >>> atdoesn't >>> VS2005 just obfuscate by default? There must be some
drawbacks.catch >>> unhandled exceptions and then display the stack trace in a
popup window. >>> Thebecause the >>> method names would be mangled, correct? That would be
a problem for me.

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------

 

[Cor Ligthert [MVP]]

Frans,

In my opinion are you mixing up a little bit in this answer "copy
protection" and "obfuscating".

The reason for the first is to protect the by you added intelligence (as it
is protected by law in the EU) is not illegally sold.

The second is in my idea to avoid that somebody is stealing your knowledge
of the used program language.

That is why I in general agree very much what Kevin has written. There are
of course a lot of exceptions on that, by instance very clever algorithms as
you wrote, which are a part of the intelligence but from which it is clever
to obfuscate those.

Although I have as well the idea that obfuscating is used to protect that
somebody sees how rotten some programs are written.



Cor

 

[Guest]

From the posts in this thread, it appears that we may be in the minority.
However, we believe obfuscation is an important and necessary part of
protecting your intellectual property.

Just load an un-obfuscated .NET assembly into Reflector, and you'll see that
it's like an open book of your source code with everything except the
comments. A simple rule of thumb: If you wouldn't publish your original
source code on the web, then you should obfuscate.

Obfuscating is easy and effective. It won't stop pirates with lots of time
and resources, but it will make their job much harder. Like all defenses,
it's a balance, in this case between the cost of obfuscating and the cost of
releasing your software unprotected. With properly obfuscated code, unless
you are writing national security software, it's unlikely pirates will even
bother to attempt to disassemble your code. Obfuscation may not be the Fort
Knox vault, but it's much more than a lock on a screen door.

In our experience, once you pay for the tool (if you are not using the free
version in Visual Studio), the cost of obfuscation is almost zero. It's
simply another step in our automated build process.

As for debugging, obfuscating is not an issue, as you should be debugging
your code BEFORE you obfuscate it.

We use the Xenocode Obfuscator. It's fast, works well, and adds limited
overhead to our assemblies. (We do not have any relationship to Xenocode
other than as a satisfied customer.)

 

[Guest]

As far as staying ahead of the competition ... I can't think of anything in
..NET based projects that could be so innovative that it requires so much
protection of content. .NET is pretty much for the non-innovators. What
..NET should do is permit the most rapid, flexible, efficient production of
large scale useful applications (it fails in most cases).

If you want to stay ahead of the competition, don't code anything based on
..NET.

I respect your opinion, but I don't understand how the tool used to build a
product determines the level of innovation in that product. I've seen some
amazing software written in crappy ol' JavaScript, and conversely I've seen
some real crap written in the time-tested C++.

The thing I love most about .NET (and C# in particular) is you simply write
the code and it works. No more spending hours chasing down memory leaks,
improperly dereferenced pointers, pointers to pointers, yada yada. Though I
had spent over a decade of my career writing C++ code, a month after C#
arrived, I dropped C++ like a hot potato.

..NET and C# enable us to produce more software in less time with fewer
defects. .NET enables us to better focus on the high-level business problem,
rather than the nitty gritty details of writing code. Let's face it--our
customers couldn't care less about what tools we use. They just want
reliable software that solves their problems.

 

[Michael C]

Any additional process is a downside in and of itself. Then you need to
ask yourself how the developers will be running the software during
development. Unless they're obfuscating the whole time, you're one step
further away from running what the customer will see - and that can be
a cause of problems.

Finally, there's the stack trace issue - obfuscator software tends to
come with a way of deobfuscating stack traces (using a map which is
created during obfuscation) but it's extra work. Not a lot of extra
work, maybe, but extra work nonetheless.

That doesn't address any of the issues raised in my post though.

Michael

 

[Jon Skeet [C# MVP]]

That doesn't address any of the issues raised in my post though.

It addresses your "If there's no down side to obfuscation then why
not?" question by giving downsides.

 

[Michael C]

It addresses your "If there's no down side to obfuscation then why
not?" question by giving downsides.

Fair call, I missed that (In my own post!!!!).

Michael

 

[Frans Bouma [C# MVP]]

Frans,

In my opinion are you mixing up a little bit in this answer "copy
protection" and "obfuscating".

The reason for the first is to protect the by you added intelligence
(as it is protected by law in the EU) is not illegally sold.

The second is in my idea to avoid that somebody is stealing your
knowledge of the used program language.

That is why I in general agree very much what Kevin has written.
There are of course a lot of exceptions on that, by instance very
clever algorithms as you wrote, which are a part of the intelligence
but from which it is clever to obfuscate those.

Although I have as well the idea that obfuscating is used to protect
that somebody sees how rotten some programs are written.

Adding a copy protection algorithm which is easily broken because
it's easy to find and simple to remove is of no use. Obfuscation makes
that process harder. I used copy protection as a reason to use
obfuscation, as someone claimed it was a waste of time.

FB

Cor



code >> can be decompiled. Yes, it's more difficult, but who are you
trying >> to protect yourself against? If it's the average user,
obfuscation is >> unnecessary. If it's the shade-tree developer, it
is possible that a >> shade-tree developer could use the tools to get
at your code, but >> what kind of a threat is a shade-tree developer
to you? If it's a >> professional, a good developer could, in time,
decompile anything you >> write in any manner. There are a lot of
ways to get at the inner >> workings of software without decompiling
as well. But this is >> something that takes a good investment of
time, and unless your >> software is very attractive and/or
innovative, noboby's going to >> bother with it.
competition. >> It takes months or even years to write software. By
the time you >> release it, you can move on to the next thing, and
anyone copying you >> is already behind. But if you waste too much
time trying to make >> your software hard to copy, that's time that
could be spent moving >> ahead. In other words, we have limited time
resources. We should >> invest our time in activities that will be
the most profitable.

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------