My revelation. sharcUs

Два слова о параллельной обработке связанных списков

2012-01-27T13:13:00.002+02:00

Предлагаю отказаться от последовательных связанных списков в пользу древовидных структур для всех случаев использования неупорядоченных данных при их паралельной обработке.

Связанный список – это динамическая структура данных, которая используется для хранения линейной коллекции данных (как правило неупорядоченных). Простейшая вариация такого списка предполагает только наличие «головного» указателя, ссылающегося на первый элемент списка. Каждый элемент состоит из данных и указателя на «следующий» элемент коллекции. Если этот указатель нулевой (NULL или соответствующий эквивалент), то это является индикатором того, что данный элемент – последний в списке. Для предоставления более быстрого доступа к требуемому элементу в списке могут использоваться дополнительные указатели. Примером такого указателя может быть «концевой» указатель, ссылающийся на последний элемент. С его помощью можно увеличить скорость выполнения операций добавления элементов в конец списка.

Для чего можно применять такой список и чем хуже обычный массив? Связанные список не предоставляет произвольного доступа к любому элементу в списке, однако позволяет добавлять новые элементы, удалять или переупорядочивать существующие за время О(1). И здесь нету никаких ограничений на количество элементов в списке, кроме, разумеется, естественных ограничений доступной памяти в системе. Таким образом, учитывая ограничения по доступу и перемещению данных, массивы и связанные списки взаимодополняемые структуры. Разработчики программного обеспечения вправе сами решать какая из структур лучше походит для применения в той или иной ситуации.

А имеет ли смысл использовать связанные списки в наши дни, с приходом эпохи параллельных вычислений? Дэн Гроссман из университета Вашингтона, говорит: «Нет». Впервые я услышал об этом заявлении от коллеги, который готовил презентацию с професором Гроссманом на конференции SIGCSE. Суть заявления сводится к тому, что везде где может использоваться связанный список, его использование можно заменить на использование дерева. Давайте попробуем разобраться насколько данная идея имеет смысл.

Связанный список последовательная структура данных которая очень хорошо подходит для последовательной обработки данных. Дерево отлично вписывается в идиому параллелизма fork-join, о которых я писал в своих предыдущих публикациях (прим. переводчика – см. публикации Клэя на http://drdobbs.com). Как и в случае со связанным списком, дерево может динамически изменять свою структуру. Время необходимое на добавление нового элемента не будет постоянным, однако в случае с упорядоченным деревом оно не превысит О (log n), что намного лучше алгоритма со сложностью O (n), когда имеется два указателя и их необходимо переместить в самый конец списка для добавления нового элемента. А что по поводу других операций, для которых может применяться связанный список? Могут ли эти операции также успешно использовать вместо списка дерево при параллельных вычислениях? Ниже представлены некоторые операции над связанным списком подбного рода и примеры того, как они могут быть «сэмулированны» с использованием дерева.

Обработка всех элементов. В последовательном процессе, для обработки каждого элемента в связанном списке, необходимо начинать с «головного» элемента, выполнять над ним требуемые операции, передвинуть указатель на следующий элемент и повторять данный процесс до тех пор пока не будут выполнены требуемые операции над последним элементом списка. Если в выполняемые операции не вовлечены другие элементы списка, то операции над элментами можно выполнять паралельно в разных потоках или процессах. Если данные упорядочены в виде дерева, то в таком случае до или после обработки текущего элемента можно параллельно в отдельном потоке выполнить обработку дочерних узлов текущего элемента. Как только некоторое пороговое количество активных отоков достигнуто, новые потоки перестают создаваться до тех пор пока запущеные процессы обработки не будут завершены.

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

Поиск. В данном случае, я имею ввиду неупорядоченный поиск. (Если у вас есть отсортированные данные, то в таком случае одного потока будет более чем достаточно для того, что бы спустится вниз до требуемого элемента, создание отдельных потоков в этом случае выглядит более чем избыточным). Для бинарного дерева существует три алгоритма поиска: preorder, inorder и postorder. Все они являются рекурсивными, а значит этот процесс можно оптимизировать с использованием нескольких параллельных потоков. Если вы не знакомы с данными алгоритмами, настоятельно рекомендую с ними ознакомится.

В другом случае необходимо найти уникальный элемент в коллекции данных. Здесь наиболее сложным моментом при реализация параллельного поиска будет необходимость проинформировать задействованные в поиске потоки о том, что поиск завершен, остановить их выполнение и убедится в том, что все потоки поиска ожидающие запуска не будут активированны. С другой стороны, если поиск должен быть полным, то есть в результате его выполнения может быть найдено несколько копий желаемого элемента, останавливать потоки при находжении первого элемента не требуется.

Эмуляция очереди или стека. И в первом и во втором случае, вставка и удаление данных осуществляется по общему принципу. Подобно тому, как связанный список используется для эмуляции очереди или стека, при использовании дерева для подобных задач необходимо убедится что когда несколько потоков пытаются вставить или удалить некоторый элемент, то доступ к структуре дерева должен быть таким, что бы гарантировать, что данные не будут потеряны, повреждены или продублированы в процессе выполнения данных операций. (Я надеюсь что все это я мог бы и не рассказывать, так как вы и так все это знаете и без меня.)

Как и с эмуляцией стека и обыкновенной очереди, очередь с приоритетами может быть реализована посредством структуры «кучи» (еще одна структура данных о которой можно почитать на досуге) на дереве. Непосредственная реализация обыкновенной очереди и стека будет незначительно сложнее, если ее осуществлять на базе дерева. Стоит учесть, что параллельное выполнение потоков на данных структурах может быть недетерминированным (в то время как вывод - детерминированным). Даже если мы используем связанный список для стека с параллельным вычислением, из-за самой природы параллелизма, порядок обработки элементов в нем в большинстве случаев будет неопределенным (если алгоритм требует некоторой упорядоченности при обработке элементов стека, о параллельных вычислениях придется забыть). Итак, поскольку у нас есть методы для безопасной вставки и удаления элементов данных, их можно приспособить к работе с любыми реализациями деревьев.

Смог ли я убедить вас в том что имеет смысл отказаться от последовательных связанных списков в пользу древовидных структур для всех видов неупорядоченных данных в случаях, когда допустима их параллельная обработка? По крайней мере я убедил в этом себя. Это выглядит хорошей идеей и я выделил для себя агрументы описанные выше, но у меня еще не было возможности использовать эту идею на практике. Поэтому мне было бы интересно узнать о наличии каких-либо операций над данными, которые традиционно используются при работе со связанными списками, и которые не могут быть реализованы в случаях использования деревьев. Первое что пришло мне в голову – списки упорядоченные по частоте использования (frequency ordered list). Однако, эта структура базируется на последовательном доступе к элементам и последовательном упорядочевании запросов поиска. А вы можете назвать методы/алгоритмы доступа к списку, которые могут выполнятся параллельно, но требующие последовательного связанного списка или такой структуры данных, которая не могла бы быть реализована с использованием дерева?

By Clay Breshears, January 17, 2012

Десять способов потерять ценных сотрудников

2011-12-27T16:48:00.001+02:00

Сложно ли таким выдающимся IT-компаниям как Yahoo! или более выраженным конгломератам таким, как, скажем, General Electrics или Home Depot сохранять свои лучшие кадры в неприкосновенности. Не так давно на GigaOM обсуждались проблемы Yahoo с ее бесприбыльным графиком рыночной строимости, бенефитами отдельных «звезд» внутри компании и утечками лучших кадров на неизвестные стартап-проекты.

И еще, имеют ли подобные компании какие-либо преимущества по удерживанию своих талантов. Я могу отметить как положительные, так и отрицательные моменты, которые присутствуют в управлении талантливыми сотрудниками в больших компаниях. Вот мой список топ-10, пункты которого «помогают» компаниям потерять свои таланты.

1. Бюрократия большой компании. Это пожалуй причина №1 которую мы слышим, после того, как ценные сотрудники покидают компанию. Но на самом деле, за этой причиной стоит некая иная причина. Никому не нравятся правила, которые не имеют смысла. Но когда таланты жалуются по этому поводу, это является знаком того, что они считают, что им не дали высказаться. Они может быть и говорили что-то ранее. Однако действительно талантливые сотрудники, обязательной сказали бы: «постойте, давайте проверим».

2. Остутствие попыток найти нечто, что было бы способно зажечь умы талантов. Большая компания представляет собой огромный, постоянно двигающийся механизм. Поэтому, как правило, нет таких специальных людей, которые бегали бы вокруг «нужных» сотрудников и спрашивали бы их без умолку, нравится ли им их текущий проект или хотели бы ли они заниматься чем то новым, что им было бы интересно и таким образом помогать компании. Отдел кадров обычно слишком занят, что бы тратить время на подобную деятельность. Начальники также разрываются на части по другим, очевидно, не менее важным делам, и вот этот вопрос по поиску заинтересованности талантов переходит из разряда обязательного в разряд желательного. Но до тех пор пока это не будет обязательным, может сказать «адиос» вашим лучшим людям. Талантливые люди на первое место ставят не власть и деньги, а скорее возможность принять участие в чем-то невероятном, способном изменить мир. Такие вещи их действительно заводят. Большие компании как правило не уделяют должного внимания этому вопросу.

3. Недостачный ежегодный анализ результативности. Вы бы изумились, если бы узнали как большие компании проводят ежегодный анализ результативности. Если он есть, то часто это сводится к тому, что в срочном порядке заполняется бланк отчетности «для галочки» и тут же отсылается в отдел кадров. Это оставляет впечатление, что начальство - и, соответственно, компанию вцелом – не интересует отдаленное будущее своих сотрудников. Если вы настолько талантливы, что вы тут делаете? И это приводит к пункту 4...

4. Нету обсуждения посвященного развитию карьеры. Тут запрятан секрет большинства боссов: большинство сотрудников не имеют понятия чем они будут заниматься через пять лет. По-нашим подсчетам менее пяти процентов людей смогут ответить на этот вопрос. Однако каждый из нас хочет, что бы разговор о нашем будущем непременно состоялся. Большинство руководителей никогда не затрагивают эту тему со своими подчиненными, даже с самыми талантливыми. Это представляет собой великолепную возможность для вас и вашей организации изменить ситуацию, если вы возьмете этот вопрос в оборот. Затрагивайте с каждым из ваших сотрудников данный вопрос раз а лучше два раза в год. Если ценные вам сотрудники знают, что вы думаете о их будущем, это пойдет только на пользу.

5. Меняющиеся прихоти / стратегические приоритеты. Я аплодирую компаниям, которые пытаются создать инкубатор или «кирпичный дом» для своих самых ценных сотрудников, используя для этого новые занимательные проекты. Проблема большинства организаций заключается в том, что у них не расставлены стратегические приоритеты. То есть, они могут подумать о подобном инкубаторе, но начать его внедрять только спустя год или два. Талантливые люди ненавидят томится в ожидании. Если вы назначили ценных сотрудников на проект, они вправе получить от проекта то, что было обещано ранее.

6. Недостаток ответственности и/или разговоров о том как нужно работать. Хотя вы не можете позволить что бы талантливые люди «валяли дурака», также будет и ошибкой пустить на самотек проекты, управляемые вашими талантами. Речь не идет о том, что вы должны лезть не в свои дела и говорить кому что и как делать. Однако, талантливый человек требует от окружающих ответственности и совсем не против нести ответственность за свои проекты. Поэтому, практикуйте небольшие митинги с вашими талантами относительно текущего состояния дел. Они будут ценить ваше внимание к их делам – но только если ваше вмешательство будет в рамках допустимого.

7. Талантливые люди любят других талантливых людей. Какие люди окружают ваши таланты? Многие организации пристраивают к выдающимся личностям более посредственных сотрудников. Для этого начальство находит тысячу и одну причину: «Ну этого парня сложно было пристроить куда-то еще...», «Давайте пока он тут побудет...». Однако, как показывают опросы талантливых сотрудников при увольнении из крупных организаций, многие увольнялись из-за того что не сработались со своими не такими талантливыми коллегами. Так что, если вы хотите сохранить ваши выдающиеся кадры при себе, побеспокойтесь что бы они были окружены не менее выдающимися личностями.

8. Момент пропущенной цели. Это может казаться очевидным, но тем не менее, насколько радужное будущее у вашей организации? Какой стратегии вы следуете? К какой цели должны стремится талантливые сотрудники вашей организации? Они могут принимать участие в обсуждение этой цели? Если ответ – нет, это нужно немедленно исправлять.

9. Недостаток открытого взаимодействия. Талантливые сотрудники хотят говорить о своих идеях и хотят быть услышанными. Но, это желание часто не согласуется со стратегиями многих организаций – и часто подобные инициативы тут же подавляются. Ваши лучшие люди в такой ситуации покинут вас и рядом с вами останутся люди всегда говорящие «Да» по любому вопросу которые вы им подкинете. Вам же следует научиться выслушивать и другие точки зрения, отличные от ваших – и брать из всех предложенных решений только самое лучшее.

10. Кто здесь начальник? Если несколько людей подчиненных одному руководителю увольняются со своих позиций – это плохой знак. Часто в подобных случаях нужно прийти и серьёзно поговорить с таким руководителем. Но, к сожалению, такая стратегия работает не всегда и дает положительный результат только в одном случае из трех. Лучшим решением будет перевод такого «начальника» на другую позицию в организации, туда, где он не сможет добраться до ваших самых талантливых.

В реальности не всегда виновата организация. Талантливые люди также несут ответственность по этому вопросу не меньше организации-работодателя. Однако, в наши дни талантливых сотрудников очень немного и поэтому на коне будут те организации, которые сами предпримут необходимые действия, что бы устранить проблемы описанные в данной статье-рекомендации и не будут дожидаться пока кто-то придет к ним и подскажет что и как нужно делать.

Базируется на публикации

http://www.forbes.com/sites/ericjackson/2011/12/14/top-ten-reasons-why-large-companies-fail-to-keep-their-best-talent/ By Eric Jackson

Так что же нам готовит Windows 8?

2011-11-25T08:23:00.000+02:00

Статья базируется на публикации Дино Эспозито "What Exactly is Windows 8?"

Metro – одно из знаковых нововведений для разработчиков, которое Microsoft представит в релизе новой версии своей операционной системы.

В сентябре Microsoft продемонстрировала первое превью разрабатываемой Windows 8. Новая версия операционной системы предназначена не только для PC, она также может использоваться и на планшетных устройствах. С точки зрения разработчика, Windows 8: система двух режимов. Первый режим базируется на продолжении развития предыдущих версий Windows, и предоставляет привычный пользовательский интерфейс и возможности для разработки. Второй режим – это абсолютно новое решение пользовательского интерфейса, которое базируется на новом системном API.

Это новое решение Windows 8 называется Metro. Оно построено на пользовательском интерфейсе Windows Phone. Оно также предлагает набор новых приложений, которые выполняются с помощью нового системного API – Windows Runtime (или сокращенно WinRT).

Из-за наличия двух режимов пользовательского интерфейса в Windows 8 – обычного и Metro – новые приложения также в перспективе будут делится на две соответствующие категории. Это очевидное и простое требование породило множество дисскусий, которые стали источниками заблуждений и необоснованных догадок.

Вот несколько ключевых вопросов, которые мучают разработчиков по всему миру, и на которые пока нету четких и вразумительных ответов:

· Какую роль играет фреймворк .NET при реализации приложений Metro?

· Что вообще требуется для написания Metro приложений?

· И более глобально, какое будущее ждет платформу Windows вцелом?

· Какое будущее у меня как, разработчика Windows?

Неопределенность, которая сейчас существует является отличным поводом для появления всевозможных страхов, слухов и сомнений. В данной публикации мы попробуем проанализировать информацию, которую Microsoft предоставила на первой презентации Windows 8, и постараемся прийти к выводу, что все страхи не имеют под собой никаких оснований.

Новое представление Windows 7

Microsoft гарантирует обратную совместимость. Таким образом все приложения, которые были написаны ранее, будут работать и на новой операционной системе так же как и прежде. Говоря о Metro, нужно понимать, что это новое семейство приложений. Windows 8 может работать в двух режимах, которые можно переключать в зависимости от своих предпочтений: стандартный режим, который и выглядит и работает так, как это было в предыдущих версиях Windows, но с небольшими обновлениями ключевых компонентов системы, и новый режим, который базируется на Metro. В Metro присутствует нативная поддержка тач-скрина, новая система рантайм, и новые подходы в программировании. Metro в первую очередь проектировалось для планшетных устройств, однако также доступно и для стандартных PC.

Можно посмтреть на данный вопрос под другим углом: классический рабочий стол Windows – это просто другая интерпретация тех возможностей которые предоставляют новые приложения Metro.

Это похоже на революцию? Можно привести мнение Стивена Синофски (Steven Sinofsky), президента подразделения Windows и Windows Live. Он говорит, что Windows 8 это попытка “придать новый облик Windows”.

Microsoft не может игнорировать существующие приложения и потребности пользователей Windows 7. Поэтому, для того, что бы всецело перейти на новый пользовательский интерфейс, и сделать его единственно возможным вариантом для взаимодействия с пользователем в новой версии Windows, необходимо приложить чрезвычайно много усилий и осущесвить очень много изменений. Поэтому Microsoft пошла на компромисное решение, принимающее в расчет наличие двух режимов.

Будет ли переход на Windows 8 чем то похожим на изменения которые в свое время принесла Windows 95? Win 95 обновила существовавшие тогда программы заместив собой устаревшую в то время консольную операционную систему MS-DOS. В то время это было начало новой вехи в развитии области операционных систем. Metro является новой вехой в развитии только лишь платформы Windows. Новшества, которые придут вместе с Windows 8 будут значительно проще и менее глобальны.

Вызов для разработчиков

Существующие приложения Windows не нужно портировать под Metro и разработчики программного обеспечения могут по прежнему писать свои программы используя классические приемы, средства разработки и применяемые технологии – фреймворк .NET и соответствующие языки программирования.

Приложения Metro потребуют нового подхода к процессу разработки, нового API и новой системы рантайм, но использоваться будут уже знакомые языки программирования и средства разработки. Например можно использовать HTML5 в связке с JavaScript и CSS3. Также можно использовать C++, Visual Basic и C#. Во всех случаях, XAML остается одним из вариантов для разработки пользовательского интерфейса.

В терминах функциоанальности, API для приложений Metro имеет много общего с API для приложений .NET: некоторые пространства имен будут переименованы и некоторые классы перемещены в другие компоненты. Важным моментом, который нельзя упустить из виду, является тот факт, что приложения Metro выполняются с использованием нового рантайма, который является оберткой над сервисами ядра Windows в манере похожей на Win32. Фреймворк .NET общается с системой через P/Invoke вызовы функций Win32. WinRT – рантайм использоуемый Metro – обращается к нативным сервисам системы более непостредственно, и использует другие подходы для их инкапсуляции.

Приложения Metro следуют логике мобильных приложений. Они никогда не выполняются непонятно как, не зависают. Говоря далее, нужно отметить, что приложения Metro распространяются через специальный маркет, благодаря чему каждое приложение проходит через процесс получения сертификата качества Microsoft. Получение лицензии на использование программы осуществляется с привязкой к конкретному пользователю, а не к машине. Настройки по умолчанию используют облако для хранения данных. И, наконец, приложение Metro должно содержать информацию о аппаратном обеспечении, на котором оно может выплнятся.

Таким образом, написание приложения Metro похоже на написание приложений под мобильные платфрмы, такие, как, скажем, Windows Phone 7. Природа и структура приложений также отличается от традиционных .NET приложений, поскольку приложения Metro призваны быть более простыми, более интерактивными и сконцентрироваными на содержимом.

Ну что? Несет ли Windows 8 в себе большие изменения для пользователей и разработчиков? Являются ли Windows 8 и приложения Metro тем, на что нужно немедленно сконцентрировать все свое внимание и воспринимать как догму? Очевидно, ответ на оба вопроса будет один – нет, я так не думаю. Windows 8 – эволюционное развитие платформы Windows. Metro – новшество, которое приходит вместе с Windows 8. Для разработчика – это очередная новая платформа, которая возможно получит развитие в будущем.

Orange Heap - Еще один бесплатный обфускатор для .NET

2011-10-07T16:11:00.001+02:00

В последнее время я активно занимался изучением принципов обфускации и существующих приемов модификации кода, направленных на затруднение процесса реверс-инжиниринга .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 – абсолютно бесплатный, поэтому не медлите, заходите на сайт поддержки, скачивайте и пользуйтесь. И, разумеется, пишите письма. Ведь только с помощью ваших отзывов я смогу узнать о наличии проблем и попытаться их исправить, а также сделать продукт более удобным и функциональным.

Как работают обфускаторы. Дополнительные возможности

2011-09-28T13:13:00.000+02:00

Введение

В предыдущих двух статьях я рассказывал о том, как работают обфускаторы. Были рассмотрены методы и приемы, которые используются ими для переименования различных символов программы и для шифрования строк и ресурсов. Далее я привел простейшие примеры нелинейного преобразования кода, которые предназначены для изменения порядка следования инструкций программы. Такие преобразования делали более сложным восприятие кода и практически невозможным преобразование его к исходнму варианту. Собственно все обфускаторы как правило и отличаются качеством подобных преобразований. Чем лучше и качественнее данные преобразования осуществляются, тем выше качество защиты обфусцированного кода и соответственно больше ценится тот или иной обфускатор.

Вместе с тем, нынешние средства обфускации имеют в своем арсенале и ряд других возможностей, которые не связаны непосредственно с такими преобразованиями, а предназначены прежде всего для повышения удобства работы с инструментом и предоставления пользователю дополнительных вспомогательных функций. Как раз о таких возможностях и пойдет речь в данной статье.

Обработка зависимостей

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

В случае если защищаемый продукт состоит из нескольких составляющих, скажем, главного исполняемого модуля и двух-трех подключаемых dll-библиотек, ситуация немного меняется. Дело в том, что безболезненно переименовать все символы без дополнительных действий не получится. И если с приватными (private) или внутренними (internal) символами, которые используются только внутри данной сборки проблем по прежнему нету – их можно переименовывать без оглядки на всю остальную систему, то с публичными элементами такой подход неприемлем. Связано это с тем, что одна сборка, которая использует некоторые типы другой, ничего не знает об актуальном именовании типов импортируемой сборки. При связывании на этапе компиляции все имена импортируемых типов сохраняются в специальную таблицу. Позже, в процессе выполнения программы, все обращения к импортируемым типам будут осуществлятся с использованием этой таблицы. А поскольку в сборке, где эти типы объявлены, в процессе обфускации имена этих типов были переименованы, то получить информацию о типе по страму имени будет невзоможно, и в итоге мы получим исключение, информирующее о том, что запрашиваемый тип не найден.

Различные обфускаторы решают подобную проблему различными способами.

Самый простой способ – превентивный. Это значит обфускаторы либо не позволяют изменять имена публичных символов, либо в ультимативной форме делать это крайне не рекомендуют.

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

Третий способ (и последний в этом обзоре) - самый корректный. Он предполагает обновление таблицы имен импортируемых символов. В данном случае после того, как все типы подключаемого модуля были переименованы, осуществляется обновление таблицы импорта исполняемого модуля, в процессе которого старые имена импортируемых символов заменяются на новые. Такой процесс преобразований получил название Inter-Assembly или Cross Assembly обфускации. Подобный вид обработки зависимостей обладает рядом преимуществ, по сравнению с предыдущими. Так, он позволяет осуществлять более глубокую обфускацию, и вместе с тем не нарушать исходную структру приложения. Это особенно актуально когда к примеру приложение состоит не из одного исполняемого файла а из двух или трех, которые совместно используют подключаемые модули. В таком случае склеивание зависимостей невозможно и стало быть рассматриваемый вид обработки зависимостей - единственный способ обфусцировать публичные символы подключаемого модуля.

Защита от реверс-инжиниринга и модификаций

Защита от дизассемблирования

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

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

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

Более продвинутый способ может выглядеть следующим образом. Код метода шифруется с помощью некоторого алгоритма шифрования и результат шифрации помещается либо в ресурсы, либо вовсе в отдельный файл. Исходное тело метода замещается кодом некоторого загрузчика, который знает где находится зашифрованный фрагмент кода и способ как его расшифровать. При вызове такого метода загрузчик получает управление, он дешифрует реальный код, и выполняет его. Таким образом при дезассемблировании исследовать этот код будет абсолютно невозможно.

Защита от модификаций

Некоторые обфускаторы предоставляют функциональность, которая способна защитить приложение от модификаций. Такой механизм часто называют tamper protection или tamper defense. В этом случае программа будет корректно выполнятся только в том случае если они не была изменена злоумышленником. Если какие то изменения были – программа просто перестанет работать, либо будет выводить некоторое сообщение о недопустимости использования модифицированной программы.

Для того что бы реализовать подобную функциоанльность используется подписывание (watermarking) исполняемых и подключаемых модулей. Алгоритм подписывания может быть любой. Это может быть и стандартное подписывание (signing assembly with a strong name) или же некоторый другой алгоритм, основанный на CRC или MD5. Суть такого алгоритма заключается в том, что перед выполнением программы осуществляется анализ существующего кода, в процессе которого на основании существующих инструкций кода формируется некоторое числовое значение или иными словами так называемый хэш, который впоследствии сравнивается с эталонным. Если модификаций не было, эти хеши будут идентичны, если же хеши отличаются – явный признак того, что код был модифицирован.

Кроме того подписывание, может использоваться не только для отслеживания модификации кода, но и для скрытой идентифиакции или маркировки конкретного экземпляра приложения. Подобная маркировка может помочь выявить факт несанкционированного использования приложения и определить его владельца, на который рарегистрирована покупка данного экземпляра приложения.

Способы конфигурации и пользовательский интерфейс

Немалое значение в популярности того или иного обфускатора играет удобство его использования, а также гибкость и интуитивность конфигурации процесса обфускации. Из всех вариантов конфигурирования можно выделить три основных подхода.

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

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

Третий вариант основан на декларативном конфигурировании защищаемого кода с помощью специальных аттрибутов. Суть данного подхода заключается в том, что на этапе разработки определенным модулям, типам и их составным частям присваиваются специальные аттрибуты, которую содержат информацию о том, как нужно обрабатывать данный элемент в процессе обфускации. Для того, что бы унифицировать процесс декларативного конфигурирования в фреймворке .NET уже существуют такие аттрибуты. К ним относятся System.Reflection.ObfuscateAssemblyAttribute и System.Reflection.ObfuscationAttribute. Первый предназначен для задания параметров конфигурации для заданной сборки, второй – для конкретного типа или его составных частей. Более подробную информацию об этих аттрибутах можно посмотреть в MSDN.

Идеальным обфускатором с точки зрения способов конифигурации процесса обфускации можно считать обфускатор, который позволяет осуществлять конфигурацию всеми тремя способами. Однако на практике такое встречается нечасто, и в большинстве случаев приходится довольствоваться меньшими возможностями.

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

Завершение

В данной статье мы рассмотрели существующие варианты обработки зависимостей, когда защищаемое приложение состоит из нескольких модулей, которые связаны между собой. Далее были рассмотрены наиболее распространенные варианты защиты приложения от дизассемблирования и модификаций. И наконец был дан беглый обзор возможных способов конфигурирования процесса обфускации и вариантов поставки обфускатора конечному пользвателю.

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

Как работают обфускаторы. Изменения внутренней логики

2011-08-25T15:32:00.000+02:00

Введение

В прошлой статье я рассказывал о самых базовых возможностях инструментов обфускации: переименовании типов и их составных частей и шифровании строк и ресурсов программы. Такие приемы могут быть эффективными и сами по себе в простейших случаях, однако они не способны защитить секретные алгоритмы и важные части программы, поскольку весь порядок следования инструкций в коде остался такой же как и был ранее. Да, если обыкновенный неподготовленый зевака откроет обфусцированную программу рефлектором или дизассемблером, то он ничего не сможет разобрать и почти наверняка слегка растроившись прекратит свои попытки понять, как там все внутри устроено. Но если же это более подготовленый человек, которому уж очень нужно разобраться с вашим кодом и он готов потратить на это свое время, то ему не составить труда проследить порядок выполнения инструкций вашей программы.

Сегодня мы пойдем дальше и постараемся разобраться с более сложными приемами, которые своей основной целью ставят изменение логики программы. После подбных преобразований разобраться с вашим кодом будет подсилу разве что матерым проффесионалам. Да и им уже придется изрядно попотеть. К слову, защитить свою программу на 100% абсолютно ото всех – это увы, задача нереализуемая, так как еще не существует такого решения, ни для .NET, ни для неуправляемого кода, которое позволило бы полностю обезопасить прогрммные продукты от взлома и несанкционированного доступа к коду. В наше время ломается все, другой вопрос – какой ценой.

Обфускация данных

Обфускация данных подразумевает изменения структуры переменных используемых в программе а также способов их использования.

Первым вариантом обфускации данных может служить изменение видимости переменной. Так, локальная переменная используемая в коде, может быть преобразована в глобальную переменную, либо поле класса, содержащего данный метод, либо вовсе в публичное поле отдельного вспомогательного класса, который может быть сгенерирован в процессе обфускации программы. В таком случае, для того что бы проследить использование данной переменной в коде, необходимо будет потратить больше времени на определение места объявления этой переменной. Если же переменная будет представлена в виде публичного поля отдельного класса, то в процессе реверс-инжиниринга необходимо будет дополнительно осуществлять проверку где оно еще используется в пределах всей программы.

Более продвинутым методом обфускации является изменение структуры переменных. Этот метод подразумевает к примеру преобразование двумерного массива к одномерному где это допустимо и наоборот. Такие преобразования усложняют восприятие кода и затрудняют реверс инжиниринг. Также можно осуществить разбивку скалярной переменной на две или более. Допустим и обратный процесс – склеивание нескольких переменных в одну. Для большей ясности можно рассмотреть пример разбивки переменной на несколько. На листинге 1 представлен некоторый метод, который в цикле выводит значения от 1 до 10.

Листинг 1.

char[] array = ...;

int i = 1;

int k = 10;

while (i < k)

{

Console.WriteLine(array[i]);

i ++;

}

Для того что бы затруднить восприятие логики программы, достаточно перменную i разделить на две переменные i и j, каждая из которых будет инкрементироваться в своем цикле. После подобных преобразований получим код, представленный на листинге 2.

Листинг 2.

char[] array = ...;

int i = 0;

int k = 5;

while(i < 2)

{

int j = 1;

while(j <= k)

{

Console.WriteLine(array[i * k + j]);

j++;

}

i++;

}

В случае использования переменных в качестве счетчика для цикла можно использовать так называемое кодирование данных, которое добавляет дополнительные инструкции для вычисления значения счетчика. Можно рассмотреть данный метод обфускации на примере. В качестве исходного кода возьмем фрагмент представленный на листинге 1, на листинге 3 – код, полученный в результате преобразований.

Листинг 3.

char[] array = ...;

int i=11;

int k = 83;

while (i < k)

{

Console.WriteLine(array[(i - 3) / 8]);

i += 8;

}

Обфускация кода

Помимо обфускации данных, существует обфускация кода или обфускация следования управляющих инструкций (control flow obfuscation). Данный вид преобразований предназначен для усложнения восприятия кода защищаемого метода. Как правило все преобразования данного типа подразумевают добавление либо инструкций переходов, предназначенных на запутывание порядка выполнения инструкций, либо всевозможных вспомогательных методов и типов, которые получают управление в процессе выполнения программы. Рассмотрим наиболее распространенные преобразования.

Добавление запутывающих ветвлений программы. Принцип данных преобразований основан на том, что в оригинальный код добавляются инструкции переходов. Рассмотрим ситуацию на примере. После осуществления преобразований кода из листинга 1 получим код, представленный на Листинге 4.

Листинг 4.

char[] array = ...;

int i = 1;

int k = 10;

while (i < k)

{

int j = 10 - i;

if(j > k)

{

Console.WriteLine("error");

i = 1;

}

else

{

Console.WriteLine(array[k - j]);

i++;

}

Если внимательно посмотреть на этот фрагмент, то можно обратить внимание, что выражение if(j > k) всегда будет ложно и фрагмент кода, относящийся к этому условию, никогда не выполнится. Такие блоки кода часто называют мертвым кодом (Dead code). Основное их предназначение заключается в отвлечении внимания, человека, занимающегося реверс-инжинирингом. Другая ветвь ничем не отличается от исходной из листинг 1, за тем исключением, что вместо i используется k – j. Если посмотреть внимательно на код, то несложно прийти к выводу, что это выражение всегда будет эквивалентно i. Итак, после преобразований был получен код, имеющий на первый взгляд мало общего с исходным кодом, однако выполняющего в точности ту же самую работу.

Добавление классов-оберток для сокрытия вызовов методов стандартных типов. Даже после преобразований выполненых ранее, код по прежему остается читаемым. Причиной этому является использование метода Console.WriteLine, который переименовать как-то нету никакой возможности, так как это стандартный класс. Для того, что бы запутать код еще больше, можно создать прокси-класс, который иначе называется Dynamic Proxy. Он будет инкапсулировать в себе вызовы метода Console.WriteLine. Листинг 5 содержит реализацию класса.

Листинг 5.

internal class llI

{

public static void Il(string s)

{

Console.WriteLine(s);

}

public static void Il(char c)

{

Console.WriteLine(c);

}

Теперь можно везде, где необходимо вызов метода Console.WriteLine заменить на вызов метода прокси llI.Il. В результате фрагмент из листинга 4, превратиться в фрагмент представленный на листинге 6.

Листинг 6.

char[] array = ar;

int i = 1;

int k = 10;

while (i < k)

{

int j = 10 - i;

if(j > k)

{

llI.Il("0xFF");

i = 1;

}

else

{

llI.Il(array[k - j]);

i++;

}

Подобные прокси отлично скрывают «настоящие» вызовы. Они могут использоваться не только со стандартными типами, но и с пользовательскими, или даже с другими прокси-объектами, создавая иерархии прокси-вызовов. Используя в комбинации приемы прокси-объектов и ветвлений можно добится невероятных результатов обфускации кода. Код полученный в результате будет очень сложен для восприятия, особенно учитывая тот факт, что названия всех методов и классов также будут в преобразованы к нечитаемому виду. Главное в этом деле не переусердствовать и вовремя остановится, так как необходимо помнить что с введением каждого нового прокси-объекта, защищаемая нами программа теряет в производительности, так как увеличивается количество избыточных вызовов и используемая глубина стека выполнения программы.

Добавление новых типов для сокрытия данных используемых в программе. Данный тип преобразований сочетает в себе обфускацию и кода и данных. Его предназначение – запутать некоторый код, который по входным данным получает в результате новые данные, которые необходимы для дальнейшего выполнения прграммы. Для ясности, рассмотрим пример, который изображен на листинге 7.

Листинг 7.

switch(c)

{

case 0x00FF0000:

Console.WriteLine("Red Color");

break;

case 0x0000FF00:

Console.WriteLine("Green Color");

break;

case 0x000000FF:

Console.WriteLine("Blue Color");

break;

case 0x00FFFFFF:

Console.WriteLine("White Color");

break;

}

Этот код по числовому значению c определяет текстовое описание цвета и печатает его на консоль. Суть рассматриваемого преобразования заключается в создании нового типа, основной задачей которого будет для каждого значения входных данных ( в нашем случае это переменная c) получить соответствующие выходные данные (в нашем случае – текстовое название цвета). Реализация нового типа представлена на Листинге 8.

Листинг 8.

internal class IIl

{

private static readonly uint[] _I = new uint[] { 0x00FF0000, 0x0000FF00, 0x000000FF, 0x00FFFFFF};

private static readonly string[] _l = new[] { "Red", "Green", "Blue", "White" };

public static string ll(uint c)

{

var i = Array.IndexOf(_I, c);

return i >= 0 ? _l[i] : string.Empty;

}

Теперь, используя данный клас можно переписать код, как показано на Листинге 9.

Листинге 9.

var I = IIl.ll(c);

if(!string.IsNullOrEmpty(I))

llI.Il(I + " Color");

Обращаю внимание, что в данном примере мы воспользовались Dynamic Proxy из листинга 5 для сокрытия вызова метода Console.WriteLine. В качестве дальнейшего запутывания кода можно добавить аналогичный Dynamic Proxy для вызова метода string.IsNullOrEmpty, а также осуществить переименование всех переменных и шифтрацию строк. После этого уж наверняка будет не очевидно что на самом деле он реализует функцуиональность кода из листинга 7.

Способы отпимизации

После всех этих преобразований, код действительно становится намного запутаннее, чем это было сразу после переименования полей и шифрования строк. Что бы в нем разобраться, теперь придется изрядно потрудится. К сожалению, платой за добавленную сложность стало увеличение размера кода, которое произошло за счет добавления новых типов, дополнительных инструкций переходов и мертвого кода и падения скорости приложения ввиду добавления необходмости вызовов прокси-методов.

В целях возмещения подобных издержек в большинстве обфускаторов применяется ряд преобразований направленных на оптимизацию размера и скорости выполнения кода.

Так, в целях повышения скорости работы программы часто применяется подход, называемый запечатыванием типов. Он сводится к тому, что любой тип, который не имеет наследников помечается ключевым словом sealed. Это может способствовать повышению производительности за счет уменьшения издержек при вызове методов такого типа.

Так же, одним из способов уменьшения размера программы может служить удаление неиспользуемых фрагрментов кода. В процессе выполнения преобразований обфускатор может проанализировать всевозможные ветви выполнения кода и найти фрагменты, которые никогда не получат управление. Соответственно, они могут быть безболезненно удалены из программы. Это положительно отразится на размере программы.

Заключение

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

В следующей статье я расскажу о том, какие еще дополнительные возможности существуют у современных обфускаторов и как они реализованы.

Как работают обфускаторы. Переименование и Шифрование

2011-07-29T11:15:00.001+02:00

Это первая статья из цикла “Как работают обфускаторы”. Основной целью этой и последующих статей прежде всего является систематизация и описание возможностей современных обфускаторов. Я попытаюсь не только описать что в них реализовано, но и объяснить неискушенному читателю, зачем оно там и как оно все работает. Я приложу все усилия для того, что бы не загружать читателя трудновоспринимаемым текстом, сложносформулированными оборотами и выражениями. Для этого материал будет преподнесен в максимально простой и доступной форме. Однако в некоторых случаях без использования сложных терминов и выражений однозначно не обойтись. Я постараюсь сделать это настолько аккуратно, что бы на качество материала это не повлияло никоим образом.

Мне ближе всего платформа .NET, поэтому при подготовке материала я рассматривал обфускаторы, предназначенные для защиты .NET-кода. Ввиду этого в обзоре не будут учтены особенности, которые имеют место в обфускаторах предназначенных других областей, например для защиты кода скриптовых языков, таких как JScript. Хотя вряд ли там присутствуют существенные отличия – основные возможности обфускаторов из разных областей мало чем отличаются друг от друга. Поэтому статья может оказаться полезной даже если вы абсолютно не знакомы с .NET.

И еще один важный момент, на который я хочу обратить внимание, прежде чем мы пойдем дальше. Ни в этой статье, ни в последующих, насколько это будет возможно я постараюсь не упоминать явно или косвенно, какую то конкретную реализацию обфускатора, дабы не сделать из статьи рекламу того или иного продукта. Возможно в отдельных случаях это было бы и полезно – на живом примере объяснить или рассказать, как все то, о чем будет идти речь, устроено и работает. Однако я уверен, что качество материала от отсутствия подобных примеров если и пострадает, то незначительно. Если вам будет интересно узнать о существующих реализациях обфускаторов, вы наверняка сможете сами найти подобную информацию сами используя поисковую систему, или же обратившись к моей публикации, где был проведен небольшой обзор, какие обфускаторы существуют и что они умеют. Обзор уже не свежий, и сегодня наверняка появилось много других решений, которые в момент написания обзора были мною упущены из вида, поэтому отнеситесь к обзору только как к отправной точке и не более того.

Введение

Это первая статья из цикла “Как работают обфускаторы”. В ней я остановлюсь на базовых возможностях обфускаторов. Будут рассмотрены операции переименования и шифрования составных частей программы. Я постараюсь на понятых примерах рассказать, что присходит в процессе обфускации с кодом и его составляющими, и как модифицируются текстовые строки и ресурсы приложения в форму, сложную для визуального восприятия.

Итак, приступим.

Переименование

Самой базовой возможностью обфускторов является переименование составных частей программы. Это, пожалуй, самое первое что приходит на ум, при упоминании термина обфускация. И, возможно, самое важное. Другой термин, которым называется процесс переименования - Name mangling. Основной задачей процесса является приведения названия переменных, классов и их составляющих к форме, которая как минимум не позволила бы понять их предназначение, а максимум – лишила бы возможность визуально проследить использование данного объекта в коде.

Предназанчение переменной, как правило проще всего определить по ее названию – стало быть преназначение переменной itemCount говорит само за себя – эта переменная предназначена для хранения количества некоторых элементов, а вот предназначение aabc – не настолько понятно. Стало быть в самом простейшем случае изменение имени itemCount на aabc уже уменьшает восприятие кода, хотя проследить использование переменной и выяснить для чего она используется не так уж и сложно.

Однако, если взять пять различных переменных, например itemCount, firstItem, lastItem, currentItem, items, и переименовать их скажем вот так: IIli, lilI, IiIl, iilI, Illl – то задача не кажется такой простой – названия переменных стали трудно различимы между собой и теперь нужно хорошенько напрячь зрение и внимание, что бы проследить использование каждой из переменных.

В действенности приведенного преобразования вы можете убедится изучив листинги, приведенные ниже. В первом листинге показана реализация некоторго метода до преобразований, во втором - тот же метод, но после модификации.

Листинг 1.

private List<int> SampleMethod(int firstItem, int lastItem, List<int> items)

{

var filteredItems = new List<int>();

var itemsCount = items.Count;

for (int i = 0; i < itemsCount; i++)

{

if (items[i] < firstItem || items[i] > lastItem)

continue;

filteredItems.Add(items[i]);

}

return filteredItems;

}

Листинг 2.

private List<int> SampleMethod(int IIli, int lilI, List<int> IiIl)

{

var iilI = new List<int>();

var Illl = IiIl.Count;

for (int IlIl = 0; IlIl < Illl; IlIl++)

{

if (IiIl[IlIl] < IIli || IiIl[IlIl] > lilI)

continue;

iilI.Add(IiIl[IlIl]);

}

return iilI;

}

Можно пойти еще дальше, и в качестве имени переменной использовать неотображаемые символы. В таком случае вместо таких символов пользователь в зависимости от используемого инструмента будет либо видеть череду квадратов, либо вовсе ничего, пустоту на месте использования переменной. Согласитесь, выражение вида “ . += ;” или “□□.□□+=□□□;” любого поставит в тупик.

Еще одним приемом запутывания кода является приведения имени разных методов с различным набором аргументов к одному имени. Например имеется два метода: AddItem(item) и GetItemByIndex(index). Параметр первого метода –– это некоторый класс, параметр второго – целое число. Поскольку типы агрументов различные – оба метода могут вполне законно иметь одно и то же имя. И теперь после переименования методов и аргументов можно получить примерно следующее: II(Il) и II(lI). Попробуйте догадайтесть что первый метод добавляет элемент, а второй возвращает по индексу. Если пойти и здесь немного дальше и тем же именем которым были названы методы, назвать переменные, классы и типы защищаемой программы (ну разумеется только в тех случаях где это допустимо) то задача усложниться до неузнаваемости. Обратите внимание на листинг 3 и все станет понятно, о чем идет речь.

Листинг 3.

private void a(a b)

{

while (b.a())

{

a = b.a(true);

a.a();

a(a);

}

Данный паттерн часто называют Overload Induction.

Существующие обфускаторы используют все эти приемы. Вместе с этим во многих из них существует возможность выбора набора символов которые будут применятся при переименовании или задания паттерна имени для переименования.

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

Некоторые обфускаторы помимо переименования переменных и классов могут осуществлять также переименования элементов разметки XAML/BAML. Сама разметка находится в ресурсах защищаемого приложения и она также может пролить свет на понимание злоумыленником того, как работает программа или хотя бы как устроены составные части программы, относящиеся к пользовательскому интерфейсу. В целом, при переименовани элементов разметки вполне подойдут приемы описанные выше, за тем исключением что для новых имен элементов вряд ли подойдут неотображаемые символы.

В завершение необходимо добавить, что многие обфускаторы по окончанию обфускации при необходимости генерируют отчет, в котором содержится информация о переименованных элементах программы. Такой отчет может оказаться полезным как и для пользователя, если ему требуется осуществить отладку или исследовать обфусцированную программу, так и для самого обфускатора, поскольку некоторые из них умеют осуществлять деобфускацию. То есть осуществлять преобразования, обратные обфускации. Для таких целей им необходим сгенерированный ранее отчет, так как иначе обфускатор не будет иметь ни малейшего представления о первоначальном имени элемента.

Шифрование

После того как все необходимые элементы программы переименованы, задача исследования программы усложняется, однако по прежнему назвать ее сложно нельзя. Причиной тому, является тот факт, что все текстовые строки программы по прежнему присутствуют в коде в своем первозданном виде. Они являются замечательными помощниками в идентификации фрагментов программы, которые интересуют злоумышленников. Очевидно, что если где-то в коде встретилась строчка “Enter your password”, будте уверены – где-то рядом есть переменная, в которой этот самый введенный пользователем пароль и находится. Определив эту переменную, задача по обходу системы защиты, для которой этот пароль предназначен уже не выглядит такой сложной.

Для того что бы сделать жизнь злоумышленнику несколько сложнее, очевидно, что с текстовыми строками нужно что-то делать. Разные обфускаторы используют различные приемы и механизмы для защиты текстовых данных, однако среди всех этих приемов можно выделить общий принцип. Если кратко, то суть защиты сводится к замене текстовой строки в коде, на некоторый метод, который в качестве параметра получает предварительно зашифрованную исходную строку, дешифрует ее и в качестве результата возвращает исходную строку. То есть, если изначально было выражение вида:

someString = “Some text”;

То после всех преобразований обфускатора получим что то вроде:

Il = ll.lIl(“□□□□□□□□□”)

Где Il – это переименованая someString, а ll.lIl – вызов метода дешифрации. В данном случае мы имеем дело со статическим методом lIl некоторго вспомогательного класса ll. В качестве параметра метод получает предварительно зашифрованную строку, которая в процессе дешифрации станет эквивалентной исходной. В самом простейшем случае данный метод может одновременно использоваться как для шифрации строки, так и для ее дешифрации. То есть если методу передать незашифрованную строку – он ее зашифрует и вернет зашифрованный эквивалент. Если передать методу зашифрованную строку, то на выходе получим исходную незашифрованный текст. Ниже на листинге 4 представлен один из возможных вариантов реализации такого метода.

Листинг 4.

public static string Encrypt(string str)

{

var length = str.Length;

var array = new char[length];

for (int i = 0; i < array.Length; i++)

{

var c = str[i];

var b = (byte)(c ^ length - i);

var b2 = (byte)((c >> 8) ^ i);

array[i] = (char)(b2 << 8 | b);

}

return string.Intern(new string(array));

}

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

Сгенерировать и добавить в код защищаемой программы метод дешифрации.
Найти в коде инструкцию загрузки текстовой строки в стек.
Зашифровать строку.
Заменить в коде инструкцию загрузки строки на вызов метода дешифрации (пп.1), передав ему в качестве параметра зашифрованную строку которую мы получили в пп.2.

Эти действия необходимо выполнить для каждой строки используемой в коде. Вуаля! Не так уж все и сложно.

Однако есть один момент который потребует небольшой доработки, для того что бы наши изменения не нарушили работу всей программы. Проблема заключается в том, что выполнив преобразования, описанные выше, мы изменили суммарный объем кода каждого метода. Поясню. Инструкция загрузки текстовой строки занимает 5 байт: 1 байт – это сама инструкция и 4 байта – это адресс строки которую нужно загрузить. После преобразований у нас получится уже 10 байт: 1 байт – инструкция загрузки зашифрованной строки в стек, 4 байта – адрес этой строки, далее 1 байт интрукция вызова метода и наконец еще 4 байта, это собственно адрес этого метода.

Если в методе, где осуществляется сокрытие текстовых строк, присутствуют инструкции условных или безусловных переходов, то метод не будет работать так, как он работал ранее. Дело в том что адрес переходов указывается в форме смещения относительно начала метода, и после наших изменений, это значение будет указано неверно. Рассмотрим ситуацию на примере. На листинге 5 показана последовательность пседво-инструкций, которая была в программе изначально. Первая колонка это смещение инструкции относительно начала метода, вторая колонка – сама инструкция. Для простоты адрес смещения я указал в виде десятичного числа.

Листинг 5.

0000 instruction_1 param

0005 jump 0015

0010 load_string “some string”

0015 instruction_2 param

После того, как мы произведем изменения необходимые для шифрования строки, получим последовательность, представленную на листинге 6.

Листинг 6.

0000 instruction_1 param

0005 jump 0015

0010 load_string [cryped_string]

0015 call decrypt_method

0020 instruction_2 param

Как видим, после проведенной модификации смещение перехода указано неверно. И изза этого программа работать не будет. Для того что бы исправить ситуацию необходимо изменить смещение на актуальное значение, в данном случае это будет 0020. Подобную корректировку при необходимости следует осуществить для каждой инструкции перехода.

Принцип шифрования встроенных в программу ресурсов немного отличается от шифрования строк. Хотя суть та же. То есть сначала необходимо осуществить шифрование ресурса и заменить исходный ресурс зашифрованным аналогом. После этого необходимо произвести модификацию всех мест в коде, где осуществляется обращение к данному ресурсу. По аналогии со строками, вместо непосредственного обращения к ресурсу, необходмо осуществлять вызов метода, который выполнит дешифрацию и вернет уже расшифрованный ресурс.

В одтельных случаях, когда в качестве ресурса использутеся файл *.bmp или вовсе файл, представленный в текстовом формате, будет разумно предусмотреть в методе шифрации возможность сжатия ресурса. Таким образом будет осуществлена и защита ресурса от посторонних глаз и оптимизация программы в форме уменшения ее размера.

Заключение

Сегодня мы рассмотрели возможные приемы переименования элементов программы, которые используются в современных обфускаторах и получили общую картину того, как осуществляется шифрование тестовых строк и ресурсов в программе. Оба процесса являются неотъемлимой чертой любого обфукатора и предназначены для затруднения визуального восприятия кода. В следующей статье я расскажу о том, какие бывают паттерны изменения управляющей логики программы (Control flow modification). Эти паттерны подразумевают изменение следования инструкций, и предназначены для усложнения логического восприятия кода, делая процесс реверс-инжиниринга обфусцированной программы еще более сложным.

Обфускация, взгляд изнутри

2011-06-29T13:44:00.005+02:00

В данной статье я хочу рассмотреть существующие приемы по обфускации кода. Статья содержит анализ различных подходов, применяемых в процессе обфускации. Рассматриваемые приемы используются как для защиты интеллектуальной собственности, так и для сокрытия вредоносного кода от антивирусных сканеров. Дополнительно, обфускация может использоваться для защиты от внедрения вредоносного кода и всевозможных несанкционированных атак. Несмотря на то, что преобразования осуществляемые в процессе обфускации могут защитить код, они также имеют ряд ограничений, связанные в первую очередь с увеличением размера кода и падением общей производительности защищаемого продукта.

Введение

В последнее десятилетие все большую долю рынка программного обчеспечения стали занимать программные продукты, рапространяемые в промежуточном архитектурно-независимом коде или иначе в байт-коде. Это спровоцировало увеличение рисков получения и несанкционированного использования исходного кода из исполняемых модулей. Подбная проблема беспокоит большое количество комапний-разработчиков программного обеспечения, они заинтересованы в защите своей интелектуальной собственности и своих продуктов от несанкционированного реверс-инжиниринга. Хотя закон об авторском праве и препятствует нелицензионному использованию программного продукта, разработчики обеспокоены возможностью воровства проприетарных структур данных и алгоритмов. Несмотря на наличие некоторых методов защиты программных продуктов, таких как шифрование, выполнение на стороне сервера и использование машинного кода, обфускация является пожалуй самым дешевым и простым способом решения данной проблемы [6]. Обфускация кода – это процесс создания нечитаемого кода, или, сильно затрудняющий его анализ. Процесс обфускации включает в себя трансформацию кода, которая меняет представление кода оставляя его логику прежней. В данной статье будет проведен обзор различных примеов обфускации, используемых в настоящее время в существующих специализированных инструментах.

Промимо всего прочего обфускация кода также может быть использована не только для защиты интелектуальной собственности. Обфускация может быть использована авторами вредоностного кода для сокрытия и маскировки небезопасного кода. Многие вирусы используют различные техники обфускации для защиты от антивирусных сканеров. С помощью всевозможных преобразований они постоянно изменяют сигнатуры своего кода. В данной статье будут рассмотрены типы вирусов, которые используют обфускацию и всевозможные приемы преобразования кода.

Статья состоит из следующих разделов:

«Общие методы обфускации» - обзор общих базовых методов используемых повсеместно в инструментах обфускации;
«Обфускация препятствующая статическому анализу программ» - обсущаются приемы блокирующие статический анализ.
«Обфускация в фазе дизасемблирования» - обзор подходов обфускации на этапе дизассемблирования.
«Обфускация относящаяся к вирусам» - обзор примеов используемых создателями вирусов.

Общие методы обфускации

Основной целью общих методов обфускации кода является запутывание кода таким образом, что было бы сложно понять как данный код работает. Сам процес запутывания может быть как очень простым, как например какие-то базовые преобразования, так и чрезвычайно сложным, изменяющим управляющую логику (control flow) и потоки данных. Приемы описанные ниже являются обобщением работы Коллбегра [4].

Качество обфускации

Качество преобразований осуществляемых в процессе обфускации определяется с помощью следующих критериев:

Эффективность: Насколько программа становится нечитабельной.
Устойчивость: Насколько сложно взломать программу автоматизированными средствами деобфускации.
Прозрачность: Насколько хорошо обфусцированный код взаимодействует с остальным кодом.
Стоимость: Насколько велик объем избыточного кода в обфусцированном проиложении.

Преобразования управляющей логики

Преобразования управляющей логики, используемые в процессе обфускации, могут рассматриваться как преобразования, оказывающие влияние на аггрегацию, порядок и выполнение операций управляющей логики. Преобразования аггрегации изменяют порядок выполнения логически связанной последовательности операций и объединяют последовательности операций, которые связанными не являются. Преобразования групировки делают порядок выполнения вычислений спонтанным. Трансформации выполнения операций добавляют новый код или вносят изменения в алгоритм исходного приложения.

Ключевым условием успешности подбных преобразований является устойчивость неочевидных и сложных для понимания конструкций и переменных [5]. Такие конструкции понятны обфускатору, но сложны для восприятия при деобфускации сторонними инструментами. Сложные для понимания конструкции являются тривиальными, если деобфускаторы могут установить их происхождение в процессе статического локального анализа, и слабыми, в случае их прослеживания в процессе глобального анализа.

Преобразования вычислений

Есть строгая зависимость между сложностью кода и числом конструкций, которое содержится в коде. С увеличиением числа конструкций в коде, добавить дополнительный запутывающий код становиться проще. Поэтому, наличие конструкций, сложных для восприятия предоставляет возможность для последующей обфускации программы. Например, базовый блок кода, B можно разделить на две части путем вставки некоторого запутывающего условия P^T (которое всегда возвращает True) в середину блока B. После этого для каждого из получившихся блоков можно применять различную технику обфускации. Также можно обфусцировать цикл путем изменения условия выхода из цикла некоторым сложно воспринимаемым выражением. Это может быть осуществлено с помощью добавления сложных блоков условий P^T(всегда возвращает True) иP^F(всегда возвращает False) которые не влияют на то, сколько раз будет выполняться тело цикла.

Обфускация абстракций данных

В последующих секциях будут описаны преобразования, которые затрудняют восприятие абстракций данных, используемых в исходном коде. Всего существует два типа таких преобразований: собственно, модификация связей наследования и реструктуризация массивов данных. Данная информация базируется на соответствующей работе Коллбегра [7].

Модификация связей наследования

В соответствии с метрикой Чидамбера (Метрика Чидамбера определяет сложность класса основываясь на количестве методов класса, глубине дерева наследования класса, количества прямых производных классов, количество прочих классов, с которыми данный класс связан, количества методов, которые могут быть выполнены в результате получения некоторого сообщения классом и т.д.) сложность программы увеличивается с увеличением глубины дерева наследования. Вместе с этим, можно исскуственно увеличить сложность программы либо путем разделения класса на несколько частей, либо путем добавления дополнительного фиктивного класса. Полагая, что класс C – это класс который будет разделен на C1 и C2, необходимо убедиться в том, что данное разделене не повредит область видимости всех переменных класса C. Другими словами, если разделить класс на две части, в одной части может ошибочно нехватать каких то переменных, которые оказались только во второй части. Кроме того, связи наследования могут быть искажены после ложного рефакторинга. Рефакторинг имеет место в следующих случаях. Во-первых, при идентификации двух классов, реализующих одинаковую логику. Во-вторых, перемещение логики, общей для двух классов в родительский класс. Ложный рефакторинг похож на обычный рефакторинг, за тем исключением, что ложный рефакторинг выполняется над двумя незвисимыми классами, которые не имеют общей логики.

Реструктуризация массивов

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

Обфускация процедурных абстракций

В последующих секциях будет рассмотрены различные виды преобразований, усложняющие восприятие процедурных абстракций программы. Это разрушает абстракции созданные пользователем или вводит новые абстракции, которые изменяют оригинальную структуру исходного кода.

Табличная интерпретация

Это одни из наиболее эффективных, но также чрезвычайно дорогостоящие преобразования, используемые при обфускации кода. Основная идея преобразования заключается в конвертации части кода в другой машинный код. Новый код выполняется новым интерпретатором виртуальной машины, включенным в обфусцированный код. Как правило в подобных случаях наблюдается существенное замедление выполнения кода, поэтому преобразования подобного рода должны использоваться только для фрагментов кода, которые требуют небольшие интервалы времени для своего выполнения.

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

Встраиваемые и невстраиваемые методы

Встраивание – прием оптимизации кода, который также нашел применение и в обфускации кода. Как только код становится встроенным (inlined), содержащий его метод ликвидируется, абстракция которую он представлял перестает существовать. Обратный процесс сводится к групировке определенного набора операций и формированию из нее отдельного метода. Примером встраивания и групировки может быть встраивание двух методов A и B которые вызываются друг за другом, и таким образом могут быть объединены в один новый метод.

Клонирующие методы

При исследовании отдельного фрагмента кода, человек занимающийся реверс инжинирингом будет смотреть прежде всего на тело метода и его сигнатуру. Окружение, где осуществляется вызов исследуемых методов, также играет очень важную роль в формировании понимания того, как работает код. Этот процесс можно сделать более запутанным, заменив вызовы реальных методов, вызовами других методов.

Обфускация встроенных типов данных

В последующих секциях будут рассмотрены различные преобразования, направленые на затруднение восприятия использования базовых типов данных в исходном приложении. Проектирование подобных преобразований, процесс весьма сложный, так как рассматриваемые типы данных являются неотъемлимой частью языков программирования. Эти преобразования являются чрезвычайно дорогостоящими и достаточно очевидными. Высокая стоимость обусловлена тем, что осуществляется воздействие на типы данных, а очевидность – потому что данные преобразования легко идентифицировать.

Разделение переменных

Некоторые переменные могут быть разделены на две или несколько переменных. В процессе разбивки переменной V типа T на две переменные p и q типа U, необходимо обеспечить реализацию следующих элементов:

Функция f(p,q), которая отображает значения p и q на соответствующее значение переменной V.
Функция g(V) которая отображает значение V на соответствующие значения p и q.
Новые операции приведения в терминах операций над p и q.

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

Конвертация статических и процедурных данных

Статические строки содержат много полезной информации для человека, занимающегося реверс инжинирингом. Простой способ обфускации таких элементов может быть их конвертация в отдельную программу, который вычисляет их значение. Можно реализовать вычисления для всех статических строк в одной функции, однако, это может упростить реверс инжиниринг. Генерация отдельных фрагментов кода для каждой строки и встраивание их в оригинальные код наверняка увеличит надежность и защищенность кода.

Склеивание скалярных переменных

Этот прием обфускации основан на объединении двух или более скалярных переменных в одну. Переменные v1, v2…vk могут быть объединены в одну переменную Vm, которая содержит в себе все диапазоны значений переменных v1, v2…vk. Арифметические операции которые выполнялись над переменными также подвергнутся преобразованию, сфокусированном на операциями над Vm. Однако степень эффективность подобных преобразований так же невысока, а стало быть подобные преобразование так же не являются панацеей.

Обфускация препятствующая статическому анализу программ

Нахождение эффективных решений данного типа обфускации задача непростая и предполагает разработку комплексных решений, которые могут привести к замедлению работы или потере точности данных. Преобразования, обсуждаемые в данном разделе описывают решения, которые затрудняют анализ программы посредством модификации управляющей логики программы (control flow). В процессе рассмотрения существующих методик, будет акцентировано внимание на приемах затрудняющих статический анализ программы. Статический анализ может быть как чувствительным к управляющей логике, так и независящим от нее. Последний вариант не способен предоставить столько информации, сколько это возможно благодаря статическому анализу зависящему от управляющей логики. Поскольку в случае наличия такой зависимости, в процессе анализа будет построен граф управляющего потока программы и данных. Приемы препятствующие статическому анализу увеличивают зависмость данных от графа управляющей логики. Это приводит к увеличение сложности и уменьшению точности анализа. Информация предоставленная в последующих секциях базируется на работе Вонга [13].

Преобразования управляющей логики

Преобразования управляющей логики осуществляются в два этапа. Первый этап осуществляет декомпозицию высокоуровневых переходов в серию выражений «if-then-goto». Следующий этап подразумевает модификацию выражений goto таким образом, что бы адресс перехода вычислялся динамически а не был задан в коде явно. Это может быть выполнено с помощью разветвления кода в соответствии с используемыми переменными. В процессе выполнения преобразований будет осуществлена замена непосредственных адресов переходов на динамически вычисляемые исходя из значений переменных, которые доступны в данном блоке кода и в результате упрощения графа управляющей логики. После проведения преобразований, явно указаные адреса переходов будут отсутствовать, а стало быть задача построения дерева переходов усложнится – теперь придется анализировать и запоминать последнее определение каждой переменной до выполнения каждого перехода.

Преобразования потока данных

После применения преобразований управляющей логики, проблема построения дерева напрямую зависит от анализа потока данных, что также является трудоемкой задачей. Фундаментальная сложность анализа потока данных свяазана с наличием иерархий данных в программе. Целью данного типа преобразований является создание дополнительных уровней данных в программе, которые будут определять вычисление, и соответственно анализ адресов переходов. Преобразования выполняются в следующем порядке:

В каждый метод добавить произвольное число переменных указателей.
Вставить исскуственные блоки или кода в существующих блоках, которые устанавливают значения для этих переменных-указателей.
Заменить ссылки на переменные и элементы массива этими указателями. Вычислния, использующие данные переменные должны быть обновлены таким образом, что бы они осуществлялись через указатели.
Определение указателей должно находится в других блоках, а не в тех где происходит их использование.

Эффектом подобных преобразований станет ситуация, когда статический анализатор будет не в состоянии определить какой блок выполнять. А поскольку определение указателей и их использование находится в разных местах, анализатор не сможет определить какое определение указателя соотностится с его использованием. Данный подход запутывания статического дизассемблирования приводит к увеличению времени анализа и уменьшению точности анализа до уровня бесполезности.

Обфускация кода на этапе дизассемблирования

Большинство рассмотренных приемов обфускации применяются на этапе декомпиляции. Но мы можем обфускировать код и на этапе дизассемблирования. В данной секции будут рассмотрены два наиболее широко применяемые алгоритма статического дизассемблирования и приемы для предотвращения каждого из них. Существует два метода дизассемблирования: статическое дизассемблирование, когда файл, подвергаемый дизассемблированию с помощью дизассемблера не выполняется в процессе дизассемблирования; и динамическое дизассемблирование, когда файл выполняется с использованием некоторых входных данных в процессе дизассемблирования. В данной секции рассматриваются только приемы, предотвращающие статическое дизассемблирование. Существует два вида статического дизассемблирования: линейная развертка и рекурсивный проход. При линейной развертке дизассемблер осуществляет обработку инструкций программы в порядке их следования в коде. При рекурсивном проходе дизассемблер обрабатывает инструкции в соответствии с управляющей логикой программы. То есть, когда встречается инструкция ветвления, дизассемблер определяет возможные варианты выполнения программы и осуществляет обработку этих ветвей. Методы описанные далее описаны в работе Линна [9].

Предотвращение дизассемблирования

Файл с машинным кодом состоит из различных секций, которые содержат различную информацию о программе. Одним из таких элементов информации является точка входа в программу, то есть местоположение машинного кода, где находится начало машинных инструкций. Для предотвращения дизассемблирования, необходимо насколько это возможно запутать восприятие того, где находятся границы машинного кода программы. Некоторые множества инструкций подвергаются проверке в процессе дизассемблирования. Это значит, что даже в случае некоторых ошибок дизассемблирования, дизассемблер выполняет синхронизацию с актуальным следованием инструкций программы. Таким образом, этот момент должен быть принят во внимание еще на этапе реализации запутывания. Некоторые приемы, используемые для предотвращения дизассемблирования описаны ниже.

Вставка мусора

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

Предотвращение линейной развертки

Дизассемблирование методом линейной развертки не может распознать данные в текстовой секции. Этот факт может быть использован для предотвращения дизассемблирования путем вставки мусорных байтов в определенном месте следования инструкций. Эти байты могут быть вставлены перед блоком, который никогда не будет выполняться в том порядке, в котором он находится относительно других инструкций. В программах, которые оптимизированы компилятором подобные блоки могут содержать до 30 инструкций. Для того, что бы поместить большее число мусорных данных, можно воспользоваться следующим преобразованием инструкций ветвления. Исходный блок условия

b_cc Addr

где cc представляет условие, преобразовать к виду:

bcc L’

jmp Addr

L’:

где cc это дополнение к предыдущему условию

Предотвращение рекурсивного прохода

Рекурсивный проход базируется на тщательном разборе управляющей логики, и именно здесь можно внести модификации для предотвращения дизасемблирования. Как только одно из ветвлений оббработано, процесс рекурсивного прохода продолжает процесс разбора одного из возможных блоков, на которые ссылается данная ветвь. Этот процесс предполагает, что это нормальное ветвление и вызовы методов работают соответственно. Условное ветвление имеет две возможные цели перехода и вызов метода для возврата в ту точку откуда вызов был осуществлен. Другим аспектом рекурсивного прохода является сложность идентификации возможных целей перехода при неявном перемещении управления внутри методов.

Функции ветвления

Предположение, что вызов функции возвращает управления инструкции следующей непосредственно за инструкцией вызова можно использовать в корыстных целях. Предположим имеется конечная карта переходов в программе:

Φ = {a₁ → b₁,a₂ → b₂ ... a_n → b_n}

Функция ветвления ƒ_Φ – это функция, вызываемая из a_i и в результате ее вызова управление передается b_i. Данную функцию ветвления можно заменить на выражение с n условиями:

A1:jmp b₁
A2:jmp b₂
An:jmp b_n

А это в свою очередь можно преобразовать следующим образом:

A1:jmp ƒ_Φ
A2:jmp ƒ_Φ
An:jmp ƒ_Φ

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

Преобразование вызова

Изменение схемы функции ветвления может использоваться для вставки мусорных байтов непосредственно после инструкций вызова. Это осуществляется посредством изменения маршрутизации в специальной функции ветвления, которая занимается управлением переходов к целевым функциям, и корректирует смещение инструкций куда нужно передать управление по возвращению из функции. Такой механизм может затруднить анализ управляющей логики сторонними инструментами дизассемблирования и усложнить поиск точки входа в программу.

Запутывающие предикаты

Предположение, что условное ветвление может иметь два выхода, может использоваться для преобразование безусловных ветвей кода к условным, котоыре всегда выполняются в заданном порядке. Это может быть достигнуто с использованием так называемых запутывающих предикатов. Как только безусловная ветка кода заменяется на условную, которая содержит некоторый запутывающий предикат, непосредственно перед этим предикатом появляется возможность вставить мусорные байты для ликвидации возможности дизассемблирования.

Сокрытие таблице переходов

Для ликвидации возможности дизассемблирования, помимо вставки мусорных байтов, можно также вставить таблицу исскуственных переходов для того что бы воспрепятствовать дизасемблированию с использованием рекурсивного прохода. Данный метод дизассемблирования будет пытаться определить размер таблицы переходов для тогго что бы идентифицировать возможные цели неявных переходов. Это поведение дизассемблера можно использовать, сделать таблицу переходов недоступной в момент выполнения.

Обфускация кода используемая в вирусах

Обфускация кода используется не только создателями коммерческого программного обеспечения для предотвращения возможности реверс инжиниринга; создатели вредоносного кода также могут использовать обфускацию для того что бы спрятать свои творения от антивирусных сканеров. В конечном счете, обе области использования обфускация имеют одну общую цель – сделать программу нечитаемой для третьего лица. Разумеется, различные области применения используют свои специфические особоенности. Вирусы должы учитывать тот факт, что их методы обфускации должны постоянно изменятся, иначе сканер будет способен из различить по постоянной сигнатуре. Это вносит ограничения по времени и пространству. Комерческое программное обеспечение ставит на первое место вопрос производительности, который органичивает использование многих возможных типов обфускации. В данном разделе будут рассмотрены различия между типами и приемами обфускации для коммерческого программного обеспечения и для защиты вредоносного кода. Первым делом стоит рассмотреть типы вирусов, которые могут использовать приемы обфускации, далее следует обратить внимание на преобразования, которые используются ими для предотвращения обнаружения. И наконец, будут рассмотрены возможности подбных приемов и варианты их использования в коммерческом программном обеспечении. В целях экономии времени исследование методик обфускации для вирусов будет предоставлено поверхностно.

Типы вирусов

Два основые типа вредоносных програм, которые используют приемы обфускации для собственной защиты от антивирусных сканеров это полиморфные и метаморфные вирусы. Простые вирусы не изменяют свое тело при каждой генерации, и поэтому сканеры способны выявить был ли заражен такими вирусами проверемый файл простым сопоставлением с некой постоянной сигнатурой. Полиморфные и метаморфные вирусы разрабатываются изначально с защитой от сканера. Такая защита базируется на приемах, которые изменяют сигнатуру кода вирусов при каждой генерации, выполняемой при заражении файла, что делает невозможным выявление вирусов по сигнатуре.

Полиморфные вирусы

Полиморфные вирусы являются расширениями шифрованных вирусов [1, 14]. Шифрованные вирусы просто зашифровывают свое тело и после этого присоединяют к себе ключ для расшифровки, который меняется от генерации к генерации. Полиморфные вирусы также зашифровывают свое тело, однако помимо этого они случайным образом изменяют свой алгоритм шифрования каждый раз, когда осуществляется инфицирование вирусом исполняемого файла-жертвы. А поскольку схема расшифровывания никогда не бывает защищена шифрованием и как правило добавляется всегда в конец файла, то это может послужить хорошую службу антивирусному сканеру. Поэтому, когда полиморфный вирус изменяет свой код дешифрации, он изменяет часть своей сигнатуры, которая является основным инструментов для сканера на распознавание вируса. Сканер в свою очередь может быть достаточно умным и подождать пока вирус осуществит деобфускацию. Также сканер может иметь возможность осуществлять выполнение вируса в «песочнице» или эмуляторе, которые позволяют вирусу выполняться без опасности для остального окружения. Как только вирус начинает выполнятся, он должен осуществить дешифрование своего тела для того что бы иметь возможность заразить жертву и поэтому эмулятор может просканировать исполняемый код на соответствие известным сигнатурам вирусов. Очевидно, данный прием имеет ограничения, одним из которых является незнание того сколько по времени необходимо выполнять код когда станет возможным проводить соспоставление по сигнатуре.

Метаморфные вирусы

Метаморфные вирусы, подобно полиморфным, осуществляют шифрование своего тела для того что бы спятать сигнатуру используемую анивирусным сканером. Метаморфные вирусы, однако, могут изменять свой исходный код и после этого осуществлять перекомиляцию самих себя если на машине-жертве доступен компилятор. Это позволяет вирусу добавить или удалить мусорный запутываюший код, который каждый раз оказвает влияние на сигнатуру кода. Метаморфные вирусы более продвинуты, нежели полиморфные. В то время как полиморфные вирусы дешифруют свое тело и после этого осуществляют заражение жертвы, метаморфные ведут себя иначе. Они никогда не раскрывают свое тело, что делает процес определения вируса практически невозможным для достаточно простого сканера. Как результат, сканеру приходится использовать различные эвристические приемы для идентификации метаморфного вируса. Среди основных приемов по прежнему используются эмуляторы, виртуальные машины которые эмулируют некоторую функциональность операционной системы. Вызовы системы слежения – это техника которая усиленно исследовалась последние годы [12, 8]. М Христодореску и другие недавно разработали прием статического анализа для выявления метаморфных вирусов [3]. Все приемы как правило основаны приемах, известных реверс-инжинерам коммерческого программного обеспечения. Статический анализ, декомпиляция и такогих приемов, котоыре в терминах теории обфускации можно назвать вставками «мертвого» кода.

Приемы обфускации

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

Вставка «мертвого» кода

Этот вид преобразований представляет собой имено то, что гласит его название, он использует вставку бессмысленных инструкций вперемешку с существующими инструкциями. Это могут быть инструкции которые ничего не делают (nop), или которые изменяют состояние программы, но потом возвращают предыдущее состояние обратно, или же инструкции переходов корые не позволяют вставленным инструкциям получить управление во время выполнения программы. С помощью всех этих изменений невозможно запутать человека, осуществляющего реверс инжиниринг, как это было показано М. Христодореску в [3], но вполне возможно воспрепятствовать нормальной работе антивирусных сканеров.

Трансформация кода

Трансформация кода это просто косметическое перемещение фрагмента кода внутри файла. Например местоположение процедуры может быть изменено, или изменено местоположение некоторых инструкций внутри процедуры, причем эти изменения не влияют на работу приложения.

Перераспределение регистров

Перераспределение регистров предполагает изменение решистров используемых реальными переменными. Если отдельный регистр R1 не используется в какой-то момент некоторым множеством переменных, но другой регистр R2 используется в данное время для хранения актуального значения некоторой переменной, то его можно заменить на R1. Снова стоит повториться, что эти преобразования никоим образом не не изменяют логику программы, но оказывают влияние на сигнатуру программы.

Замещения инструкций

Если сравнивать данное преобразование с теми которые были описаны выше, то данный прием является наиболее эфективным, даже если смотреть с точки зрения реверс инжиниринга. Замещение инструкций реализуется с помощью некоторого списка соответствия инструкций. В этом случае, инструкция в теле кода заменяется на другую, но аналагичную. Данный подход коренным образом изменяет сигнатуру кода, и практически не возможно осуществить деобфускацию, особенно если список соответствий недоступен.

Сравнения

Создатели вирусов осуществляют обфускацию кода для того что бы изменить сигнатуру кода вируса, таким образом, что бы антивирусные сканеры былы не в состоянии их идентифицировать. Это имеет смысл поскольку сканеры могут искать факт заражения вирусом даже там, где его нету. Это очевидное отличие от той обфускации, которая используется для затруднения реверс инжиниринга. В последнем случае обфускация используется для защиты и сокрытия некоторой чувствительной информации, о наличии которой знает человек, занимающийся реверс инжинирингом программы. Вцелом, приемы обфускации используемые вирусописателями не настолько эффективны, как приемы используемые в коммерческом програмном обеспечении. Однако, существуют примеры когда создатели вредоносного кода могут использовать методы обфускации, коорые вполне годятся и для комерческих программ. Таким примером может быть прием используемый вирусом, который называется Zmist, для того что бы спрятать свой полиморфный дешифратор [12]. Код дешифрации помещается в код жертвы небольшими фрагментами, которые соединены между собой инстркуциями безусловных переходов. Такой прием можно использовать в коммерческих решениях. Важные и чувствительные алгоритмы могут быть разбиты на фрагменты и разбросаны по всему остальному коду. Главным образом, преобразования применяемые к вирусам не защищают от атак реверс инжиниринга и поэтому не могут применятся для защиты коммеческих продуктов.

Взгляд под другим улом

На обфускацию можно посмотреть еще под одним углом, который до этого еще не рассматривался в данной публикации. Это обфускация, которая используется для предотвращения вредоносных встраиваний кода направленных изменения функционирования комерческих прогрудктов..Подобные атаки, как правило реализуются путем вставки вредоносного кода в существующую программу с целью получения управления этим вставленым кодом [10]. Очевидно, что для того что бы вставить подобный вредоносный код и успешно его выполнить необязательно иметь четкое представление обо всех нюансах работы кода программы-жертвы. Для предотвращения подобных атак, имеет смысл запутать программу настолько, что бы было сложно понять куда нужно вставлять вредоносный код для получения управления. И для таких целей обфускация также придет на помощь. В данный момент проводятся исследования вопросов обфускации, основной целью которой является динамическое изменение местоположения данных и выполняемого кода во время выполнения програмы [11, 2]. Подобные приемы призваны не только усложнить восприятие программы, но также и реализовать защиту от повторяющихся атак, которые не смогут успешно завершится изза того, что структура программы будет постоянно изменяться. Это особено интересный прием, так как он может оказывать влияние на то, как вирусы могут мутировать для того что бы избежать идентификации сканерами.

Заключение

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

В основу данной статьи положена публикация Arini Balakrishnan и Chloe Schulze «Code Obfuscation Literature Survey».

Литература

Understanding and managing polymorphic viruses, 1996.
Sandeep Bhatkar, Daniel C. DuVarney, and R. Sekar. Address obfuscation: an efcient approach to combat a broad range of memory error exploits.
M. Christodorescu and S. Jha. Static analysis of executables to detect malicious patterns. In 12th USENIX Security Symposium, pages 169–186, August 2003.
Christian Collberg, Clark Thomborson, and Douglas Low. A taxonomy of obfuscating transformations, July 1997.
Christian Collberg, Clark Thomborson, and Douglas Low. Manufacturing cheap, resilient, and stealthy opaque constructs. In Principles of Programming Languages 1998, POPL’98, pages 184–196, 1998.
Christian S. Collberg and Clark Thomborson. Watermarking, tamper–proofing, and obfuscation — tools for software protection. In IEEE Transactions on Software Engineering, volume 28, pages 735–746, August 2002.
Christian S. Collberg, Clark D. Thomborson, and Douglas Low. Breaking abstractions and unstructuring data structures. In International Conference on Computer Languages, pages 28–38, 1998.
A. Lakhotia and E. U. Kumar. Abstract stack graph to detect obfuscated calls in binaries. In IEEE International Workshop on Source Code Analysis and Manipulation, September 2004.
C. Linn and S. Debray. Obfuscation of Executable Code to Improve Resistance to Static Disassembly, 2003.
C. M. Linn, M. Rajagopalan, S. Baker, C. Collberg, S. K. Debray, J. H. Hartman, and P. Moseley. A multi–faceted defence mechanism against code injection attacks.
M. Madou, B. Anckaert, P. Moseley, S. Debray, B. De Sutter, and K. De Bosschere. Software protection through dynamic code mutation.
Peter Szor and Peter Ferrie. Hunting for Metamorphic, September 2001.
Chenxi Wang, Jonathan Hill, John Knight, and Jack Davidson. Software tamper resistance: Obstructing static analysis of programs. Technical Report CS–2000–12, 12 2000.
T. Yetiser. Polymorphic Viruses: Implementation, Detection, and Protection. VDS Advanced Research Group, January 1993.