Click to See Complete Forum and Search --> : [RESOLVED] .Net to native?


tr00don
April 1st, 2009, 09:40 AM
I am a beginner in C# but I have many years of experience in programming for Windows (mainly Delphi). After successfully running my first C# program (using images, sound, file IO) I can see the advantages of .Net programming. But there is a huge drawback that I cannot just brush away.

Here is my problem: .Net executables are easy to decompile; I have decompiled my code using software that I got off the Web. Moreover, I couldn't find a utility to compile .Net code to native executables on Windows (there may be options on Linux). Since I (also) do non-open-source software development, I wouldn't consider moving to C#/.Net unless there was an option for me to convert my .Net CIL code to native code. The ngen.exe utility that comes with the .Net framework doesn't seem to be an option.

How do you compile your .Net code to native code? I doubt all .Net programmers open-source their applications. Those who are tempted to ask "Why do you want to hide your code?" please abstain.

Thank you.

boudino
April 1st, 2009, 10:00 AM
Shortly: you cannot. It is the way which .NET was designed, that every assembly contains metadata which allows anybody simply reflect the code.

You can make the compiled code human unreadable with obfuscator (see here (http://www.preemptive.com/obfuscator.html)).

tr00don
April 1st, 2009, 10:16 AM
Thank you. According to that web site, obfuscation does not fully protect the code against reverse-engineering. It is ironic that a company such as Microsoft, who put so much emphasis on IP protection and patents, would want every developer to publish readable code.

I think there will be two classes of code, eventually: native/commercial and .Net/open-source. The former will need a digital certificate or some other mechanism to run (hint!) while the latter will be open to "inspection" by the .Net parser... and everybody else, for that matter.

Unless open-source developers figure out how to convert .Net code to native code.

Update: I guess I was right on the money, so to speak: "Games for the Wii and iPhone would need to statically link the Mono runtimes, invoking the need for a commercial license." (http://www.desktoplinux.com/articles/AT7746284247.html). There are already AOT-compiled Mono games running on the iPhone (http://arstechnica.com/open-source/news/2009/01/open-source-mono-framework-brings-c-to-iphone-and-wii.ars) and the dev tools license cost $1400+ (http://unity3d.com). If Novell and others can do it then Microsoft can do it. Well, that means in the future developers will have to pay both for the dev tools and for their apps to run in "Intelectual Property-protected"-mode on client's machines.

eclipsed4utoo
April 1st, 2009, 11:17 AM
This is probably the biggest draw back for developing in .Net. This is the main reason you don't see many commercial apps that are build with .Net.

It's not that big of a deal for me right now, since I work for a company that does custom software for clients. So it's not that big of a deal for somebody to reflect my code to look at it.

Shuja Ali
April 1st, 2009, 01:04 PM
I tend to disagree with Post # 3 & 4. The world of computing has changed and any new applications that are built are built as SaaS which means you don't give an application to the user, rather you just provide the application as a service.

How many of us know that any Java application can be reverse engineered same way the .NET code is?

tr00don
April 1st, 2009, 01:18 PM
any new applications that are built are built as SaaS which means you don't give an application to the user, rather you just provide the application as a service.

That is well said from the perspective of a server software developer who works for a SaaS provider. What if you are a contractor? Additionally, some of us are mainly desktop software developers. How about the mobile market, particularly games? Some apps must run on your machine.

Shuja Ali
April 1st, 2009, 01:35 PM
That is well said from the perspective of a server software developer working for the service provider. What is your client wants to run it off their servers? Additionally, some of us are mainly desktop software developers. How about the mobile market, particularly games? Some apps must run on your machine.
That is the reason you have Obfuscators around. There are third-party obfuscators (http://search.msn.com/results.aspx?q=.NET+obfuscation+software) that are pretty good. Some of the managed code that microsoft writes is obfuscated too, but i really don't know what tool or technology do they use.

Also Visual Studio ships with a community edition Obfuscator, but i have never used it.

Did you explore Ngen.exe, don't know how useful it will be to you.

tr00don
April 1st, 2009, 01:55 PM
That is the reason you have Obfuscators around.

Did you explore Ngen.exe, don't know how useful it will be to you.

Obfuscated software can still be decompiled.

Regarding ngen.exe, according to this: http://msdn.microsoft.com/en-us/library/ms973839.aspx :

"If you run ngen.exe before you ship the program, you limit the optimizations to the ones available on your machine."

How I read it: ngen.exe generates code that may or may not run on other machines.

Mutant_Fruit
April 1st, 2009, 02:02 PM
Native code can be decompiled. Nothing can stop a determined person, take DRM as a prime example. If you're that worried about someone decompiling your software, the best you can really do is just obfusticate it. It makes it that little bit harder which would deter the casual person.


This is the main reason you don't see many commercial apps that are build with .Net.

Heh, I think i'd rapidly run out of numbers if I tried to count the number of commercial tools/apps built using .NET ;)

tr00don
April 1st, 2009, 02:10 PM
Native code can be decompiled.

Yes, but only to Assembler. Good luck with reverse-engineering that. :)

BigEd781
April 1st, 2009, 02:11 PM
This is probably the biggest draw back for developing in .Net. This is the main reason you don't see many commercial apps that are build with .Net.


Huh? I don't know where you are looking, but C# is currently the 7th most popular language out there (http://www.tiobe.com/content/paperinfo/tpci/index.html). What exactly are all of these people doing with it if not building commercial .NET apps? I know that it is popular for internal stuff as well, but internal apps alone do not take you to #7.

tr00don
April 1st, 2009, 02:18 PM
C# is currently the 7th most popular language out there (http://www.tiobe.com/content/paperinfo/tpci/index.html).

Yes, but the fine print reads: "The ratings are based on the number of skilled engineers world-wide, courses and third party vendors." It doesn't count the actual number of .Net application out there. Besides, I think our friend meant .Net desktop aplications.

BigEd781
April 1st, 2009, 02:29 PM
Yes, but the fine print reads: "The ratings are based on the number of skilled engineers world-wide, courses and third party vendors." It doesn't count the actual number of .Net application out there. Besides, I think our friend meant .Net desktop aplications.

Well, it's not very practical (or possible) to count every app out there. Do you think the stock market index works by averaging the value of every public company out there? No, it uses an index for approximation.

Shuja Ali
April 1st, 2009, 02:29 PM
I know we can decompile VB 6 Code too. That one was compiled to native code too.

The thing is that if some one is hell bent to decompile something, there are tools available to do that. Part of .Net framework can be decompiled, but I don' see Microsoft being worried about that. And there are other number of applications that are built on top of .Net framework that are shipped today too and I don't see the ISVs being worried about decompilation.

eclipsed4utoo
April 1st, 2009, 02:31 PM
Huh? I don't know where you are looking, but C# is currently the 7th most popular language out there (http://www.tiobe.com/content/paperinfo/tpci/index.html). What exactly are all of these people doing with it if not building commercial .NET apps? I know that it is popular for internal stuff as well, but internal apps alone do not take you to #7.

I would like to see a list of known commercially available applications that were written in .Net that I can buy right now for my PC. Maybe just a few, not a whole list(I don't exactly know how to search google for this).

I don't mean niche market applications that a guy in his room created and is selling. I mean applications that are built and sold by medium to large size companies.

Mutant_Fruit
April 1st, 2009, 04:59 PM
http://www.telerik.com
http://codicesoftware.com/xpfront.aspx
http://www.mindtouch.com/
http://unity3d.com/
http://www.medsphere.com/
http://www.fanfaresoftware.com/
http://www.vistadb.net/
http://www.coversant.net/


Though that's not really relevant at all to the topic ;)

What exactly is it that makes you afraid of someone decompiling your code? What was the reason you asked the question in the first place?


EDIT:

Update: I guess I was right on the money, so to speak: "Games for the Wii and iPhone would need to statically link the Mono runtimes, invoking the need for a commercial license." (http://www.desktoplinux.com/articles/AT7746284247.html). There are already AOT-compiled Mono games running on the iPhone (http://arstechnica.com/open-source/n...ne-and-wii.ars) and the dev tools license cost $1400+ (http://unity3d.com). If Novell and others can do it then Microsoft can do it. Well, that means in the future developers will have to pay both for the dev tools and for their apps to run in "Intelectual Property-protected"-mode on client's machines.

The fine print with that while you can AOT an assembly, you still need to retain all the .NET metadata to allow the program to run. If you can 100% AOT the *entire* assembly (can get tricky with reflection/generics), then you can strip out the method bodies. So if you decompiled the assembly, all the classes/methods would be there, but the method body would be empty. If anyone actually wanted to hack your program, they still have all the ASM and can still run any normal ASM to C converter to get easily readable C code.

tr00don
April 1st, 2009, 05:58 PM
What exactly is it that makes you afraid of someone decompiling your code?

If anyone actually wanted to hack your program, they still have all the ASM and can still run any normal ASM to C converter to get easily readable C code.

You are funny, really. I guess you must be an open-source developer. You want to know "what makes me afraid of" something like that. I could answer that it's personal choice. Or I could answer that 99% of commercial software is not open-source.

If what you say about native code conversion to C were enough to reverse-engineer commercial software then the IT industry would not exist. I think you speak from a purely theoretical perspective. By the way, do you work in academia?

I suggest you visit http://trescom.org and share your ideas with those fans who have been trying to "analyze" the Trespasser executable ever since the PC game was released back in 1998.

Mutant_Fruit
April 1st, 2009, 06:22 PM
You are funny, really. I guess you must be an open-source developer. You want to know "what makes me afraid of" something like that. I could answer that it's personal choice. Or I could answer that 99% of commercial software is not open-source.

I think i just phrased my question badly. I'm wondering why you asked the question. Did you ask because you are worried that someone will decompile your code, make minor changes, then resell it?

Are you worried because you have some amazing algorithms which must be kept top secret?

Are you worried that people will bypass your registration mechanism?


If what you say about native code conversion to C were enough to reverse-engineer commercial software then the IT industry would not exist.

How do you think people hack software and crack dvd/bluray encryption? It's very doable, it just requires a lot of time and effort.

So before we get too far derailed from the topic, I think you are being needlessly fearful. If someone actually cares enough to crack/hack/decompile your app, they will. Obviously a .NET language will be easier to decompile and a C or ASM app will be harder, but still doable.


Or I could answer that 99% of commercial software is not open-source.

100% of commercial software isn't open source according to the open source definition. Though whether or not you open source your application doesn't impact the language you write it in. .NET doesn't enforce your application is open source, so I'm not quite sure why you're mentioning this.

Zaccheus@Work
April 2nd, 2009, 05:38 AM
Obfuscated software can still be decompiled.
So can a native program, but in both cases, the class names, function names, and variable names are made meaningless - which is the important thing.

darwen
April 2nd, 2009, 07:13 AM
I tend to agree with Mutant_Fruit.

I'd say 99% of most applications wouldn't give you anything useful if you were to decompile them.

There's nothing to stop someone from using one of your assemblies in their own applications of course, but then again the same is true if you write a COM component.

Of code which is highly sensitive I'd say it falls into two categories :

(1) Code containing data which must be protected - e.g. encryption keys. You can get at these equally well if the key is in code or if it is in .NET. Anyway you can move the encryption/decryption parts into native code to make it more difficult for a hacker.

(2) Algorithms. Again I have to say I can't think of a single algorithm which would need protecting this much apart from possibly because of a speed optimisation. In this case the code will be in native anyway...

I really don't see the ability to decompile .NET code as a problem. And have worked for a few commercial companies actively using it to develop desktop applications and they don't see it as a problem either.

And bear in mind I'd say that 99% of the time and cost in producing a working piece of software has nothing to do with clever algorithms etc. It has just to do with volume of work and how long it takes to write a line of code.

Far more important is what you intend to do with the software in future...

Darwen.

tr00don
April 2nd, 2009, 10:11 AM
I'm glad most of you feel safe knowing that all .Net code you develop and release is freely available to the rest of the world. After all, who would need it? From this perspective, Intellectual Property lawyers may want to start looking for new jobs. The IT industry will soon have a strong reason to stop fighting over trade secrets and software patents. All algorithms one can possibly create will end up in the public domain. Software development will no longer be about coding optimal data structures and algorithms but about how fast one can type at the keyboard.

Few realize that there is an ongoing effort to create new types of property. In a world where natural resources are limited and the population is growing, intellectual property is the best option newcommers have to become owners of something they didn't inherit but can build through their own effort in a free market economy. And if history is any guide, property needs to be protected and defended or it could be lost. Isn't that the way of life in the New World? That is also why DRM is here to stay, whether we like it or not; but that's another story.

If I did software development for a living, to put bread on the table and gas in the tank, and I knew that my code can be easily decompiled by my competitors then I probably couldn't sleep at night. Fortunately, I don't have to do that.

Arguments about how easy it is to reverse-engineer assembler code are greatly exaggerated. It may be "easy" to hack into code to bypass a S/N validation routine but it is a lot more difficult to infer a 200 KB algorithm that uses dynamic data structures and recursive procedure calls.

That being said, I strongly believe open-source software has its solid place in the IT ecosystem and is critically important for start-ups, academic developers, hobbyist programmers, and most importantly, for sharing ideas. In Silicon Valley all began with the Homebrew Computer Club.

Zaccheus@Work
April 2nd, 2009, 11:03 AM
You seem to be ignoring some basic facts here.

Mutant_Fruit
April 2nd, 2009, 11:07 AM
Intellectual property is the best option newcommers have to become owners of something they didn't inherit but can build through their own effort in a free market economy.

Which is why there's a huge fight to make software unpatentable in the US and it's already unpatentable in the EU.


That is also why DRM is here to stay, whether we like it or not; but that's another story.

Look at the history of DRM, it has always been cracked/worked around and it only angers the legitimate customer when they lose access to their legally purchased data. DRM won't be gone completely in the next few years, but in the longer term it's going to go. DRM is already being phased out in a number of high profile cases, the iTunes store and Vodaphone (http://tech.yahoo.com/news/nm/20090311/tc_nm/us_vodafone_music) being two prime examples.


Arguments about how easy it is to reverse-engineer assembler code are greatly exaggerated. It may be "easy" to hack into code to bypass a S/N validation routine but it is a lot more difficult to infer a 200 KB algorithm that uses dynamic data structures and recursive procedure calls.

And how could you do the same for a .NET assembly which has been obfusticated? It'd be just as hard.

tr00don
April 2nd, 2009, 12:17 PM
Sorry, I couldn't resist...

Which is why there's a huge fight to make software unpatentable in the US and it's already unpatentable in the EU.

That is a good fight and hopefully it will be successful because M$ and the gang have gone way too far in their greed. Pretty soon we will all have to pay them a fee just to be allowed to click on a button.

Look at the history of DRM, it has always been cracked/worked around and it only angers the legitimate customer when they lose access to their legally purchased data.

And rightly so, because, again, the greed of these corporations has no limits. They don't inform the customer about the limitations of the license, they call it "marketing strategy". I call it misleading the customer.

And how could you do the same for a .NET assembly which has been obfusticated? It'd be just as hard.

"At best, obfuscation merely makes it time-consuming, but not impossible, to reverse engineer a program... No-one can guarantee that obfuscation will present any particular level of difficulty to a reverse engineer." (http://en.wikipedia.org/wiki/Obfuscated_code#When_used_alone)

"The bytecode formats used by many virtual machines (such as the Java Virtual Machine or the .NET Framework Common Language Runtime) often include extensive metadata and high-level features that make decompilation quite feasible. Machine language has typically much less metadata, and is therefore much harder to decompile." (http://en.wikipedia.org/wiki/Decompiler)

Mutant_Fruit
April 2nd, 2009, 07:17 PM
At the end of the day, it's your choice. You deem .NET to only be suitable for opensource applications, so don't use it. I'm not particularly bothered either way. All I know is that there are plenty of high profile companies selling high profile software who appear to have none of the fears you do.

As for your wikipedia quotes, that pretty much sums up exactly what I was saying.

EDIT: It's also worth pointing out that if anyway does decompile my commercial application and attempts to resell it, they'd be in jail so fast they wouldn't be able to organise a phonecall to their significant other ;) And yes, it is easy to tell. That's from personal experience. Google 'monotorrent' and 'seedpeer' if you want to see the details.

dglienna
April 2nd, 2009, 08:47 PM
OFFICE 2007?

Expressions WEB?

just about everything Microsoft is doing the framework now...

Zaccheus@Work
April 3rd, 2009, 03:29 AM
"The bytecode formats used by many virtual machines (such as the Java Virtual Machine or the .NET Framework Common Language Runtime) often include extensive metadata and high-level features that make decompilation quite feasible. Machine language has typically much less metadata, and is therefore much harder to decompile." (http://en.wikipedia.org/wiki/Decompiler)

The very next sentence is: "Some compilers and post-compilation tools produce obfuscated code (that is, they attempt to produce output that is very difficult to decompile). This is done to make it more difficult to reverse engineer the executable."

The article then goes on to show how easily machine code can be reverse engineered.

tr00don
April 3rd, 2009, 11:34 AM
The article then goes on to show how easily machine code can be reverse engineered.

Try reading and figuring out this sample: http://www.microapl.co.uk/asm2c/sample86C.html

Then have a look at this: http://www.microapl.co.uk/asm2c/RelogixPrices.html

That should give everybody an idea of how "easy" it is, in practice, to reverse-engineer native code.

But there is hope for .Net programmers. Mono can do static linking (with licensing implications) so I guess M$ will provide a tool to the same purpose, sooner or later -- for a price, of course.

Mutant_Fruit
April 3rd, 2009, 12:07 PM
Now, suppose you have a .NET assembly where every variable is called "a", every method is called "a" and every class is called "a". Wouldn't that be just as difficult to reverse engineer?

EDIT: Also throw in whatever other obfustications you feel like, such as obfusticating constants, if/while loops etc.

tr00don
April 3rd, 2009, 12:30 PM
Now, suppose you have a .NET assembly where every variable is called "a", every method is called "a" and every class is called "a". Wouldn't that be just as difficult to reverse engineer?

Absolutely! And it would be as difficult for me, if I were to write that application, to debug my code. :)

You win. And hey, watch out for nasty seedpeers... ;)

I'm off this thread.

TheCPUWizard
April 3rd, 2009, 09:21 PM
1) ANY program can be reverse engineered. Until DRM is embedded in the processor itself, this will be true. I have reverse engineered programs written in just about every language over the past 30 years. If there is a gain to be made from reverse engineering, somewone will do it.

2) There are two distinct issues, the first is copying your implementation (see point #1), the second is tampering. The techniques for making tamper resistant code apply to all languages.

3) Obsfucation takes many forms. The simple "identifier substitution" really does nothing (just consider if you were reverse engineering a program written by someone who use variable names in their native tongue which you do not speak. However there are many techniques that can be added (an most commerical obsfucators add them) which makes reverse engineering exactly on-par with any native language.

As was mentioned early in the thread...if you distribute your code, then any and every "Security" measure can be broken, and will be if there is sufficient incentive. For "real" programs this is very rarely an issue since what the customer wants is support and will typically purchase from a reputable vendor.

Joeman
May 6th, 2009, 02:18 PM
I know I am alittle late posting, but I have to comment :)

I am a huge fan of open source( virtualbox, linux, sauerbraten, firefox, code::blocks, gcc, blender, and lots more ). The more the better, but I do believe in keeping your source code private. I am not a fan of making it easy to steal high level code when you want your code private and it is exactly how microsoft left it with the .net program languages. So now the coder has to worry about it( the high level code ). Sure there are ways to help defend your high level code. Even very costly ones.


(an most commerical obsfucators add them) which makes reverse engineering exactly on-par with any native language.


If cost isn't an issue, native is free .. that is if you can compile to native like c, c++, vb6, and so forth.

Arjay
May 6th, 2009, 04:35 PM
I have to wonder.... what percentage of programs out there really have to worry about reverse engineering?

dglienna
May 6th, 2009, 09:07 PM
What? I wrote an app a long time ago, and instead of 300 sales, I ended up getting ONE sale, and 300 satisfied-for-now rejections. That was back in the QuickBasic days, though.

TheCPUWizard
May 6th, 2009, 09:29 PM
If someone is writing "jelly bean" programs and attempting to sell them, they are typically looking at a sell price of well under $100 (US). Much of the competition already comes in the form of other free or trial or low cost products. Generally these programs are so simple that there is no need for reverse engineering, as it can be duplicated just from observation.

If someone is writing commercial application they are typically looking at sell prices of several hundred (or much more). They are complex enough that reverse engineering becomes an important part of a competitor duplicating the product.

However, in the latter case, what the customer is buying is VALUE, most often in terms of SUPPORT. If you build a reputation of supporting your products that differentiates it from the competition (regardless of if the compition developes an original solution, clean clones yours, or even downright steals it) then your company will have a significant market share.

At least that is how it hasw worked for my company for the past 25 years, as well as for every small to mid sized software development company that has managed to stay in business for 7 years or more.

I have not had ANY first (or second) hand verifiable knowledge of any software shop losing significant revenue soley based on the ability (or lack thereof) to reverse engineer their product.