Open KvanTTT opened 3 years ago
:white_check_mark: Build ConfuserEx 829 completed (commit https://github.com/mkaring/ConfuserEx/commit/b4a38a059e by @KvanTTT)
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.
I'll try to explore more, but later.
Consider switching the PR to draft for the time being.
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.
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?
Unfortunately not. The same error that I've already described.
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.
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.
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:
The first one, extract a minimal example. Sure I can reproduce it on production since the exception exists 😊
Fix #379