VM structs' field read order different across samples.

[puff]

As with #4, this is because field order changes across samples, likely due to different Eazfuscator.NET versions being used.
This is an issue because reading the fields increments the position by the amount of bytes read. Since the amount of bytes read varies per field, this can result in invalid data or a crash.

The VM structs' fields need to be pattern matched where they are used and cross referenced with where they are set.

[puff]

Looking into this and found out the VM structs that holds those fields has the same order across samples and Eazfuscator.NET versions. Examples of this would be the VMMethodInfo, VMExceptionHandler, and (possibly) VMParameter structures.

This could definitely be used to find the field order. After mapping the struct's set methods to their respective fields, it would be trivial to determine the order these fields are set in their respective Deserialize methods.

Example: VMMethodInfo's VMLocals set method is the 2nd method in the class (ignore the constructor, it's generated by either de4dot or renaming in dnSpy, it can be filtered out anyway).

Knowing this, we can find the position in which VMLocals is set in the DeserializeMethodInfo() method:

We now know the VMLocals field is set in the 5th position.

This can obviously very easily be fixed in an Eazfuscator.NET update though, so it may be better to go with the original idea of pattern matching and cross referencing.

Edit: The BindingFlags AND operands are also scrambled across samples, however the order in the struct is the same:

Many constants also change, such as the VMInlineOperand type codes and VMExceptionHandler type codes.

[puff]

Another way to tackle this is to use profiles for each Eazfuscator.NET version. Since the read order and these constants change per version, and not per sample, it's possible to just create profiles for each version. The program could select the profile to use either by analyzing or could just bruteforce all profiles until one doesn't error.