mkaring / ConfuserEx

An open-source, free protector for .NET applications
https://mkaring.github.io/ConfuserEx/
MIT License
2.31k stars 353 forks source link

Fix failed renaming due to blocking references (exclude from renaming) #385

Open KvanTTT opened 3 years ago

KvanTTT commented 3 years ago

Fix #379

AppVeyorBot commented 3 years ago

:white_check_mark: Build ConfuserEx 829 completed (commit https://github.com/mkaring/ConfuserEx/commit/b4a38a059e by @KvanTTT)

mkaring commented 3 years ago

This is very likely just fixing a symptom and not the actual issue. It relies on the entire structure being in a state that is correctly renamed for the runtime in that state, but this isn't guarantied. I'm guessing to have to work for sure, would be to revert all the names to the original name, to ensure that everything is still working fine.

From the classes/methods listed in the error message, it's not possible to identify the actual problem? It's very likely related to the inheritance structure in that case.

KvanTTT commented 3 years ago

I'll try to explore more, but later.

mkaring commented 3 years ago

Consider switching the PR to draft for the time being.

KvanTTT commented 2 years ago

This is very likely just fixing a symptom and not the actual issue. It relies on the entire structure being in a state that is correctly renamed for the runtime in that state, but this isn't guarantied.

BTW, I think symptoms fixing is better than not fixing them. At least output assembly will work if the first option is applied.

mkaring commented 2 years ago

The thing with this change is, that this is unlikely to work in many cases. The place where the obfuscation is interrupted in this case is at the point where parts of the structure that needs to be renamed as a whole, is already renamed. Meaning this is likely to still produce an illegal result.

@KvanTTT: Your issue is still present after #425 has been merged?

KvanTTT commented 2 years ago

Unfortunately not. The same error that I've already described.

mkaring commented 2 years ago

The property not being renamed anymore is the expected result of the change. The fact that you are still seeing an error, points to some part of the inheritance structure still being renamed. Any chance you could check the other types that are part of the inheritance and see if any property is still being renamed? For ease of searching you should be able to produce the same issue with the debug rename mode.

KvanTTT commented 2 years ago

Thank you for pointing out at debug renaming mode. Anyway, I still can not reproduce the issue. But I've noticed a prefix in erroneous property that I can not achieve in a test sample. I mean BaseHandler::Logger instead of just Logger in the correct program. Yes, it looks like it should not be renamed.

Also, I've noticed there is something strange with invalid metadata protection. There are different errors in invalid metadata protection turned on/off and renaming with renPublic=true is used.

mkaring commented 2 years ago

When you say you "can't reproduce it". You mean that you can't extract an minimal example to show the issue or that you can't reproduce the issue anymore in your production code? Bit confused about this one :wink:

KvanTTT commented 2 years ago

The first one, extract a minimal example. Sure I can reproduce it on production since the exception exists 😊