Net framework 5, а также среды Visual Studio 2012 и C#

46
Глава.1 .Модель.выполнения.кода.в.среде.CLR
ПриМеЧание
По.умолчанию.сборки,.загружаемые.с.локальной.машины.или.по.сети,.обладают.
полным.доверием;.это.значит,.что.им.разрешено.выполнение.чего.угодно,.включая.
небезопасный.код .Однако.по.умолчанию.сборки,.выполняемые.по.Интернету,.не.
получают.разрешений.на.выполнение.небезопасного.кода .Если.они.содержат.не-
безопасный.код,.выдается.одно.из.упомянутых.исключений .Администратор.или.
конечный.пользователь.может.изменить.эти.настройки.по.умолчанию,.однако.в.этом.
случае.он.несет.полную.ответственность.за.поведение.этого.кода 
Следует учитывать, что верификация требует доступа к метаданным, содержа-
щимся во всех зависимых сборках. Таким образом, когда вы используете PEVerify 
для проверки сборки, программа должна быть способна найти и загрузить все упо-
минаемые сборки. Так как PEVerify использует CLR для поиска зависимых сборок, 
при этом используются те же правила привязки и поиска, которые обычно приме-
няются при исполнении сборок. Эти правила будут рассмотрены в главах 2 и 3.
IL и защита интеллектуальной собственности
Некоторых разработчиков беспокоит, что IL не обеспечивает достаточного уровня 
защиты интеллектуальной собственности для их алгоритмов. Иначе говоря, они 
полагают, что кто-то другой может воспользоваться дизассемблером IL, взять по-
строенный ими управляемый модуль и легко восстановить логику кода приложения.
Да, IL-код работает на более высоком уровне, чем большинство других ассем-
блеров, и в общем случае дизассемблирование IL-кода выполняется относительно 
просто. Однако при реализации кода, работающего на стороне сервера (веб-служба, 
веб-форма или хранимая процедура), сборка находится на сервере. Поскольку по-
сторонний не сможет обратиться к сборке, он не сможет и воспользоваться любыми 
программами для просмотра IL — ваша интеллектуальная собственность в полной 
безопасности.
Если вас беспокоят распространяемые сборки, используйте «маскировочные» 
утилиты от независимых разработчиков. Такие программы шифруют все закрытые 
символические имена в метаданных сборки. Постороннему будет трудно расшиф-
ровать такое имя и понять назначение каждого метода. Учтите, что маскировка 
предоставляет лишь относительную защиту, потому что среда CLR должна в какой-
то момент получить доступ к IL-коду для его JIT-компиляции.
Если вы не считаете, что маскировка обеспечивает желаемый уровень защиты 
интеллектуальной собственности, рассмотрите возможность реализации более 
секретных алгоритмов в неуправляемом модуле, содержащем машинные команды 
вместо IL и метаданных. После этого вы сможете использовать средства взаимодей-
ствия CLR (при наличии достаточных разрешений) для работы с неуправляемыми 
частями ваших приложений. Конечно, такое решение предполагает, что вас не 
беспокоит возможность дизассемблирования машинных команд неуправляемого 
кода.

---