I've been learning C#, XAML, and the .NET framework for some time now, and am looking forward to creating programs written in C#, using the WPF framework.

 

However - coming from a C++ background - what concerns me the most is that the .NET framework and C# can easily be decompiled, even if I run it through an obfuscator. If someone really wanted to, they can spend a whole year, de-obfuscate my code, and read my logic behind how the software runs.

 

I'm just curious, so I ask all current C# developers - What drives you to keep developing with C# & .NET, despite risking having your .NET framework code de-obfuscated and reverse engineered? It was never an issue with C++ libraries.

Don't use C# or .NET. :smile:

I did some research on obfuscators and apparently I kinda answered my own question in a sense - because obfuscators can hide code from 99.9% of the consumer population. Of course, you still have that 0.1% that lurk on thepiratebay. And as developers, we all know - no matter how much we hide and protect, if someone wants in on our code, they will have in, no matter what language you use.

 

But for the 99.9%, this decompile error is all they will see if they try and bust through my code:

https://dl.dropboxusercontent.com/u/7596209/IMGUR%20SIM/ObfuscatorSuccess.jpg

 

Should have done some research before posting. My bad...

 

 

It was never an issue with C++ libraries.

 

Sure it is ... but most of the time one doesn't need to know the entire code if they are looking for something specific.  C++ is no more secure than any other language .. in fact, there are many folks that can easily read assembly.  Anyway, there are other products beyond just Dotfuscator that can stop reflecting a .NET app.

 

Also, hopefully one isn't releasing symbolic debug information with their product (I've seen this a few times).

 

However these days most of the really secure stuff is client/server based and if setup properly one will never get to "the code".  The problem is so many client/server based application aren't secured properly, even at very large institutions (Sony, Adobe, BofA, etc. etc.).

 

I wouldn't worry too much about 'thepiratebay' ... those folks are primitive at best case and only pick on already easy to hack software.  Anyone with some real knowledge isn't going to be messing around with piratebay or anonymous junk.  If a pretend hacker is posting about it then that's for certain an empty shell with no real content and to be ignored.  The more knowledgeable hackers will be looking for money targets, counter intelligence, ... not thepiratebay.  thepiratebay is just the Robin Hood syndrome ... or what many want to convince themselves that's what they're doing (has no impact on the corporate/wall street world but has a big impact on consumer costs).

 

Cheers, Rob.

Rob,

 

Your whole reply impressed me - very well said.

 

Henry,

 

In response to your original question, I've got a few points that I think about when picking a language. I'm fluent in both C#/.NET and C++ (and C++/CLR, which is .NET for C++). My thought process on using .NET is this: similar to what Rob said, many times, chunks of the code aren't available directly to client and won't be as easily accessible to a "hacker" or decompiler or if it is, does it really matter?

 

The other thing to consider is the amount of time it would really take somebody to reverse it. For example, smartCARS (our ACARS platform) was written in C++ using the .NET (CLR) for the GUI. There are parts of it, that, if decompiled, would reveal something similar to the original source. That said, it's mixed in with native code that generates line after line of bit shift operators or ridiculous references that I can't even figure out when comparing it line by line with the original source. The amount of time it would take to put that back together, even with partial source, isn't at all worth it for a "hacker." Our installer system is written in C# - if it's decompiled, yes, it would be visible. In this case, it's not the technology that's important, it's where it's used. There are only so many ways to accomplish the same task of installing files.

 

The above points, of course, supplement Rob's points. Simply using C++ isn't an obfuscation method - it does stop things like dotPeek from reversing it to easy-to-read source, but it doesn't make it edit proof. 

 

To answer the original question, what keeps us using one language or another? It's what we need - we deal with language-relevant problems as they come. If you need flexibility and integrated support/tools - use C#/VB. If you need heavy optimization or native interaction (gauges, etc.) - use C++. That said, ultimately, it's mostly up to developer experience and preference as both sides of the field are starting to balance out.

Rob,

 

Thanks for your reply; until now, I never knew that C++ could be reverse engineered into assembly, which could mean something to anyone who understands x86 assembly.

 

Collin,

 

Also, thank you for your explanation. Like you said, it's more about what we need, as developers, rather than what's the best language to protect your code. I have given C# a go and I have to say, it seems really easy to work with, especially when using it simultaneously with XAML in WPF.

 

On top of all that, the obfuscator I picked up seemed to keep breaking & crashing decompilers and deobfuscators with an "Error: unable to decompile" message, so with that being the cherry on top, I think I'm very satisfied I made the decision to try out C#. It will definitely work with the standalone training tools I am developing; it will only make my job even more efficient with Visual Studio's powerful built in tools.

 

Once again, thank you both so much for your replies.

I'd agree with the other guys.  While there are ways to decompile, it's pretty rare that it's worth it.  Most developers would much rather 'reinvent' anyway and they'd really have to have some unusual reason to go after your particular code.  The only guidance I'd use is simply to pick the language that works best for the job you're trying to accomplish. 

Henry, you may have noticed that I moved your original post from the (generic) forum to this more specialized forum, since I was confident that you'd receive far more cogent answers here.

I was always taught to pick the best tool / solution for a problem.

 

If you're creating an application where the security of your compiled application is the primary concern, then perhaps C# isn't the proper tool, or as you've noted, the tool needs to be adapted to the problem at hand, in your case with the use of obfuscation.

 

I primarily develop in C#, but the reason I do so is because I value it's strength in being able to rapidly develop programs based on specific ideas or experiments, which represents the vast majority of my code writing energy.

 

Out of the finished applications that have had enough merit to be useful to others besides myself, I've been content with a freeware or donationware model, so I've never needed to give thought to code security.

 

The few times I've been involved with projects that aren't open source or freeware, they haven't been written in C#.  However, code security was low down on the list among the reasons for not being in C#.

I use an obfuscator. C# is the next best thing since sliced bread, and this is the solution.

 

A good, proper one costs a lot of money, but makes code virtually impossible to understand.

 

And i can read assembly and easily see what C++ is doing

What revolutionary code are you writing that you are so concerned about reverse engineering?

 

Cheers!

 

Luke

Thanks for all your replies!

 

Henry, you may have noticed that I moved your original post from the (generic) forum to this more specialized forum, since I was confident that you'd receive far more cogent answers here.

 

Yup Ive noticed; thanks.

 

 

I use an obfuscator. C# is the next best thing since sliced bread, and this is the solution.

 

A good, proper one costs a lot of money, but makes code virtually impossible to understand.

 

And i can read assembly and easily see what C++ is doing

 

Ditto! Fully convinced C# is the way to go for my next project for a private type rating institute, which involves simulating the EGPWS to exact finest detail, fit for computer based training.

 

I actually use a freeware obfuscator, but as you can see in my 2nd post, that error message is seen when I attempt to run the program through de-obfuscators and decompilers. I purchased 3 de-obfuscators and downloaded 3 freeware just to test - so far all of them either crashed-to-desktop or generated that error message.

 

 

What revolutionary code are you writing that you are so concerned about reverse engineering?

 

Cheers!

 

Luke

 

I don't have anything big, it's because I had a really bad experience in my earlier years (long before I turned 18, when I didn't patent anything) and my work was reverse engineered, stolen, improved on, and patented by another company, where I was very good friends with a lot of their developers. But back then, I did not know anything about code protection; I only knew how to write code.

 

Now, I'm taking extra measures to make sure history doesn't repeat itself. And I'm quite convinced it won't B)

Code patents are fraudulent in my opinion. Not a single piece of code has ever told the computer that 1+1 is anything other than 10.

 

Copyright... sure, patent... bullship!