Repository navigation
how to make string unreadable or scrambled or obfuscated? #64
Description
Activity
By default the pattern for strings that are excluded from obfuscation is /.*/
:-D
We're happy to receive pull requests for this new feature. We consider it to be of very little value, to be honest, and that's why this has not been implemented for almost 20 years, now.aw, that's unfortunate for me. well, I guess I should wait for it. but it could help to make it more nonsense :)
@Dj-jom2x if you obfuscate strings you will need a mechanism to deobfuscate said strings at runtime. You would likely put this mechanism in your obfuscated JAR making it very vulnerable for reverse engineering. I would say the benefits clearly do not outweigh the hassle of implementation, but as @yGuy said we would not oppose to it as an additional feature via a PR.
I have the following anotation
@Around(value="methodsOfInterest()", argNames="ajc$aroundClosure")
but the
methodsOfInterestmethod got renamed.So is this a bug?
@adminy No, this is not a bug. yGuard does not adjust String literals that contain method or field names. Either exclude
methodsOfInterestfrom obfuscation or do not use annotations that work on member names. Essentially, the same rules that apply to reflection apply here as well.Reacted by AdminyHi everyone, I think we can add something like this: Simple string obfuscator. The idea is to replace the string with a new Object where the toString method is returning the correct string at runtime but I think it will crash the java decompilers. Do you think this will add value?
Why do you think that this would crash decompilers? This is completely legal java. It's just obfuscated in a very obscure way.
However disassembling the code, copy pasting it and running the piece of code will get you the clear results. I just pasted the sample code into an online java repl and it successfully returned "hello". So this will not crash decompilers.
Also this code will have a dramatic influence on the runtime because it will get rid of strings and instead recreate them for each and every usage (also destroying referential equality and thus possibly breaking your code).My stance on this (feature and implementation):
- of little use
- possibly breaks code at runtime
- definitely hurts performance
IMHO if we ever add something like this, we would need to make this opt-in on a per string basis. And then we can just as well use rot-13 or simply inline the bytes new String(new byte[]{1,2,3,4,5}) - all that matters is that the clear text is not in the code and cannot be grepped, after all. Rot-13 or even just byte encoding is not really less secure than the code produced by the Simple string obfuscator.
That said, we would accept pull requests if this is an opt-in and can be configured to not be applied to all strings.
Reacted by Marian TîrleaClosing as wont-do.
everything is obfuscated except for strings.. also can i exclude some strings not to be obfuscasted that has pattern too