Is it still easy to crack .NET and java code nowadays?

I guess it depends on the project. It's so easy to reverse engineer .net code, that we had to use obfuscator, and route stuff throug native dll with a much more of trickery to keep hackers away. Normally I think its not that serious.

But the tools reverse the binary to very clear code. I don't like that.

That's why I hesitate to switch language

I don't see it as much of a concern myself. If you're doing something clever enough to bother, you should use legal means of protection, rather than weak technical measures. If you have something worth real money, they're going to reverse it whether its in transparent IL, obfuscated, C++ or Klingon. The effort they'll expend is proportionate to the value of your code... Or, someone will hack it just because they're bored.is

I mean, honestly, is your code *really* worthy of this trade-secret protection, or is this just the usual tin-foil-hat-wearing conjecture of -- "oh noes! Someone is stealing our codes and they're gonna make a bajillion dollars!!!"

My take, much like it is for DRM, is that there's simply no point, and that your time would be better spent making your product better.

It's still relatively trivial to circumvent the copy protection in C++. Losing double digit percentage productivity to make some cracker spend 4 hours instead of 1 is a horrible business decision.

why not just use Dotfuscator ?( AFAIK it comes with VS Pro and Up )
because it renames every thing so that even a computer has a hard time working out whats going on( at least so they say )

The barriers to reverse engineering are very low. Minecraft mods are written as plain Java code that patches the official classes. All tools merely point out that obtaining minecraft.jar is subject to copyright and one must own a legal version.

you should use legal means of protection, rather than weak technical measures[/quote]
Legal means imply large funds. They aren't an option for majority.

It's still relatively trivial to circumvent the copy protection in C++. Losing double digit percentage productivity to make some cracker spend 4 hours instead of 1 is a horrible business decision.[/quote]
Halving your productivity but preventing someone from taking your distribution verbatim, reverse engineering it (automated) and releasing their own modified version in 2 hours is a good trade-off.


Rather than protection or security, we're talking about barriers to entry. Native compiled code is irreversible. One can decompile it into assembly, but not much more, making it useless for reuse, mostly through "accidental" loss of information made by compiler (variable and function reorganization, data removal, inlining vs. duplication, complete removal of symbol information).


JavaScript/HTML5 is failing to gain traction for precisely this reason in many fields. It requires everything to be in plain, portable form (js, JPEG/PNG/GIF, xml/JSON). To reuse it, just download everything (page->save) and you're done.


The value of code: Many will say it's not worth anything and point to github. But when you spend two weeks (as expert in domain) tuning some algorithm, not wrestling some basic API, it suddenly gains value which would be immediately lost by someone who copies it in usable form. Even developing a robust OGL/ES initialization code that works across 200 browsers suddenly gains value, since it gives something that requires extensive testing where final lines of code are just a conclusion.

Like DRM or not, taking away the ability to protect puts an upper bound on effort that will go into such products. Effect can be proven via game theory, favoring race to bottom, where effort spent on code and assets needs to go towards zero. The adverse effect is it eliminates any additional value that could go towards forming legal protection. There are very few examples where long-term value would form through a fully open product alone and copyright laws have never helped the cause, in all cases they harm the goodwill of users and developers.

If your game/software is so valuable, e.g, Windows, no matter how smart you tried to protect (there are so many genius in Microsoft tried to protect Windows), your product will definitely be cracked in very short time.
If nobody cares your product, you are safe, even if you give out the source code.

So I suggest just put your time on product quality, no matter which language to use.
If one day you are so successful that cracking is a big problem, language is not a problem, crackers can crack your C++ app very easily.

Funny that you ask that because, i just hacked(or fixed?) a program(don't worry, it was free) obfuscated in c# that was doing something really anoying, writing "Download in my msn status every time the app started and closed, even if i unchecked the "show what im listening too" in msn, it was being enabled again automatically every time no matter what i did, and was becoming very annoying to uncheck every time i used it, and they're was no option to turn this off in the application. I have to say, i had a hard time with it, especially when decompiling it with ILDasm or similar programs. I only got it because strings aren't obfuscated, and it was changing a registry key, wich i noticed was being set to true when toggling the option in msn, and remembered seeing it in the decompiled MSNMessage.dll of the program too. So i hex edited the reg. key name to something else and it worked. I got lucky, but i don't think i could have recompiled it using the tool i had, or my very limited knowledge in the matter.

So, I think it's definitively easier to crack native code than obfuscated c# code.

Note: Im far from being a reverser but i've experimented here and there like everyone else who is curious about how things work, and what i did was more a fix than a hack, and after 10 years of programming, you start to know how apps work...

[color=#1C2837][size=2][/quote][color=#1C2837][size=2]Halving your productivity but preventing someone from taking your distribution verbatim, reverse engineering it (automated) and releasing their own modified version in 2 hours is a good trade-off.[/quote]
[color=#1C2837][size=2]

[color=#1C2837][size=2]That depends. If you're halving your productivity to prevent someone from ever reverse engineering your code then it may be a good trade off. [color=#1C2837][size=2]If you're halving your productivity to increase the time taken to reverse engineer your code from 2 hours to 8 hours, then it's likely not.
[color=#1C2837][size=2]

[color="#1c2837"]Like DRM, obfuscation merely increases the effort an attacker has to put in - and like DRM it's mathematically flawed and requires orders of magnitude more effort to implement than to break.

I write all my logic in c++.
The GUI can be written in .NET or Java.

Whether it's obfuscated or not, the hacker can do whatever he wants with my GUI. I don't care.
Going deeper into any logic I wish to hide, will take much more effort (unless he speaks fluent assembly in his every day life)

I write all my logic in c++.
The GUI can be written in .NET or Java.

Whether it's obfuscated or not, the hacker can do whatever he wants with my GUI. I don't care.
Going deeper into any logic I wish to hide, will take much more effort (unless he speaks fluent assembly in his every day life)

I don't think that will help you much. The interop layer between the managed and native code will provide a very large amount of info for a hacker to use.

[quote name='Idov' timestamp='1318271149' post='4871146']
I write all my logic in c++.
The GUI can be written in .NET or Java.

Whether it's obfuscated or not, the hacker can do whatever he wants with my GUI. I don't care.
Going deeper into any logic I wish to hide, will take much more effort (unless he speaks fluent assembly in his every day life)

I don't think that will help you much. The interop layer between the managed and native code will provide a very large amount of info for a hacker to use.
[/quote]

yes, he'll be able to use my C++ interface, but what then?
If I use serial number which blocks all c++ activity if it's incorrect, he'll still have to hack the unmanaged code to use it.
Hacking the GUI gives him nothing (I think).

yes, he'll be able to use my C++ interface, but what then?
If I use serial number which blocks all c++ activity if it's incorrect, he'll still have to hack the unmanaged code to use it.
Hacking the GUI gives him nothing (I think).

Any reverse engineer worth his salt can back out your "security" in about 2 minutes using a simple machine-language trick. You might annoy someone for half an hour while they figure out what you did, but you're not preventing much of anything.

Sure, it's harder than just reversing the managed code - I'll grant you that. But basically any dedicated reverser isn't going to be stuck just because you're not doing everything in managed code. Cuts out Joe Random Newbie - again, I'll grant you that - but IMHO J.R.Newbie isn't the guy to worry about in the first place.

yes, he'll be able to use my C++ interface, but what then?
If I use serial number which blocks all c++ activity if it's incorrect, he'll still have to hack the unmanaged code to use it.
Hacking the GUI gives him nothing (I think).

I didn't mean he'll use your interface by calling it. I meant the interface provides information that makes it easier for him to hack the native code itself. He gets information about data types that are being passed to/from the native code, as well as the location of each function of the interface in the native code. That might not sound special, but it REALLY helps him when he goes to hack the native code.

To be honest, I feel a bit alienated by this fatalist attitude towards the value of ones own code that seems to be rampant on this board lately. People claiming that you could just as well post your code on facebook because it's so worthless even the most basic protection would be wasted, that the general value of code is zero (pointing to github or whatever), and so on.

I totally disagree with these claims. Did you look at the general code quality for projects on sites like github, sourceforge and co ? 99% of the code available there would not even pass basic code review in any serious software company. High quality, clean, well tested and documented code can gain value very quickly. And we're not even talking about trade secrets or any super innovative new algorithm here. It's simply about good craftsmanship. And that costs money. Of course this can get exponentially higher if actual trade secrets come into play.

Mind you, we are not talking about cracking here. We are talking about illegal code reuse. Someone taking large chunks of your code and copying them almost verbatim into his own products. Someone stealing your valuable time in order to improve his products without major effort.

Yes, you can take legal action against that. However, as Antheus mentioned, few people have the financial resources to pay for the lawyers and the legal procedures, which can take years. Furthermore, a lot of these violations occur in countries where legal action is not an option (eg. China). And finally, it can be extremely hard to prove that the offending party actually took your code. In contrast to some people here, these intellectual property violators might not think their (stolen) code to be worthless and will certainly not keep it open for you to inspect that easily.

So in conclusion, yes I think that easy decompilation is a major concern with managed languages. There is no perfect solution to this problem as of yet (at least not as good as native compilation, which makes code reuse almost impossible). The minimum for any serious project should be obfuscation.

I totally disagree with these claims. Did you look at the general code quality for projects on sites like github, sourceforge and co ? 99% of the code available there would not even pass basic code review in any serious software company.

Meanwhile those of us working in one of those "serious" software companies know that that's nothing but wishful thinking.

[quote name='Yann L' timestamp='1318325113' post='4871382']
I totally disagree with these claims. Did you look at the general code quality for projects on sites like github, sourceforge and co ? 99% of the code available there would not even pass basic code review in any serious software company.

Meanwhile those of us working in one of those "serious" software companies know that that's nothing but wishful thinking.
[/quote]
I may be a bit biased by the harsh code review procedures imposed in the defense sector. Sure, some corporate code is abominable, especially when deadlines approach. Still, this code is written in-situ and designed to fit into a certain project. Usually it works (more or less) for its intended purpose. As bad as it may be, it still has 'virtual' value - the amount of money the company payed the employee(s) to write it. A lot of the FOSS code out there has negative value. It is more expensive to fix it and push it into the required shape (often due to lack of documentation) than to simply rewrite everything from scratch. And then there is the issue of viral licenses of course.

Let's be honest here; even though many of us are writing well structured, 'good' code, I'd wager that few programmers write code that meets Antheus' description of high value code. Code that requires a lot of tuning or expert knowledge just isn't that common. The vast majority of code is still just plumbing between libraries to achieve the desired effect.

Code does have value. The issue I have is that generally (imo) you generate more wealth spending your time making code than protecting code. Especially if your idea of protecting code is migrating from a managed to unmanaged language.

In my experience, decompilation is usually done for studying methods on solving a problem that's got a programmer stumped (for example someone working on a software 3D engine might decompile pixomatic) or for studying internal workings of a code (for example, a closed-source SDK). Generally even if they decompile your code with the intention of outright copying it; they're too stupid to know what to do with it once they've got the code in front of it. Wannabe programmers aren't anything you should be seriously concerned with.

Of course, if your method happens to be some trade secret and not something that someone showed you here on gamedev.net; maybe you have something you should invest time in protecting. I'm not familiar with these practices though, never had to deal with any attempts at stopping me in my reverse-engineering days.

I would argue that you should just make your product in the language of your choice. Once it's just about ready for release you should start considering these things.

As an aside, I do believe that the Mono project has an AOT compiler if you want to compile your CLR IL to native code.