Hey Erik... Just curious.. would you not have these problems at the "inner layers" too? Let us say ... I use Hibernate to persist my objects... since I would have to use xml mapping files between classes and database tables... I can not obfuscate my business/persistent objects as well in a straight forward fashion!
May be the obfuscation tool need to look for string references as well....in the same way as an advanced refactoring IDE would do... or something like that to make our life simple! :-) ~raghu On 12/9/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > I have used KlassMaster on distributions that contain Struts classes > before, and I took your approach as I recall. I didn't obfuscate Action > classes, but there was nothing important in them anyway. Also, KlassMaster > has a great scripting language for getting around the problems you mention, > and it knows how to edit web.xml, etc. In my opinion, it is well worth the > price ($400 for a single license last time I checked). > > Erik > > > -----Original Message----- > From: Raghu Kanchustambham <[EMAIL PROTECTED]> > Sent: Dec 9, 2005 4:38 AM > To: Struts Users Mailing List <user@struts.apache.org> > Subject: Re: [OT] obsfucating struts web application > > Laurie.. are you sure this will work? > > Let us say i have a mapping that maps to a TelephoneAction in my > strus-config.xml... the class name will get 'garbled' after obfuscation. > When a hit is made, the struts runtime will look up the TelephoneAction > class to forward the request and notices there is no class with that name > anymore! Whether bytecode or sourcecode obfuscation, this problem will > still > persist! > > One solution: Use the option *not* to obfuscate classnames of action > classes. > > But are we done? Not yet... what if we use dispatch action class? By > similar > logic, you should leave even your method names unobfuscated! So that isnt > too good... > > One of my friends suggested one ways to obfuscate the action class names > and > methods.As a part of obfuscation process generate a file containing > mappings > from old names to new names. Then based on this generated file, you can > write a script to work on config.xml to find and replace the unobfuscated > names with those from the mappings file generated. Some amount of work, > but > I guess it should work. > > The other approach is not to obfuscate action class names and method names > in them. Just do flow obfuscation on these action classes. Action classes > by > design would not have too much "business code" in them .. as they would be > delegated to some "business classes". Even if complex code (in terms of > number of lines) does exist in them, flow obfuscation will make it > difficult > to read them. If they are fewer number of lines, then it may be easy to > break flow obfuscation, but then in most cases the code would be so simple > that it is OK that the hacker knows it ! ;-) Since rest of the classes > (other than action classes) are obfuscated with out any constraints, you > should be safe... at most your action classes would be "broken" into. May > be > .. you can treat your action classes like the DMZ (demilitarized zone). > > Dont know if some tools support all what has been written so far. If they > do > someone please let us know! :-) > > Regards, > Raghu > > > On 11/20/05, Laurie Harper <[EMAIL PROTECTED]> wrote: > > > > su mo wrote: > > > Hi, > > > > > > I have STRUTS 1.2.7 based web application which I want to protect the > > > decompilation of class files. I would like to obsfucate the code using > > > JShrink or other obsfucating tools. > > > > > > I am wondering if anyone done this before to make the Struts 1.2.7based > > web > > > application work with obsfucated class files. > > > > > > I want to mention that I am using Dispatch action with parameters > > attribute, > > > so my method names and class names are clear text on the > > struts-config.xml > > > > A byte-code obfuscator should have no effect on the way a class runs. > > Unless you obfuscate at the source code level before compiling (which > > would cause all sorts of problems) you shouldn't need to worry about it. > > > > L. > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
