2010-07-15 8 views
0

Насколько я понимаю, сильное именование создает криптографический хэш сборки, для которого используется как сильное имя для загрузки dll.C# Сильное именование dll, не обнаруживая модификаций

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

Это работает для некоторых изменений в двоичном формате, однако я нашел, что изменение бинарных, особенно статических строк в двоичном формате не приводит к тому, что приложение сообщает, что не может найти DLL соответствующего сильного имени.

Может ли кто-нибудь объяснить мне, какие данные из сборки используются для создания сильного имени, и почему сильное имя не всегда обнаруживает модификацию dll? Есть ли способ, которым я могу заставить его включить дополнительную информацию в сильное название?

Есть ли альтернативный способ я могу обнаружить повреждение двоичного кода?

Приветствия

Райан

ответ

0

Вы должны посмотреть здесь: Authenticode Signatures and Strong Name Signatures и How do I Sign .Net assemblies with Authenticode signature?

Эти две подписи полностью независимы друг от друга. Сильное имя помогает обеспечить уникальную идентификацию сборки. Authenticode позволяет проверить, кто автор сборки.

И

Если оба типа подписи применяются к сборке, сильное имя подписи обернут в подписи Authenticode. Это означает, что я могу изменить байты подписи Authenticode, чтобы он больше недействителен без аннулирования сильной подписи имени. Обратное неверно - изменение байтов сильной сигнатуры имени приведет к аннулированию как его, так и сигнатуры Authenticode.

+0

Спасибо за ваш ответ, но Authenticode рассказывает о подписании вашей сборки, чтобы указать, кто автор, кто они такие, и что этому программному обеспечению можно доверять. Моя озабоченность заключается не в том, чтобы доверять источнику, так как это программное обеспечение предназначено только для внутреннего использования. Я обеспокоен тем, что программное обеспечение должно использоваться в критическом процессе, поэтому мы хотим узнать, поврежден ли двоичный файл, чтобы мы могли сообщить оператору, что его необходимо переустановить. – Ryan

0

Насколько я знаю, хэш, используемый при сильном наименовании, включает весь файл, поэтому я не уверен, почему некоторые изменения не отключают проверку.

Есть ли вероятность, что ваша сборка добавлена ​​в список проверок?

+0

Нет, некоторые изменения, похоже, вызывают сильное именование, а другие нет. В частности, если я изменяю содержимое статически скомпилированных данных, таких как константы или строки, я не получаю предупреждения о невозможности найти DLL с правильным сильным именем, и приложение выполняется без жалобы, но вывод неверен. – Ryan

0

цифровая подпись, созданная при сильном именовании сборки хэш содержимого сборки, с исключением любого Authenticode Подписи, сильных данных имени Ассамблеи, и контрольной суммой заголовка PE, затем подписывает хэш закрытого ключа ,

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

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