Discussions

News: Obfuscation and Java

  1. Obfuscation and Java (81 messages)

    Paul Tyma discusses the world of Obfuscation (not just what a Perl hacker does in a long one-liner), and how it fits into the Java world. He discusses code manglers, encrpyting Strings, the future, and whether it is even worth it.

    How many of you use obfuscators?

    The New Obfuscation

    Threaded Messages (81)

  2. This old saw.[ Go to top ]

    The old saw of obfuscation comes up time and time again on the Java forums. My advice is always "don't bother."

    http://www.google.com/search?q=site%3Aforums.java.sun.com+obfuscation

    Here's the key thing that I note on 99 out of 100 of those occasions: The person worried about how they can protect their code from decompilation is new to Java, and often new to programming. Often the worlds of spelling and grammer are pretty new to them too.

    You can reverse engineer any code if you have the time and access to the code. Obfuscation doesn't change that - it makes it trivially harder, that's all.

    If your code is so super-duper top secret that it's worth preserving, sell it as a web service; nothing else will keep it safe (and maybe not even that).

    But there are a lot more people out there who think their code is worth of theft than there are people inclined to steal it. And for that tiny subset, the binary (obfuscated or not) is probably just as useful as the source code.

    Dave.
  3. Re: This old saw[ Go to top ]

    You can reverse engineer any code if you have the time and access to the code. Obfuscation doesn't change that - it makes it trivially harder, that's all.

    Trvially harder?! If you think that the difference between unobfuscated and obfuscated code is trivial, then please send me your resume. You must be some sort of genius!
    Often the worlds of spelling and grammer are pretty new to them too.
    Of course, your misspelling of grammar is ironic, right?!
  4. Trivially harder.[ Go to top ]

    Yes, I spotted my mis-spelling after I clicked the submit button, boy do I look a schmuck. I claim I've been corrupted by the web (I caught myself typing "their" instead of "they're" the other day).

    I'll admit that "trivially" is perhaps a bit of a troll, but I honestly don't consider it to be more than an order of magnitude harder.

    In the end my beef is not with the obfscation tools (more power to the elbows of those who spotted a market), but the perceived need for them.

    I have never met anyone who actually *needed* obfuscation - yet I *have* worked on projects where the algorithms were intensely valuable trade secrets.

    So who are these people who *need* it, rather than *thinking* they need it?

    Dave.
  5. Re: This old saw[ Go to top ]

    Trvially harder?! If you think that the difference between unobfuscated and obfuscated code is trivial, then please send me your resume. You must be some sort of genius!

    Sure, 'trivial' is about right, especially if all you want to do is remove some license key restriction.

    I have decompiled and 'cracked' obfuscated java just to test the security (before anyone calls FACT, I have a paid up license for the software in question). It really isnt that difficult with a little perseverance (people crack disassembled binaries all the time and IMHO this is MUCH harder). Infact, I found this task to be easier than deciphering some of the non-obfuscated code I have seen, at least with obfuscated code you can expect the variable names to be meaningless.

    As always, the security of obfuscation is relative to the cost of the software. For a $10 piece of shareware its probably good enough, but if the software costs thousands, then there is an incentive!
  6. Marginal profit.[ Go to top ]

    For a $10 piece of shareware its probably good enough, but if the software costs thousands, then there is an incentive!

    The offering from PreEmptive Solutions is just shy of $400. At $10 that means that 40 people must be stealing your software and not interested enough to de-obfuscate it for it to be worth bothering.

    And that's making a lot of assumptions that are favourable to the obfuscation software - amongst them that "stolen" software is never going to make you money, and that the cost of the software is related to the likelihood of a crack being developed.

    Since I personally have bought quite a few bits of software that I tried out as cracked copies (the Nero ROM burning software being the latest), I'm doubtful about the value of that assumption.

    Dave.
  7. Re: This old saw[ Go to top ]

    Trvially harder?!

    For the trees, yes it is only trivially harder. For the forest, it helps to have the original identifiers. On the other hand, it is always difficult to understand the big picture of an application without the help of documentation and the originating engineers.

    God bless,
    -Toby Reyelts
  8. This old saw.[ Go to top ]

    You can reverse engineer any code if you have the time and access to the code.
    The key here is time. 99% of the people wouldnt have the time to do that. So obfuscation protects ur code from them.
    If your code is so super-duper top secret that it's worth preserving
    why wud u want somebody to hack away the license key to ur product. it wud be nice to make it tough for atleast 99% of the people.
  9. The mythical 99%[ Go to top ]

    The key here is time. 99% of the people wouldnt have the time to do that. So obfuscation protects ur code from them.
    why wud u want somebody to hack away the license key to ur product. it wud be nice to make it tough for atleast 99% of the people.

    Yet again, I don't understand the reasoning here. Who are these hypothetical people who're smart enough to dis-assemble, alter, and re-compile a class file, but aren't smart enough to go the extra step and de-obfuscate it?

    They're not 99% of the people I know - 100% of the people I know fall into the "don't care enough to crack it", or the "could crack it in their sleep" categories.

    Dave.
  10. The mythical 99%[ Go to top ]

    They're not 99% of the people I know - 100% of the people I know fall into the "don't care enough to crack it", or the "could crack it in their sleep" categories.Dave.
    I see no meaning to crack software, there are a few GB of source code on SF.
  11. The mythical 99%[ Go to top ]

    Encyption and obfuscation are both attempts to make stealing something cost more than paying for it.

    A very small percentage of people are both cabible and interested enough to do it. The problem is, all you need is one person. A much larger portion of the population is willing to download a crack.
  12. OK here is a subject I know WAY too much about. I was at one point in my life a co-founder of a Java DRM company. Clearly encryption and obfuscation were of prime interest to us!

    People have tried security through obscurity for centuries. It doesn’t work. Simple as that. As has been pointed out here.... There are plenty of lonely people willing to muck through whatever level of obscurity you provide to find that one golden line of code that disables whatever check they are providing. In the end.... it’s simply lame.

    Unfortunately, thanks to some quite serious core security muck ups in Java's runtime it doesn’t matter if you do obscurity, encryption, anti-tampering or volcan mind melding, the VM itself is the weakest link.

    For instance, were you aware that the VM does now runtime validation of the rt.jar classes to assure they werent tampered with? Yup. None what so ever. Go ahead. Recompile Boolean.java and change true to false and false to true. Now replace it in rt.jar and have some fun!

    Now this seems pretty innocent. But it gets ugly fast. What if you rewrite the root classloaders? What if you rewrite the SecureClassloaders to ignore the SHA-1 hashes in the signed JARS (hacking them is much simplier but...) what if you rewrite the Exception class to muck with the call stacks, or leave a Trojan horse inside of rt.jar to spit out encryption keys used to encrypt license files..... What about random seeds, passwords, obfuscation algorithms, your childhood friend under the bed.

    In every security stack the weakness is the top of that stack. Why attack an encrypted license file when you can simply remove the offending line.

    The worrisome part is the top of this stack is the VM. And at heart, its doing no runtime checking of its own loaded classes to be sure they aren’t trojaned. That’s a huge problem. If you have an app running on a VM, how do you know that VM isnt tampered with? SUN doesn’t publish secure hashes of the rt.jar. You could have a trojaned rt.jar right now and have NO idea.

    I would stop worrying about obfuscating your code and start worrying about who is keeping Java it self secure......

    Dave Wolf
    Cynergy Systems
  13. Java DRM[ Go to top ]

    Unfortunately, thanks to some quite serious core security muck ups in Java's runtime

    The whole premise of this post seems way off base to me. It is IMPOSSIBLE to develop client-side software alone that can not be hacked. That is what TCPA is all about. You have to run specialized hardware together with a specialized operating system that prevents users from reading and writing arbitrary memory locations.

    I haven't delved deeply into TCPA, but it seems likely that you should be able to emulate TCPA hardware on a non-TCPA platform, which would then allow you to crack all the software depending upon TCPA guarantees. As an example, a user could run a slightly-modified version of Bochs on a non-TCPA motherboard, and your software will be just as insecure as it was pre-TCPA.

    I can tell you another thing too - TCPA as "trusted computing" is an absolute joke. TCPA is precisely about a lack of trust of the consumer, and you won't find me paying money to purchase hardware that actively limits the software I can execute.

    God bless,
    -Toby Reyelts
  14. Unfortunately, thanks to some quite serious core security muck ups in Java's runtime

    Dave,

    Offtopic, but would you care to elaborate ?

    Thanks
    Rohit
  15. You're aware that it was "David Wolf", not me that said that, yes?

    Personally I think that his assessment is 100% wrong.

    Dave.
  16. The mythical 99%[ Go to top ]

    (1) If you are making consumer software and worth anything, someone on the Net would crack it, no matter what protection you use.
    (2) If you are making business software, what protects you is your lawyer plus your CEO's marketing skills.
    (3) No matter what you are making, some open source project would pop up, mimicking your ideas and coming with a better implementation than yours.
    (4) Your software is typically worth much less than you think it should. ;-(
  17. The mythical 99%[ Go to top ]

    (1) If you are making consumer software and worth anything, someone on the Net would crack it, no matter what protection you use.

    I have used a lot of cracked software. And there have been a lot of applications where I have not been able to find a working crack anywhere. What a surprise in these times, when everything and more is on the net. So I had to purchase the software.

    It is not about whether it can be cracked. It is about whether the protection can be made good enough so that the amount of people willing to crack it falls below a critical level. Sure, some chinese dude cracks it and puts the key on his FTP, but good protection can (in a good scenario) avoid 80% of your losses from piracy.
  18. The mythical 99%[ Go to top ]

    I have used a lot of cracked software. And there have been a lot of applications where I have not been able to find a working crack anywhere. What a surprise in these times, when everything and more is on the net. So I had to purchase the software.

    But was the software obfuscated? How do you know that obfuscation was the reason why a crack did not exist?

    Unless you personally are the sort of person who would have tried decompiling the software to crack it, AND it's written in Java, AND you couldn't purely because it was obfuscated, then this doesn't add anything to the tally in favour of obfuscation software.

    And if you were all of these things, how much did the software cost? Unless it was more than the cost of the obfuscation software, you don't in yourself justify the expense - if it was, say, $40, then ten more people exactly like you are required before a $400 outlay on protecting this software is justified.

    And even then it's pointless if there's an eleventh person otherwise like you who CAN crack the obfuscation.

    Dave.
  19. The mythical 99%[ Go to top ]

    But was the software obfuscated? How do you know that obfuscation was the reason why a crack did not exist?

    Dunno. My point was not that _obfuscation_ made me buy the software. The posting which I replied to said that there's always someone who's going to crack the software. My point was that sure there's going to be, but that's not the issue. As long as cracking is hard enough, the developer can avoid most of his losses.

    So it's not about whether it CAN be cracked, but HOW EASILY it can be cracked.
  20. The mythical 99%[ Go to top ]

    The posting which I replied to said that there's always someone who's going to crack the software.

    Not quite - my point is that there is a VERY small group of people who might want to crack the software, know enough to use the tool, and don't know enough to de-obfuscate the code.

    A little illustration (hope this survives the posting):

    {------------A---...------}{-B-}{----C----}

    A. Group who don't know enough to crack anything.
    B. Group who know how to crack plainly compiled code only.
    C. Group who know how to crack anything.

    My point is that group B is tiny compared with groups A and C, and that you need only one (or at least, very few) person in group C before it's available to all three groups.

    Suppose 99% of people are in group A, 0.9% are in group C, and 0.1% are in group B. Suppose you sell 1000 copies.

    We expect 990 people in group A to want it, 9 in group C to want it, and only 1 in group B to want it. But if any of the 9 people in group C release their crack it's available to all 1000.

    Targetting your resources to defeating group B is therefore a waste of time.

    Dave.
  21. The mythical 99%[ Go to top ]

    Oh, and if anyone wants to argue the point - the weak point is my contention about the relative ratios of groups A,B, and C. This is my anecdotal opinion; if you can point me at some specific research proving otherwise, I'll revise my opinion.

    Dave.
  22. The mythical 99%[ Go to top ]

    The posting which I replied to said that there's always someone who's going to crack the software.
    Not quite - my point is that there is a VERY small group of people who might want to crack the software, know enough to use the tool, and don't know enough to de-obfuscate the code.

    Sure - by the way, I was replying to a post by "Hacking Bear", not you. I am not sure if you though that I was replying to you, but anyways.

    {------------A---...------}{-B-}{----C----}
    But if any of the 9 people in group C release their crack it's available to all 1000.Targetting your resources to defeating group B is therefore a waste of time.

    I think a couple of your assumptions are not 100% valid:

    - You assume that attempts to defeat group C are worthless. I do not think so. They might be able to crack well obfuscated code, but it will take them more time, and they might have some other applications to crack, might get bored with reading the obfuscated crap, or migh have some nice TV shows to watch. (Of course, some might enjoy the challenge) Even if "group C" were able to crack it, copy protection can have an effect on how many will have the patience to do it.
    - You assume that once 1 out of group C cracks it, it becomes available to all 1000. That is not the case - probably all software has been cracked, but when a John Doe tries to find a working crack for a given version, there's a high likelihood that it won't be easy to find. Sure, if you belong to "inner circle" of people who know where to look for, you'll find it....but 95% of people will have hard time googling, be attacked by kazillions of porn popups and start to have second thoughts about purchasing the valid license. The harder the protection, the poorer the availability of cracks (or the longer it takes for the cracks to be released).

    I just seem to think that this is not a black/white issue, and even a non-perfect solution can be worthwhile.
  23. The mythical 99%[ Go to top ]

    There's some nit-picking to be had about the precise definition of these groups (i.e., group B could equally be "unable to unobfuscate but disinclined to do so"), but otherwise my model holds.

    So it really amounts to an attack on the relevant proportions of the three groups - which I readily admit to be unscientific. This is just my assessment of the likely proportions of these people given the technical competence of people I meet and my own skillset.

    I reckon I could crack most obfuscation schemes with very little effort, and I reckon I'm probably slightly below average in competence. So probably most technical able people fall into groups A or C. In my opinion.

    Now, show me some good research that refutes that and I'll likely revise those opinions - but I've not seen anything indicative as yet.

    Dave.
  24. The mythical 99%[ Go to top ]

    Although actually, of course, I fall into group A because I really could never be bothered to crack software.

    I'll certainly download cracked software to give it a spin. But then if I continue to use that software I buy it, and I suspect that's pretty common.
  25. The mythical 99%[ Go to top ]

    The posting which I replied to said that there's always someone who's going to crack the software. My point was that sure there's going to be, but that's not the issue.

    My points in the original posting is that if cracking is not an issue, then it must be covered by point (2), (3), or (4).

    By the way, in software, most of the time, what people need is to stealing the main idea and not the actual codes. For example, MS needed not to have the sourc code to the orignal MaxOS to duplicate the window desktop UI design. This becomes even more of a problem as the state of programming tools and design methodologies (like OO patterns) have evolved a lot than at the time of Win 1.0. In fact, the late comer could often have better implementation since the requirements become much clearer.

    This is also why software patent is important still.

    And in the end what protects the "first mover" is the "first mover" marketing advantage. Failing to take that advantage, as in the case of Netscape, you are doomed as well.
  26. The mythical 99%[ Go to top ]

    I have used a lot of cracked software.
    Have you ever saw cracked JAVA application ?

    BTW setup linux, there are many free applications with source code and you will not need to use any cracked software. I have never saw cracked software for linux, there are more free applications than I need.
  27. Obfuscation and Java[ Go to top ]

    if your going to obfuscate for some reason use one that changes class names to illegal names.
    it can be decompiled like any other class but compiling the code again is another matter. you would have to refactor the code manually since no compiler can compile it and and no ide that i know of can refactor it. or you would have to change the code you want direct in the bytecode with becl or something like it.
    but if someone have time enough all code can be decompiled and make sense to the reader.
    another thing is that they are nice to minimize jar size with.
  28. Obfuscation and Java[ Go to top ]

    FWIW Obfuscation has a few other benefits, including massive reduction in JAR size (depending on the obfuscator, of course.) So for an applet, it might make very good sense for a reason like this.

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Shared Memories for J2EE Clusters
  29. Shrinking code size.[ Go to top ]

    If you want to shrink code size (and you're not prematurely optimising), use a tool for that purpose.

    If your obfuscator can be tuned to do that, that's fine, but in that case it's a code shrinker too, and that's what you're using it as, not an obfuscator.

    Don't think of an obfuscator as a tool for code shrinkage just because it might *coincidentally* have that function.

    There's some overlap between the two tool types - but that doesn't make either an argument in favour of the other.

    Dave.
  30. I use, I like[ Go to top ]

    I've used the open-source Proguard package to obfuscate code for a client-side app. It's a piece of cake to integrate into an Ant build.

    Of course if it's a top secret algorithm you're positive that you need to protect, obfuscation is not the answer - you probably need to run it on a server only. And as for protecting somebody cracking the licence key, I can see that obfuscation isn't going to a silver bullet (although it would make it a little harder).

    However, obfuscated code is a great deterrent to, say, the rival company that wants to have a look at the inner workings of your desktop app. When every package, class, method and variable has a name like a, b or c, it would take forever to make sense of decompiled code. Obfuscation is particularly appealing when the package / class / method / variable names in the source make it very clear what the code is doing.
  31. And as for protecting somebody cracking the licence key, I can see that obfuscation isn't going to a silver bullet (although it would make it a little harder).

    As someone else pointed out elsewhere in this thread: It only takes one person to crack the license key. I'm not sure if that argument was supposed to be for or against, but to my mind it's against.
    However, obfuscated code is a great deterrent to, say, the rival company that wants to have a look at the inner workings of your desktop app. When every package, class, method and variable has a name like a, b or c, it would take forever to make sense of decompiled code.

    You know, that really isn't true. Context is everything - I do crosswords, and the first five clues are the buggers; once you've got them filled in, the rest just flow. Figure out what the first dozen variables and classes should be called, and the rest will just slot straight into place.

    And again, we've got this myth of the person, in this case a rival company, that's really interested, to the point that they try to decompile your code, in trying to reverse engineer your code - but they apparently aren't bright enough to take it the extra step.

    I just don't believe in this group of people who, like a Bond villain, are smart but not quite smart enough.

    Dave.
  32. Re: the licence key - yes, obfuscation is unlikely to add any significant extra protection against somebody cracking it.

    I disagree with you on the second point, however. The app I'm talking about has around 50,000 lines of code spread across several thousand class files. It's by no means a trivial matter to figure out how the code is structured, even with the source, the JavaDocs, and somebody to explain it.

    Sure, the mythical Bond villain from a rival company could easily decompile the code. Sure, if they had a LOT of patience and time they could work through the resulting source, making sense of it step by step. After all this effort they might be able to take some ideas from the design, perhaps rip off a couple of the core packages directly.

    But why would they bother going to such lengths? Like, I suspect, most applications, there's nothing revolutionary inside... it would make more sense for the rival company to spend their time building a new and improved rival application from scratch!

    So, for me, obfuscation is about raising the barrier of entry to the point where nobody in their right mind would be bothered to even try to make sense of the source.

    To throw in a little modesty: quite possibly the 'rival company' doesn't even exist and the chances of anybody wanting to decompile the code are slim to none. But knowing that the source code is obfuscated takes a weight off my mind, and it certainly seems to keep management types happier to know that we've made at least some effort to protect the source.
  33. I disagree with you on the second point, however. The app I'm talking about has around 50,000 lines of code spread across several thousand class files.

    But you're positing a competitor who really wants to steal your code. It's not as trivial as "mere" decompilation, but it's perfectly do-able, if time consuming.

    If the choice is between spending two months coding up an equivalent, or two weeks undoing the obfuscation (and we're mooting a competitor who has no qualms about the ethics of this) why do you think the obfuscation will stop them?

    What are the extraordinary circumstances where the two weeks really buys you anything?

    And if the code isn't going to take your competitors only a couple of months to write from scratch, is it really worth bothering? And spending the money on the obfuscation software? And taking the performance hit? And working around reflection issues?

    And the longer it would take your competitor to rewrite the software from scratch, the bigger the incentive they have to reverse engineer it!
    It's by no means a trivial matter to figure out how the code is structured, even with the source, the JavaDocs, and somebody to explain it.

    I'm sorry, but I just don't agree. That's something I do pretty often, and I've never found it terribly hard. Boring, but not difficult.

    Dave.
  34. If the choice is between spending two months coding up an equivalent, or two weeks undoing the obfuscation (and we're mooting a competitor who has no qualms about the ethics of this) why do you think the obfuscation will stop them?

    But if a competitor decompiled the source, and de-obfuscated it so that it made sense, they'd have an application that looked and behaved exactly the same as mine! Copyright would be rather helpful here and there'd be no way that they could legally market it.

    All the competitor would realistically be able to do would be to take ideas from the source, or perhaps steal a couple of the inner packages.
    What are the extraordinary circumstances where the two weeks really buys you anything?

    For the sake of argument, I'll assume that you're are correct about the timescale. Integrating obfuscation into the build took under a day, so that's pretty good going!
    And spending the money on the obfuscation software?

    Proguard is open-source and free.
    And taking the performance hit?

    AFAIK there isn't any, outside of the build process.
    And working around reflection issues?

    True, but it's pretty straightforward to configure in an ant script.
    I'm sorry, but I just don't agree. That's something I do pretty often, and I've never found it terribly hard. Boring, but not difficult.Dave.

    Does this make you the mythical Bond villain? ;-)

    I don't doubt that you'd be able to, but I do doubt that the gains would make it worthwhile, especially considering my copyright point above.
  35. Bear in mind that I don't doubt that obfuscation does "work" in that it makes it somewhat harder to decompile software.

    But that the people who would decompile software in the first place will probably make the extra effort to deobfuscate it.

    And that's the only reason I think that obfuscation is pointless.

    Now,
    But if a competitor decompiled the source, and de-obfuscated it so that it made sense, they'd have an application that looked and behaved exactly the same as mine! Copyright would be rather helpful here and there'd be no way that they could legally market it.

    I absolutely agree. But this is also the same true if the code is not obfuscated. I consider copyright to be of much greater value than obfuscation software. And it's free too!
    All the competitor would realistically be able to do would be to take ideas from the source, or perhaps steal a couple of the inner packages.

    True. And they're either pretty easy to write yourself, or they're really hard and valuable.
    For the sake of argument, I'll assume that you're are correct about the timescale. Integrating obfuscation into the build took under a day, so that's pretty good going!

    I assume you mean "integrating obfuscated code" into the build - but apparently we're talking about only a few ideas, or some key inner packages, remember? So yep, under a day seems reasonable.
    Proguard is open-source and free.

    Fine by me, use it if it makes you happy. Personally I think it's a waste of time (time is money) - but this article is written by someone who sells obfuscation software remember.
    AFAIK there isn't any, outside of the build process.

    They can interfere with the JIT compilation process, as noted in other threads here, but fair enough, if you're not feeling the pain that's something you can disregard.
    And working around reflection issues?
    True, but it's pretty straightforward to configure in an ant script.

    Ok, but that's more time spent messing around with the build to me.
    Does this make you the mythical Bond villain?

    So, Meeeeester Bond. You have my secret. But I have yours (bwah ha ha).
    I don't doubt that you'd be able to, but I do doubt that the gains would make it worthwhile, especially considering my copyright point above.

    Thanks for the faith in me and my evil cohorts, but I think that exactly the same point applies to un-obfuscated software.

    Dave.
  36. One possible answer?[ Go to top ]

    But if a competitor decompiled the source, and de-obfuscated it so that it made sense, they'd have an application that looked and behaved exactly the same as mine! Copyright would be rather helpful here and there'd be no way that they could legally market it.
    I

    You know, it occurs to me that this is a possible rebuttal to my argument - the one group of people who would find some true value in obfuscation software are the people who have stolen someone else's code.

    It's going to be a lot harder to prove the relationship between the two pieces of code after the control flow, variable, method, and class names have been changed.

    :-)

    Dave.
  37. I don't think obfuscation can be generalized as good or bad, it's all really a case of "various shades of grey", and "how long is a piece of string?" etc. etc.

    I don't believe that anything in the world can realistically make the source code of a client side Java app truly secure. There is no silver bullet.

    Decompiling un-obfuscated code is trivial, whilst making sense of decompiled, obfuscated code is undeniably harder (I suspect orders of magnitude harder in many cases). And for anyone to want to do it, the benefits have to outweigh the time input required.

    Whether or not it's a good idea to obfuscate depends on a million and one factors that can't be generalized from one application to another. Which is where the shades of grey come in, and of course the length of a piece of string.

    Personally, I'd prefer it if the army of Bond villains spent their time struggling to make sense of my obfuscated code, rather than building newer and better features to put into their own rival app - I think that focusing their energies towards de-obfuscation would be far less productive. However, I think that if the code wasn't obfuscated, those unethical villains could certainly gain from decompilation, and it would be worth the minimal time input required.
  38. I shall now digres.

    A phrase you used that stands out is "No Silver Bullet". Now, it is perhaps not as common knowledge as it should be, but a Silver Bullet in the computer science sense is precisely a tool which aids in solving that problem by an order of magnitude.

    In the original context, the search for a silver bullet for developing software, the point was made that merely writing the code was a task which took up a relatively small part of the project development lifecycle. As a result, even if a tool could reduce the time spent writing code to zero it wouldn't achieve an order of magnitude improvement in the total development time!

    4GLs are the archetypal tool claiming, but failing, to be a silver bullet.

    So, if you believe that obfuscation adds an order of magnitude of difficulty to the task, then it's a silver bullet.

    Anyway, addressing your actual point:
    Whether or not it's a good idea to obfuscate depends on a million and one factors that can't be generalized from one application to another. Which is where the shades of grey come in, and of course the length of a piece of string.

    Maybe. My assessment is that there are very few circumstances where obfuscation gives a real benefit in return for the investment of time and money and the potential disadvantages.

    Show me research that contradicts that and I'll reconsider.

    Personally, I'd prefer it if the army of Bond villains spent their time struggling to make sense of my obfuscated code, rather than building newer and better features to put into their own rival app

    Wouldn't your time be better spent improving your app to be more solid, featureful, and just generally spiffy than that of your competition. After all, if they're not trying to de-obfuscate your code, you're wasting time while they catch up...

    Dave.
  39. I remember that Sun's JSSE is obfucated. Why don't you show us how easy is to de-obfuscate under 1MB code and post the sources anonymously somewhere on the net.

    Maybe try to optimize their code base a little and smash some ugly bugs over the dinner. What do u say?

    Regards,
    Horia
  40. Thanks for the definition of silver bullet, I wasn't aware of that. What I way really trying to say is that the source of a client-side app can never be 100% secure.
    Wouldn't your time be better spent improving your app to be more solid, featureful, and just generally spiffy than that of your competition. After all, if they're not trying to de-obfuscate your code, you're wasting time while they catch up...

    The extra time / cost that goes into setting up and maintining obfuscation is clearly one of the million and one factors that need to be taken into account when deciding whether it's worth obfuscating at all.

    In my case the time input has been minimal. The actual benefits resulting from obfuscation would be hard to quantify, perhaps impossible as there are so many unknown factors involved (not least the phsychology of the 'rivals').

    But I'd argue that the minimal time input that's gone into the obfuscation of my code has been worth it for peace of mind alone. Which is another factor that can't really be quantified...

    Possibly it's the forums I should worry about, not the obfuscation ;-)
  41. But I'd argue that the minimal time input that's gone into the obfuscation of my code has been worth it for peace of mind alone. Which is another factor that can't really be quantified...
    How much is your peace of mind worth if it's misplaced?

    Ok, ok, I get the point, and I'm belabouring mine.

    Dave.
  42. Management Types[ Go to top ]

    ...keep management types happier to know that we've made at least some effort to protect the source

    And here's where I have a bit of a problem with obfuscation software. The people who buy it seem to be the uninformed - and in my opinion it's a complete WOMBAT (Waste Of Money, Brains, And Time).

    I think it also has some risks associated with it - are you sure your management understand the distinction between "obfuscated" and "truly secure"?

    Dave.
  43. I use, I like[ Go to top ]

    Have you ever try to decompile something that was obfuscated with Proguard? it's pretty week compared to say zkm, that does flow obfuscation and encodes strings. Still zkm can be defeated if you're persistent but it took me an entire day once
  44. I use, I like[ Go to top ]

    You shouldn't write code that is easy to read in the first place :)
  45. Proguard[ Go to top ]

    I've not actually tried to decompile anything obfuscated by Proguard, just knowing that it changes the class, method and variable names makes me satisfied that it does enough for my purposes.

    I'm wary of introducing flow obfuscation - no sound basis for this, just the thought of it introducing subtle bugs gets me worried!
  46. I use obfuscation and encryption for my java projects to offset the security issues associated with bytecode. In J2ME you can't even encrypt so obfuscation is the only way. It's not just about people taking your code it's also about code security. Obfuscation also makes it harder for people to find weaknesses in your code. I think it comes with several benefits. Especially with respect to countries that don't respect IP. Not that I respect IP law that puts people in jail and drives down small business (Not enough $ for lawyers and a lack of legal knowledge), but like the American populace I pay for most of my software. Unlike India, China, Russia, Poland, and many more. Information will eventually be free one way or another so I think is a losing battle to have IP law. Just make taking your IP more costly than paying for the product and you won't have any serious problems. Obfuscation and encryption helps increase the cost of others trying to compete against you.

    I predict that after the next World War (The Bloodiest War not the end) which I feel has already started IP law will go away anyways. Just look at how India, China, Russia, Poland, and others are catching up tech wise. Japan has shown America what happens when other countries copy our business processes and build on them. If we don’t wake up soon we will be a third world country tech wise with Australia and a few others as our only crumbling IP partners.

    I can compete with Indian engineers in America, but not with Indian engineers in India. How stupid is that? I work my butt off while they profit from it and have more earning power than I do (22k =~ 130K). They might start with bombing Bangalore, Beijing, Hong Kong, and Moscow to marginally counter act the theft from engineers and scientist in IP countries. They will not rid themselves of IP law or subsidize their engineers and scientist. Either give engineers and scientist a chance or both sides will lose millions. Non IP countries attract talent because of better pay while IP countries turn them away. Just look at the number of engineers per capita being generated by India and China. Not only that, but they attract the smarter people unlike in the U.S.. Indian computer scientist make 10 times more than the average person in India while in America the average Restaurant Manager make about the same as a computer scientist.

    Whups. Sorry kind of got off topic towards the end. LOL.
  47. I'm going to paraphrase you, very rudely, as:
    Blah, blah, blah, foreigners are all more dishonest than "us", and they're going to take away our jobs

    So what?

    Let's assume that Indians, Chinese, Canadians, Limeys, the Irish, Spaniards, and anyone with a, you know, funny accent, is just plain born criminal.

    Are you calling them stupid too?

    If they can crack the obfuscation, what's the point in using it?

    It comes down to the fact that the overlap between software that's valuable enough to protect AND which has an audience both smart enough to try to decompile it BUT who are stupid enough not to be able to decompile it is, I would posit, so small as to be invisible.

    There's a market for the software because more people have a faith in the value of their own product than give credit to the hypothetical people who might want to steal it.

    Dave.
  48. IP yellow[ Go to top ]

    I'm going to paraphrase you, very rudely, as: Blah, blah, blah, foreigners are all more dishonest than "us", and they're going to take away our jobs
    So what?

    What do you mean so what?

    I think you trivialize the lives of millions of Americans, Canadians, Some Europeans (EU), and others that work hard and only have the skill to become an engineer or scientist. Not everyone wants to become an MBA/Manager/CEO/CFO/CIO... Some people actually want to create something new and different, and they don't all live in protectionist economies with false exchange rate set by governments and not by marke..
    Let's assume that Indians, Chinese, Canadians, Limeys, the Irish, Spaniards, and anyone with a, you know, funny accent, is just plain born criminal.Are you calling them stupid too?

    Not at all. Nothing I said had anything to do with what I feel is criminal activity or stupidity except by governments on both side. One government controlled exchange rates. Two so-called government protected IP rights (Rich people with lawyers).
    If they can crack the obfuscation, what's the point in using it?

    To increase the cost/time of hackers and copy artist.
    It comes down to the fact that the overlap between software that's valuable enough to protect AND which has an audience both smart enough to try to decompile it BUT who are stupid enough not to be able to decompile it is, I would posit, so small as to be invisible.There's a market for the software because more people have a faith in the value of their own product than give credit to the hypothetical people who might want to steal it.Dave.

    No. Good grief. Its not just about copy artist as I stated in my previous post. Nothing new anywhere, not that I expected otherwise. :)
  49. IP yellow[ Go to top ]

    I think you trivialize the lives of millions of Americans, Canadians, Some Europeans (EU), and others that work hard and only have the skill to become an engineer or scientist. Not everyone wants to become an MBA/Manager/CEO/CFO/CIO... Some people actually want to create something new and different, and they don't all live in protectionist economies with false exchange rate set by governments and not by marke..

    Then where do you come from, the moon? The EU operates all manner of protectionist strategies. So does the US. So does Canada. Sure, they have some mutual agreements, and we even have the WTO where there's some effort to keep the barriers to trade lowered, but pointing the finger rather vaguely at wherever it is you *are* pointing it doesn't prove a thing.

    And, I might add, most people, regardless of where they come from, want to create something "new and different" and to blindly accuse other nations of blind mercenary instinct sounds, in a word, racist.

    I think *you* trivialise the lives of people all over the world who don't consider life without a TV to be poverty.

    Dave.
  50. IP Equality[ Go to top ]

    I think you trivialize the lives of millions of Americans, Canadians, Some Europeans (EU), and others that work hard and only have the skill to become an engineer or scientist. Not everyone wants to become an MBA/Manager/CEO/CFO/CIO... Some people actually want to create something new and different, and they don't all live in protectionist economies with false exchange rate set by governments and not by marke..
    Then where do you come from, the moon? The EU operates all manner of protectionist strategies. So does the US. So does Canada. Sure, they have some mutual agreements, and we even have the WTO where there's some effort to keep the barriers to trade lowered, but pointing the finger rather vaguely at wherever it is you *are* pointing it doesn't prove a thing.And, I might add, most people, regardless of where they come from, want to create something "new and different" and to blindly accuse other nations of blind mercenary instinct sounds, in a word, racist.I think *you* trivialise the lives of people all over the world who don't consider life without a TV to be poverty.Dave.

    I did not say anything that contradicts your statement regarding protectionism by the US, EU, or Canada. They just have different protections. That does not mean that the US protects the non government scientist and engineers like India, China, and others do with false exchange rates. Much of the US protections are in farming. That does not help any engineer or scientist.

    I did not say anything about others not wanting to create. In fact I said the opposite. Please read before you post.

    No, you trivialize the store value of work in money and thus the lives of people. Poverty is in the eye of the beholder not a set value. It is a poor term that socialist, fascist, and communist use to steal.
  51. IP Equality[ Go to top ]

    Poverty is in the eye of the beholder not a set value. It is a poor term that socialist, fascist, and communist use to steal.

    Poverty is when you don't have enough money to eat or buy clothes.
  52. IP Equality[ Go to top ]

    Poverty is in the eye of the beholder not a set value. It is a poor term that socialist, fascist, and communist use to steal.
    Poverty is when you don't have enough money to eat or buy clothes.

    How much clothing and food are you talking about? :) LOL

    I like what you say, but your just plain wrong.

    Grow up and realize the pain and suffering of a mind that must flip burgers, but wants to build an AI to flip the burgers instead. I would prefer to live without food or clothes instead if I must be enslaved. Freedom Comes At A Price. The U.S. is no longer free.
  53. what?[ Go to top ]

    travis,
    some remarks on ur comment. just continuing the trend u started:

    <quote>
    I work my butt off while they profit from it and have more earning power than I do (22k =~ 130K)
    </quote>

    im flattered to know that. be my guest, get settled in india and enjoy the "better earning power" here. to tell u as a matter of fact, software here is much more expensive if u consider the PPP.

    <quote>
    Indian computer scientist make 10 times more than the average person in India while in America the average Restaurant Manager make about the same as a computer scientist.
    </quote>

    that is coz indian "average person" earns much less than US perhaps. wrong comparison here.

    <quote>
    Much of the US protections are in farming. That does not help any engineer or scientist.
    </quote>
    <quote>
    They might start with bombing Bangalore, Beijing, Hong Kong, and Moscow to marginally counter act the theft from engineers and scientist in IP countries.
    </quote>

    sheer xenophobia i must say. u must be a very frustated soul to suggest extreme measures of that sort. anyways, i wonder what do u eat? hope not software. ultimately the protections from "lower end" gets exaggerated on higher levels. i think food subsidies are much more harmful, but that would be starting a new debate. IP laws -yes,india mgt need to mend things a lot, at the same time, remember most of the P2P stuff actually originates in US. not that P2P is bad in any sense, but we all know its role as far as illegal software (and i include all sorts here) is concerned.
    and there are deficiences everywhere. remember US firms patenting traditional indian herbs, which are used for ages here.

    <quote>
    That does not mean that the US protects the non government scientist and engineers like India, China, and others do with false exchange rates.
    </quote>

    dont generalize.in context of india, i would be glad to hear from u what u mean by false exchange rates?

    there is nothing black and white in this world. somewhere down the line US is also benefitting greatly from the indians, chinese and others. believe me, its not charity that many US companies employ indians/chinese etc.i would love to see TSS threads focus on technical things more than involved in fanatical discussions.

    to borrow from purdy, peace :-)
  54. Japan has shown America what happens when other countries copy our business processes and build on them.
    Do you really think that Japan prospered because they copied american business processes? Heh. The kanban is surely an English word. And whom did Saturn copied its business processes from?
  55. Japan has shown America what happens when other countries copy our business processes and build on them.
    Do you really think that Japan prospered because they copied american business processes?
    Yes.
    Heh. The kanban is surely an English word. And whom did Saturn copied its business processes from?

    I was refering to the rebuild after WWII. Like I said they built on our ideas. So now we steal what we can emulate.

    They made out like bandits they went from emperor to industrialized democracy in 20 years. We went from the world dominating industrial power to failing national socialist (Starting the fascism period in 2001 that historically persists for ~20 years.). Average earning power when adjusted for inflation is down for over 30 years except for 1984 (www.bls.gov). I think we should take the Asimo and more to make up for the losses.
  56. Non IP countries attract talent because of better pay while IP countries turn them away. Just look at the number of engineers per capita being generated by India and China. Not only that, but they attract the smarter people unlike in the U.S.. Indian computer scientist make 10 times more than the average person in India while in America the average Restaurant Manager make about the same as a computer scientist.Whups. Sorry kind of got off topic towards the end. LOL.
    It is bit silly, is not it ? Upload your code to SF and you will see how it is usefull and haw many evil people from evil countries need it.
  57. I am a respected hacker in my country, don't say which one, hafta find it yourself. My code is obfuscated from the time I write it because all I write is simply a pile of crap. Your code is not safe with me because I'm pure evil. I cracked half of the Spring framework before I realized its sources are freely available, however that was a positive experience. My current interests are cracking the String class from java.lang and making its toString() method output bad jokes and obfuscating all the code on SourceForge so that those many hackers out there spend time cracking it and leave my company's code alone.

    Fffear me ! If you ever pass by SouthEast Europe drop me an email and we'll go cracking quality beer and snacks.
  58. LOL.

    I am from the same country as u are I guess.

    Regards,
    Horia
  59. encryption would be the way...[ Go to top ]

    Good and interesting article.

    When talking about protecting code, then encrypting it would be the only way. Of course, in hardware memory, everything could be reached...

    In this article, why in this case (protecting code) encrypting with private/public cryptography is not considered?

    I mean: encrypting with private key and while runtime, decrypting is done with public key...
  60. encryption would be the way...[ Go to top ]

    Because it doesn't help.

    Firstly, you have to have an online system - in which case there are a number of genuinely secure service-based options available to you.

    Secondly, if you have unsecured hardware, it will always be possible to extract the locally held key, use it to carry out the key exchange, and use the results to decrypt the remaining logic.

    Encryption doesn't solve this sort of problem - secure hardware might (debateably - hardware can be hacked) but carries its own risks.

    Dave.
  61. Encryption is like Obfuscation[ Go to top ]

    Because it doesn't help.Firstly, you have to have an online system - in which case there are a number of genuinely secure service-based options available to you.Secondly, if you have unsecured hardware, it will always be possible to extract the locally held key, use it to carry out the key exchange, and use the results to decrypt the remaining logic.Encryption doesn't solve this sort of problem - secure hardware might (debateably - hardware can be hacked) but carries its own risks.Dave.

    First encryption can help some.

    Second don't use a locally held key. Use SSL with a remote licensing server with a remote key. I agree that a local key is more dangrous.
  62. First encryption can help some. Second don't use a locally held key. Use SSL with a remote licensing server with a remote key. I agree that a local key is more dangrous.
    But if you decompile the client code, you'll find how to contact the remote server, get that key and decrypt the encrypted bytecode... The code that you send to the client has to be something that can be decrypted by the client JVM. If the JVM is able to get the decrypted bytecode, why wouldn't you be able to do what the JVM does and get that decrypted code?

    And anyway, you could get the decrypted code without any key, just by "enhancing" the bytecode of java.lang.ClassLoader so that before loading any class, you dump its bytecode in a file.
  63. Yep. And.[ Go to top ]

    First encryption can help some. Second don't use a locally held key. Use SSL with a remote licensing server with a remote key. I agree that a local key is more dangrous.
    But if you decompile the client code, you'll find how to contact the remote server, get that key and decrypt the encrypted bytecode... The code that you send to the client has to be something that can be decrypted by the client JVM. If the JVM is able to get the decrypted bytecode, why wouldn't you be able to do what the JVM does and get that decrypted code? And anyway, you could get the decrypted code without any key, just by "enhancing" the bytecode of java.lang.ClassLoader so that before loading any class, you dump its bytecode in a file.

    True. Although, you could further reduce tampering by using a self modifying custom classloader that passes the checksum of the custom classloader to the licensing server for verification and a number of other checks before passing a key.

    The point as specified in my first post is to increase the cost not make it impossible since that would be impossible. This is not just a java issue. You could use the new non byte code JVM (Not really a jvm) with the java language to remove the magnitude of difference.

    From weakest to strongest:

    -1. Source Code
    0. Byte Code w/Debug/Variable Data
    1. Byte Code wo/Debug/Variable Data
    2. Encryption of Byte Code wo/Debug/Variable Data
    3. Obfuscated of Byte Code wo/Debug/Variable Data
    4. 2 & 3
    5. Machine Code
    6. Poorly Designed Code :)

    I use 4. Although, using 5 would make java like a non byte code language as far as security is concerned. I find 6 to be a bad idea. If your going to do 0 you might as well OS the project. If I could figure out a model to make money other than 6 using I would just open up my 100k line project. Heck I am not making anything now, but I do not like others messing with my code.

    This is an advantage of non byte code languages have over Java and TOY.NET

    I still love Java despite its few minor weaknesses.
  64. What about HASP?[ Go to top ]

    Of course anything is breakable, but what do you think about using HASP+obfuscation+native compilation?
    <url>http://www.hasp.com>

    There is a utility (envelope or something like that) in the suite that wraps your binary and can insert arbitrary check points in execution flow. This can be applyied only to exe and dll files, but one can compile to native binary parts of the java application (the whole application if using SWT).

    Regards,
    Horia
  65. What about HASP?[ Go to top ]

    Whatever. It's all still "security by obscurity" and there's a reason why the phrase implies a Bad Thing.

    As always, the need for almost-but-not-quite secure software doesn't seem to me to exist.

    Dave.
  66. What about HASP?[ Go to top ]

    HASP can add more protection, but exist HASP Emulator Professional Edition http://www.brstudio.com/. So HASP can't 100% protect software from stealing
    eToken IMHO more secure.

    Well if you have software, have work key and have a lot of time and knowledge.. then you reverse engineering code.
    Only if haven't code you can't decompile it.. All other just increase reverse engineering cost.
    If reverse engineering cost more then your algorithm cost - you win :)
  67. Game Over[ Go to top ]

    All other just increase reverse engineering cost.
    If reverse engineering cost more then your algorithm cost - you win :)

    Not true. If I spend $500 on an obfuscation tool, and someone then spends $600 worth of their time in reverse engineering it, I'm still out of pocket by $500. This is not a zero sum game.

    Dave.
  68. Game Over[ Go to top ]

    If I spend $500 on an obfuscation tool, and someone then spends $600 worth of their time in reverse engineering it, I'm still out of pocket by $500. This is not a zero sum game.Dave.

    But I guess u r intelligent enuf not to buy the obfuscation tool for every software that u build. So I wud call it a one-time investement of 500$. Lets say u have an enemy who is a hacker and he decides to hack every product that u build. Lets say u build 5 products. The hacker would now have to spend 600 * 5 = $30000 worth of his time. So even thou he may have successfully hacked all ur products, he still lost $30000, and u r out of ur pocket by just 500$. Now will he continue to do this?? Depends on how big of an enemy he is :)
  69. Game Over[ Go to top ]

    600 * 5 = $30000

    OK, NullPtr, I'm not hiring you to do accounting ;-)
  70. Game Over[ Go to top ]

    600 * 5 = $30000
    OK, NullPtr, I'm not hiring you to do accounting ;-)

    Gosh!!! I think I got too carried away to project numbers in favour of obfuscation :)))
  71. Game Over[ Go to top ]

    All other just increase reverse engineering cost.If reverse engineering cost more then your algorithm cost - you win :)
    Not true. If I spend $500 on an obfuscation tool, and someone then spends $600 worth of their time in reverse engineering it, I'm still out of pocket by $500. This is not a zero sum game.
    I mean algorithm cost not an obfuscation tool cost.
    If algorithm cost $300 I am not spends $600 worth of my time in reverse engineering it. I spend time to write my own version of algorithm.
  72. Game Over[ Go to top ]

    An algorithm that costs a mere $300 to implement is hardly a work of genius worth protecting, though, is it?

    I have trouble in believing in this company that is so spectacularly unprincipled that they would rather reverse engineer a competitor's product (with or without obfuscation), than spend half a day on developing their own replacement.

    Dave.
  73. Obfuscation and Java[ Go to top ]

    I live in a pretty safe city, my house is on a corner, I have thermal/motion security which is posted for all to see. This will eliminate a VERY large percentage of persons who would like to steal my stuff. A thief will do a cost analysis of breaking into my house vs. a neighbors house and try their house instead (I hope). Plus I have a big German Shepard (big coward) for those wishing to try anyway. This will not deter someone who is hell bent on breaking into my house, but will eliminate most of them.
    The same can be said for obfuscation tools. There will always be someone who is going to try to ‘crack’ you code. You just have to raise the cost (time) high enough to deter most of them. As far as your ‘cracked’ code ending up on a Warez site, when is the last time you tried to get something from a Warez site without getting a Trojan/SpyWare/Virus/ etc in the bargain?

    -Pete
  74. Obfuscation and Java[ Go to top ]

    I live in a pretty safe city, my house is on a corner, I have thermal/motion security which is posted for all to see. This will eliminate a VERY large percentage of persons who would like to steal my stuff. A thief will do a cost analysis of breaking into my house vs. a neighbors house and try their house instead (I hope). Plus I have a big German Shepard (big coward) for those wishing to try anyway. This will not deter someone who is hell bent on breaking into my house, but will eliminate most of them. The same can be said for obfuscation tools. There will always be someone who is going to try to ‘crack’ you code. You just have to raise the cost (time) high enough to deter most of them.
    First, if your house has a security system, cameras, gates and unleashed dogs, it just screams "Good stuff inside!" ;-)) Anyway, this comparison is flawed. No one is going to rob the same house day after day after day unless it is a WAREhouse. Unlike material stuff, software can be copied in infinite (though countable) numbers. And there are always some guys who crack software just for fun. The tougher protection, the bigger pride to break it. After they did their job, thousands of other guys can use your product free of charge and absolutely free of efforts. All calculations in the posts above apply only to the case of greedy cracker who keeps cracked software for himself. Probability of this event is close to zero.
    As far as your ‘cracked’ code ending up on a Warez site, when is the last time you tried to get something from a Warez site without getting a Trojan/SpyWare/Virus/ etc in the bargain?-Pete
    You can get AIDS or VD having sex. Which does not mean, that having safe sex is impossible. They also say that the fear of being caught having sex in public places makes it even more desirable :-) Dont obfuscate your product, and it will be much less sexy.

    The best protection is to store part of your code on external device like USB-key or COM-port key. But this can be cracked too after only one legal purchase. On the other hand, if you sell CAD/CAM systems for tenth of bucks apiece, the price for a legal copy would be unbearable for a regular cracker. Well, those guys have friends, who work in design studios and would not mind to have that expensive CAD system for their home office... So, unless _all these keys_ are stored in deposit boxes, the product would eventually be cracked.
  75. Obfuscation and Java[ Go to top ]

    ...if you sell CAD/CAM systems for tenth of bucks apiece...
    Tenths of thousand bucks, of course :)
  76. Obfuscation and Java[ Go to top ]

    Totally agree with you....
    I live in a pretty safe city, my house is on a corner, I have thermal/motion security which is posted for all to see. This will eliminate a VERY large percentage of persons who would like to steal my stuff. A thief will do a cost analysis of breaking into my house vs. a neighbors house and try their house instead (I hope). Plus I have a big German Shepard (big coward) for those wishing to try anyway. This will not deter someone who is hell bent on breaking into my house, but will eliminate most of them. The same can be said for obfuscation tools. There will always be someone who is going to try to ‘crack’ you code. You just have to raise the cost (time) high enough to deter most of them. As far as your ‘cracked’ code ending up on a Warez site, when is the last time you tried to get something from a Warez site without getting a Trojan/SpyWare/Virus/ etc in the bargain?-Pete
  77. He discusses code manglers, encrypting Strings, the future, and whether it is even worth it.How many of you use obfuscators?

    There seems to be a wealth of expertise, and opinion, about decompilation and obfuscation in the contribution to this thread. However, anyone who wants to learn more on the subject might like to check out a new book: Decompiling Java, by Godfrey Nolan, published by Apress.

    This goes more deeply into obfuscation and decompilation than any other current book. It also walks through building an obfuscator and a decompiler to build the reader's understanding.

    - Fiachra
  78. I have nothing against the author personally, but I make a point of avoiding anything that has been marketed through "astroturfing".

    I was particularly irritated by your attempt to push the book on the Risks Digest list.

    I would have no problem with your promotion of the book if you made it clear that you had a personal connection with the author.

    Dave.
  79. I have nothing against the author personally, but I make a point of avoiding anything that has been marketed through "astroturfing".I was particularly irritated by your attempt to push the book on the Risks Digest list.I would have no problem with your promotion of the book if you made it clear that you had a personal connection with the author.Dave.

    People do need money to eat and provide clothing for themselves as previously defined by you. How can you sell something without advertising?
  80. People do need money to eat and provide clothing for themselves as previously defined by you. How can you sell something without advertising?

    That may be the most fatuuous argument I've heard put forward to date. Something of an achievement; well done.
  81. People do need money to eat and provide clothing for themselves as previously defined by you. How can you sell something without advertising?
    That may be the most fatuuous argument I've heard put forward to date. Something of an achievement; well done.

    What exactly are you trying to say was foolish about my argument?

    Please at least provide an argument with your next post.
  82. For the hard of thinking.[ Go to top ]

    It barely qualifies as an argument, but if you really want me to take it apart, fine.
    People do need money to eat and provide clothing for themselves as previously defined by you. How can you sell something without advertising?

    The advance from Apress would feed someone in a country that has true poverty for a couple of years even if the book never sells a single copy.

    The astro-turfer worked for the Irish Times, so I doubt either he or the author are living below the poverty line anyway.

    Even if they do live below the poverty line, I'm not obliged to buy the guy's book for any reason whatsoever, nor am I obliged to refrain from pointing out the dubious quality of the recommendation.