From: Rudy Velthuis on
Willem van Rumpt wrote:

> However, before considering switching languages, complex obfuscation
> and encryption techniques, there's one important point that lots of
> people seem to forget:
>
> Most code written is not rocket science, and is easier to write
> yourself, than to reverse engineer.

Exactly! Fully agreed. Many people seem to forget that.
--
Rudy Velthuis http://rvelthuis.de

"Computers are good at following instructions, but not at reading
your mind." -- Donald Knuth
From: Peter Duniho on
Tony Johansson wrote:
> Hi!
>
> I just wonder about this Reflector tool.
> If I made a dll in .NET can then a person that have this DLL look at all the
> source code by using the Reflector tool ?
> I mean can he/she recreate all the source code.
>
> If I instead have a DLL unmanaged code for example made in C++ is it here
> possible look at the source code by using some kind of tool.
> I mean something that remind of Reflector ?

You got a lot of good replies, but more specifically to your question:
yes, there are tools that "decompile" unmanaged code back to other
languages, such as C++. They work best when you know the original
tools/languages used to create the unmanaged, compiled native code, just
as Reflector works best when you tell it what version of .NET was used
and what language.

..NET MSIL is especially easy to decompile a la Reflector, because so
little of the optimization happens during the C#-to-IL stage and because
so much of the original information is still present (variable names,
meta-data for data structures, etc.). But even the unmanaged
decompilation tools can do a remarkably good job.

Pete
From: Tony Johansson on

"Peter Duniho" <no.peted.spam(a)no.nwlink.spam.com> skrev i meddelandet
news:OBPa%23eQ2KHA.4016(a)TK2MSFTNGP05.phx.gbl...
> Tony Johansson wrote:
>> Hi!
>>
>> I just wonder about this Reflector tool.
>> If I made a dll in .NET can then a person that have this DLL look at all
>> the
>> source code by using the Reflector tool ?
>> I mean can he/she recreate all the source code.
>>
>> If I instead have a DLL unmanaged code for example made in C++ is it here
>> possible look at the source code by using some kind of tool.
>> I mean something that remind of Reflector ?
>
> You got a lot of good replies, but more specifically to your question:
> yes, there are tools that "decompile" unmanaged code back to other
> languages, such as C++. They work best when you know the original
> tools/languages used to create the unmanaged, compiled native code, just
> as Reflector works best when you tell it what version of .NET was used and
> what language.
>
> .NET MSIL is especially easy to decompile a la Reflector, because so
> little of the optimization happens during the C#-to-IL stage and because
> so much of the original information is still present (variable names,
> meta-data for data structures, etc.). But even the unmanaged
> decompilation tools can do a remarkably good job.
>
> Pete


Hi!

Is it possible to say that MSIL can in a way be understood as a language of
it's own just to get a better understanding of MSIL.

//Tony


From: Peter Duniho on
Tony Johansson wrote:
> Is it possible to say that MSIL can in a way be understood as a language of
> it's own just to get a better understanding of MSIL.


I'm not sure I understand the question. But yes, MSIL is absolutely a
language in and of itself. It is the low-level instruction code used by
Microsoft's "common language infrastructure".

It would be silly to write code in MSIL itself, because of the several
excellent high-level language choices available. But certainly there's
some value in understanding MSIL as a language unto itself; doing so
gives one a greater and deeper insight into what actually happens when
you write specific kinds of code inthe higher-level languages.

Pete
From: Arne Vajhøj on
On 10-04-2010 16:22, Family Tree Mike wrote:
> On 4/10/2010 3:58 PM, James Finch wrote:
>> Since .NET programs and libraries are compiled to MSIL, basically yes.
>> Anyone can use .NET Reflector to view your source code almost as you
>> wrote it. You can use various tools (Dotfuscator, etc.) to make the code
>> more difficult to interpret, but if someone really wants to reverse
>> engineer your code they will. It's that simple. You can make it more or
>> less difficult but never impossible.
>>
>> When programs are written in C and C++ they are compiled to native
>> machine code and are rather more difficult to reverse engineer than
>> MSIL, but still never impossible. If you wish to protect your .NET code
>> so that some idiot doesn't take credit for your work, the best you can
>> do is use obfuscation techniques to make the code so difficult to
>> understand that it would be easier for them to write an application from
>> scratch that does the same thing. There are commercial tools available
>> to make this process easier and also provide string encryption, etc.
>
> Many would say the best you could do is to create web services so that
> the heart of your code is remote and thus inaccessible. True that they
> could reverse engineer the client that connects to your service, but
> they cannot identify an algorithm that maybe you wanted protected which
> is housed on the server.

It can be a fine solution.

But it does have some implications regarding being connected,
performance etc..

Arne

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: DataGrid, sort numeric column after parsing xml
Next: GDI+