Есть программный продукт, состоящий из EXE и около 10 dll файлов. Продукт сделан на C# под .NET4 . Обфусцируется SmartAssembly (который при обфускации естественно не меняет имена публичных функций и пропертей, описанных в DLL). Именя публичных функций и пропертей, описанных в DLL, делаем нечитаемыми (поскольку обфускация на них не влияет, и если их оставлять как есть - то легко станет понять что происходит в коде).

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

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

Нужны советы:
1. Как сделать анализ кода (например через Reflector) более затруднительным - чтобы проанализировать наш функционал было значительно дороже, чем воссоздать его с нуля.
2. Как усовершенствовать механизм активации, чтобы он был труднее для взлома?

p.s. Слышали про сервер (или программу) "###КОД" (или как то так называется), которая запутывает код класса,  может кто сталкивался

1. Мы изменили имена публичных фукнций DLL (там где не получилось сделать internal), но мы не меняли имена многих публичных пропертей (из DLL). Эти проперти используются обфусцированными функциями. Вопрос следующий: не получится ли у взломщика на базе открытых и понятных имен пропертей - дизассемблировать код обфусцированных SmartAssembly функций в читаемый?

2. Мы в коде оставляем много комментариев (в функциях и над ними). Не доступны ли они в конечной сборке?

Ответ на вопрос:  Как усовершенствовать механизм активации, чтобы он был труднее для взлома?
(Простой но Эффективный способ защитить программу)

Пользователь регистрируется на вашем ресурсе получая логин и пароль.

В вашей программе создается защищенное подключение к серверу авторизации (к примеру я использую Socket+OpenSSL)
через которое пользователь авторизуется используя свою учётную запись.

Через это же подключение проверяется наличие идентификатора в базе (например серийник CPU возведённый в степень серийника HDD в корне серийника MB). Соответственно если запись есть то аккаунт активирован.

Если нет то запускаем триал или к примеру предлагаем купить где в окне отображается идентификатор который нужно ввести
в личном кабинете на вашем ресурсе (собственно функция введения идентификатора в базу и будет продаваться).

Также через заданный интервал будет создаваться новое подключение все через тот же Socket+OpenSSL для проверки статуса активации, так как новое подключение содержит уже новые ключи это предотвратит от попытки проснифить трафик и подменить пакет. 
Как дополнение это подключение можно использовать для проверки если к примеру идентификатор имеет временное ограничение то программу можно завершить процессе её работы так как срок лицензии истек.



ИТОГ:
1) Идентификатор закрепляется за учетной записью.
2) В случае смены ПК идентификатор легко меняться через личный кабинет.
3) В случае кражи вашей учетной записи пользователь не сможет пользоваться программой так как у него другой идентификатор.
4) В случае кражи и учетной записи и подмены идентификатора (в данном случае подмена серийных номеров железа-"возможно на виртуальных машинах") достаточно сменить пароль от учетной записи.

Может что-то и упустил спрашивай.

Добавлено через 8 минут и 17 секунд

Все закоментированные строки компилятор пропускает.

Не знаю будет ли полезно и насколько применимо к шарпу - я тока на дельфях такое делал. Но думаю и тут вполне можно применить.

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