Sign in to follow this  
lucky6969b

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

Recommended Posts

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.

Share this post


Link to post
Share on other sites
why not just use [url="http://www.google.co.za/url?sa=t&source=web&cd=1&ved=0CBoQFjAA&url=http%3A%2F%2Fwww.preemptive.com%2Fproducts%2Fdotfuscator%2Foverview&rct=j&q=dotfuscator&ei=gPePTre6Loa1hAeU4qgX&usg=AFQjCNHBk7Pb9YNLDGWxGaYGiPgDpaZysw&cad=rja"]Dotfuscator[/url] ?( 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 )

Share this post


Link to post
Share on other sites
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.

[quote] 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.

[quote]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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 <program name>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...

Share this post


Link to post
Share on other sites
[color=#1C2837][size=2][/quote][/size][/color][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][/size][/color]
[color=#1C2837][size=2]
[/size][/color]
[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. [/size][/color][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.[/size][/color]
[color=#1C2837][size=2]
[/size][/color]
[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.[/color][/size]

Share this post


Link to post
Share on other sites
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) :)

Share this post


Link to post
Share on other sites
[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) :)
[/quote]

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.

Share this post


Link to post
Share on other sites
[quote name='Nypyren' timestamp='1318276901' post='4871186']
[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) :)
[/quote]

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).

Share this post


Link to post
Share on other sites
[quote name='Idov' timestamp='1318280260' post='4871212']
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).
[/quote]

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.

Share this post


Link to post
Share on other sites
[quote name='Idov' timestamp='1318280260' post='4871212']
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).
[/quote]

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.

Share this post


Link to post
Share on other sites
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 [i]cracking[/i] 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 [i]your[/i] valuable time in order to improve [i]his[/i] 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.

Share this post


Link to post
Share on other sites
[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.
[/quote]

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

Share this post


Link to post
Share on other sites
[quote name='Red Ant' timestamp='1318325439' post='4871383']
[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.
[/quote]

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.

Share this post


Link to post
Share on other sites
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 [b]does[/b] have value. The issue I have is that generally (imo) you generate more wealth spending your time [i]making [/i]code than protecting code. Especially if your idea of protecting code is migrating from a managed to unmanaged language.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
I wouldn't make the claim that code has no value. Indeed, well-engineered, battle-tested code is really, really valuable. However, the value of the code comes in large part from its original source form. Its not just what the code does, but how it does it -- specifically, doing it in a way that is fully correct, maintainable, and efficient. I think the first two in particular are difficult to glean from the output of a decompiler. In other words, even if someone is able to determine the functionality of the code, the original producer of the code still maintains the upper hand in reliability, and is able to respond to new needs with more agility.

For Managed code, JVM languages, javascript -- by all means, use tools to obfuscate your work. Generally, tools exist with are available cheaply, or for free, and there's not much overhead in running your release builds through them before they go out the door. Sure, it doesn't provide you a great measure of additional security, but its a negligible change to your overall flow of production. What I would oppose is making drastic changes to the way you work in the pursuit of making the lives of reverse engineers more difficult -- Switching to an unmanaged language would surely accomplish that, but *your* productivity goes out the window. Other methods would likewise be effective -- self-modifying code, for example, but again, the product becomes more difficult to engineer.

Now, the point has been made regarding DRM, that for a AAA game which sees 98% of its sales within the first 8 weeks and has a long tail that is essentially negligible, it makes sense to invest time and effort into delaying crackers -- If you can delay cracks by 4 weeks, you've just protected 50% of your revenue. But I think for most indie game developers, and for small, niche software vendors in general, the reality of their market is that sustaining the long tail is their bread and butter -- making your engineering life more difficult simply doesn't do much for (and in many ways can act against) your ability to continue to meet customer desires or maintain customer relationships.

Share this post


Link to post
Share on other sites
Obfustication is generaly enough.

I have a game engine written in java and games that use it. Ive spent alot of time on this and I also wouldnt want some one to simply decompile my engine and use it as is. So when making a release build of a game I obfusticate all the engines classes together with all the games classes into one package, obfuscating all class, method and variable names. My engine would allready be a pain to use without its documentation so trying to use the obfuscated version of it without documentation would be insane, A would be code stealer would be much much better of using/buying a different engine than attempting to use mine.

Share this post


Link to post
Share on other sites
[quote]High quality, clean, well tested and documented code can gain value very quickly.
...
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. [/quote]

I agree that high quality code accompanied by good tests and documentation can be valuable - but as decompilation provides neither tests nor documentation, I don't view it as a problem.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this