C++, .NET, Native Compilation, Assemblies.. ????

I'm beyond confused with what MS has done to C++ with visual studio 2003 and visual studio 2005.

In VS2003, you can create your C++ project and can select between .NET and Win32 (and others)...

Now, if you select win32, you can write your C++ using the win32 API and compile to native code.. Fast executables, no .net framework required, and MUCH better protection against dissasembly.

But what if you use C++ and the .NET framework.. is there still any way you can compile to native code or can you only compile your projects to managed assemblies?

I read that you can compile C++ using VS2003 to unmanaged assemblies but am not sure how that is possible? Where they simply referring to using the Win32 API?


The reason I ask is because I am still not convineced that .NET is the future for software developers who have valuable IP to protect. With managed assemblies being so easy to disassemble (even if you obfuscate which is worthless), any valuable IP is visible plain as day.

I've also been doing some research that states in windows Vista, using win32 API will be discouraged and only supported for backwards compatability. The core lanage for vista will be to use .NET framework..


If MS makes .net the future (which is clear they will), how are windows .net programmers supposed to protect their applications from reverse engineering? Even if you put your value IP in a c++ compiled native dll and call them using a managed .net assembly, you can still simply disassemble your .net exe to obtain all the necessary information to use that DLL for your own purposes.


Please help shed some light on my confusion..

Obfuscation is likely at least as effective as native code in preventing reverse engineering (i.e. neither approach works).  Further, your concerns over putting native code in a DLL and calling it from a managed assembly make little sense.  It's just as easy to figure out how to call and use a DLL with native tools and code as it is to inspect the managed code that calls the DLL.  Being able to call a DLL in no way exposes any intellectual property.  I find the "managed code can be reverse engineered" arguments to be lacking in substance and heavy in FUD.

Well... i have noticed a lot of invalid information on this forum in regards to reverse engineering both antive and managed assemblies.

I think it should be mandatory that you can use IDA and other reverse engineering tools if you wish to help learn the community about the pro's and con's of both native and managed assemblies.

The only thing obfuscation helps prevent is reading the naming convention of the developer.

Obfuscation does not prevent you from completley unpacking a managed assembly (which is VERY easy) and then simply modifying the code (in a very easy form) as you see fit.

ANY obfuscated managed assmebly can be EASILY reverse engineered... meaning it is extremely difficult to write software with any type of licensing mechanism or sale value by using the .net framework and managed assemblies in their true (but obfuscated) form.

When you are working with native executables, there are a lot more tools available to protect your work. There are many solutions out there that will not only pack your executables with anti-debug, anty-proc dump, anti-soft ice, etc. etc.. but will also add polymorphism hooks to your code to prevent RAM dumping and other methods of reverse engineering.


If you feel that a managed assembly can be just as safe as native code, i'd hope that you're not putting any valuable IP into your exe's.


A few more tid bits that may help spark conversation.

If you have an application that requires you to enter in an application key to proceed.

With a managed assembly, you can simply decompile the entire assembly, locate the prompt and simply comment it out, then recompile your assembly. Even if it is obfuscated, this process is very easy.

With a native image, you can load it up into a debugger like IDA, then set break points and step through your program until you find the prompt.. insert some code to jump over it.. and call it a day. For this, you need to know how to use a tool like IDA, how to use a debugger, need to know assembly, etc. etc..

But what if your native image has been protected using the so many available solutions out there.. Well, you would need to know what solution was used to pack the EXE.. and either write your own unpacker (are you that smart??) or find a packer somewhere on the exetools forums (if it even exists)...

So you unpacked your EXE... but now its so mangled up its hard to even debug.. and your debugger gets caught at a lot of places where invalid registeres are being set and the power of the function calling methods are put to use. Do you know what is in your registers? Do you know how to follow the code flow even though IDA can not?


The above is a pretty common scenario in the reverse engineering world.

My point is, it is farily easy to make your native code more difficult to reverse engineer, but it is near impossible to make your managed assemblies even slighly difficult to reverse engineer without using the help of native compiled loaders and/or tools.

I can't believe companies like Adobe are going to be releasing photoshop for the Vista platform in managed .net assemblies.

If so, how will they ever protect their sales? Sure, the current versions can be hacked.. but by skilled people who know what they are doing and who have the time. If its done in a managed assembly, anybody with a little amount of skill can unpack it and modify it to their likings.

CodeGuru123 wrote:

The only thing obfuscation helps prevent is reading the naming convention of the developer.

Absolutely not, if you take Dotfuscator as an example you will see that it can do A LOT MORE than what you say.

I know exactly what dotfuscator does, (the commercial version).

I know what it DOES.. and how it really affects reverse engineering.

String encryption, object renaming, control flow manipulation.. linking of assemblies.. All seem great but only the object renaming is really important..

To help you understand where I come from.. I develop both win32 native code, and managed .net assemblies. I also use products like packers and obfuscators to protect my work... and i use tools like IDA and unpackers to test the protection levels of my work and how hard they are to reverse engineer.

If you feel that you can develop a managed .net assembly protected with the best of the best .net protection tools (while keeping it a managed assembly without using any win32 native help) that is secure, feel free to send it to me and I'll show you exactly how easy it is to reverse engineer.

CodeGuru123 wrote:

If you have an application that requires you to enter in an application key to proceed.

With a managed assembly, you can simply decompile the entire assembly, locate the prompt and simply comment it out, then recompile your assembly. Even if it is obfuscated, this process is very easy.

Or someone who aquires the key legitimately can pop it in a text file and share it on Kazaa. Security through obscurity isn't security.

True, that vulnerability exists for both scenarios..

So what is the solution to that? As a developer you are informed of leaked key's.. and disable those key's in future deployments... or you generate a new algo and require customers who wish to upgrade use new key's..

The problem with the managed assembly is as soon as you release your new updated version, it can be hacked in minutes.. where as a packed, polymorphic native compiled exe would take quite a bit longer than just minutes to simply decompile a managed exe and comment out a function call or simply set another function to return true.

How is that not an issue?

Have you actually tried to decompile a managed assembly that's obfuscated?

Yes, note my reply 2 replies ago where I tell you my experience.

Because I have done exactly what you ask I can see the major issues in releasing corporate software packages like Office, Photoshop, Nero, etc.. in a complete .net managed environment.

There is no way these companies (sans MS) are going to release .net solutions when they can be so easily hacked.

The reason I started this thread was to bring awareness to the issue that seems to be so overlooked, get feedback on how others feel about it, and see if anyone knows what MS plans to do in the future to help companies protect their IP that has to be distributed with the EXE's they ship.

http://www.remotesoft.com/salamander/protector.html

I know of remotesoft and their protector... their protector and others works by a pretty simple system..

What they do is take your managed assembly and pack it into a loader program (which is win32 native compiled btw)... the loader program executes first making sure you do not have any debug tools running and then executes your managed assembly (from within the packed exe)..

This prevents you from simply taking the managed exe and decompiling it. To get it out of the protector, you have to unpack the  exe first.... then you have your MSIL, just as it was right before you packed it with your loader util.

 

Is it unreasonable to believe that solutions like these are not acceptable for the big software developers of the industry?

It applies to other protectors that use whole assembly protection.
RemoteSoft Salamander .NET protector is different. It doesn't use a loader to encrypt the whole .NET file, and you won't find the MSIL code by dumping out memory.  I believe Salamander .NET Protector is the only one that really matters in protecting your .NET code.

I just used the evaluation version two days ago to protect my code, and so far it's wonderful.  I'm still testing to see whether I can reverse engineer my software after Salamander .NET protection.  Will keep you guy posted.

Chan.

Remotesoft definately has a lot of neat tools to help you protect and check the protection levels of your .NET assemblies.

I wish people who used .net were more concious about the serious security issues.

For example, the thread about cryptography.. I certainly hope they weren't thinking of even attempting crypto in a .net assembly.

For those of you that want to look more into what remotesoft has to offer, their website is www.remotesoft.com .

If you don't care if people decompile your assembly, then you don't worry about .net's decompilation ease.. and enjoy how easy it is to make beautiful GUI apps with windows forms.

LMAO -Yeah, and maybe if you pray to your imaginary friend up in the sky every day, he will actually help you. 

Anyone who says MSIL code cannot be decompiled has no idea what they are talking about.  Sure, it may obscure the code a little so you cannot tell what the variable names were before that the dev liked to use, but nonetheless all the code is right there in front of you to access. 

I love .Net and create websites in it everyday, but I would never release a commercial win app in it unless I did not care if people saw the source code.

I am in disbelief when I get a hold of commercial products that have been written in .Net.  I enjoy looking through their code and using what I like in my own programs.  It is a nice learning tool for me so I hope more companies like Adobe and the like put all their apps in .Net managed code. : )

Here is a simple idea to remember...

If it is created by a computer, it can be hacked/decompiled by a computer.

So that basically covers everything from native to managed code to anything that is encrypted or whatever.

CodeGuru123 wrote:

With a managed assembly, you can simply decompile the entire assembly, locate the prompt and simply comment it out, then recompile your assembly
. . .
With a native image, you can load it up into a debugger like IDA, then set break points and step through your program until you find the prompt.. insert some code to jump over it.. and call it a day.

Exactly. Both are crackable. One is crackable by x people and takes y hours, the other is crackable by 10x people and takes y/10 hours. Is there really a difference? If people want to crack your software, you just need one dedicated cracker.

Obfuscation works for the 99% case. I don't see a meaningful difference between the 1% that will break through your obfuscation and the 0.1% that will crack your native code. No, not even if it's 0.01%.

Hasp license keys will wrap your .NET app I believe until a key is inserted but like everyone is saying if anybody wants your code they will get it, but remember one thing, your code is your property meaning if you find someone coping it, i.e. your competitor its going to be very easy to prove using .NET, and slighty more difficult with unmanaged code.

Rob