views:

391

answers:

11

I came across this post on the MSMobiles.com blog that says the following, among other things:

.Net is great in so many ways but for commercial apps? No way! Anybody can just look at your source code. A high end obfuscator will help a lot but any determined hacker will fix your code in less than a day. I know this from sad experience despite spending $1000s on anti-piracy and obfuscation tools.

It then says the following about developing commercial Windows Mobile apps in .NET:

be prepared for 1-day delay after which your competitors will copy your functionality and place their own apps with the same functionality in the Skymarket

For those familiar with .NET: is this truth or nonsense? Is this issue somehow specific to Windows Mobile, or does it apply to .NET on Windows as well? This just seemed surprising to me because I know that Microsoft writes a good amount of its own client-side software in .NET (and that many vendors write expensive apps in Java, which apparently has the same problems), and it seems strange that their IP could be stolen so easily.

+1  A: 

It applies to .NET on windows as well. It also applies to Java.

You can obfuscate the code, and some of the obfuscators are good (you can easily find a good one through google), but in the end, you will have to be vigilant in protecting your IP, as obfuscators are not a perfect technology. The obfuscators beat the decompilers, which get smarter, and beat the obfuscators, which get smarter, etc, etc.

Technially, you can figure out how a C++ program works, or any program works by looking at the compiled code. It's just that the level it is compiled down to is much more complex than say, IL (which is what .NET apps are compiled to).

casperOne
+7  A: 

I would argue it is largely non-sense for the simple reason that if your competitive advantage and business success is dependent on some algorithm in your code then you are screwed already. Successful apps are about so much more than just the code, it is one of many pieces.

If this is something you really fear then I would invest in obfuscation and pre-pay for some legal counsel (pretty cheap believe it or not) who will send cease and desist letters on your behalf to a competitor who you believe stole your code. While this is going almost nowhere legally - the threat of action is just about your most effective tool.

keithwarren7
+1  A: 

Go and do a google on Reflector. Yes it is real, yes it happens, and yes you obfuscation can help but is not perfect. And then go and reflect on Reflector itself. Not sure if Redgate is still obfuscating it but the original author obfuscated it using unprintable characters preety nasty to work through.

The same problem exists with Java however, so pick your posion. Ohh and a true determined hacker will crack any application on any platform so pick a platform for its functionality and that is geard to your problem and your skill set.

Use tools to help increase your security and raise your bar.

JoshBerke
Obfuscation isn't a very high bar to get over in reverse engineering. It barely slows someone down.
Simucal
It simply raises the bar, will it stop a motivitated attacker no of course not and I never tried to indicate otherwise...
JoshBerke
A: 

One of the nice things about IL is that it fully qualifies all types by their full name. So when you look at obfuscated code in, say, Reflector, you could have a dozen variables in the same class with the same name, but since they are fully qualified in the IL the runtime has no problem with them.

Sean Bright
A: 

It is very easy to read a .Net assembly. You can try by yourself:

http://www.codeproject.com/KB/dotnet/NetDasm.aspx http://www.shutterspeaks.com/2006/08/27/how-to-disassemble-net-assembly-files/

There are obfuscators available to make the job harder. With Mono (Open source implementation of .Net), it is also possible to compile .net code into an executable, taht should make disassembly a lot harder.

Julien
+4  A: 

There is some truth in yet around the ease of decompiling a .NET application. (This applies to any .NET application, not just ones running on Windows Mobile.)

It is relatively easy to take a compiled assembly and get the source code using both free and commercial tools. (Simply take a look at Reflector.) That being said, you can use an obfuscator, which will stop the majority of people but will only slow down a determined hacker.

Despite all of that, there are decompilers for almost any language and if a company (or person) is determined to see the internals of your product they will find a way no matter what.

Reading the post you reference really sounds like it was written by someone who had a very bad experience with Microsoft, .NET, and/or Windows Mobile and some of the statements made are incorrect at best. (Particularly the point about this not being a problem on an iPhone because it's written in "native" code.)

Scott Dorman
A: 

Yes, casper is certainly right, you can always just look at the machine code. Though the more complex object-oriented relationships like polymorphism are hard to discern when looking at the assembly code level.

But in my opinion, the whole protecting source code mentality is flawed. The open source philosophy is that opening up your code to public scrutiny helps make your software better because more people are there finding bugs and security flaws. Also, Linus's law is being embraced by more and more major companies like Sun, Google, etc.

Daniel
+3  A: 

While it might be slightly easier with intermediate bytecode languages, the fact of the matter is you can do this with any language.

Executable code can be disassembled and gone through with ease. IDA-Pro can load native executables, disassemble them and with the Hex-Rays plugin it can even provide C like pseudo-code to go over. Even without Hex-Rays it isn't terribly difficult to step through the assembly code and deduce what is happening. This is how keygens are made for licensed products. They are disassembled and programmers study the relevant assembly code responsible for generating and verifying the product keys.

However, the cost of reversing any major feature out of an app is pretty high. So unless it is some highly competitive feature that involves trade-secret algorithms it is almost always easier and more cost effective to simply hire programmers to write it from scratch than reverse engineer it.

If you are looking for a higher level of protection you can obfuscate your code and use a commercial packer which makes disassembling the program more challenging (and prevents any reflectors from being used while the application is packed). However, these can be circumvented and unpacked and obfuscated code doesn't really slow down a good RE at all. So, don't stress over it too much, .NET is just as suitable as any other non-bytecode language in my own opinion.

Simucal
Languages with full reflection must carry more identifier info around.So purely intuitively, I'd say there is definitely a language angle, and the ability to decompile doesn't hit all languages as hard.
Marco van de Voort
A: 

Intellectual property of software really isn't just in the code itself, it's in the idea that started to product, the knowledge gained while developing, testing and deploying the product, and the infrastructure involved in fixing, maintaining and enhancing the product.

Having the code to an application is a lot like having a car. Sure, you can take it apart and see exactly how it was put together, but can you start turning out cars next week just because you have that knowledge? Hardly.

ctacke
"but can you start turning out cars next week just because you have that knowledge?"-I'm not sure if this is a good analogy since everybody and thier brother doesn't have a factory which makes exact duplicates of cars at almost zero cost.
John MacIntyre
I wouldn't say you can develop software at zero cost either. A direct copy of your software is called piracy, so I consider that different that this concern. Garnering IP from stolen code and using it in another app is far from free. You have to understand it to use it.
ctacke
(cont'd) plus the factory actually isn't relevant here. If you had a factory, you still couldn't churn out cars. You'd need engineers to do the design, factory configuration, etc. The cost would still be in time and labor, just like in software.
ctacke
+1  A: 

Your only option is to have a network app - you distribute just clients who query a master server. This way the source that does hard work is your secret.

Spikolynn
A: 

I have not used it in awhile, but Salamander.NET will convert .NET apps to Win32 native apps (with no framework dependencies). Not sure if it ever got upgraded to .NET 2.0 or higher, but it worked in 1.1 back in 2005.

JasonRShaver