37

I know it seems odd to say, but a fellow programmer at work deliberately used a couple of bad programming practices on purpose! I'll explain. First let me say that he's an intelligent guy and for the most part he writes intelligible code.

He was asked to implement licensing on a web application project written in Java. Since it's Java, if one really wanted to, one could probably hack open the jars and read the names of the classes and methods written inside. His solution to this problem was to quite literally to awkwardly call variables and methods less-than-obvious names and plant them inside already congested classes rather than generating new classes.

His justification was that if a hacker wanted to switch out certain classes in order to bypass licensing checks (and therefore get a free copy of the product), he'd have a far more difficult time of it if it weren't obvious which methods perform these particular tasks. Only after he had done it did I confront him about it, suggesting that we could perhaps buy some sort of obfuscator library to do it for us, while maintaining good programming practices. He claims to not have had the time or resources to search for that kind of solution.

..Which leaves me at a dilemma. Do I look for a obfuscator library in Java and fix his old code (which might be a little touchy about remodeling his code), or do I leave it as it, as much as that irks me to no end?

Neil
  • 22,670
  • 45
  • 76
  • 4
    If your question is about how to handle the politics of this situation, then many of the answers here are pointing in the right direction, but if as a comment of yours suggests, you really want a better alternative to propose, you might want to check out answers to this question: http://stackoverflow.com/questions/6018215/how-to-obfuscate-string-constants/6018904#6018904 – Mark Booth Jul 05 '11 at 15:57
  • Here's a list of open source obfuscators. There shouldn't be any cash outlay involved in using one of these. http://java-source.net/open-source/obfuscators. Maybe that will make him more receptive to using clearly-named source code. – Ken Bloom Jul 05 '11 at 18:20
  • 8
    If a hacker with access to your clean source code can hack your authentication then it's hackable, period. No amount of obfuscation will help. If you are after a solution that stops some hackers, then on top of obfuscation you may also want to use some of his misdirection practices (hide things in unlikely classes that can't be easily replaced). Frequent updates that completely change your authentication practice also help. Many users get tired of relying on hackers and just buy it. – Bill K Jul 05 '11 at 21:55
  • 2
    Was he renaming locals? If so, he's wasting his time - they don't exist as named variables in the compiled code anyway. – Nick Johnson Jul 06 '11 at 01:01
  • 1
    It's called "obfuscation" and although it is being more frequently used these days, its not full-proof!..although it will delay someone from cracking the code, it can be cracked!..what I would like to see is a compiler that can encrypt the object code and only be executed with the correct key, so that even someone with a disk editor, disassembler or any other cracking tool will never be able to make heads or tails out of it! – Joe R. Jul 06 '11 at 01:51
  • @Nick: Assuming he is compiling without debugging symbols. On that note, some obfuscators purposely fill the debugging symbol table with garbage to trip up naive decompilers (for example, a local variable named `for` or `if` or `4+5/2`). That *really* wreaks havoc on decompilers that merely copy-and-paste the debugging symbols into their generated source code. – Adam Paynter Jul 06 '11 at 09:30
  • @Frank, you might find this interesting then: http://en.wikipedia.org/wiki/Aladdin_Knowledge_Systems –  Jul 07 '11 at 08:20
  • 6
    "His solution to this problem was to quite literally to awkwardly call variables and methods less-than-obvious names and plant them inside already congested classes rather than generating new classes." and "First let me say that he's an intelligent guy" do not go well in the same paragraph! – devoured elysium Jul 20 '11 at 06:51
  • 1
    There was method in his madness, @devoured. :) – Neil Jul 21 '11 at 14:05
  • This is called, "Cutting off your nose to spite your face." – JeffO Jan 09 '12 at 15:58

12 Answers12

94

Security through obfuscation is never good security. There must be better ways of protecting your intellectual property. And that is what you and your colleague should bring up as a joint concern with your manager. If management then decide that they don't want to spend the time or money on improved security, then both of you will have to live with that decision (it's not your product, it's the company's product) and better not spend (waste?) any more time on the subject.

wolfgangsz
  • 5,373
  • 1
  • 22
  • 24
  • 31
    +1 Obfuscation is NOT security, just a comfort blanket. – uɐɪ Jul 05 '11 at 14:05
  • 7
    If you can come up with a better solution than obfuscation, then I'll mark your answer as the correct one. How can you guarantee that someone with access to the war file can't modify its functionality for at least what concerns licenses? – Neil Jul 05 '11 at 14:16
  • If I could have thought of a better solution, I would have already added it to my answer. Sorry, I am not an expert in securing web applications written in Java. – wolfgangsz Jul 05 '11 at 14:19
  • 5
    You can't guarantee it at all when someone has got access to the files. But the truth is: The simplest mechanism prevents 99,99% of users from doing harm to your software. A dedicated and skilled hacker WILL ALWAYS find a way to bypass application security. You can, however, switch to remote verification, so your program will only run when authenticated against a service of yours. In order for that to be secure, you need to encrypt your whole program and have some kind of bootloader. BUT: if someone has got a valid key, he can reverse engineer the software again anyway. – Falcon Jul 05 '11 at 14:22
  • @Falcon: Then how can I have my cake and eat it too? Can I not have good programming practices and keep my web application secure from 99.9% of users? Once it's hacked, it could in theory be used on countless machines, costing the company thousands. – Neil Jul 05 '11 at 14:23
  • 1
    Yes, I concurr. As most hackers are skilled in following spaghetti code anyway, I think obfuscation is of little use against the dedicated ones. I'd invest a few hundred bucks in an obfuscator, though, to scare away not so dedicated hackers who just peek. I'd prefer the clean code for my app. – Falcon Jul 05 '11 at 14:29
  • 1
    @Falcon: Well the point is not to keep all hackers out, then at least to putting it on a silver platter. I, too, would prefer clean code if I had to pick. – Neil Jul 05 '11 at 14:41
  • 7
    @Neil: Implement the core business logic in a microcontroller attached as a USB dongle. You didn't say it has to be cheap or easy to implement ;) – SF. Jul 05 '11 at 14:51
  • 8
    @SF.:Touche. I think it ought to require three satellites to simultaneously link as well, just for the hell of it. ;) – Neil Jul 05 '11 at 15:08
  • 2
    @Neil No matter what obfuscatory tricks you pick, if your software is good enough to be interesting to people who don't want to pay, someone will reverse-engineer their way past your licensing checks. Once one person has done that, it's game over - they distribute the modification to everyone who wants it. All the extra obfuscation bought you was a few more hours, at the expense of a maintenance nightmare. – Nick Johnson Jul 06 '11 at 00:59
  • I feel like [my answer here](http://stackoverflow.com/questions/4532540/c-how-to-make-it-harder-for-hacker-cracker-to-get-around-or-bypass-the-licensin/4532568#4532568) is relevant. – Ben Voigt Jul 06 '11 at 04:16
  • 2
    @SF - Using an external micro like that isn't really any harder to hack or reverse, it just requires a different skillset. – Fake Name Jul 06 '11 at 04:36
  • @Fake Name: If your debug toolset consists of very, very fine grinder, microscope and logic probes of sub-micron thickness, you may change your opinion about "isn't any harder". Just a matter of picking a chip with correctly implemented fuse bits. (FYI, fuse bit - a special register bit that can be written only once, disabling specific features permanently - features like "access flash from outside".) – SF. Jul 06 '11 at 07:13
  • @SF: I've fixed wrong Fuse Bits in the past. All you need is a programmer and an interface. You can do that, even for small SMD chips, on nearly every board. BUT: You could create your own IC and use a non-standard programming method to obfuscate the whole process :) – Falcon Jul 06 '11 at 07:35
  • @Falcon: That means the fuse bits were implemented wrong. Correct implementation disables parallel programming as well. – SF. Jul 06 '11 at 09:02
  • @SF: It's device dependent. – Falcon Jul 06 '11 at 09:08
  • @Falcon: Yes. Some devices have a half-assed implementation that can be overridden. Pretty much beating the whole purpose. – SF. Jul 06 '11 at 11:44
  • @SF: For most vendors of microcontrollers, fuse bits are set to configure internal oscillators, watchdogs etc. I guess for most general purpose applications you should always be able to reset/change fuse bits. Locking the flash memory completely is a special requirement and I am sure there're special chips out there for just this purpose. – Falcon Jul 06 '11 at 12:05
  • 1
    "Security through obfuscation is never good security." er... that's precisely the point of obfuscation, and it works **pretty darn well**... – user541686 Jul 09 '11 at 05:00
84

Original: What does your boss say? Find out - do that.

I was asked to elaborate the above:

First of all, I think you have more than one dilemma:

  • Should you "fix" another persons code?
  • Is the implementation (herefrom A) of the other persons bad enough that it should be replaced with something else?
  • Will an obfuscator (herefrom B) be better for this "embed licensing in our application"?

First of all, seen from a business case the problem IS solved. A is in place and is - most likely - a "good enough" solution for the problem. Your company may be happy with it basically just protected enough that deliberate effort is necessary to break it.

This mean that even if you dislike it (and, trust me, you will see a lot worse through your career) it does what is needed. Hence, as the problem IS solved, you should not "just do it" but rather convince the person who is in charge of assigning your work that the long term price of this implementation will be high enough to warrant a rollback and choosing a stock obfuscator. This will require quite a bit of preparation from you, and also note that obfuscators have downsides too that you need to know (other answers cover this well). E.g. stack traces are not immediately usable, etc. It all depends on how important it is to avoid pirating. Note that the hardest to break is the ones that require hardware dongles to run and is most likely more expensive than your customers will like.

Therefore, this decision is not yours to make, as your company needs to use additional resources to go to B. Hence you need to bring your concerns to the person responsible, explain this and any other long term concern well enough for him to understand why you consider it inferior to your suggestion. Then let him take the decision, and regardless what it turns out to be, respect it and behave accordingly in a professional manner. Note that the original author will most likely have to maintain it anyway as he wrote it and if he leaves or do not want to anymore, then you can bring up the matter again.

In other words: What does your boss say? Find out - do that.

Note also, that this would have been different if you had raised the issue earlier so that the wasted money for the time spent implementing A was smaller. In other words, when the choice between A and B was to be made.

Finally, I would like to comment your question about "just fixing other peoples code". This is not a small fix to existing code (which I find fine and encouraged, especially with tests in place). It is a disruptive rollback and reimplementation, and even in teams with common code ownership this would not be an acceptable thing to do - at least to me - without prior approval.

Hopefully this clarifies my point of view.

  • 8
    My boss is no programmer and I'd probably have a hard time explaining why we should invest time and money into doing something which ultimately won't modify the behavior of the program in any way. – Neil Jul 05 '11 at 13:42
  • 15
    @Neil: ...so maybe it's time to introduce your boss to the concept of "maintenance costs"? – SF. Jul 05 '11 at 13:56
  • Ask the project manager? – tehnyit Jul 05 '11 at 13:58
  • My boss is the project manager in theory, though in practice it's the programmer himself who manages it for the most part. – Neil Jul 05 '11 at 14:18
  • 1
    @Neil: If your boss doesn't understand the concept of technical debt, then they've no business being your boss. – Binary Worrier Jul 05 '11 at 14:24
  • 1
    @Binary Worrier: Tell me about it. He's more of a technical advisor (for things not Java) than a boss, though I suppose people assumed that'd make him good for what concerns managerial skills. – Neil Jul 05 '11 at 14:27
  • 21
    Is this going to become the default response to every single question about coworkers or the work environment? I know that some nub had to go and tell you to post this as an answer, but come on, it *isn't* an answer. This is actually a semi-decent (albeit awkwardly-worded) question about the problems with security through obscurity; this "answer" is insulting. – Aaronaught Jul 05 '11 at 14:33
  • 8
    @Aaronaught. This answer cuts to the bone when it is "implementation A is bad, I suggest we do implementation B" because additional work (equaling money) needs to be done. If it was a choice between implementing A or B the answer would have been different. I suggest you open a question on meta if you want a more detailled answer. –  Jul 05 '11 at 14:46
  • Aaronaught: this is precisely what the boss is about. If it was just sloppy programming, the answer would be different. But considering no security is fault-proof against crackers, security through obscurity, while costly, is one of viable options, and it is precisely the boss' job to balance the costs vs the profits. – SF. Jul 05 '11 at 14:49
  • 2
    Are you actually trying to defend this mindless quip as being insightful? The clarification you just posted would have been a *slightly* better answer, except even that still demonstrates no comprehension of the question itself. You could post this as an answer to almost **any question on this site** and it would be equally on-topic and equally useless. – Aaronaught Jul 05 '11 at 14:51
  • 22
    "Is this going to become the default response to every single question about coworkers or the work environment?" Why not? If this was worded as a technical question .e.g. "Which is better Automated obfuscation v's hand coded (=bad practise) obfuscation" then that's an entirely different question, and warrants a technical discussion. All "Should I fix this behind my co-workers back?" questions ultimately boil down to "No, bring it to the attention of team/higher power" – Binary Worrier Jul 05 '11 at 14:56
  • @Aaronaught, comments are not meant for discussion (which I believe you know already). –  Jul 05 '11 at 14:58
  • Well it was never about changing the code behind his back, per se. Obviously if he didn't want the code to be changed, it wouldn't change, but there'd be nothing to discuss either. Assume he were game for a change when presented with a better alternative solution. – Neil Jul 05 '11 at 15:07
  • "He was asked to implement licensing on a web application project written in Java." - by whom then? Somebody must have initially cared about that, and probably still does. – bonifaz Jul 05 '11 at 16:08
  • 1
    @Aaronaught, also feel free to write an answer. If it is better, it will get more votes. –  Jul 05 '11 at 16:59
  • 1
    I've got to say, that's a terrible answer. The job of a nontechnical supervisor is not to pull answers out of the air. The job of the senior technical person, when a question is beyond his authority without being beyond his competence, is to honestly outline the costs and benefits of possible choices and make a recommendation. – Michael Lorton Jul 05 '11 at 18:03
  • 3
    @Thorbjørn [the general consensus](http://meta.programmers.stackexchange.com/questions/1816/is-this-really-the-sort-of-answer-we-as-a-community-want-on-our-site) is that these one-line quips that don't elaborate are not answers we want here: is there *any* extra insight or explanation you can provide in your actual answer? –  Jul 05 '11 at 18:54
  • @Mark, sure there is. I'll elaborate later. –  Jul 05 '11 at 19:16
  • @Thorbjørn: +1 again if I could. Excellent elaboration. – Binary Worrier Jul 07 '11 at 07:52
13

Do I look for a obfuscator library in Java and fix his old code (which might be a little touchy about remodeling his code), or do I leave it as it, as much as that irks me to no end?

No, going back behind someone and altering code that they are responsible for would be a worse offense than writing the questionable code to begin with.

You've brought it up with the programmer, your next step is to keep your nose out of it or bring it up with management and then keep your nose out of it.

DKnight
  • 3,897
  • 1
  • 22
  • 31
  • Then when I fish through these classes in the future, I'll just hold my nose I guess. – Neil Jul 05 '11 at 13:46
  • 3
    When you have a direct responsibility for that code then altering it to your liking is fine, but if there is a joint responsibility you're going to need someone to arbitrate. It's easy to hurt working relationships and waste time on situations like this, better to not make an issue of it if possible. If an issue needs to be made then get it out of the way ASAP. – DKnight Jul 05 '11 at 13:53
6

Was there an official code review of any kind - or was the confrontation you had an unofficial "code review"? I would say that since this is a delicate and important subject such as security and licensing, you need to raise this up the chain. You've done the first part - confronting the programmer. However, now that he is not listening, you can/should take it up. If you don't, you may be part of the problem.

I would tell him that you are going to do it - this MAY change his mind. If it doesn't, write a very politically correct, yet accurate and concise email about the situation to your boss, and CC the programmer. In the email, ask for a meeting between the three of you and/or any other participating party.

Always meet these things head on - yet in a political and amicable way.

Catchops
  • 2,529
  • 13
  • 20
  • Certainly a commendable approach. I noticed the code modification myself, updating my code from SVN. Though chances are, if he isn't in agreement, convincing my boss to take these security precautions is likely not going to result in any change since the programmer could argue that it already 'works.' – Neil Jul 05 '11 at 13:50
2

If you can find an obfuscator that can obfuscate the signature of classes (method names etc.), well, propose to buy and use it.

Till then, you might have to live with it. I admit doing something similar in a recent Grails project - the license checks are deliberately embedded in the already large login method, so it would be pretty difficult to replace the method to bypass the check.

user281377
  • 28,352
  • 5
  • 75
  • 130
  • 1
    I can't tell you how much that bothers me, though you're probably right that I'll have to live with it. – Neil Jul 05 '11 at 13:47
2

Can he demonstrate that such a hack is feasible, or is it just a hypothetical scenario that he's kinda worried about? Can he give a live demo of this working? He should try. Seriously. If it works, it should be presented to management, and then suggest getting an obfuscator.

If an obfuscator isn't secure enough, have you looked into other ways of securing the JAR, maybe something like encrypting it, or compiling it to native code?

RE: reworking his code: Is it just a matter of renaming? Many IDEs have refactoring tools that can do this quite easily.

FrustratedWithFormsDesigner
  • 46,105
  • 7
  • 126
  • 176
  • He strikes me as bit paranoid, though I can see why. If the product were hacked, it would probably mean his job. I won't say it's possible, but I know enough to know how you can hunt for method names and if there were an obvious method called "isLicenseValid", would be a matter of writing a class which has this method and always returns true to 'hack' it. I think this program is complicated enough without complicating it further, though he seems to want to be sure of it. I think I could fix his code easily by renaming it, yes. – Neil Jul 05 '11 at 14:13
  • Just because you have a method called "isLicenseValid" doesn't mean it can be hacked by simply writing a class with the same method. If you mark your class as "sealed" (that's the C# syntax), then 3rd parties can't just circumvent your security checks by writing subclasses and overriding your method. In any case, unless this guy is the company's security officer, why would it mean his job if the product is hacked? – Tundey Jul 05 '11 at 15:20
  • 2
    @Tundey, it's not a matter of subclasses (how would they be loaded?): it's a matter of writing *the same class* and putting the hacked version earlier in the classpath search list. – Peter Taylor Jul 05 '11 at 15:37
  • 1
    ha.I remember the joys of class loading in Java. Still there has to be a better way to mitigate against that. Actually, if your class loader isn't compromised, how can someone write a class that's the same as your class? Especially if your JAR is signed? Wouldn't signing your JARs and sealing your classes solve the problem of someone writing a class with the same name as yours? – Tundey Jul 05 '11 at 15:48
  • 1
    @Tundey the Sun JVM is (mostly) open source, you can modify it. – Spudd86 Jul 05 '11 at 21:05
  • It's even easier than what you're saying. As long as you have the .class files it's as easy as editing the bytecode. – devoured elysium Jul 25 '11 at 13:07
2

Regardless of how valuable your IP is, the intelligent thing isn't to mangle your code in the hopes of confusing hackers. Apart from the fact that it's going to be a nightmare to maintain going forward, it doesn't really solve any problem. It just makes it harder but not impossible. So it's not really a solution and the side effects are bad. It's like taking medicine that doesn't work and has bad side effects.

Your problem is how to secure your IP. Find a solution for that: obfuscators, licence server etc.

Tundey
  • 227
  • 2
  • 6
  • I agree with you 110%. For what concerns securing the IP, that's a safeguard for our client to make, since it is their machine which runs the web application, not our own, though you make a valid point. I was more concerned with the client who has direct access to our product on their machine and can pick it apart. A license server is only as good as the clientside security. If you can bypass accessing the license server, no tricks in the book will keep you from using the program license-free. – Neil Jul 05 '11 at 15:43
1

I ran into a similar problem when another developer named our encryption/decryption routines str__copy and str__delete (notice the second underscore). It was lame and could have been done better, so we waited until there was a story where updating the licensing was necessary. Management didn't have a problem with the extra handful of hours because we described it as "clean up so the next time we go into licensing, it'll take less time and it'll be more secure". Problem solved, no hurt feelings.

FrustratedWithFormsDesigner
  • 46,105
  • 7
  • 126
  • 176
Christopher Bibbs
  • 2,709
  • 15
  • 12
  • Well of course we can always change it later, though I think the change needs to be in the head more than the code. – Neil Jul 05 '11 at 14:08
  • 1
    @Neil Then I'd suggest you're the one who needs the change in the head. If the code works, has adequate testing, and is well commented going that route instead of using and obfuscator isn't the best choice, but isn't the end of the world either. Fix it later if it is a problem and just move on otherwise. – Christopher Bibbs Jul 05 '11 at 14:13
  • @Christopher_Bibbs: Put your mind at ease. I can almost certainly assure you that it will, in fact, present a problem eventually. – Neil Jul 05 '11 at 14:42
1

My first thought was maintenance of that code. If the code is already obfuscated and he's moved on, good luck trying to get a handle on that code. You will then be the hacker trying to decipher the code.

Instead I would recommend cleaning up the code and using an obfuscator do all the hard work. Long term you'll have much manageable code and you leave all the crazy complexity to whoever wants to hack your license.

Do remember that no obfuscater is perfect, and a very determined hacker can reverse engineer anything, but at least it will only be him. Plus obfuscaters add a lot more complexity than that one guy probably can.

Steph
  • 11
  • 1
0

I highly agree with the answers that you should ask your boss about the issue and do what he says.

However a very important addendum to these answers is that you should document your concerns about both security and maintainability. Whether or not you change the code, it is important that people know what you're concerned about and why. This is important both proactively (your boss can't make a decision he doesn't even know needs to be made) and defensively (if/when a hacker pokes holes in the poorly secured licensing system, they can't blame you for their mistake.)

jhocking
  • 2,641
  • 19
  • 18
0

"Don't be the most superior professional to know of a problem".

In other words, tell your boss and go from there. If you keep quiet, and you're the top of the totum pole on that secret, when push comes to shove you'll be responsible. Tell your boss in passing and let him decide of a way to approach it. That way you are relieved of the burden of choice.

Don't just tell your boss, because a lot of managers maybe aren't as technical, but do what we always do: give the problem and possible solutions with the advantages/disadvantages for each of those solutions. Then let them decide and have that passed off. That's why managers/leaders get paid the big bucks!

0

The plain truth is that given enough time and resources anything can be cracked. It is a simple function of how popular your app is. The more popular it is the more skilled hackers it attracts and more time is devoted to breaking it. Code obfuscation provides just that - a means to increase the time required to break it, similar to cryptography. So if your code is obfuscated it requires the attacker to be skilled and devote time to it otherwise he will despair and give up. You have to ask yourself if your app is worth the trouble on both ends.

It is actually amazing how hard it can become to crack obfuscated code. You can easily turn a simple 10 line C program in a 100 line assembly one through obfuscation. If you try debugging it you will jump around meaninglessly in code and can be really frustrating to step through it. Eventually it will break but it becomes really hard and since nothing is really impossible that is the point. Code obfuscation reduces the number of people that are able to break it.

Sure there are better ways, like trying to confuse the debugger not the cracker, but this a cheap and efficient one. However naming things awkwardly doesn't quite cut it. You have to change control flow calling functions that don't really do anything for your overall code but increase the size and complexity of it: call dummy functions whose return value isn't used anywhere, from inside functions that really do something. You can already see how this can get really confusing.

You have something that the attacker doesn't. The original source code. Find a way to organize it better for yourself.

user66734
  • 29
  • 1
  • 2