Все началось, когда я захотел проанализировать код в CVE-2017-8759. Я знал, что исправление для CVE было в классе с именем WsdlParser.cs внутри System.Runtime.Remoting.dll, который является частью. Net Framework. Возможно, у вас есть эта dll на вашем компьютере в месте, похожем на:
C: \ Program Files (x86) \ Справочные сборки \ Microsoft \ Framework.NETFramework \ v4.7 \ System.Runtime.Remoting. dll
Я использовал ilspycmd для повторной сборки кода обратно в C# и заметил, что в выходном каталоге отсутствует WsdlParser.cs:
Позже я использовал CFF Explorer и увидел, что этот тип действительно отсутствует в метаданных в TypeDefs:
Однако я точно знаю, что этот класс существует:
- Это в документации Microsoft: https://referencesource.microsoft.com/System.Runtime.Remoting/metadata/wsdlparser.cs.html
При использовании отражений и LoadAssembly () I удалось найти класс:
Assembly assembly = Assembly.LoadFile(@"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.7\System.Runtime.Remoting.dll");
foreach (var type in assembly.GetTypes())
{
if (!type.FullName.EndsWith("WsdlParser"))
{
continue;
}
Console.WriteLine("Great Success");
}
Я заметил, что это поведение соответствует всем внутренним классам в этой DLL, но я не понимаю, как это имеет смысл. Я предполагаю, что может быть процедура пост-сборки для удаления данных внутренних типов, но если так, как я смог найти класс, загрузив сборку? Я думал, что CIL загружает типы, используя метаданные TypeDef, но есть ли дополнительное пространство, где хранятся эти данные?
Чтобы лучше это понять, я создал тестовый проект C# с внутренним классом, и проверял метаданные с помощью CFF Explorer. Внутренний класс был там, как и должно быть, в отладочной и сборочной версиях.
Так что же это за вуду?
Спасибо, ребята.