Decompiler.NET reverse engineers your CLS compliant code

[Brian Henry]

btw, I just ran this on a largly obsucated project we created in house, and
the code came out no where close to what it looked like orignally. it's not
even really understandable

 

[ErikS]

Guess why he posted the PDF version of that compasion article and not the
online version:
http://www.sys-con.com/story/?storyid=45917&DE=1

Hint: Read the comment section.

 

[Brian Henry]

ha!

Guess why he posted the PDF version of that compasion article and not the
online version:
http://www.sys-con.com/story/?storyid=45917&DE=1

Hint: Read the comment section.

 

[Vortex Soft]

you are a f#(*@#($* moron...

Get off your knees, I think you've satisified Jon's ego enough...

So many people became really upset because the .net programmers who read
this thread will be more careful. The dog's barking can be heard miles away.



What kind of people is interestered in hidding critical security
information?


Nick258

 

[Vortex Soft]

Try recompiling in Release mode, then decompiling.
Then try obfusticating the release mode dll and then decompiling it again.

Tell us what you see.

Every thing that can be encrypted can also be decrypted.

By design, the enumerations' element names are accessible in the wun
time, so they are exposed to the reverse engineering engine.
May be more that enumerations are exposed, I don't know.


_abc2389

 

[Vortex Soft]

Try recompiling in Release mode, then decompiling.
Then try obfusticating the release mode dll and then decompiling it again.

Tell us what you see.

Thanks for your suggestion.

Every thing that can be encrypted can also be decrypted.

By design, the enumerations' element names are accessible in the wun
time, so they are exposed to the reverse engineering engine.
May be more that enumerations are exposed, I don't know.


It's the compiler task to avoid exposing non exportable symbols.
Do you agree?



_abc2389

 

[One Handed Man \( OHM - Terry Burns \)]

My view is that in essence, comments should serve to explain code which
either has some quirk in it to compensate for an inadequacy or issue with
classes which it interacts with or is dealing with some particularly complex
or intricate algorithm.

Otherwise, my beleif is the same as yours, well written code needs little
explaination when being read by someone competent.

--

OHM ( Terry Burns )
. . . One-Handed-Man . . .
If U Need My Email ,Ask Me

Time flies when you don't know what you're doing

Hm, yeah, that doesn't even count. It's all throw-away stuff.
Anyone that thinks "comments" are optional, Is optional. But
it's your mess so what I think doesn't matter.

You miss understood my statement! I did not intend to imply that comments
are optional. I actually meant that a lot of comments are redundant. If you
label (name) the code for what it does, then I (in addition to Fowler &
Kerievsky below) don't see a real need for the comment. Fowler also suggests
that if you have a block of code with a comment preceding it, that you
should move the block of code to its own method, with the comment as the
name of the method.

Another example is putting a comment on a variable or parameter declaration.
If you simply pick a fuller name for the variable or parameter, do you
really need a comment on it?

For example, I have a routine that needs two date variables:

' with comments
Dim d1 As DateTime ' the start date
Dim d2 As DateTime ' the ending date

' without comments
Dim theStartDate As DateTime
Dim theEndingDate As DateTime

If you simply name the first variable as theStartDate do you really need a
comment suggesting the value is the start date?

Consider seeing d1 & d2 used 5 times in your routine, would the code be as
readable as using theStartDate & theEndingDate?

Would you need comments when you use d1 & d2?

Would you need comments when you use theStartDate & theEndingDate?

In other words "Human-Readable Code" or as Fowler states in Refactoring "Any
fool can write code that a computer can understand. Good programmers write
code that humans can understand".

You may want to read (& apply the ideas in) Martin Fowler's book
"Refactoring" and Joshua Kerievsky's book "Refactoring to Patterns" both
from Addison Wesley to have a better understanding of my statement.

Hope this helps
Jay

Mr X.

comments. Code without comments is rather worthless.

JH [Mon, 13 Sep 2004 15:30:37 -0500]:

In my experience well written code shouldn't need comments!

Well, see, that's in your experience, which obviously has never
had to deal with SOMEONE ELSE's "well-written code" (haha).

' adopted to VB.NET
Public Shared Sub Main()

Hm, yeah, that doesn't even count. It's all throw-away stuff.
Anyone that thinks "comments" are optional, Is optional. But
it's your mess so what I think doesn't matter.
--
40th Floor - Software @ http://40th.com/
iPlay : the ultimate audio player for iPAQs
mp3, ogg, mp4, m4a, aac, wav, and then some
w/surround, xfeed, reverb - all on your ppc

 

[Jon Skeet [C# MVP]]

Thanks for your suggestion.

Did you follow it?

Every thing that can be encrypted can also be decrypted.

I think you've missed what obfuscators do. They map existing names to
"nonsense" names, and only give the developer the map. Stack traces etc
can then be "decrypted" - but only someone with the map.

If you think that everything encrypted can be decrypted without the
private (secret) part, I suggest you read up on one-time pads as a
simple counter example. You could also tell me what this message says:

0 1 2 3 4 5 6 7 8 9 A.

Anyone with the appropriate text file would be able to work out what
that meant, but I don't think you'll be able to, somehow.

A good obfuscator will completely remove all information that can be
removed, as far as anyone without the nonsense->original map is
concerned. You may still be able to understand the code, but it's a
*lot* harder to do so.

 

[Cor Ligthert]

Jay,

This has been a long time discussion when Cobol was the major programming
language.

Some where in my opinion using it as a kind of Assembler because they had to
write too much.
(Code was not typed on a screen at the beginning).

However I have always been for explaining names and even used in that time
never a prefix, however things as "day in dateofbirth" while a lot found
that as well to much work; you earned that when you had to do a lot of
maintenance and could easy create copy parts with that (and reuse the name
day).

(This is indirect an answer on a message from OHM from past week about
prefixes).

VB had in my opinion not the same first goal as COBOL, "making a program
that could be read in plain English". However, you can reach it very much,
therefore document it in the code with readable names, and therefore make it
possible to avoid documentation sentences (which often are made that bad,
that it brings you more on the wrong way than the right way).

COBOL was a superior language in that, however it is completely created
around batch processes. In my opinion, have the later extensions to make it
usable for interactive use, never reached the possibilities from languages
which where directly made for that and therefore it will die.

This is not in contradiction with what you write, however to give some extra
historical background.

Cor

 

[Nak]

LOL! Good work!

Nick.

the really funny thing is the fact you are selling classes you stole from
code project and assembled them together to make this

 

[Frans Bouma [C# MVP]]

http://www.junglecreatures.com/

Try it and tell me what's happenning in the Microsoft Corporation.
Notes:

VB, C# are CLS compliant

C# is not CLS compliant.

You can also use managed code with C++
Using what they call obfuscator, will not help you for a long time.
For each new obfuscator there will allways exist a new deobfuscator.

not necessarily. The point is that you can make totally not related methods
make overloads of the same method which you then call a0oO or whatever.
Whenever that happens, you are not able to reproduce the real method.

If you for example make all your forms in a .exe internal and all methods of
these forms internal, you can practically mangle everything in the .exe to a
couple of overloaded methods.

FB

 

[Frans Bouma [C# MVP]]

Thanks for the compliments regarding our Decompiler.NET product. The
product includes a built-in obfuscation option that generates
obfuscated source code that you can recompile that still runs like the
original code. You may want to try this feature to see how readable
the obfuscated code is.

Our obfuscator encrypts string literals and replaces them with
references. It also includes unique advanced features not provided by
other available obfuscators like generating public stub methods and
properties to avoid breaking public interfaces, but factoring their
bodies and calls within the same assembly into obfuscated
implementation methods. Our refactoring feature also includes an
option for encapsulates fields with generated properties and tightens
their scoping to private.

That's great, but frankly, obfuscating compiled VB.NET or C# code is not
rocketscience. All you have to do is this a little grouping of methods with
the same return value/access level and make them overloads, mangle names for
internal/private/protected methods/parameters/members/properties and 99% of
the code is impossible to read. Good thing is: these tables are documented by
microsoft and any person with an afternoon of time can write an obfuscator
for that.

Execution flow mangling is indeed more complex, however often this is done
by simply pre-jitting code to native x86 assembler and place the routines as
native code inside the assembly. This confuses decompilers, but also makes
the JIT functionality of the CLR pretty much useless in a lot of occasions.
Take into account that it is very hard to get this right when you take into
account complex event handling with 3rd party controls (e.g. a grid control)
and most developers will opt for the lowest possible obfuscation option
possible to avoid problems. You see, it takes extra testing work to test the
obfuscated executable through and through, as the code can work differently
when obfuscated. Oh, your obfuscator obviously produces 100% reliable code,
I'm sure, but I don't live in dreamland.

Frans.

 

[Herfried K. Wagner [MVP]]

Jay,

In my experience well written code shouldn't need comments! At least not a
lot of comments.

I agree. Decompiling to "steal" something developed by someone else IMO
is only useful if the code that is stolen is valuable. Most simple code
is not valuable and can be easily implemented without stealing and
reconstructing. Complex algorithms are worth stealing, and these
algorithms are often heavily commented or documented. If comments,
documentation, and local variable names are missing, the reconstructed
code will compile, but it will take hours to understand it.

 

[Herfried K. Wagner [MVP]]

My view is that in essence, comments should serve to explain code which
either has some quirk in it to compensate for an inadequacy or issue with
classes which it interacts with or is dealing with some particularly complex
or intricate algorithm.

ACK.

Imagine there are '' HACK ...' or '' TODO ...' comments in the code, and
the person who reconstructs the code doesn't have these comments...

 

[Brian Henry]

another example of great programming *rolls eyes*... trying to exit this
piece of junk I get

See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

************** Exception Text **************
System.NullReferenceException: Object reference not set to an instance of an
object.
at aa6f.aa6g.abat(Object __0, EventArgs __1)
at System.Windows.Forms.Control.OnValidated(EventArgs e)
at System.Windows.Forms.Control.NotifyValidated()
at System.Windows.Forms.ContainerControl.ValidateThroughAncestor(Control
ancestorControl)

 

[Cor Ligthert]

Herfried,

You wrote that "steal" very right in quotes, when I see this thread (when I
missed one excuse me) than I get the idea that decompiling is always for
stealing and that has not to be so.

You are the first one who showed that.

Cor

 

[Herfried K. Wagner [MVP]]

You wrote that "steal" very right in quotes, when I see this thread (when I
missed one excuse me) than I get the idea that decompiling is always for
stealing and that has not to be so.

I remember many EULAs which prohibit decompilation to protect their
property. The decompiler mentioned before can be used for stealing code
or innovation made by another party.

 

[Cor Ligthert]

I remember many EULAs which prohibit decompilation to protect their
property. The decompiler mentioned before can be used for stealing code
or innovation made by another party.

Right however can be used as well for legal decompilation. To say it in
another way, you can use a hammer to kill somebody, for that a hammer is not
an illegal tool. (I had first the gun in the US however that does not count
less for us in the EC, so maybe is the hammer better).

However for buying guns in the US (and with us as well, I legaly had them)
are regulations same as you wrote about EULA.

Cor

 

[One Handed Man \( OHM - Terry Burns \)]

Thats right, its all about what risk is acceptable, how hostile is the
environment in which you put your valuables at risk. Given enough time most
codes can be cracked eventually, the question is at what cost in time and
resources it takes to do this. For example, securing a novel with 128 BIT
RSA encryption would be good enough for me as an Author if I was convinced I
had written a bestseller, however, If I wrote an Autbiography ( being me ),
then simply asking for a clear password would be good enough.

--

OHM ( Terry Burns )
. . . One-Handed-Man . . .
If U Need My Email ,Ask Me

Time flies when you don't know what you're doing

 

[CJ Taylor]

No.. it has nothing to do with being more careful. But you think you've
come across this amazing revalation that none of us knew about.

Microsoft told us of the "security concerns" of reverse engineering with
..NET all the way back in Beta 2 days...

Sun did the same thing with Java.

And many many more companies that developed compilers.

Don't make such a big deal about it. If you continue to read about .NET
you'll learn there are many tools. Don't forget, nothing will every protect
everything 100%, that's just how life is.