Preventing decompilation
-
Shog9 wrote:
i write really lousy code
You do? I thought the code for CPhog was very good :-D
Heh, thanks. :)
---- Scripts i’ve known... CPhog 1.0.0.0 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
-
BrockVnm wrote:
Is there a way to split out your code and protect it without using obfuscation?
Well, at very least, you can then obfuscate just the important code without needing to do so for your entire app. But depending on your needs, there may be even better ways - such as running it on your server and communicating with it via a web service or etc., thus removing the need to allow such sensitive code on the end-users' machines at all. But, i'm speaking from the perspective of a company whose interest is in protecting key algorithms and (especially) data - i've no interest in schemes to protect a program from being run. Looking at it from the other angle, you get John's perspective, where there are scores of people with full access to your (compiled) code, just looking to break copy protection schemes. In that case, your only real option is to just throw as many roadblocks as possible in the path of the would-be cracker - it's not really possible to effectively secure the program, but if you can discourage all but the most hard-core then you'll probably be ok.
---- Scripts i’ve known... CPhog 1.0.0.0 - make CP better. Forum Bookmark 0.2.5 - bookmark forum posts on Pensieve Print forum 0.1.2 - printer-friendly forums Expand all 1.0 - Expand all messages In-place Delete 1.0 - AJAX-style post delete Syntax 0.1 - Syntax highlighting for code blocks in the forums
-
Right, and I have a bridge in Brooklyn you might want to buy. :rolleyes: Unless you are specifically excluding commercial software in your comment then I couldn't possibly disagree with you more. We have built and sold commercial software via the internet for over 10 years now and I could write a good sized novel on all the nefarious stuff I've seen people do when they have any kind of access to your code and the motivation to do so. Not obfuscating commercial software is negligent at best.
If someone can penetrate your security with your code then they can penetrate it without. Who was it that said, "Security through obscurity isn't?" Also, I would hope that the use of strongly named assemblies would mitigate the risk of someone stealing code, altering, and then pawning it off as yours. "Until the day of his death, no man can be sure of his courage" -- Jean Anouilh
-
If someone can penetrate your security with your code then they can penetrate it without. Who was it that said, "Security through obscurity isn't?" Also, I would hope that the use of strongly named assemblies would mitigate the risk of someone stealing code, altering, and then pawning it off as yours. "Until the day of his death, no man can be sure of his courage" -- Jean Anouilh
-
If someone can penetrate your security with your code then they can penetrate it without. Who was it that said, "Security through obscurity isn't?" Also, I would hope that the use of strongly named assemblies would mitigate the risk of someone stealing code, altering, and then pawning it off as yours. "Until the day of his death, no man can be sure of his courage" -- Jean Anouilh
Ennis Ray Lynch, Jr. wrote:
Who was it that said, "Security through obscurity isn't?"
Whoever said that was incorrect. Probably what they should have said is "Security through obscurity isn't perfect". Strongly named assemblies are useless if you can easily create source code from the assembly, you simply re-sign it with your own key and away you go. The real problem isn't people pawning off our software as their own, it's breaking our license key system then posting a free version on a warez site. If we make no effort at all to prevent it then we're negligent. If people are capable of breaking the encryption on top of our obfuscation then I have someone to go to who built it and is responsible to fix it but so far it's not happened. We use signed xml license documents, strongly named assemblies that are obfuscated and then encrypted with an IL loader system. Can it be hacked? I'm sure it can, anything can. Is it worth it for the casual cracker to take on? Doubtful they would put in the effort. The worst we've seen in the past is requests for cracks for our software and ultimately they didn't crack it, they used a stolen credit card from a nice older couple in Arizona (who didn't even own a computer) to purchase a license via an email account created on a hacked network at (ironically) a computer networking company in another part of the U.S., posted the license key on a China based warez site and we found out about it when we suddenly had over a thousand downloads of our software in the space of what would normally be 20 and immediately re-released our software with a special exception for the stolen license. That's the reality of what software developers face, of course it's bloody worth it. We're talking about thousands of hours of my sweat and gray hairs to make something worth selling. My livelihood. It's not a casual academic discussion to me and in the real world you do whatever you have to to protect your livelihood. We've since added things to prevent the above scenario, and knock on wood nothing serious since. The bottom line is that it's worth a certain amount of effort because it prevents nearly all the casual piracy that goes on all the time with less protected software.
-
Are a combined security effort with your domain and local machine. I am quite sure a machine set to only run strongly named assemblies from a list of trusted authors would not run the affected code. "Until the day of his death, no man can be sure of his courage" -- Jean Anouilh
-
Ennis Ray Lynch, Jr. wrote:
Who was it that said, "Security through obscurity isn't?"
Whoever said that was incorrect. Probably what they should have said is "Security through obscurity isn't perfect". Strongly named assemblies are useless if you can easily create source code from the assembly, you simply re-sign it with your own key and away you go. The real problem isn't people pawning off our software as their own, it's breaking our license key system then posting a free version on a warez site. If we make no effort at all to prevent it then we're negligent. If people are capable of breaking the encryption on top of our obfuscation then I have someone to go to who built it and is responsible to fix it but so far it's not happened. We use signed xml license documents, strongly named assemblies that are obfuscated and then encrypted with an IL loader system. Can it be hacked? I'm sure it can, anything can. Is it worth it for the casual cracker to take on? Doubtful they would put in the effort. The worst we've seen in the past is requests for cracks for our software and ultimately they didn't crack it, they used a stolen credit card from a nice older couple in Arizona (who didn't even own a computer) to purchase a license via an email account created on a hacked network at (ironically) a computer networking company in another part of the U.S., posted the license key on a China based warez site and we found out about it when we suddenly had over a thousand downloads of our software in the space of what would normally be 20 and immediately re-released our software with a special exception for the stolen license. That's the reality of what software developers face, of course it's bloody worth it. We're talking about thousands of hours of my sweat and gray hairs to make something worth selling. My livelihood. It's not a casual academic discussion to me and in the real world you do whatever you have to to protect your livelihood. We've since added things to prevent the above scenario, and knock on wood nothing serious since. The bottom line is that it's worth a certain amount of effort because it prevents nearly all the casual piracy that goes on all the time with less protected software.
How many casual pirates purchase your software because of the "security" you put in place? I think you are confusing the concept of security with the concept of protecting intellectual property. I have no qualms with protecting IP but to say a hacker is a pirate and claim security is the issue is a literary device I cannot come to terms with. "Until the day of his death, no man can be sure of his courage" -- Jean Anouilh
-
How many casual pirates purchase your software because of the "security" you put in place? I think you are confusing the concept of security with the concept of protecting intellectual property. I have no qualms with protecting IP but to say a hacker is a pirate and claim security is the issue is a literary device I cannot come to terms with. "Until the day of his death, no man can be sure of his courage" -- Jean Anouilh
IP is not really a concern when it comes down to it for most of the software on the planet. Let's face facts here, how much real break through technology is hidden inside most software? Not much. What is at issue for most who are concerned with protecting their software is cracking of licensing schemes. A hacker or more appropriately a 'cracker' trying to bypass the licensing of software is in fact probably the most common and important security issue to most software publishers. Perhaps the posters original question was concerned with protecting some kind of patentable intellectual property, that's not what I'm talking about. If you think I'm talking about people breaking into online software to steal information or disrupt service I apologize for the confusion. If you are just plain disagreeing with the idea that there is any merit to trying to protect software from theft and piracy then we'll just have to disagree on that one.
-
IP is not really a concern when it comes down to it for most of the software on the planet. Let's face facts here, how much real break through technology is hidden inside most software? Not much. What is at issue for most who are concerned with protecting their software is cracking of licensing schemes. A hacker or more appropriately a 'cracker' trying to bypass the licensing of software is in fact probably the most common and important security issue to most software publishers. Perhaps the posters original question was concerned with protecting some kind of patentable intellectual property, that's not what I'm talking about. If you think I'm talking about people breaking into online software to steal information or disrupt service I apologize for the confusion. If you are just plain disagreeing with the idea that there is any merit to trying to protect software from theft and piracy then we'll just have to disagree on that one.
I was just qualifying my who cares statement. However, licensing is not security imho. "Until the day of his death, no man can be sure of his courage" -- Jean Anouilh
-
I was just qualifying my who cares statement. However, licensing is not security imho. "Until the day of his death, no man can be sure of his courage" -- Jean Anouilh
-
:-D That depends on whether you wrote the software or are using the software that someone else wrote. As a developer *and* publisher security encompasses a lot more than it does to an end user.
To see how many pirates would buy the software if it could not be pirated and the compare that revenue with the cost of implementing some of the more lame anit-piracy schemes out there. "Until the day of his death, no man can be sure of his courage" -- Jean Anouilh
-
To see how many pirates would buy the software if it could not be pirated and the compare that revenue with the cost of implementing some of the more lame anit-piracy schemes out there. "Until the day of his death, no man can be sure of his courage" -- Jean Anouilh
Simple, buy two dozen donuts, put half on a table in your office with a FREE DONUTS sign, set up another table beside it with the other dozen, put a price sign up, set up a cash register and stand behind it and charge people who want one and see which donuts are gone first. There is no study required, that's ludicrous.
-
Simple, buy two dozen donuts, put half on a table in your office with a FREE DONUTS sign, set up another table beside it with the other dozen, put a price sign up, set up a cash register and stand behind it and charge people who want one and see which donuts are gone first. There is no study required, that's ludicrous.
If you take away the free donuts how many people that would have taken a free donut will not partake of the paid donut? Try the following experiment: Buy 1 dozen donuts 5 days a week and go to a large office and setup shop in the break-room. Sell the donuts for a profit (count your overhead and the office overhead, Fuel, etc.). Next go to a different but equally sized office and repeat only giving away the donuts. Repeat for several weeks. Then come back with data. "Until the day of his death, no man can be sure of his courage" -- Jean Anouilh
-
Most code is not that important taken individually. Unless you have a trade-secret algorithm (which is patentable BTW? (idk) there is nothing that can be gained. "Until the day of his death, no man can be sure of his courage" -- Jean Anouilh
You can't patent algorithms. You have to patent the system/process around it. regards, Paul Watson Ireland FeedHenry needs you
eh, stop bugging me about it, give it a couple of days, see what happens.
-
If you take away the free donuts how many people that would have taken a free donut will not partake of the paid donut? Try the following experiment: Buy 1 dozen donuts 5 days a week and go to a large office and setup shop in the break-room. Sell the donuts for a profit (count your overhead and the office overhead, Fuel, etc.). Next go to a different but equally sized office and repeat only giving away the donuts. Repeat for several weeks. Then come back with data. "Until the day of his death, no man can be sure of his courage" -- Jean Anouilh
Well it's safe to say that in the first office you would have made some money or not depending on how good the donuts are, the market forces at work, the quality of your service etc. In the second office you are out of pocket 5 dozen donuts, the cost of gas etc. Perhaps in my original analogy we should put up a sign with the Free Donuts saying underneath "These donuts were stolen" and see how that affects the outcome. Anyway, this discussion is interesting and all, but what practical, personal experience in the business has taught me is what I go by so I'll take comfort in my heretical beliefs and let you take the last word if you care to reply. ;)
-
So yesterday a colleague of mine was telling me how easy it is to decompile .Net and Java compiled code. So this made me a little uneasy and I did a quick Google search to find out that this was something that could be done easily. I know a lot of people here write .Net code and some of use write java code. What do you do to prevent people from decompiling your compiled code? Is there any secure way to prevent this?
As the thread has mentioned, you want to Obfuscate your code. I researched this topic several month ago, and I discovered that it is quite reliable. Different vendors will increase the level of obfuscation; thus, making it that much harder to decompile the code into something useful (or worth taking). My search led me to investigate what would you do if you legitimately needed to recover code which you were entitled to, but you had lost your code. Restoring the code is quite expensive and difficult. Even on the simplest obfuscators, simple decompilation and recompilation fails ... there is not enough space to describe what all can be done. Nonetheless, language rules are far stricter than the byte code. Obfuscation will protect intellectual property most of the time ... but there are determined people out there that don't value their time at all and may take the time to decompile ... and rebuild the app. After a time analysis, I feel confident by saying that they usually could've coded the app in about the same time it took fix the decompiled obfuscated code. Unfortunately, obfuscation does not protect you from hardcoded values and such, nor smaller identifiable code block that may shed light or even reveal how a particular task was accomplished. During my research I did find vendors that could even protect you in these areas ... but I couldn't dream of affording their proud products. Just my 2 cents ... hope this is helpful to someone if not interesting. It is worth protecting your work always, even simple measures are better than none. :cool: Thanks, ElGatoRojo13