That could be interesting. I'll be looking into small optimizations first, like removing unnecesary branches, store/load operations -- something like shrinking on a bytecode level.
Cheers,
Eric.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Is there any news about this feature? I really would vote for it because it causes a lot of work to be done by hand before decompiled code is compilable again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm currently testing and documenting the new ProGuard GUI. Bytecode shrinking and optimisation are probably up next. Bytecode scrambling might follow later. I'd have to learn more about any adverse effects on the JIT compiler though.
As I'm working on ProGuard in my spare time, I'm setting my own pace and my own schedule. If you have special requests, you can always contact me.
Cheers,
Eric.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I understand that you're developing ProGuard in your spare time and so I'm requesting nothing, simply asking ;). But maybe it could be helpful to know that RetroGuard is using this technique.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm pretty sure RetroGuard doesn't apply byte code scrambling; the actual program code is left unchanged.
Perhaps you're thinking of the use of reserved java keywords such as 'for' and 'while' for class names, method names, and fields names? I don't have any immediate plans to implement this, because it is so easy to work around it.
Eric.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry for the confusion bringing here. You are right, I actually I meant using reserved words as identifiers.
But how to work around this that easy you say? At least it hinders freshly decompiled code to be compilable until it is precessed by hand I thought. Is there really an automatic way to quickly make the code valid again?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Good decompilers automatically detect these reserved keywords, or they at least provide an option to add a prefix to all identifiers.
Another solution is to obfuscate the code again, this time not using any reserved keywords.
Eric.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2004-03-14
I don't understand how byte code shrinking and optimisation help to obfuscate the code? I thought the whole point of obfuscation was to hide the meaning of the code. Maybe I'm missing something. I'm pretty new to all this.
Obviously this is your project and you can do what you want, but wouldn't the point of optimisation and code shrinking be part of a different project like "ProSpeedup" or something.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Shrinking and optimisation don't really help to obfuscate code, indeed. I look at it differently though: obfuscation and shrinking help to optimize code (memory-wise). I think optimisation is an interesting topic, so that is what I'm pursuing right now. ProGuard provides the right basis.
Eric.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Another neat feature would be byte code scrambling, which means, that byte codes are swapped randomly where it does not change the meaning.
Goal: fool decompilers like Jad, so they aren't possible to reconstruct, for instance, if-else, for-, do- and while-loops.
Cheers,
Tom
That could be interesting. I'll be looking into small optimizations first, like removing unnecesary branches, store/load operations -- something like shrinking on a bytecode level.
Cheers,
Eric.
Is there any news about this feature? I really would vote for it because it causes a lot of work to be done by hand before decompiled code is compilable again.
I'm currently testing and documenting the new ProGuard GUI. Bytecode shrinking and optimisation are probably up next. Bytecode scrambling might follow later. I'd have to learn more about any adverse effects on the JIT compiler though.
As I'm working on ProGuard in my spare time, I'm setting my own pace and my own schedule. If you have special requests, you can always contact me.
Cheers,
Eric.
I understand that you're developing ProGuard in your spare time and so I'm requesting nothing, simply asking ;). But maybe it could be helpful to know that RetroGuard is using this technique.
I'm pretty sure RetroGuard doesn't apply byte code scrambling; the actual program code is left unchanged.
Perhaps you're thinking of the use of reserved java keywords such as 'for' and 'while' for class names, method names, and fields names? I don't have any immediate plans to implement this, because it is so easy to work around it.
Eric.
Sorry for the confusion bringing here. You are right, I actually I meant using reserved words as identifiers.
But how to work around this that easy you say? At least it hinders freshly decompiled code to be compilable until it is precessed by hand I thought. Is there really an automatic way to quickly make the code valid again?
Good decompilers automatically detect these reserved keywords, or they at least provide an option to add a prefix to all identifiers.
Another solution is to obfuscate the code again, this time not using any reserved keywords.
Eric.
I don't understand how byte code shrinking and optimisation help to obfuscate the code? I thought the whole point of obfuscation was to hide the meaning of the code. Maybe I'm missing something. I'm pretty new to all this.
Obviously this is your project and you can do what you want, but wouldn't the point of optimisation and code shrinking be part of a different project like "ProSpeedup" or something.
Shrinking and optimisation don't really help to obfuscate code, indeed. I look at it differently though: obfuscation and shrinking help to optimize code (memory-wise). I think optimisation is an interesting topic, so that is what I'm pursuing right now. ProGuard provides the right basis.
Eric.