• Post Reply Bookmark Topic Watch Topic
  • New Topic

Obfuscated code - How big of a performance drop?  RSS feed

 
john price
Ranch Hand
Posts: 495
Chrome Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Obfuscated code - How big of a performance drop?
Thanks,
John Price
 
Paul Clapham
Sheriff
Posts: 22828
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why do you think there is a performance decrease?
 
Alexander Kober
Ranch Hand
Posts: 32
IntelliJ IDE Java Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Obfuscation will usually not affect performance at all. There are some obfuscators that may insert additional instructions on byte code level (e.g. splitting loops), but they will generally not make your program run less efficiently. In fact, some obfuscators will actually improve the startup performance a tiny bit by shrinking your code.
 
john price
Ranch Hand
Posts: 495
Chrome Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry I took so long to respond. Is there anything wrong with obfuscated code? There are no downsides?

Thanks,
John Price
 
Stephan van Hulst
Saloon Keeper
Posts: 7974
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Obfuscated code tends to be hard to read.
 
john price
Ranch Hand
Posts: 495
Chrome Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks for the quick response. Isn't that the point of obfuscated code? And you obfuscate it AFTER you compile it, right?

John Price
 
Alexander Kober
Ranch Hand
Posts: 32
IntelliJ IDE Java Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
It is true that you obfuscate code after compilation, but readability is still an issue when you think about logging/debugging. It is rather hard to decipher a customer's log file when all the classes are called something like "a.b.c.d.E". There are, of course, tools that let you remap the obfuscated class names back to the real ones, but it still means that you have to keep all the obfuscation logs of all the versions you ever release.

The bigger issue, however, is what obfuscation does to reflection. Obfuscators can not deal with magic strings, so stuff like 'Class.forName("foo.bar.MyClass")' or 'myClass.getDeclaredMethod("foo",...)' will longer work. This can be a rather annoying issue with persistence layers, e.g. when you want to write your session data to xml. You'll usually end up excluding parts of your application from obfuscation, or adding special annotations to types and methods to preserve the information you need. It's extra work and, obviously, it lowers the quality of the obfuscation.
 
john price
Ranch Hand
Posts: 495
Chrome Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
From what I understand, reflection is using other homemade classes' methods. If I do not use these (I usually do not), then there won't be a problem except for debugging. The project I am currently working on is a client/server chat program. It runs perfect and 100% of the security is on the server. I would just rather not have people know my homemade protocols and such. Plus, if I put some backup security (for error messages to the user), they could know exactly what I am looking for in the bad things and know what to avoid. This makes for easier "hacking", and the time for blocking hackers is between 5-10 seconds (manually enter in some code, server side). In this amount of time, they could easily get information that shouldn't be shared (such as bad words, etc) that I have blocked through the server. This is obviously a standard problem in the security department. Anyway, I want to obfuscate this code so that the hackers (not that many people use my software ) would not see my server side "blocks". I am getting confused writing this, probably because I haven't figured out 100% what I'm going to do security-wise. My security for the program is IP addresses, which could easily be avoided with proxy servers. The client is Applet wise. The website I am using to host is free, but offers a ton of bandwidth, space, and blocks most proxy servers. If they downloaded the unobfuscated Applet and decompiled it, they would know exactly what I am blocking, as well as some intricate methods. If I were to add the error messages, client side (so it doesn't even send it to the server if it doesn't concur with certain restrictions), I wouldn't want people to be able to view it. Anyway, I guess most of my program doesn't even matter to this subject because the question is about performance and obfuscated code. I'm not even sure I should be posting the above information about my server/client because you probably don't want to hear it and (?) doesn't add anything to the conversation.

MODS : Please edit this message as necessary to remove irrelevant information as you see fit.

Confused,
John Price
 
Ulf Dittmer
Rancher
Posts: 42972
73
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For applets the same is true that goes for JavaScript: you can't trust what the client sends to the server. Therefore, whatever the client-side code does, also needs to be done on the server.

Also note that any security that is based merely on the attacker not knowing how exactly it works is called "security by obscurity", and is considered not secure at all.

I want to obfuscate this code so that the hackers ... would not see my server side "blocks".

I don't understand this - how would hackers ever get access to the server-side code? If they actually manage to break into the server to get the class files, then you have much bigger problems to worry about.

I'll move this to a more appropriate forum, as it has nothing to do with performance.
 
john price
Ranch Hand
Posts: 495
Chrome Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Let's say I have an ArrayList of blocked words (cuss words, invalid names, etc). Imagine for a second that the server takes the message the user sent, and scans it through the ArrayList. If the message contains any of the words in the ArrayList, it doesn't send the message to anyone. I do not even send a return message to the client, for certain reasons. The usernames are handled through the server too, so no one can actually set their name through the client, only by making a request to the server, who can accept or deny the name. If it passes, the name is attached to an IP address (mapping). When the user connect, there is an IP address connected to the specific PrintWriter the user is attached too. If the user tries to send a message, it takes the IP address of the sender and searches for a PrintWriter and name. It takes the name, adds it to the message and sends the message off to the checker. The checker scans the message for blocked words. If it passes, it sends it off. If it fails, it does nothing. If I were to check just the message for "blocked words" on the client, that would save the server some performance and time. I could also easily send the user a message telling them that their message contained word X and that it is not allowed. I would keep the "extended" functionality on the server, but it would never be called unless someone made their own client. In that case, I wouldn't care about sending any error messages to them because I want them to use my program, and don't care about catering to their own program.

John Price
 
Alexander Kober
Ranch Hand
Posts: 32
IntelliJ IDE Java Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Never trust anything coming from the client when doing a client-server-architecture. Always recheck every assumption made in your client code. I know this sounds rather snobbish, but it really is one of the core rules to follow. :-)

That aside, even with obfuscation in place, it would be fairly easy to circumvent a system like the one you described. Let's assume that 'moose' is a bad word. If i realize that your client is filtering my use of the word, i will first search the decompiled (but obfuscated) code for the word 'moose'. Your naive (no offense) filter list will show up somewhere, and i can replace / delete the code anytime. You could, of course, manually obfuscate your algorithm, e.g. by having your filter list 'encrypted'. Still, thanks to the availability of runtime aspect weaving or other techniques i dare say i would find the filter routine in less than an hour.

What obfuscation really does for you is making it harder to understand and recompile non-trivial projects, but java still makes it very, very easy to identify isolated functions if you know what you're looking for.
 
john price
Ranch Hand
Posts: 495
Chrome Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So basically, I should just stick to having the list on the server, correct?

Thanks,
John Price
 
Alexander Kober
Ranch Hand
Posts: 32
IntelliJ IDE Java Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Let's say there is nothing wrong with having the list on the client and on the server. If the client does filter a message (i would assume that most of your users will not be using hacked clients) your server won't have to => less messages to parse. It's just that you don't have a guarantee that the client will do the filtering, whether you obfuscate your client code or not.
 
john price
Ranch Hand
Posts: 495
Chrome Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am assuming no one will try to hack my client. Maybe some kids or something, but nothing serious. But,
A. I want to figure this out if I did professional work
and B. I want my program (client + server) to be secure (I am upgrading to SSL currently, 95% done with SSL work).

I actually wouldn't care if someone hacked it (as long as no permanent damage), because it's a personal project and it's just for fun. None of my users depend on it. So far, they are only using it because I asked them. It runs fine (as I said before), but I just would not rather people see my list. I CAN send messages to the users on the server, but I don't want that strain on it. If I put the list on both, it would reduce strain on server (and therefore only be filtering bad words for hackers or people that make their own clients). But again, I don't want people to see that list. If they see that "happy" isn't filtered but "excited" is, they might use "happy", which I might not want them too. If they send messages with cuss words (and the list is on the client & server), they will easily be able to see a customized error message, having no strain put on server. If this isn't possible or is out of my range, it is okay. I just wanted to know (and will implement it if possible).

Thank you very much,
John Price
 
Alexander Kober
Ranch Hand
Posts: 32
IntelliJ IDE Java Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think treating every application like it going to be the biggest thing on the market is a good thing, it makes you think twice about your design. In this spirit, two more things you could consider for an application like the one described (assuming that the client code is already obfuscated and therefore 'hard to read'):

1) You could transfer the list from the server to the client when the client connects. This obviously only makes sense when the list is small, otherwise you'll generate more traffic than the thing is worth.

2) If the list is relatively large, store it on the client in an encrypted file and transfer the cipher key from the server upon connection.

Both approaches are not secure in any way. But since the list is no longer stored on the client in clear text, it should be enough to put off the occasional script kiddy. A lot of people will be deterred when they see that the code is obfuscated and they'd have to add a runtime hook to the application to get to your list (since it is one thing to read obfuscated code, but another thing to recompile it). Of course, another kind of people will be incited to hack your client just for the challenge :-)
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!