Как проверяется эталонная сборка, чтобы проверить, не была ли она взломана?

Question

Этот вопрос касается проверки сборки, чтобы проверить, не была ли она подделана для злонамеренной деятельности. При создании сборки создаются метаданные. Метаданные включают таблицы, такие как таблицы определения типов, таблицы ссылок на типы и таблицы манифеста. Справочные таблицы содержат запись для каждой ссылки на сборку, а запись содержит сборку, на которую имеются ссылки, ее открытый ключ и значение хеш-функции. Манифест содержит сведения о сборке, на которые ссылается каждая сборка, и включает в себя имя сборки, ее открытый ключ и алгоритм хеширования. Я также понимаю, что во время выполнения, когда сборка загружается, она генерирует цифровую подпись сборки с открытым ключом, встроенным в манифест, и сравнивает ее с цифровой подписью, уже встроенной в сборку. Если цифровая подпись совпадает, то она загружается. Мои вопросы ниже.

1. Таблица метаданных Ссылка на сборку включает HASH. Также упоминается, что он не используется. Тогда какова его цель?
2. Эта проверка сборки происходит каждый раз при загрузке сборки?
3. Что произойдет, если оно не печатается строго?

Answer 1

1. Хороший вопрос.

На самом деле,

"Общеязыковая среда выполнения также выполняет проверку хэша; манифест сборки содержит список всех файлов, составляющих сборку, включая хэш каждого файла в том виде, в каком он существовал на момент создания манифеста. При загрузке каждого файла его содержимое хэшируется и сравнивается со значением хеш-функции, хранящимся вманифест. Если два хэша не совпадают, сборка не загружается. "http://msdn.microsoft.com/en-us/library/ab4eace3.aspx

но ...

"Каждая запись (таблицы метаданных AssemblyRef) также содержит некоторые флаги и значение хеш-функции. Предполагалось, что это значение хеш-функции должно бытьконтрольная сумма битов ссылочной сборки. CLR полностью игнорирует это хеш-значение и, вероятно, продолжит делать это в будущем. "Джеффри Рихтер, "CLR via C #", 3-е издание.

И в соответствии с моими частными исследованиями сборок .Net 4.0 - хэш-суммы действительно игнорируются на этапе привязки сборки, даже если сборка была подписана крипто-ключом ипоэтому имеет строгое имя.

Через некоторое время я понял, что функция обхода строгого имени вызывает такое поведение.Поэтому вам нужно «создать запись DWORD со значением 0 с именем AllowStrongNameBypass в ключе HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft.NETFramework», чтобы включить проверку строгого имени (+ hashsum).

Answer 2

1: нет, он используется.Ecma-335, раздел II, глава 6.2.3 о директиве .file:

Байты после .hash определяют значение хеш-функции, вычисляемое для файла.VES должен пересчитать это хеш-значение до доступа к этому файлу и сгенерировать исключение, если оно не совпадает.Алгоритм, используемый для вычисления этого значения хеша, задается с помощью алгоритма .hash (см. Пункт 6.2.1.1).

2: Только если проверка строгого имени включена.Обратите внимание, что по умолчанию он отключен, поскольку .NET 3.5 SP1 в сценариях полного доверия.Вы должны явно включить его с помощью caspol.exe

3: при условии «строгого имени» проверка невозможна.