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?

10
  • 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: stackoverflow.com/questions/6018215/…
    – Mark Booth
    Commented Jul 5, 2011 at 15:57
  • 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
    Commented Jul 5, 2011 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
    Commented Jul 6, 2011 at 1: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.
    Commented Jul 6, 2011 at 1:51
  • 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
    Commented Jul 20, 2011 at 6:51

12 Answers 12

Reset to default
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.

19
  • 31
    +1 Obfuscation is NOT security, just a comfort blanket.
    – uɐɪ
    Commented Jul 5, 2011 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
    Commented Jul 5, 2011 at 14:16
  • 6
    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
    Commented Jul 5, 2011 at 14:22
  • 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.
    Commented Jul 5, 2011 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
    Commented Jul 5, 2011 at 15:08
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.

19
  • 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
    Commented Jul 5, 2011 at 13:42
  • 15
    @Neil: ...so maybe it's time to introduce your boss to the concept of "maintenance costs"?
    – SF.
    Commented Jul 5, 2011 at 13:56
  • 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
    Commented Jul 5, 2011 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.
    – user1249
    Commented Jul 5, 2011 at 14:46
  • 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
    Commented Jul 5, 2011 at 14:56
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.

2
  • Then when I fish through these classes in the future, I'll just hold my nose I guess.
    – Neil
    Commented Jul 5, 2011 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
    Commented Jul 5, 2011 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.

1
  • 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
    Commented Jul 5, 2011 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.

1
  • 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
    Commented Jul 5, 2011 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.

6
  • 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
    Commented Jul 5, 2011 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
    Commented Jul 5, 2011 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
    Commented Jul 5, 2011 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
    Commented Jul 5, 2011 at 15:48
  • 1
    @Tundey the Sun JVM is (mostly) open source, you can modify it.
    – Spudd86
    Commented Jul 5, 2011 at 21:05
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.

1
  • 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
    Commented Jul 5, 2011 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.

3
  • 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
    Commented Jul 5, 2011 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
    Commented Jul 5, 2011 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
    Commented Jul 5, 2011 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.

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.)

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.

Not the answer you're looking for? Browse other questions tagged or ask your own question.