XenocodeRCE / neo-ConfuserEx

Updated ConfuserEX, an open-source, free obfuscator for .NET applications
http://yck1509.github.io/ConfuserEx/
Other
756 stars 89 forks source link

Does ver5 means version 4.5 and above (in Confuser.Runtime/AntiTamper.JIT.cs) ? #30

Closed Bonjour123 closed 5 years ago

Bonjour123 commented 5 years ago

Every thing is in the title :) Also, I would like to know:

1) If yes, then why not use Environment.Version.Minor ? 2) If yes, then I guess 17020 is the last revision before 4.5 ? 3) If 2, then the fact that index in the vtable of getMethodDefFromMethod changes according to ver4, ver5, !ver4 means that for each case, the CLR (because getMethodDefFromMethod is in the CLR, yes ?) changed. So it means one could get and use the version of the CLR to make the right adjustments ?

Precision: For 3), I'm talking about the HookHandler function

Bonjour123 commented 5 years ago

Up ? Could some of the authors answer please ?)

mkaring commented 5 years ago

I'm keeping closer track of my fork, so sorry for the delayed answer. All in all you're right. The revision numbers are used because they are more detailed than the values in environment. 17020 was the last release of the 4.0 framework. Version.Minor can’t be used because the Minor version is 0 for all .NET framework runtimes since 4.0. So detecting the actual running framework is not reliable anymore using Environment.Version.

In any case as of right now I do not recommend using the JIT mode for anti tamper, because it actually has to check the version of the currently active JIT compiler to work reliable. There are changes done to the vtable in the repo of CLR. I'm not sure if they only affect the .NET Core runtime or also the upcoming 4.8 release of the .NET Framework.

Bonjour123 commented 5 years ago

Ok, so now I understand why you didn't use Environment.Version :) Let's say I would like to know the index in vtable of getMethodName for a particular version (so that in turn I can make my code work for every version), how could I do that ? In other words, how did you get the particular index of getMethodDefFromMethod for a particular version, which in the end gave you the ability to make the code work for all versions ?

17020 was the last release of the 4.0 framework

Where can I get this type of information, I searched all over the net without result .

To I could sum up my question as "how and where to get header files for a particular version ?"

mkaring commented 5 years ago

Getting those revision numbers works best by setting up a virtual machine and installing the version you want to test.

The proper way to determine the vtable index is to get the version GUID of the JIT implementation. The coreclr code is open source. So you can find the values from the history of this project.

Bonjour123 commented 5 years ago

OK, I thought that there was maybe somewhere a file that would gather such info. Ok, so I will do as you say. Thanks a lot, you greatly helped me ! Just a last question: I remember a few days ago I tried to get the coreclr code for a particular GUID, and I couldn't find it by a simple research of github. Is there a way to have on github a folder with all the different versions of the coreclr ?

mkaring commented 5 years ago

I don't think so. I'm currently working on the same problem. I use the history of the JIT interface to get the versions and I use VMs to verify older versions.

XenocodeRCE commented 5 years ago

Bonjour,

In addition to what mkaring gently replied, I just wanted to quote original ConfuserEx coder :

https://github.com/yck1509/ConfuserEx/issues/281#issuecomment-146129767

Hello,
JIT Anti-Tamper is no longer supported due to massive incompatibility across different version of framework.

Not only that, but it has been shown to be an unefficient protection system : even if you make magically compatible antitamper JIT mode with current .NET Frameworks, all your effort will be gone since 1-click deobfuscation tools already handle that protections.

Also it would be better to re-write a full implementation of the Profiler API for C# to be able hook CompileMethod, instead of using shady bytes manipulations.

Bonjour123 commented 5 years ago

Yes, I knew there was the possibility to use the profiler API, but by laziness I guess, I didn't considered it. So I will have a little bit closer look on it :) Thanks a lot, both of you !

Bonjour123 commented 5 years ago

Something I didn't precised though is that my goal is to hook a function in an extern executable, do you still recommend me to use the profiler API ?

XenocodeRCE commented 5 years ago

So i'm gonna close that issue, as what you are looking for does not realy concerns ConfuserEx.

What you can look for are : differences between internal and external hook, process injection.