"Quis custodiet ipsos custodes" - Кто будет сторожить сторожей?(лат) 

Теоретически можно (и нужно) настроить правила безопасности, которые будут запрещать доступ неподписаных (или подписанных неизвестно кем) приложений к критическим ресурсам. 
Но опять же возникает вопрос, поднятый в начале поста. Где уверенность, что программу безопасности не подменят? Где уверенность, что не подменят сам загрузчик Винды (или другой оси)...?

Зато сейчас полностью исключены случаи подмены библиотек (думаю не ошибусь, если скажу, что 70-80% действительно вредоносных вирусов этим промышляют), что уже, ИМХО, проело плешь всему Майкрософту вместе взятому. Не зря же они придумали систему проверки целосности/оригинальности системных библиотек.

P.S. $tatic, извини, не врубился (точнее невчитался) в твой вопрос, вот и ответил невпопад  

Ну я предполагал такую ситуацию: в программе есть защита (допустим она шароварная). Код программы находится в дллке (подписанной) и загружается загрузчиком, который проверяет ее подлинность. Если хакер взламывает дллку для сброса защиты, то подпись файла меняется и загрузчик сильно ругается . Так вот я имел в виду, что загрузчик тоже теоретически можно подменить, даже если и он был подписан. Тут все дело в том, что если пользователь использует кряк, то он знает, что ему придется отключать систему безопасности фреймворка.
Аналогичный случай наблюдался при взломе Windows XP SP1 крякером Reset5, когда недобросовестный  пользователь должен был загрузить систему в безопасном режиме, чтобы ему не мешала система проверки целостности библиотек SFC.
Конечно анализ обфусцированной программы выполнить очень сложно. Но хакеру надо найти именно тот участок, который ответственнен за защиту программы. Ему же не надо полный reverse engineering делать. Естетственно эту проверку можно спрятать среди кучи левых методов, но хакер ведь может получить полный исходник в виде проекта для студии (это может плагин FileDisassembler для Reflector), загрузить его в студию и запустить в режиме отладки. Ведь этот метод фактически недоступен при анализе программ в машинном коде.
А вот над измененным загрузчиком IL-кода стоит подумать.
ЗЫ. Хакеры давно уже научились обходить проверку подлинности библиотек. Читайте Криса Касперски.

Нормальный обфускатор не позволит дизассемблировать программу в высокоуровневый язык (будут кидаться ошибки), и всё что останется - декомпилировать и отлаживать IL-код, что практически равносильно анализу программ в машинном коде. Кстати, хороший пример защиты исходного кода - как скрыты исходники самого Reflector-а  .

Скажите кто каким обфускатором пользуется?

Пока серьёзным не приходилось пользоваться, DotFuscator community edition юзал.

Чё меня бесит, так это то, что если допустим в программе есть закрытая переменная с паролем, например

то этот пароль можно просто и без проблем выдрать из программы. Кто-нибудь пробовал открывать экзешник или дллку в блокноте? Даже слепой не сможет не заметить среди тучи слов вполне логичные password2server = 1234567890. Мне не понятен принцип работы обфускатора. Что изменится с исполнительными файлами и библиотеками программы? Будет ли виден пресловутый пароль через блокнот?  

Никто никогда не хранит такие данные в открытом виде. Чаще используют хеши (для сравнения) либо зашифрованные строки.

mr.DUDA, как можно хранить хэш, если базза требует именно пароль, а не его Хэш?
Аааа, ключевое слово --- "для сравнения", тогда понятно 

Поподробнее. Насколько сильно нужно их шифровать? Какой-нибудь циклический сдвиг (А->Б, ..., Я->А) подойдет?

некоторые обфускаторы шифруют строки. сорри, конкретных примеров не помню.

Чем круче алгоритм шифрования, тем лучше.
Ещё лучше - не хранить конфиденциальную информацию в теле программы.

mr.DUDA, а хде 
Чувствую   Хотя про защиту 

Скажи мне, ну нафига хранить секретный логин и пароль в проге ? К чему логин ? И пароль ?

Вот вам паранодиальный (для большинства задач) сценарий создания системы безопасности   

1) Создается private/public key pair
2) Им подписываются сборки
3) В сборках с помощью System.Security прописывается, чтобы вызывающий код был подписан, и чтоб public key подписи совпадал с public key из п.1
4) Все это обрабатывается обфускатором

Для клиент-серверной дополнительно шифруется траффик, например с помощью sink'ов. Для шифрования от сервера к клиенту используется public/private key pair из п.1. Для шифрования от клиента к серверу используется другой, временно создаваемый сервером, key pair. 

Все это добро работает под MS .NET 2.0. А теперь давайте попробуем этот сценарий хакнуть.

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

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