VC7.1 and IL code

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?
 
C

Carl Daniel [VC++ MVP]

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?

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?

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
 
M

Marcus Heege

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?

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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top