Java Forum / General / September 2007
Obfuscating methods
cmurthy - 06 Sep 2007 09:23 GMT How are commercial Java softwares released by Oracle, Sun, etc? What Java Obfuscators are used by the commercial Java products?
Andrew Thompson - 06 Sep 2007 11:38 GMT >How are commercial Java softwares released by Oracle, Sun, etc? >What Java Obfuscators are used by the commercial Java products? Judging by the StackTraces returned for most Java API's, I am guessing that few, if any of them, are obfuscated. But then, usually they are written well enough that the programmers are *not* embarrassed of their own code, so it hardly matters*.
* There are two other reasons that obfuscators are generally used. Making code harder to reverse engineer, which is rather pointless, and reducing the size of the distributable, which can be quite effective, but carries its own development/ debugging overhead.
 Signature Andrew Thompson http://www.athompson.info/andrew/
cmurthy - 12 Sep 2007 07:14 GMT > >How are commercial Java softwares released by Oracle, Sun, etc? > >What Java Obfuscators are used by the commercial Java products? [quoted text clipped - 15 lines] > > Message posted via JavaKB.comhttp://www.javakb.com/Uwe/Forums.aspx/java-general/200709/1 Hi,
Thank you for the response.
I'm not a hardcore JAVA programmer though. But why aren't the code Obfuscated? Above, did you intend to say that Obfuscating the code doesn't matter to them at all?
Stating the issue i'm facing, I have created/used Java Wrappers around a few API's written in C. As a matter of Security issue, we need to use some kind of Obfuscation for protecting the code from being reverse engineered.
Do you suggest any of the better Obfuscators being used commercially?
Thank you.
Andrew Thompson - 12 Sep 2007 08:06 GMT ...
>I'm not a hardcore JAVA Java is a word, so unlike acronyms or abbreviations, only the first letter should be Upper Case.
>..programmer though. >But why aren't the code Obfuscated? You'd have to ask them. I can give you the reasons I would avoid using obfuscation, if in their position. - Getting meaningful StackTraces is a lot more helpful for developers who need to use the API's. - If someone really wants the code, they will either reverse engineer it (despiteany obfuscation) or if that looks to be too expensive/difficult, revert to getting a bunch of people to sit down in front of the program and describe the inputs and outputs, then give that description to Java devlopers with the instruction to 'code that'.
>Above, did you intend to say that Obfuscating the code doesn't matter >to them at all? I cannot say. All I know is that generally they don't.
>Stating the issue i'm facing, I have created/used Java Wrappers around >a few API's written in C. >As a matter of Security issue, .. Who's security exactly? What is it, specifically, that you wish to prevent the end user from doing? * (e.g. Protecting the secret encryption key used to wrap up the I/O with a banking server? Preventing the user from directly accessing the C API's in ways except as clearly defined in the Java program? What..?)
>..we need to use some kind of Obfuscation >for protecting the code from being reverse engineered. Obfuscation will make it harder. *Nothing* can prevent it.
You are better to look to keeping sensitive code entirely out of the end user's VM, if at all possible, and instead offer it only through a web service.
OTOH, without knowing more details of exactly what you seem to be being very coy about*, it is hard to provide good advice.
* What is it all for?
 Signature Andrew Thompson http://www.athompson.info/andrew/
Hunter Gratzner - 12 Sep 2007 08:35 GMT > I'm not a hardcore JAVA programmer though. > But why aren't the code Obfuscated? Why should they? And please don't give us that "trade secret" thing. The majority of all code varies from bog standard code to junk code, and the only trade secret is the mediocre or disgusting code quality. It is usually the junk code authors who think they need to obfuscate, so they can hide the disgusting code quality. Another larger set of people who thing they need to hide something are the ones using stolen code, e.g. non-compliant usage of GPL code is becoming epidemic.
C code can be disassembled, Java code decompiled. The difference? Java decompilation can be done faster than C disassembly. Obfuscation slows down Java decompilation. But it does in no way prevent decompilation. A villain can still get your oh so precious code. They can get it with C code, they can get it with Java code, they can get it with obfuscated Java.
> Above, did you intend to say that Obfuscating the code doesn't matter > to them at all? I don't know what Andrew intended. In my opinion obfuscation doesn't gain you anything, except that it delays decompilation by a few days or weeks.
> Stating the issue i'm facing, I have created/used Java Wrappers around > a few API's written in C. > As a matter of Security issue, Security? Did you say SECURITY? You have no f.cking clue about security if you think obfuscation of any kind will protect your APIs. And we are not even talking about Java obfuscation here. A simple assembler debugger can reveal your oh so precious C APIs. No one would even have to look at the Java wrappers.
> we need to use some kind of Obfuscation > for protecting the code from being reverse engineered. No, you don't.
First, there is a great chance that there is objectively no secret at all in your code worth protection.
Second, in the unlikely event that there is something to hide, then you are vastly underestimating the abilities, talents, determination and resources of people being interested in it. Whether it being the proverbial lonely hacker, interested competing businesses or government agencies.
Third, your best bet for protection is the law and product quality. That first of all requires that your software adheres to the law (e.g. no usage of GPL code without releasing all source, etc.).
> Do you suggest any of the better Obfuscators being used commercially? I am not Andrew, but I don't suggest obfuscation. It is a waste of time and money. And even worse, it gives you a false sense of security.
Roedy Green - 12 Sep 2007 09:40 GMT On Wed, 12 Sep 2007 07:35:45 -0000, Hunter Gratzner <a24900@googlemail.com> wrote, quoted or indirectly quoted someone who said :
>. Obfuscation slows >down Java decompilation. But it does in no way prevent decompilation. Have a look at a disassembly of Jet natively compiled Java source code. At the very most you might have the patience to take apart a method or two. see http://mindprod.com/jgloss/jet.html
 Signature Roedy Green Canadian Mind Products The Java Glossary http://mindprod.com
Hunter Gratzner - 12 Sep 2007 11:43 GMT On Sep 12, 10:40 am, Roedy Green <see_webs...@mindprod.com.invalid> wrote:
> Have a look at a disassembly of Jet natively compiled Java source > code. At the very most you might have the patience to take apart a > method or two. First, it is not unlikely that the hypothetical trade secret is hidden in just one or two methods.
Second, hypothetically assuming I have a need for analyzing such a binary I won't do that by myself. I would shell out $100 or maybe $1000 to some coder in a low-wage country. $1000 can buy month of work there.
Andrew Thompson - 12 Sep 2007 10:54 GMT ... (OP)
>> But why aren't the code Obfuscated? > >Why should they? ...
>.. Another larger set of >people who thing they need to hide something are the ones using stolen >code, e.g. non-compliant usage of GPL code is becoming epidemic. That angle had not occured to me. I must be too 'innocent and honest' (sounds better than 'pig ignorant and clueless').
As an aside, were you referring to server side code, or code intended for the client-side?
I would imagine there was a 'swords edge' problem with using code illegally in apps., in that if the app. became widespread and well known, surely the legal owners of the code would be able to both establish and prove* that the code, even obfuscated, was ripped, wouldn't they?
Or have I vastly underestimated the power of obfuscators?
<DWS> Oh, unless of course the illegal app. was distributed with a 'no reverse engineer' caveat in the licence. That'd sure stop the legal owners from finding out. </DWS>
* To the satisfaction of a court specialised to deal with copyright/patent matters.
 Signature Andrew Thompson http://www.athompson.info/andrew/
Hunter Gratzner - 12 Sep 2007 12:40 GMT > That angle had not occured to me. Misusing GPLed code? Generally speaking, independent of what the OP is doing, GPL violations have become epidemic.
> As an aside, were you referring to server side > code, or code intended for the client-side? As I see it, number one in GPL violations are devices of Asian origin with embedded Linux. A (chip) design house creates a SoC, a reference design, and delivers a firmware SDK with some Linux exclusively for its cusomers. OEMs adapt the reference design, assemble the SoC on some mainboards and get some firmware adaptation done, often by another company. Often proprietary software is added, like device drivers. Everything has to happen fast and cheap. The boards are sold to other OEM companies. These do customisation, put the boards into an enclosure and a box. Someone imports the devices. If not branded already, someone might again customize / brand them, adds AC/DC power supplies, creates one of these fine operation instructions we all love, etc. Someone acts as reseller. Finally they end up in a shop.
Already at the second or third step no one cares about the GPL any more.
Number two is Windows software, typically produced on a budget by outsourcing companies. It is just so tempting to link in an existing library instead of writing the code from scratch. Particularly if you lack the necessary skills to implement something by your own at all. For example, very recently a well known game producer silently bundled a DOS emulator with the re-release of a classic games bundle.
Server software is usually no problem, at least not with the GPLv2. Running customized GPL software on a public server is, at least under the GPLv2, not regarded as a distribution of that software. And without the distribution on is not required to deliver the source code. I have been told that this has been partly changed with the GPLv3, but I am not a lawyer.
> I would imagine there was a 'swords edge' problem > with using code illegally in apps., in that if the app. > became widespread and well known, surely the > legal owners of the code would be able to both > establish and prove* that the code, even obfuscated, > was ripped, wouldn't they? The problem is the cost for an individual to take legal measures, particularly in foreign countries. Businesses are better equipped to protect their interest, but an individual often can only try to name and shame the violators. However, such naming and shaming often does not leave the open-source circles, so it has little impact on the public image (and sales figures) of the violators. End-users are also very insensitive to such violations. In times when "sharing" music has become a national sport it is hard to see something bad in using software that is in fact unlicensed, particular if one paid for it or for the device it powers.
> Or have I vastly underestimated the power of > obfuscators? No. There are, for example techniques developed that don't care about obfuscation when it comes to the detection of similarities in executable code http://www.st.cs.uni-sb.de/birthmarking/
> Oh, unless of course the illegal app. was distributed > with a 'no reverse engineer' caveat in the licence. > That'd sure stop the legal owners from finding out. There are countries in the world where reverse engineering for various purposes is legal and can't be restricted by a license, so that is not the biggest problem. And IMHO the above cited birthmarking is not reverse engineering in my book, but IANAL.
Andrew Thompson - 17 Sep 2007 02:39 GMT (A.T.)
>> ...have I vastly underestimated the power of >> obfuscators? > >No. There are, for example techniques developed that don't care about >obfuscation when it comes to the detection of similarities in >executable code http://www.st.cs.uni-sb.de/birthmarking/ That* reminds me to note that the figures shown, seem to support that even an obfuscated app. could be easily recognised.
* Or rather, Arne's follow-up to another part of the thread.
 Signature Andrew Thompson http://www.athompson.info/andrew/
Arne Vajhøj - 17 Sep 2007 01:22 GMT >> How are commercial Java softwares released by Oracle, Sun, etc? >> What Java Obfuscators are used by the commercial Java products? > > Judging by the StackTraces returned for most Java API's, > I am guessing that few, if any of them, are obfuscated. It is obviously never used in any of the open source stuff and that count for a lot of Java code.
But I have seen it frequently in commercial code from Borland, IBM etc..
Arne
Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
|
|