VC7.1 and IL code

  • Thread starter Thread starter Bit byte
  • Start date Start date
B

Bit byte

I have some IP (intellectual property) concerns regarding IL code.

1). If I compile a native (i.e. 'unmanaged') C++ project (i.e.
application or library) using C++ and the VC7.1 compiler tools, how can
I be sure that it is native code (not IL) that is generated?

2). Is native code generated by default for native C++ code projects?
 
Bit byte said:
I have some IP (intellectual property) concerns regarding IL code.

1). If I compile a native (i.e. 'unmanaged') C++ project (i.e. application
or library) using C++ and the VC7.1 compiler tools, how can I be sure
that it is native code (not IL) that is generated?
Click to expand...

By not compiling with /clr. You can use dumpbin /disasm on an image to see
the native disassembly - if you apply it to a managed assembly you won't see
much of anything.
2). Is native code generated by default for native C++ code projects?
Click to expand...

It depends on the project template that you choose. If it's a Win32, ATL or
MFC project then it's native. If it's any of the .NET project templates,
then it's managed.

-cd
 
Bit byte said:
I have some IP (intellectual property) concerns regarding IL code.

1). If I compile a native (i.e. 'unmanaged') C++ project (i.e. application
or library) using C++ and the VC7.1 compiler tools, how can I be sure
that it is native code (not IL) that is generated?

2). Is native code generated by default for native C++ code projects?
Click to expand...

Re native - managed compilation:
* All functions implemented in files compiled without /clr are compiled to
native code
* All functions implemented in files compiled with /clr are compiled to
managed code, unless they are defined in a #pragma unmanaged area
* #pragma unmanaged areas are evil - most cases where they seem to be useful
are ugly pitfalls; instead of using #pragma unmanaged, separate native code
out into files compiled without /clr

My personal opinions regarding runtime-based code (IL code or byte code) and
intelectual property:
* It is often very easy to reverse engineer runtime-based code
* Obfuscater often provide only certain amount of help
* It is also very easy to detect cross component method calls of native code
(See Logger.exe, ...). This is a huge help for reverse engineering native
code, too.
* Usually, most of the code that is written is not worth much protection.
* To make the code that is worth to be protected less reverse engineerable,
a) make sure you reduce calls into other DLLs to an absolute minimum -
especially calls into system DLLs
b) make sure you don't deploy debug symbols of the code you want to
protect
c) if really necessary, protect your code with hardware
c1) dongles (www.wibu.com)
c2) smartcard-like hardware that contains and executes your code, so
that your code is never seen by somebody else
d) if hardware is too expensive consider executing your protectable code
on your servers and make it available via web services

Marcus
 
Back
Top