Protecting code

[Sky Fly]

Hi,

I know that when an .NET exe is run, the CLR loads
the exe (along with dependent assemblies),
compiles them to native code then runs the code.
Assuming the assemblies are loaded from a remote
inaccessible location, is it possible that during
any of the stages of loading the exe into memory,
a person with malicious intent could attach a
debugger and serialise the exe and assemblies
to disk so that she can disassemble/decompile them?

Cheers,
--
Akin

aknak at aksoto dot idps dot co dot uk

[Huihong Luo]

Yes, that is 100% possible.

The CLR will probally save a copy of the files into the
local disk. One place to look at is
c:\windows\assembly\download

Even if CLR does not save a copy, one can easily hook up
certain CLR dll to get the .NET assemblies, or use a
debugger as you suggested.

To launch a .NET assembly, CLR first calls into _CorExeMain
() or _CorDLLMain() method defined in c:\windows\system32
\mscoree.dll. One can replace mscoree.dll, and save a copy
of all .NET assemblies within those two methods. A few
lines of code will do the trick.

In short, if you want to protect your intellectual
properties, do not distribue the raw files. Once option to
use our obfuscator or protector to protect the code. The
former renames symbols to make it more difficult to
understand the decompiled code, and the protector modifies
code to make decompilation virtually impossible.

For more info, see http://www.remotesoft.com

Huihong

-----Original Message-----
Hi,

I know that when an .NET exe is run, the CLR loads
the exe (along with dependent assemblies),
compiles them to native code then runs the code.
Assuming the assemblies are loaded from a remote
inaccessible location, is it possible that during
any of the stages of loading the exe into memory,
a person with malicious intent could attach a
debugger and serialise the exe and assemblies
to disk so that she can disassemble/decompile them?

Cheers,
--
Akin

aknak at aksoto dot idps dot co dot uk
.

[Keith Patrick]

I think we're at a point now where it's a given that someone out there can
reverse engineer your code as long as they can run it. Whether it's
intermediate code or machine language, someone has the skills to know how it
works. It's always been that way, really, which is a reason why security by
obfuscation is unreliable. The key is making sure your data is secure,
since it is the true commodity.

[Richard Grimes [MVP]]

Sky Fly wrote:

Hi,

I know that when an .NET exe is run, the CLR loads
the exe (along with dependent assemblies),
compiles them to native code then runs the code.
No. Code is JIT compiled on a method by method basis. The *first* time a
method is called it is JIT compiled and the native code is cached in memory.
After that, when the same method is called the cached native code is used.
This means that if a method is not called, it is not JIT compiled.
Assuming the assemblies are loaded from a remote
inaccessible location, is it possible that during
any of the stages of loading the exe into memory,
a person with malicious intent could attach a
debugger and serialise the exe and assemblies
to disk so that she can disassemble/decompile them?

When the library is downloaded it is stored in the Downloads folder, so that
on future runs it is not downloaded again. If you use the command console
you can locate the actual folder where the assembly is stored and
disassemble it.

Richard
--
my email ev******@zicf.bet is encrypted with ROT13 (www.rot13.org)

[Godfrey Nolan]

"Keith Patrick" <ri*******************@nospam.hotmail.com> wrote in message news:<#6**************@TK2MSFTNGP11.phx.gbl>...

I think we're at a point now where it's a given that someone out there can
reverse engineer your code as long as they can run it. Whether it's
intermediate code or machine language, someone has the skills to know how it
works. It's always been that way, really, which is a reason why security by
obfuscation is unreliable. The key is making sure your data is secure,
since it is the true commodity.

I dislike the argument that it doesn't matter if it's machine code
or intermediate code, I think that is an enormous copout started by
Sun and now Microsoft.

Yes you can disassemble machine language into assembler but getting
the original source code back is nowhere near as easy as with IL or
Java bytecode. It takes real skill to understand what's going on
with machine code, it takes no skill at all to run Anakrino, so in
effect anybody can access your code in .Net or JAD if you're using
Java.

In machine code the data and instructions are intermingled so it is
orders or magnitude more difficult to recover the original source code.
Take a look at dcc from the University of Queensland to see what sort
of C output you get from machine code. It's also very compiler dependent
so I believe code compiled with Borland will produce different native
code than say Microsoft's compiler.

Thanks

Godfrey Nolan
in**@riis.com

[Alek Davis]

Amen.
- Alek

"Godfrey Nolan" <in**@riis.com> wrote in message
news:20**************************@posting.google.c om...

"Keith Patrick" <ri*******************@nospam.hotmail.com> wrote in

message news:<#6**************@TK2MSFTNGP11.phx.gbl>...

I think we're at a point now where it's a given that someone out there can reverse engineer your code as long as they can run it. Whether it's
intermediate code or machine language, someone has the skills to know how it works. It's always been that way, really, which is a reason why security by obfuscation is unreliable. The key is making sure your data is secure,
since it is the true commodity.

I dislike the argument that it doesn't matter if it's machine code
or intermediate code, I think that is an enormous copout started by
Sun and now Microsoft.

Yes you can disassemble machine language into assembler but getting
the original source code back is nowhere near as easy as with IL or
Java bytecode. It takes real skill to understand what's going on
with machine code, it takes no skill at all to run Anakrino, so in
effect anybody can access your code in .Net or JAD if you're using
Java.

In machine code the data and instructions are intermingled so it is
orders or magnitude more difficult to recover the original source code.
Take a look at dcc from the University of Queensland to see what sort
of C output you get from machine code. It's also very compiler dependent
so I believe code compiled with Borland will produce different native
code than say Microsoft's compiler.

Thanks

Godfrey Nolan
in**@riis.com