Необходимо защитить некоторые сборки от модификации (или, другими словами, как определить, модифицирован ли бинарный файл сборки после компиляции). Как я могу добиться этого в .NET 4.0 встроенными средствами .NET?
Проблема только в обнаружении модификации файла dll, а не в защите от декомпиляции, реверс-инжиниринга и так далее.
Вы можете использовать сборки со строгими именами (см. ЗДЕСЬ).
У них есть открытый ключ и цифровая подпись, и как только они будут изменены, они больше не будут загружаться JIT:
Строгие имена обеспечивают надежную проверку целостности. Прохождение проверок безопасности .NET Framework гарантирует, что содержимое сборки не было изменено с момента ее сборки.
НО, как упомянул Стив, это не совсем безопасно!
К сожалению, сильные имена обеспечивают защиту потребителя. Они не защищают разработчика сборки от того, что его код не был изменен. удалить строгое имя. После удаления его можно изменить по желанию.
Даже защита, предоставляемая потребителю, ограничена сильными именами. Поскольку центрального реестра открытых ключей нет, невозможно узнать, подписана ли сборка конкретным издателем. Хакеры могут изменить подпись и подписать ее своими ключами после внесения изменений. По правде говоря, сильные имена действительно защищают только от хакеров, изменяющих системные библиотеки времени выполнения ... даже тогда я не уверен, насколько они эффективны для реальной атаки на систему.
Поскольку код можно легко изменить даже при использовании строгого имени, добавление какой-либо простой проверки хэша ваш собственный код не обеспечит никакой дополнительной защиты. Единственный способ иметь хоть какую-то надежду — использовать инструмент защиты программного обеспечения профессионального уровня, который предлагает обнаружение несанкционированного доступа.
Строгое имя, подписывающее вашу DLL и использующее полное имя для ссылок ( включая подпись) должны помочь с этим.
Это не защита от дурака - кто-то всегда может разобрать не только DLL, но и любые другие приложения, использующие ее, и обновить эти ссылки на свою новую версию DLL.
Попробуйте подписать свои сборки цифровой подписью. Чтобы узнать больше, ознакомьтесь со статьей журнала MSDN Magazine Использование подписей со строгими именами. .
Я бы предложил сделать хэш сборок во время компиляции. Сохраните его где-нибудь в своем приложении и проверьте его во время выполнения с помощью нового вычисленного хэша сборки.
Как предполагает @Steve (и другие), процесс, использующий это, называется «Сборки со строгими именами».
