Is it still easy to crack .NET and java code nowadays?
#2 Members - Reputation: 463
Posted 07 October 2011 - 09:25 PM
But the tools reverse the binary to very clear code. I don't like that.
#4 Members - Reputation: 2751
Posted 07 October 2011 - 10:14 PM
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.
#6 Members - Reputation: 334
Posted 08 October 2011 - 01:12 AM
because it renames every thing so that even a computer has a hard time working out whats going on( at least so they say )
Disclaimer: Each post of mine is intended as an attempt of helping and/or bringing some meaningfull insight to the topic at hand. Due to my nature, my good intentions will not always be plainly visible. I apologise in advance and assure you I mean no harm and do not intend to insult anyone.
#7 Members - Reputation: 2369
Posted 08 October 2011 - 06:58 AM
Legal means imply large funds. They aren't an option for majority.you should use legal means of protection, rather than weak technical measures
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.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.
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.
#8 Members - Reputation: 683
Posted 08 October 2011 - 11:44 AM
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.
http://www.cpgf.org/
cpgf library -- free C++ open source library for reflection, serialization, script binding, callbacks, and meta data for OpenGL Box2D, SFML and Irrlicht.
v1.5.5 was released. Now supports tween and timeline for ease animation.
#9 Members - Reputation: 249
Posted 10 October 2011 - 01:21 AM
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...
#10 Members - Reputation: 806
Posted 10 October 2011 - 02:07 AM
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. 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.
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.
#11 Members - Reputation: 194
Posted 10 October 2011 - 12:25 PM
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)
#12 Members - Reputation: 1866
Posted 10 October 2011 - 02:01 PM
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.
#13 Members - Reputation: 194
Posted 10 October 2011 - 02:57 PM
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.
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).
#14 Moderators - Reputation: 7562
Posted 10 October 2011 - 10:50 PM
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.
[Work - ArenaNet] [Epoch Language] [Scribblings] [Journal - peek into my shattered mind]
#15 Members - Reputation: 1866
Posted 11 October 2011 - 01:38 AM
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.
#16 Moderators - Reputation: 1754
Posted 11 October 2011 - 03:25 AM
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.
#17 Members - Reputation: 432
Posted 11 October 2011 - 03:30 AM
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.
#18 Moderators - Reputation: 1754
Posted 11 October 2011 - 04:08 AM
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.
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.
#19 Members - Reputation: 3330
Posted 11 October 2011 - 07:35 AM
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.
#20 Members - Reputation: 240
Posted 11 October 2011 - 08:00 AM
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.






