ConfuserEx
ConfuserEx copied to clipboard
mkaring
Optimizaton: Local variable reusage
Local variables are always declared for the entire method, but they may not be used for the entire method.
This optimization should reduce the local variables by analyzing the scope where the local variable is used. Two variables with disjoint scopes may be combined into a single variable, provided both are reference types or the same value type.
The challenge for this optimization is to properly detect the scope of the variables.
This "optimization" will reduce the size of the stack marginally. Also it is unlikely to have any measurable impact on the performance. How ever local variables that are being reused do not make for easier to read code. So if nothing else, it is something to make the deobfuscated sources a little harder to work with.
This sounds more like an enhancement for the compiler, not for an obfuscator.
There is no reason to have this done by the compiler for .NET that targets MSIL, as I am fairly certain that the JIT compiler does things like this anyway. It only makes the scope of the variables harder to follow, when you try to decompile the code and that is something an obfuscator should do. Plus is comes without any negative impact on the performance of the application and that is something that can't be said for most obfuscations.
I had this whole response typed out, then realized you were talking about the .NET compiler, not the JIT compiler, and now it all makes sense. I doubt it would save much space, of course, but it would be somewhat harder to trace that combined variable back to two original names.
I think this would probably interfere with the reversible rename obfuscations, wouldn't it? So I think if a reversible style is enabled, this optimization should disable itself or throw an error or something, on the assumption that reversible means you depend on the ability to map obfuscated names back to source names.
It won't interfere with the reversible rename, because local variables aren't subject to that anyway. The names of local variables aren't present in Release builds anyway. The decompilers can only reconstruct them using the *.pdb file. The decompiler usually just "guess" what the name of the local variable could be, based on the source of the value it's initialized by (if it's a method or a property) or just by the type.
This "guessing" doesn't make things easier in case the variable is reused, because it may be used in a completely different context later in the function.