-
Notifications
You must be signed in to change notification settings - Fork 89
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
object name overloading #34
Comments
That seems like a good idea. |
You can open a pull request if you want |
I want to ask a question that has nothing to do with the subject. I tried to multilingualize the neo-ConfuserEx. Use the VS2017 to open the prompt: Confuser.Runtime …… NETFramework,Version=v2.0 …… But Microsoft does not offer downloads SDK 2.0 (https://dotnet.microsoft.com/download/visual-studio-sdks). Could you tell me what I should do? Must it be based on .NET Framework 2.0? |
Runtime must always be compiled with lowest possible FW / Core (if you want to port it to Core) to ensure maximum compatibility. Here is a download link : https://www.microsoft.com/fr-fr/download/details.aspx?id=1639 Please, open your own issue for that kind of question, there is no problem i'm here to provide as much as as possible |
i like this idea ;) |
I'm migrating over to neo-ConfuserEx after using Dotfuscator for a while. I'm surprised that one of the features I liked from Dotfuscator didn't make it here.
When Dotfuscator renames objects, it combines objects of different types to the same name, so long as signatures don't overlap. For instance, you might have a namespace named "x", a class named "x", and several methods named x which all have different signatures: x(), x(string), x(int), x(string, string), x(StringBuilder, string, bool), and so on.
While long random names are hard to read, they are also unique, which lends itself to search-and-replace techniques. When you have 50 methods all named "x" that do completely unrelated things, it's a little harder to visually understand a project.
I've dabbled in reflection and types, and what I've seen makes me think .NET would already provide most of the info needed. As I understand it, .NET treats the name+signature as the complete name of any object. The internal structure for old-name vs. new-name might need to be made aware of this additional information.
V2 of this feature might further confuse things by identifying signatures that do not yet exist for a particular name, adopting some other method with the same signature, altering constants and control flow, and adding that to the mix. These additional methods could be called by dead branches of switch statements elsewhere in the code.
I'd be interested in contributing to this, though I'm not sure how.
Thanks for your work on this very useful tool!
The text was updated successfully, but these errors were encountered: