Эволюция защиты .Net-программ

Не секрет, что защита .Net-программ представляет собой значительную трудность из-за их большой открытости. Во-первых, из них совсем просто восстановить исходный текст программы на языке высокого уровня C# или Visual Basic. Даже имена классов и методов будут точно как писал разработчик этой программы! Во-вторых, такие программы не содержат коды команд процессора х86, Pentium, AMD и т.п. Там совсем другие команды на языке MSIL (Microsoft Intermediate Language — промежуточный язык, разработанный фирмой Microsoft для платформы.NET Framework).

В процессе работы они преобразуются так называемым JIT-компилятором в команды процессора и затем выполняются с обычной скоростью. В результате, применение таких методов защиты как для обычных программ (их еще называют Native-программами, программами на родном языке процессоров) невозможно в принципе. Т.е. все предыдущие технологии защиты исполняемых файлов абсолютно неприемлемы для .Net и необходимо создавать новые!

Когда два года назад мы осознали необходимость создания простого (автоматического) средства защиты .Net-программ, мы не сразу поняли, что придется начинать все заново. В результате проведенного в 2006 году исследования этого рынка было выяснено, что хороших защит таких программ электронными ключами просто не существует! Очень легко снимается дамп памяти, и они восстанавливаются в незащищенном виде.

Сделать защиту оказалось так сложно и трудоемко, что до сих пор нет ни одной защиты .Net-программ с привязкой к электронным ключам, чтобы они не взламывались за 10-20 минут работы специалиста по взлому! Точнее не было, пока мы не выпустили новую версию защиты .Net-программ в нашем релизе версии 5.3. Теперь взлом по настоящему трудоемок, особенно, если защищать с помощью новых электронных ключей Guardant Sign, которые шифруют трафик обмена между защищенной программой и ключом на сеансовых ключах.

Новая версия программы защиты .Net-программ обладает мощными возможностями. Вот их краткий список:

• Перемещения кода методов в защищенный контейнер, откуда они берутся только когда должны быть исполнены, при этом они ненадолго остаются в памяти т.н. домена в доступном виде. Теперь невозможно «сдампить» все приложение целиком;
• Максимальное применение принципов защиты Native-кода там, где это возможно. Поскольку методы защиты Native-кода гораздо лучше проработаны, анализ и взлом такого кода более трудоемок;
• Защита сложных проектов, которые включают в себя множество DLL-файлов;
• Шифрование строк через электронный ключ;
• Защита не только EXE, но и DLL — файлов;
• Обфускация имен и классов.

Конечно, всегда есть что совершенствовать, но можно утверждать, что на данный момент это самая совершенная автозащита для .Net-программ электронными ключами. Мы будем стараться ее совершенствовать и всегда идти на шаг впереди взломщиков.