.NET and java simplify our jobs drastically. But yet still a lot of disassembly tools emerged.
Do you guys just obfuscate your code? or that's not enough.
At least, C++ is not for casual hacker...
Thanks
Jack
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.
But the tools reverse the binary to very clear code. I don't like that.
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.
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 )
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.
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 <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...
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.
[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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement