В последнее время я активно занимался изучением принципов обфускации и существующих приемов модификации кода, направленных на затруднение процесса реверс-инжиниринга .NET программ. Отчасти, результатом всего этого процесса исследования стал цилк статей “Как работают обфускаторы” (часть 1 (Переименование и шифрование), часть 2 (Изменения внутренней логики), часть 3 (Дополнительные возможности)). Данным циклом я занимался несколько последних месяцев. Если вы интересуетесь вопросами обфускации, крайне рекомендую его к прочтению. Статьи легко читаются и содержат много полезной и наглядной информации.
Однако одним только циклом дело не закончилось. Для того что бы прочувствовать все нюансы, которые возникают с процессе создания средства обфускации я пошел немного дальше и решил написать свой собственный .NET обфускатор. Результат не заставил себя долго ждать и уже в начале сентября я выпустил первый публичный релиз, спустя четыре с половиной месяца после начала работы над проектом. А через две недели выпустил небольшое обновление с исправлениями ошибок, которые были найдены и исправлены после релиза.
На самом деле на реализацию конечного продукта было потрачено с апреля по сегодняшний день всего лишь чуть более 160 часов. Поскольку у меня есть основная работа, времени на собственные проекты не так то и много. В связи с этим реализация обфускатора растянулась на несколько месяцев. Уверен, если бы я занмался проектом фул-тайм, мне бы с лихвой хватило трех-четырех недель на доведения проекта с нуля до того состояния которое есть сегодня.
Посмотреть на результат моих трудов и даже воспользоваться ими можно зайдя на сайт поддержки продукта. Ссылка на сайт: http://orangeheap.blogspot.com.
А теперь немного о том, как получилось то, что получилось, и, собственно, что же все таки получилось?
***
В основу работы обфускатора Orange Heap положен фреймворк CCI (Common Compiler Infrastructure – http://ccimetadata.codeplex.com) С помощью него осуществляется доступ к метаданным программы и производятся необходимые изменения. Для таких целей, помимо CCI существует еще как минимум один доступный инструмент: Mono.Cecil. Однако мой выбор пал именно на CCI. Я не знаю лучше ли он чем Mono.Cecil и если лучше то чем. В тот момент, когда я только начинал заниматься проектом, для меня оба фреймворка былы чем-то неизвестным и в процессе выбора я руководствовался принципом «пальцем в небо». Единственное что я знал, так это то, что на базе Mono.Cecil уже существуют решения, в том числе и коммерческие, которые позволяют осуществлять обфускацию. Фреймворк CCI был менее исследован, и отзывов о его использовании было гораздо меньше. Но, наверное, тот факт, что CCI разрабатывался Microsoft Research подтолкнул меня к выбору именно этого фреймворка.
Ну, хватит лирики, лучше продолжим дальше разговор об Orange Heap. Продукт состоит из двух частей: консольное приложение и Windows-приложение.
С помощью Windows-приложения, можно осуществлять конфигурацию процесса обфускации. Данный процесс конфигурации позволяет указать такие опции как: нужно ли переименовывать публичные элемента и неймспейсы, нужно ли зашифровывать строки, нужно ли склеивать защищаемые сборки в одну монолитную сборку.
Помимо этого можно указать каким образом должно осуществляться переименование элементов. На сегодняшний день существует две политики переименования: нечитаемые символы (Normal policy) (в дизассемблере или рефлекторе такие имена будут отображаться в виде квадратиков) или имена вида a1, a2,.. a14,.. a445 (Developer policy). Наличие двух политик переименования связано лишь с тем, что в процессе обфускации (не только с помощью Orange Heap но и с любым другим обфускатором, в том числе и коммерческим) программа может сломаться и перестать работать так, как она работала до этого. Если такая ситуация произошла, значит, очевидно, нужно как-то изменить процесс обфускации (например запретить что-то переименовывать или шифровать) и запустить его заново. Но в случае если все переменные, типы и методы отображаются в виде квардатиков – задача становится не очень тривиальной. В этом случае имеет смысл задавать имена в виде a1, a2, … Такие имена проще анализировать в процессе поломки программы средствами отладки. После того как причина поломки была устранена, можно вернуть «квадратики», обфусцировать программу и отдать ее на съедение врагам.
Помимо рассмотренных опций с помощью Windows-приложения можно также указать какие элементы должны быть переименованы, а какие должны остаться нетронутыми, то же самое касается и шифрования строк – для каждого метода, типа и сборки в отдельности можно указать, где нужно шифровать строки, а где не нужно. После того как процесс конфигурирования завершен Windows-приложение может запустить процесс обфускации на основании полученной конфигурации. При желании эту самую конфигурацию можно сохранить в конфигурационный файл. В этом случае ей можно будет воспользоваться в другой раз для запуска процесса обфускации без необходимости конфигурировать процесс еще раз.
Консольное приложение не имеет возможности конфигурировать процесс обфускации и может только использовать конфигурационный файл полученный в процессе конфигурации с помощью Windows-приложения. Для эстетов конечно, есть и тернистый путь – можно самому вручную создать или отредактировать конфигурационный файл, благо – это обыкновенный xml-файл, а в документации Orange Heap присутствует описание его формата. Однако, мне кажется, что Windows-приложение позволяет достаточно гибко осуществлять настройку процесса обфускации и вручную править конфигурауционный файл имеет смысл только если очень чешутся руки.
В процессе обфускации Orange Heap формирует файл-отчет – в котором содержится информация о старом и новом имени переименованного элемента. В данный момент эта инфорамция из файла будет полезна при анализе и исправлении возникающих проблем в обфусцированной программе. Однако я не исключаю того, что в будущем (и только в том случае если у меня дойдут руки до реализации подобной функциональности) данный файл может быть полезен при осуществлении де-обфускации.
В данный момент Orange Heap поддерживает обфускацию WinForm-приложений. По крайней мере в процессе предрелизного тестирования я успешно и беспрепятственно смог обфусцировать несколько достаточно больших WinForm-приложений. Если какие-то вопросы с обфускаций WinForm существуют - я буду очень рад о них узнать. Пока же никто мне подобной информации не предоставил.
WPF/Silverlight – пока terra incognita для Orange Heap. Если хотите проверить - даже не пытайтесь. Все равно ничего не получится. Но я не думаю что это большая проблема. Ведь по правилам хорошего тона UI и логика должны быть разделены. Поэтому можно просто XAML поместить в одну сборку – логику в другую. В этом случае сборку с логикой можно безболезнено обфусцировать, защитив тем самым вашу интеллектуальную собственность. Собственно сам Orange Heap так обфусцирован с помощью самого себя (Windows-приложение базируется на WPF).
Хорошая новость заключается в том, что несмотря на то, что подобную ситуацию можно решить описанным выше способом, я все же планирую добавить поддержку WPF/Silverlight. Реализация этой функциональности только лишь дело времени.
Вот пожалуй и все об Orange Heap. Надеюсь данная статья вызвала интерес и вы обязательно посмотрите как он работает на деле. Orange Heap – абсолютно бесплатный, поэтому не медлите, заходите на сайт поддержки, скачивайте и пользуйтесь. И, разумеется, пишите письма. Ведь только с помощью ваших отзывов я смогу узнать о наличии проблем и попытаться их исправить, а также сделать продукт более удобным и функциональным.
