Protecting code

  • Thread starter Thread starter Sky Fly
  • Start date Start date
S

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,
 
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
 
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.
 
Sky said:
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.
Click to expand...

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?
Click to expand...

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
 
Keith Patrick said:
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.
Click to expand...

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
(e-mail address removed)
 
Amen.


- Alek

Godfrey Nolan said:
"Keith Patrick" <[email protected]> wrote in

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
(e-mail address removed)
Click to expand...
 
Back
Top