4

I know that all assemblies can be decompiled somehow, but C# & VB applications are the easiest to be decompiled into source code using tools like ( .Net Reflector ).

So my question is, if I programmed an application using .Net assemblies and functions with C++, would it be easy to decompile it as if it was a C# or VB application with .Net reflector and such tools? Ok, if I programmed it without using any function from .Net framework and made UI only what calls .Net assemblies, would be easy to decmpile also ?

My question is similar to this one : Could this C++ project be decompiled with such tools like a .NET Reflector? but no one has answered him correctly, so can anyone help me ?

I want to use .Net and C++ to make my application compiled into both Native & Managed code!

Community
  • 1
  • 1
Alaa Salah
  • 885
  • 1
  • 13
  • 23
  • 2
    C++/CLI compiles down to IL, same as C# and VB. There’s no difference in terms of decompilation. – Konrad Rudolph Jul 28 '13 at 22:02
  • I think the real problem is *what* do you want to protect, since *any* code can be decompiled/disassembled(All you can do is to make the life a little bit harder for the attacker). – I4V Jul 28 '13 at 22:04
  • 1
    It is a silly question. If *you*, as the author of the assembly can't figure out if it can be decompiled then that means that a smarter programmer will have to figure out whether that's possible. Which inevitably means that this smarter programmer isn't going to be interested in your code at all, he can of course write a much better version of it. With comments. – Hans Passant Jul 28 '13 at 22:12
  • 1
    Its not a silly question. I've worked as several places where our partners wanted to help develop core software solely so they could take it all and walk away. Software written in java/.net or a script language makes it quite easy to decompile compared to optimised native code. – gbjbaanb Jul 28 '13 at 22:23
  • 3
    @gbjbaanb 'our partners wanted to help develop core software solely so they could take it all and walk away' - why are you asking us? Talk to your lawyers about copyrights/patents. – Martin James Jul 28 '13 at 23:21
  • 1
    @KonradRudolph that's not entirely true, see my answer. – Tamás Szelei Jul 29 '13 at 00:20
  • @fish I simplified. When people talk about C++/CLI (or incorrectly “C++.NET”), 95% the time they mean managed code. – Konrad Rudolph Jul 29 '13 at 08:41
  • 1
    @Hans: What a ridiculous idea. Your reasoning starts with the premise that programming knowledge == vertical knowledge, which is not a safe assumption. As a result, your conclusion is valid just about *never*. It's not the *code* that a better programmer is interested in, it's the algorithm that the code describes, and the higher level description of that algorithm he can get, the easier it is for him to get at the domain-specific knowledge that he doesn't possess himself. Or knowledge of the specific vulnerabilities in your code. – Ben Voigt Jul 29 '13 at 15:41

1 Answers1

7

There is no "C++.Net". There is C++/CLI, which is a C++-like language that can be used to glue native C++ code with the .NET world. The managed code you write in it (ref classes) will be compiled to MSIL. The "native" code will compile to either MSIL or native. If you want to compile some parts to native code you need

#pragma managed(push, off)

void foo() {}

#pragma managed(pop)

in your source. The managed pragma can be used to choose the compilation target per-function. Or you can compile without the /clr flag per-module and set your project to produce a mixed-mode assembly.

Be aware that marshaling the native types to .NET and back can take a serious performance hit on your application - and that happens every time you cross the native-managed boundary. But interoperation between such embedded native code and managed code is much faster than normal p/invoke.

See also this question: C++CLI. Are native parts written in pure C++ but compiled in CLI as fast as pure native C++?

Community
  • 1
  • 1
Tamás Szelei
  • 23,169
  • 18
  • 105
  • 180