У нас в конторе довольно долго обсуждались варианты защиты программного кода и в итоге был написан фрэймворк делающий примерно следующее:

1. После компиляции все модули системы пропускаются через encryptor, который читает сборки, получает тела функций, криптует их одним из алгоритмов шифрования и пишет обратно в сборку.
2. При запуске программы используем .NET Profiling Api позволяющий перед вызовом функции JIT компайлером получить тело метода, дешифровать его и "подсунуть" оригинальное тело метода.

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

Предвосхищая вопросы перфоманса могу сказать что он сильно зависит от алгоритмов шифрования, но практика показала что использование симметричных алгоритмов даёт приемлимый (для нашей системы) результат.

Хм, интересный способ, похоже на загрузчики Java. В Java это реализуется почти стандартно, а вот в .NET как? Исли можно пример или ссылки по теме.
Спасибо.

Почитать можно например здесь.

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

Вряд ли CLR позволит удалить из сборки таблицу метаданных  

Это был чисто теоретический вопрос    

это был чисто теоретический ответ   

Кто знает может это всё к лучшему...

сорсы дороже стоят, но в таком случае всем придется делать open-source проекты. 

Поднимаю тему опять


jfx, ты извини, но ты совсем не в курсе вопроса   
Сборку защищают для того, чтобы ее нельзя было подменить на другую  
Проверкой ключей и строгих имен заниматся прога (сборка) использующая защищенную сборку.
Если мы удалим publicKey из сборки, то прога будет ругаться на попытку подсунуть ей другую сборку вместо необходимой (защищенной ключем).
P.S. Повторяю еще раз: StrongName сборки нужно для защиты ее от подмены 
Если сделать хоть какое изменение в сборке мы теряем ее Строгое Имя. После этого все программы, которые используют защищенную сборку будут ругаться на измененную. 
P.P.S. Механизм подписывания сборок используется так же механизме предоставления прав сборке.
Например можно запретить неподписанным (ключем которомы мы доверям) сборкам доступ к реестру, диску С:  (можно вообще много чего запретить).
После этого если злоумышленник изменит код сборки, то он потеряет ее подпись, а следовательно и возможность навредить 

Почитал я 3-х летнюю дискусию, и возник вопрос рас уж так исторически вышло что всё можно дизасемблировать, а .нет можно ещё и декомпелировать, тогда КАК ЖЕ НАМ ПРОГРАМЕРАМ ПРИВЯЗЫВАТЬ НАШ ПРОДУКТ К ЖЕЛЕЗУ?

Ведь вся наша проверка видна декомпилятором и легко можно написать кейген используя наш код!!!

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

А что с етим в мире .нет?

Не забуддте про вопрос который набран ЗАГЛАВНЫМИ БУКВАМИ.

Rapalex, всё решается на самом деле очень просто. Есть такое слово: обфускация. И никакая декомпиляция не поможет 

Я когда-то устанавливал 9-Rays Obfuscator. Короче там была какая-то примочка, которая помимо обфускации что-то еще делала с бинарником, в результате чего сборку вообще нельзя было загрузить в любой декомпилятор. Они просто выпадают с ошибкой. Не только ILDasm, но и Reflector. Кстати сам 9-Rays Obfuscator именно этой фичей и защищен. 

А если хакер именно эту прогу и поломает? 
Может скомпилированную (и обфусцированную) прогу на .NET сжать каким-нибудь упаковщиком и обработать DotFix FakeSigner?
Да, и еще. Ведь при запуске проги на .NET управление получает вначале загрузчик, который уже потом запускает mscoree.dll. Можно ли сделать свой загрузчик, который вначале расшифрует код IL, а уже потом отправит его на выполнение?
Кстати если бы обфускаторы давали классам имена в юникоде из символов какой-нибудь "левой" кодовой страницы ИМХО было бы весело 

Они и так достаточно "левые", поди разбери что имеется ввиду в коде типа "a._b.c()._d(_e.a);" 

Теоретически, должно измениться ее строгое имя  

И где это будет проверено?