Сильное присвоение имени сборке действительно не предназначено для защиты подписанной сборки. Он предназначен для защиты другой сборки, которая загружает подписанную сборку.
Например, если EXE является доверенным и хочет загрузить известную DLL из известного местоположения (например, GAC, сетевой ресурс, Интернет и т. Д.), Это можно сделать, используя строгое имя с некоторым уровнем уверенность в том, что сборка не была подделана.
Но, если весь набор сборок разобран, а затем повторно собран и подписан, то да, вы правы, они могли бы просто переписать строки кода, которые загружают остальные сборки, так, чтобы он загружался их с новым (поддельным) ключом.
Но этот вид вмешательства будет очевиден. Другими словами, строгое подписание имени является явным доказательством подделки, но не предотвращает его во всех случаях. Добавьте к этому тот факт, что локальный администратор может полностью отключить проверку строгого имени (в целях «разработки»), и очевидно, что подпись строгого имени не является пуленепробиваемым механизмом безопасности.
То же самое касается Authenticode и подписи драйверов. Мы все видели продукт, который инструктирует пользователей «игнорировать предупреждение системы безопасности». Это в основном то, что сделал бы EXE, если бы проверка строгого имени была отключена или подписи были удалены из всего набора сборок - это игнорировало бы предупреждение.