Каковы рекомендации по подготовке проекта (продукта) к обфускации?

Быстрое развитие мультимедиа и Интернет технологий в последние годы вызывает потребность в защите такой интеллектуальной собственности, как программные продукты (ПП).

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

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

Не стоит путать проектирование с программированием. Какие факторы необходимо учитывать?  Типичной обфускацией является символьная – когда обфускатор только и всего изменяет названия типов, полей, методов, свойств и событий на бессмысленные. Тип Obfuscator переименовывается в 0, а его метод Run() – тоже в 0, а параметры методов просто перенумеруются – 0,1,2,3,4. После подобной обфускации теряется логическая связь между классами, дизассемблированной код – трудночитаем.

Если необходимо обфусцировать замкнутую систему – тогда подойдет полная обфускация, когда изменяются все названия членов сборки, и в этом случае концы найти на порядок гораздо труднее чем в случае, когда кое-какие методы, типы остаются не обфусцированными (такое возможно при обфускации exe-файлов не использующих Reflection).

Кроме символьной обфускации есть еще обфускация алгоритмов методов – когда простейшее умножение I*3 может быть представлено более сложным алгоритмом, например – I*((1+1/2)*2) или запутаны while и for. Редко можно встретить полностью замкнутые, автономные системы, поэтому типичным случаем будет являться частичная обфускация. Хотя идеальной задачей для более качественной обфускаци будет являться как раз написание максимальной замкнутой системы сборок.

Рекомендации по подготовке проекта (продукта) к обфускации:

1. Для усложнения дизассемблирования  можно использовать подмену типов (которую не всегда возможно реализовать из-за sealed типов) Имеется ввиду такой приемчик – некий системный тип SomeType наследуется в новом типе AnotherType, который подходит для обфусцирования (он лежит в пределах видимости сборки, его можно назначить как internal).  На выходе получается испоьзование SomeNamespace.0 вместо известного System.SomeType. Если планируется использовать некоторые типы как публичные но хотелось бы их максимально защитить, стоит их поместить в «защитную скорлупу» наследования. Некий тип public SomeType можно превратить в два класса : internal _SomeType (underground class), который несет всю реализацию класса, кроме публичных свойств, необходимых для сериализации и для использования во внешнем для сборки коде, и public SomeType, который будет наследоваться от _ SomeType (front class), но нести внешнюю нагрузку – иметь публичные свойства, необходимые для сериализации, конверсии, использования во внешнем для сборки коде.
2. Используются атрибуты в коде. Многие из них достаточно тесно помогают взаимодействовать среде .Net с классами. Например атрибут TypeConverterAttribute – им привязывают к классу класс конвертера SomeConverter. Не каждый обфускатор «знает» об этом – и поэтому стоит уберечь класс конвертера от обфускации или проверить как обфускатор работает с атрибутами. Иначе связь, установленная между двумя классами посредством атрибута может быть разрушена.
3. Если класс идет под обфускацию, необходимо задуматься о механизме его сериализации. Класс- наследник Form сериализует себя таким образом что если обфускатор изменил имя его типа SomeForm на 0, то возникнет проблема при инициализации десериализации такого класса – он просто не сможет найти ресурс 0.resources, так как сериализовался в в SomeForm.resources.
4. Используется так же static string обьявления вместо const string – это затруднит поиск инициализации этого поля (в метаданных оба обьявления будут представлены как поля).
5. Если имеется список строк, которые  представлены как список строковых констант, лучше список строк обьявите/ опишите как строковый массив, а в константах храните индекс к необходимой строке в строковом массиве.
6. Если  необходимо защитить некий алгоритм от лишнего просмотра – необходимо отдайть его выполнение нескольким классам, этим распределяем задачу задачу, может быть разгружаем память.
7. Стоит переложить выполнение алгоритмов не одному методу, а части алгоритма передавать в выполнение различным классам, фактически выполнение алгоритма будет являться взаимодействием нескольких классов.
8. Необходимо инициализировать классы формы без использования .resx и .resources файлов — к ним лучше обращаться по индексу во избежание проблем при обфускации ресурсов.

После обфускации:

1. Обязательное тестирование обфусцированной сборки.
2. После обфускации, обязательно проверить сборку утилитой peverify, которая идет с .Net Framework SDK – эта утилита проверяет метаданные сборки на корректность. Если сборка помечена как CLS-compliant – это тестирование обязательно. 
3. Обязательно обратить внимание, как обфусцирован сам обфускатор.
4. Создается тестовый проект, который быстренько протестирует сборку .

Источники информации:

• Обфускация. Википедия.
• Обфускация и защита программных продуктов.
• Обфускация — есть такое слово. Исходники ру. Язык программирования.