Improvement for "replaceClassNameStrings" to optionally replace partial paths

[bernhardf-ro]

Currently replaceClassNameStrings only causes complete strings of fully qualified class names to be modified. Would it be possible to add an option to also modify strings containing paths starting at the root, but not ending in a class? So for example when you have the following replacement: System.out.println("com.mycompany.MyClass"); => System.out.println("b.c.d"); the new option would also cause the following: System.out.println("/com/mycompany/resources/" + filename); => System.out.println("/b/c/resources/" + filename); There should probably be a minimum of two path segments and separators should be configurable, like for replaceContent. If this won't be included in the near future, could you point me to the code that modifies the strings, so I can have a look at it?

[Fohlen]

It would probably be best to add a regex here so the users can configure it to their liking

[thomasbehr]

The code that replaces class name strings is in com.yworks.yguard.obf.classfile.ClassFile#replaceConstantPoolStrings.

That said, "/com/mycompany/resources/" + filename" is not a class name and thus should not be affected by a feature called "replaceClassNameStrings". In my opinion, code along the lines of System.out.println("/com/mycompany/resources/" + filename); is a horrible anti-pattern which should not be used at all. Use Class.getResource and Class.getResourceAsStream or (if you need a package name string) use Class.getPackage and Package.getName. Aside from being the correct approaches to resource handling, both of these approaches are "obfuscation safe". If you really, really need yGuard to adjust strings like "/com/mycompany/resources/", put those strings in resource files and use yGuard's <adjust> element.

[bernhardf-ro]

Thanks, we'll have a look at the code.

However we still think this would be a valuable new feature (or a new, clearly named, sub-option). We use yGuard for both obfuscation and repackaging for a large code base as well as dependencies that we'd prefer to not have to change the sources of. More general package/path string correction would enable this and other new use-cases for yGuard.