The game includes an assembly resolver that is poorly thought out, and it causes numerous TypeLoadException errors.
When looking to resolve a requested assembly, the game's resolver searches the AppDomain's list of loaded assemblies and looks for the the first assembly whose name matches the beginning of the requested assembly. It ignores version, culture and public key token. This behaviour violates Microsoft's primary advice in the What the event handler should not do section of the Resolver documentation.
This results in the following wrong matches:
a loaded assembly named 0H or 0 of any version would be seen to match a request for 0Harmony[1.2.0.1]
Suppose a mod provided DLLS named a.dll, b.dll, c.dll and so on, covering all possible prefixes. which can be completely empty. These malicious dlls would be returned as matches for the harmony library being requested, and for every other assembly that is requested. This is a hijack vulnerability.
a loaded assembly named 0Harmony[2.0.4.0] would be seen to match a request for 0Harmony[1.2.0.1]
Here the change in major version number indicates that the 2.0 version is not a compatible replacement for the 1.2 version. Communicating this incompatibility is the very purpose of incrementing the major version number, and by matching based on name alone, the game causes a TypeLoadException when the caller attempts to use the returned 2.0 assembly, thinking it is a 1.2 assembly.
There are some mods, like Network Multitool by @MacSergey which use this hack to publish the en localization as a default in an fake assembly named NetworkMultitool.resources, Version=1.2.0.3, Culture=en which does does not exist. The resources the mod wants are instead in the assembly NetworkMultitool, Version=1.2.0.3, Culture=neutral which does exist. The mod relies on the resolver behaviour that "any assembly, of any version, that is named 'N.dll' or 'Ne.dll' or 'Network.dll' is a match for a request for NetworkMultitool.resources of any version, and also for NetworkMultitool.real"
The Harmony mod will treat this class of bug in mods as "exploit of a vulnerability", but will allow it as deprecated behaviour until version 1.1 to allow affected mod authors to clean up their mods.
The game includes an assembly resolver that is poorly thought out, and it causes numerous
TypeLoadExceptionerrors.When looking to resolve a requested assembly, the game's resolver searches the
AppDomain's list of loaded assemblies and looks for the the first assembly whose name matches the beginning of the requested assembly. It ignores version, culture and public key token. This behaviour violates Microsoft's primary advice in the What the event handler should not do section of the Resolver documentation.This results in the following wrong matches:
0Hor0of any version would be seen to match a request for0Harmony[1.2.0.1]a.dll,b.dll,c.dlland so on, covering all possible prefixes. which can be completely empty. These malicious dlls would be returned as matches for the harmony library being requested, and for every other assembly that is requested. This is a hijack vulnerability.0Harmony[2.0.4.0]would be seen to match a request for0Harmony[1.2.0.1]TypeLoadExceptionwhen the caller attempts to use the returned 2.0 assembly, thinking it is a 1.2 assembly.There are some mods, like Network Multitool by @MacSergey which use this hack to publish the
enlocalization as a default in an fake assembly namedNetworkMultitool.resources, Version=1.2.0.3, Culture=enwhich does does not exist. The resources the mod wants are instead in the assemblyNetworkMultitool, Version=1.2.0.3, Culture=neutralwhich does exist. The mod relies on the resolver behaviour that "any assembly, of any version, that is named 'N.dll' or 'Ne.dll' or 'Network.dll' is a match for a request forNetworkMultitool.resourcesof any version, and also forNetworkMultitool.real"The Harmony mod will treat this class of bug in mods as "exploit of a vulnerability", but will allow it as deprecated behaviour until version 1.1 to allow affected mod authors to clean up their mods.