How to obfuscate a j2ee application

[Sean Li]

I'm doing a research on obfuscators. The purpose is hide business logic and database access code from hackers.
My project is a whole java application, using jsp+struts+business delegate+session facade+dao+bmp.
As it's known, in Struts framework, there are some config.xml files, which map those action classes and form bean classes. They are in xml file, which means we cannot change the package name and the class name of these struts classes.
Also, on the back end, we have session beans and entity beans, which have their name written in deployment descriptor. That means we cannot change the package and class name neither. Further, to make sure ejb container still can recognize them. We cannot change public methods of those beans.
So, what can an obfuscator do? The classes left are some utility classes like DAO, ServiceLocator and so on.
Can any product make that?

[Sean Li]

Does anybody know that? Did I post to wrong forum?

[Maulin Vasavada]

HI Sean
I guess you are correct in your assumption. Its really difficult to obfuscate classes that are referred by xml files and all.
I guess even if there exist a solution it would have to be from the app server provider who knows the xml files generated specific to the provider etc...
Still, I would believe that there would be some parts in the whole deployment that can't be obfuscated partly due to the reason that they are meant to be in user friendly form
Regards
Maulin

[Maulin Vasavada]

Hi Moderators,
I have encountered the following error while posting the above message. Please have a look.
----------------------------------------------------
Sorry, UBB has encountered an unexpected, fatal error. This error is extremely abnormal. Please contact the board administration. The error text is:
/home/vhost1/saloon.javaranch.com/vroot/html/ubb/Forum1/forum_1.threads: Expected to write out 204714 bytes, but file on disk is only !]
Here is the backtrace:
Backtrace: ubb_lib_filehandle.cgi:185 -> sub UBB::FileHandle::tracer
Backtrace: ubb_lib_filehandler.cgi:132 -> sub UBB::FileHandle::close
Backtrace: ubb_lib_files.cgi:411 -> sub UBB::FileHandler::close
Backtrace: ubb_lib_files.cgi:65 -> sub main::WriteHashToFile
Backtrace: ubb_lib_posting.cgi:145 -> sub main::UpdateForumTopics
Backtrace: ubb_new_reply.cgi:469 -> sub main::update_forum_summary
Backtrace: ultimatebb.cgi:645 -> sub main::submit_new_reply
----------------------------------------------------
Regards
Maulin

[Jeroen Wenting]

You want your code to be invisible to the owners of the machine on which it is deployed???
Short answer: don't deploy your code to their machine.
If you're so paranoid you don't even trust your customers to the point that you want to hide your classnames from them, I suggest you find some other customers or better yet a different line of business (say, selling blunt knifes or rifles with the firing chamber welded shut).
Or if you want to remain in the software business, start up an ASP (application service provider) and host the software yourself, renting out serverspace and bandwidth rather than having the customers running their own servers.

[Sean Li]

Oh, man! be practical.
If you don't know how, just say sorry. Whether it's necessary or not is definitely not your business.

Originally posted by Jeroen Wenting:
You want your code to be invisible to the owners of the machine on which it is deployed???
Short answer: don't deploy your code to their machine.
If you're so paranoid you don't even trust your customers to the point that you want to hide your classnames from them, I suggest you find some other customers or better yet a different line of business (say, selling blunt knifes or rifles with the firing chamber welded shut).
Or if you want to remain in the software business, start up an ASP (application service provider) and host the software yourself, renting out serverspace and bandwidth rather than having the customers running their own servers.

[Jeroen Wenting]

I'm quite practical...
ANY file you send to a customer can potentially be used to figure out your deepest secrets.
If those secrets are so important that you want noone to know them, the only thing you can do is not send any files to anyone.
That means remote hosting of services in an environment controlled directly by you where only the data generated by your application ever reaches the customer in the form of text, html, or whatever format they can use.
If your level of paranoia extends to not wanting to take advise you don't like, that's your problem not mine.

[Sean Li]

Stop here. It's a place for discussig technology, not a place for argument. I don't want to waste my time and precious space of Javaranch. I quit.
But I still want somebody really know obfuscation and j2ee can continue to discuss this topic.

Originally posted by Jeroen Wenting:
I'm quite practical...
ANY file you send to a customer can potentially be used to figure out your deepest secrets.
If those secrets are so important that you want noone to know them, the only thing you can do is not send any files to anyone.
That means remote hosting of services in an environment controlled directly by you where only the data generated by your application ever reaches the customer in the form of text, html, or whatever format they can use.
If your level of paranoia extends to not wanting to take advise you don't like, that's your problem not mine.

[Jeroen Wenting]

All I said is that you cannot obfuscate things the way you want.
Either you take it or leave it, wishing there were a solution doesn't make it so...
You can of course create your package- and classnames to be meaningless gibberish, which is what obfuscation is all about in the first place, but they'd still be listed in deployment descriptors so anyone with access to those can see at least which are what kind of classes.
If you encrypt the war and ear files and provide a JVM that can use those encrypted files but not let the user decrypt them you might be able to prevent that, but to the best of my knowledge that would mean writing your own JVM.

[Sean Li]

As you said, no matter how, you can see which class is ejb or not. But it's ok. ejb is just a interface. If I don't put my business logic implementation in the session bean, use some util classes instead. and then obfuscate these classes. things are better.
To the entity bean. If I choose bmp as the solution. I agree it's hard. Even if I use jdo, people can still get all the connection information from the package.jdo file.
If some tool can change the change all package, class and method name(don't touch those methods used by ejb container ), and then write back to deployement discriptor. maybe it's good enough.
Writting a JVM is toooooooooo much inpractical. I would never take it.

[Vadivel Pm]

What you said that only correct. I did major research on it. All the classes which are directly used by jsp. So jsp is executed by the server during the runtime. During the obfuscation we cannot change the class name,package name and field names which are resides in jsp.
As per my knowledge we can make .jar file as obfuscator but those the jar files will not work in the jsp. I am sure in this.

Any one having the solution on it pl,give me. I will become so happy

Thanks Guys,

By Vadivel PM,

[Henry Wong]

Vadivel Pm wrote:What you said that only correct. I did major research on it. All the classes which are directly used by jsp. So jsp is executed by the server during the runtime. During the obfuscation we cannot change the class name,package name and field names which are resides in jsp.
As per my knowledge we can make .jar file as obfuscator but those the jar files will not work in the jsp. I am sure in this.

Also, obfuscating the generated servlet makes no sense ... as anyone (on the server) who can access the generated servlet, can also access the JSP code. Why would anyone want to steal the generated servlet code, when they can steal the JSP code instead?

As for the clients, they see neither the JSP, or the generated servlet. They only see the HTML/javascript that is generated by the servlet. So, there is no need to obfuscate the servlet, in that case also.

Henry

[Henry Wong]

Hmmm.... How about not exposing the JSP at all?

Is it possible to generate the servlet from the JSP, and then, obfuscate the servlet, prior to installing it on the untrusted server? Install the JSP on a trusted server, generated the servlet, obfuscate it, and repackage it as a servlet solution on the untrusted server.

Henry