Dotfuscator and others

  • Thread starter Thread starter Just D.
  • Start date Start date
J

Just D.

Guys,

What's the current situation with obfuscating, dotfuscating, encryption and
other tricks that we could do to .NET applications before deployment? It
wasn't very good a year ago, was something changed since that?

Just D.
 
No real breakthroughs, no. I don't forsee anyway for obfuscation to
improve by leaps and bounds without some signifigant change in the
framework.
 
I have to agree. I try to stay busy innovating; I find it renders reverse
engineering pretty impractical.

--Bob
 
I know it's just speculation, but I found it interesting what some are
trying to do..

Isn't making reverse engineering impractical the whole idea?

jim
 
Just said:
Guys,

What's the current situation with obfuscating, dotfuscating, encryption and
other tricks that we could do to .NET applications before deployment? It
wasn't very good a year ago, was something changed since that?
Click to expand...

Well, obfuscators do a good job, even the community edition of dotfuscator
can create unreadable code, but you have to program for it first. So here are
some tips.

1) download a copy of NDepend. http://smacchia.chez.tiscali.fr/NDepend.html
This tool shows you which methods can be internal, private and protected
while you probably made everything public for example.
2) your .exe application should solely contain internal classes and internal
methods/properties (or private).
3) seal your mainform / startup form.

Due to the internal classes and internal/private methods, the code can be
mangled very good as types can be mangled as well. If you don't do this, code
will be almost not obfuscated, at least not the types and public methods.

Frans.
 
Jim said:
I know it's just speculation, but I found it interesting what some are
trying to do..

Isn't making reverse engineering impractical the whole idea?
Click to expand...

Not necessarily. A library perhaps can't be reverse engineered, but the
interface it exposes can still be used in your own code. What's thus also a
problem is finding copy protection code. Through obfuscation, this can be a
very hard job. Which makes the protection of the obfuscated work a little
easier.

Frans.
 
William Stacey said:
IMO, not worth reading. Very biased with leaps of logic.
Click to expand...

And hugely inaccurate.

Let's see:

1) "The problem is .NET, Microsoft=3Fs slowly evolving and very difficult
to understand effort to network-enable everything [...]"

That gives a completely inaccurate idea of the aim of .NET. Network-
enablement is only a small part of the story.

2) "You can write a program in C# or Visual Basic.NET. .NET is almost
exclusively Just-In-Time compiled. JIT'ing means, "I was just about to
interpret this, but I'll compile it at the very last minute instead."
In effect, the .NET code remains in interpretation-intended form right
up until the end."

Given that it's exclusively JIT-ted, claiming that it's
"interpretation-intended" at any point is bizarre.

3) "Java is interpreted and subject to this same vulnerability"

Apparently Robert still lives in about 1996, when Java really *was*
interpreted. While HotSpot (the most commonly used JVM, I believe) is a
mixed-mode JVM, interpreting code sometimes and JIT-ting it at other
times, the vast majority of JVM execution is JITted code, not
interpreted.

4) "The result is that nearly every emerging Microsoft product is
vulnerable, including the OS itself. That=3Fs one reason why we are
always hearing more, not fewer, stories about Microsoft security
problems."

How many security vulnerabilities have been announced in .NET products?

5) "The answer to providing a modicum of security for interpreted
applications has to this point been obfuscation -=3F making the code look
different so it can be difficult to decompile and figure out."

No, the answer to providing security is in strong authentication of
code, and making sure that that code itself is secure. Something being
easily reverse engineered doesn't make something insecure: if your
security relies on people not knowing exactly what the program does,
your code isn't secure to start with. Security through obscurity just
doesn't work.


Those aren't all the problems with the article (the idea that dynamic
program changes should basically be variable renaming ones is
ridiculous) but they're the clearest ones...
 
Well, there is Syncfuscation and confuscation. Syncfuscation is for
C#.Net, I read somewhere and the latter, is something that I am toying
with myself because the name sounds swell!:)

Tell you what, all fuscations sound like somebody was frisking something
from a general store or something.

Probably, a change of suffix is called for!

with regards,


J.V.Ravichandran
- http://www.geocities.com/
jvravichandran
- http://www.411asp.net/func/search?
qry=Ravichandran+J.V.&cob=aspnetpro
- http://www.southasianoutlook.com
- http://www.MSDNAA.Net
- http://www.csharphelp.com
- http://www.poetry.com/Publications/
display.asp?ID=P3966388&BN=999&PN=2
- Or, just search on "J.V.Ravichandran"
at http://www.Google.com
 
Back
Top