Какие части сборки проверяет подпись строгого имени

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

Я создал небольшое тестовое приложение, которое просто выводит имя сборки, подписывает его строгим именем, а затем добавляет к нему дополнительные значки. Ниже представлена ​​программа:

class Program
{
    static void Main(string[] args)
    {
        Console.WriteLine("My name is " + Assembly.GetExecutingAssembly().GetName());
    }
}

После того, как я изменю сборку, я все еще могу ее запустить, и она без проблем распечатает имя сборки с моим токеном открытого ключа:

My name is TestApp, Version=0.0.0.0, Culture=neutral, PublicKeyToken=cd4a03be895200fa

Теперь у меня вопрос: подписание строгого имени проверяет только некоторые части сборки, т.е. не хеширует ресурсы win32, или я совершенно не понимаю, как работает подпись строгого имени? Если моя сборка была изменена после подписания, разве она не должна перестать работать?


person Einar Egilsson    schedule 10.02.2012    source источник


Ответы (1)


Строгое имя состоит из идентификатора сборки - ее простого текстового имени, номера версии и информации о культуре (если предоставляется), а также открытого ключа и цифровой подписи. Он создается из файла сборки (файла, содержащего манифест сборки, который, в свою очередь, содержит имена и хэши всех файлов, составляющих сборку), с использованием соответствующего закрытого ключа.

Из документации строго именованных сборок

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

Хэши используются для предотвращения изменения файла сборки, поэтому, если вы измените скомпилированную dll (используя, скажем, HEX-редактор), она не будет загружена (поскольку хеш не будет совпадать). Но как только хеши совпадают и сборка имеет правильную подпись - горит зеленый свет.

person Alexey Raga    schedule 10.02.2012
comment
Но разве цифровая подпись не включает хэши ресурсов win32? Потому что кажется, что их совершенно нормально изменять после того, как сборка была подписана, и она по-прежнему работает без проблем. Каково ожидаемое поведение подписанной сборки, если она изменена? Можно ли его запустить? - person Einar Egilsson; 10.02.2012
comment
@EinarEgilsson, что произойдет, если вы попытаетесь установить эту исполняемую сборку в GAC? - person Lex Li; 10.02.2012
comment
@LexLi А, хорошо, вот и ошибка. Не удалось проверить подпись строгого имени. Таким образом, изменение ресурсов уничтожает сигнатуру строгого имени. Интересно, что .exe все еще можно запускать, я бы подумал, что он не сработает! - person Einar Egilsson; 10.02.2012
comment
Простой тест может сказать правду :) GAC как безопасное хранилище доверенных сборок выполняет строгую именованную проверку, когда вы пытаетесь добавить сборки, но Windows не выполняет такую ​​же проверку, когда вы пытаетесь запустить исполняемый файл. Authenticode - более надежная система проверки, чем сильное имя, если вы хотите изучить, msdn.microsoft .com / ru-ru / magazine / cc163583.aspx - person Lex Li; 10.02.2012