[6.1] Code Pruning Changes which Resources are Obfuscated
kevinmmccormick
Posts: 2
In our project we use a lot of reflection (primarily due to databinding in Windows Forms) so we decided to disable Code Pruning in SmartAssembly (adding the DoNotPrune to many of our classes became tiring and we have very little prunable code). We are using SA 6.1. We are not using Resource Compression/Encryption.
Upon disabling pruning, we noticed that another part of our code that picks up resources via Reflection stopped working.
We compared a pruned+obfuscated EXE with an obfuscated-only EXE and noticed that in the pruned EXE, *some* resources were not renamed/obfuscated, while in the obfuscated only EXE, *all* of the resources were renamed/obfuscated.
We also compared using DLLs and it seemed to have the same behavior: when pruning was enabled, some of the resources were obfuscated, but with pruning disabled, all of the resources were obfuscated. Here's the tough part: there doesn't appear to be any pattern to which resources are obfuscated, and which ones aren't.
We're not entirely sure why this is occurring, and we're kind of at a loss to figure out what to do.
Upon disabling pruning, we noticed that another part of our code that picks up resources via Reflection stopped working.
We compared a pruned+obfuscated EXE with an obfuscated-only EXE and noticed that in the pruned EXE, *some* resources were not renamed/obfuscated, while in the obfuscated only EXE, *all* of the resources were renamed/obfuscated.
We also compared using DLLs and it seemed to have the same behavior: when pruning was enabled, some of the resources were obfuscated, but with pruning disabled, all of the resources were obfuscated. Here's the tough part: there doesn't appear to be any pattern to which resources are obfuscated, and which ones aren't.
We're not entirely sure why this is occurring, and we're kind of at a loss to figure out what to do.
Comments
In executables, everything can be renamed and internalized. With DLLs, however, the behavior is different because of course renaming will break all the entry points and render it useless. So SA will not rename any methods or properties that have the "public" access modifier declared on them.