You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, this project does not support devirtualizing data virtualization. This isn't high priority though, as you can still see the plain data when analyzing statically.
Data virtualization replaces the fields with a structure, and setting/getting the variable with a method in the struct:
SetValue() encrypts the value and stores it in a field in the struct.
GetValue() returns the decrypted value.
From analysis, it seems these structs all share at least two things:
Using internal access modifier
A constructor with a single string argument (it's never called anywhere)
2.a. Primitive:
2.b. Reference:
From Eazfuscator's documentation, only primitive types, one-dimensional arrays of primitive types, and the following types are supported:
System.DateTime
System.Enum
System.Guid
System.String
System.TimeSpan
For detection of this, we could first look through the fields and find any that are structs. Then, look at that struct's constructor to check if it matches either the primitive constructor or reference constructor (see above screenshots).
Next, we would have to map the type with the struct.
For primitive types, we can either find GetValue() or use the field set in the constructor to get the type.
For reference types, this would have to be done by either finding GetValue() and using its' return type or finding SetValue() and using its only argument's type.
To find the GetValue() method, iterate through the struct's methods where the return type is not void and the instructions contain an ldfld to the encrypted field (which is always the field set in the constructor).
For the SetValue() method, search for a method in the struct where the return type is void, and contains a single argument. Then check if the instructions contain an stfld to the encrypted field (which is always the field set in the constructor).
Finally, once we've found the original type, it's as simple as replacing the field type and iterating through every method's instructions and replacing calls to GetValue and SetValue on these field structs. TODO: Check if custom getter/setters are compatible. Using access modifiers could help optimize this, for example, by only checking methods in the current type for private fields.
The text was updated successfully, but these errors were encountered:
Currently, this project does not support devirtualizing data virtualization. This isn't high priority though, as you can still see the plain data when analyzing statically.
Data virtualization replaces the fields with a structure, and setting/getting the variable with a method in the struct:

SetValue() encrypts the value and stores it in a field in the struct.
GetValue() returns the decrypted value.
From analysis, it seems these structs all share at least two things:
2.a. Primitive:
2.b. Reference:
From Eazfuscator's documentation, only primitive types, one-dimensional arrays of primitive types, and the following types are supported:
For detection of this, we could first look through the fields and find any that are structs. Then, look at that struct's constructor to check if it matches either the primitive constructor or reference constructor (see above screenshots).
Next, we would have to map the type with the struct.
For primitive types, we can either find GetValue() or use the field set in the constructor to get the type.
For reference types, this would have to be done by either finding GetValue() and using its' return type or finding SetValue() and using its only argument's type.
To find the GetValue() method, iterate through the struct's methods where the return type is not void and the instructions contain an ldfld to the encrypted field (which is always the field set in the constructor).
For the SetValue() method, search for a method in the struct where the return type is void, and contains a single argument. Then check if the instructions contain an stfld to the encrypted field (which is always the field set in the constructor).
Finally, once we've found the original type, it's as simple as replacing the field type and iterating through every method's instructions and replacing calls to GetValue and SetValue on these field structs. TODO: Check if custom getter/setters are compatible. Using access modifiers could help optimize this, for example, by only checking methods in the current type for private fields.
The text was updated successfully, but these errors were encountered: