Как я не попал в лапы серой конторы.

Забавная ситуация произошла со мной на днях, дело в том что я в данный момент безработный программист :) Ищу работу в области разработки на С\С++, удалённую или в офисе, не важно. Раскинул резюме (включая hh.ru) и с более менее подходящими компаниями пытался связатся. Хотя я по интересам больше склонен к системной разработке и различным ИБ областям, мне вполне подходит работа с прикладным софтом, но это к слову. И так в один прекрасный вечер мне на email приходит письмо, от какой-то русской компании занимающейся разработкой в области ИБ и им требуется разработчик со знаниями С++\asm, WinAPI, PE и т.п. Не стану рекламировать данную контору, поэтому никаких адресов в статье не будет. Я конечно был рад, работа в той области в которой я уже не одну собаку съел, конечно мне была очень интересна.

Monstra PE Engine

В последнее время много моих разработок были тесно связанны с разбором и модификацией исполняемых файлов PE\PE+. Я старался писать переносимый код, однако функционал разрастался, где-то дописывался под конкретные цели и архитектура, как это бывает в таких ситуациях, стала очень сложной. Поэтому было решено разработать единую универсальную библиотеку, полезную не только мне в своих проектах, но и другим разработчикам. И назвал я сеё чудо Monstra PE Engine, имя собсно удобное и для других форматов (тут автор как бы намекает что возможно в будующем будут поддерживатся и другие форматы исполняемых файлов, например ELF).

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

В данный момент библиотека реализована на 50% и в скором времени будет выложена во всеобщий доступ. Мало того, мои утилиты DLib Attacher и PE Compare Tools будут портированы на данный движек и возможно будут далее сопровождатся. Так что живие примеры тоже будут. Кстати в открытый доступ выброщены и исходники перечисленных выше приложений.

Вот собственно и всё что хотел сказать, надеюсь это будет полезно кому-то кроме меня :)

О расширении секций PE приложений

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

Проблемы расширения

Начнём пожалуй с того, что взглянем на проблемы которые стоят на нашем пути. На самом деле проблема только одна, это связи. Их можно поделить на 2 типа:

1. Смещения (анг. offset), т.е. относительные адреса, которые могут указывать на данные из других секций.
2. Виртуальные адреса(анг. virtual address), которые обычно находятся в кодосекции (напр. mov eax, dword ptr[00404264])

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

Рис. 1. Связи внутри PE приложения

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

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

Изменение размера произвольной секций PE файла

Пример техники изменения виртуального размера произвольной секции исполняемого файла и нормализации связей через релоки. Реализованы следующие фитчи:
- Изменение виртуального размера произвольной секции
- Нормализация смещений PE заголовков (включая импорты, экспорты, ресурсы и т.д.)
- Нормализация виртуальных адресов через релоки
- Поддержка PE и PE+(x64) частично
и т.д.

Добавление крайней секции в PE файл

Техника добавления крайней секции в PE файлы. Демонстрируются следующие фитчи:
- Добавление последней секции и внесение в неё данных из файла
- Пересчёт PE checksum (IMAGE_OPTIONAL_HEADER.Checksum)
- Сдвиг оверлея
- Сдвиг Bound Import заголовков
- Поддержка PE и PE+(x64)

Расширение крайней секции PE файла

Пример техники расширения крайней секции исполняемого файла. Демонстрируются следующие фитчи:
- Растягивание последней секции и внесение в неё данных из файла
- Пересчёт PE checksum (IMAGE_OPTIONAL_HEADER.Checksum)
- Сдвиг оверлея
- Поддержка PE и PE+(x64)

Установка Visual Studio 2010 и 2012 вместе.

Не знаю то ли я где-то туплю, то ли Мелкомягкие, суть в чём, ставлю 2010 студию, наверх 2012 и последняя абсолютно не желает компилить С++ програмы. После плясок с бубном выяснилось что заголовочные файлы и либы под 2012 почему-то не установились. Проблему решил перебросом папки VC из установленной на другом ПК 2012 студии. Система нипель ёпт!

OllyDbg 2.01 Released

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

Как и предполагалось баги некуда не делись, для обычного ровного приложения полёт нормальный, но как только подсунешь нечто с tls callback, или базонезависимый код, всё крешится, зависает, буфероверфловится и т.п. чернь. Даже ручная трассировка вызывала креш.  Нормально реверсить проты и мальварь в таких условиях явно невозможно. Тваютомать!

В общем мы(покрайней мере я) всё ещё верим в тебя Олег, что ты сможешь допилить вторую линейку до стейбла, запилишь туда х64 и прочие крутые плюшки. Уж больно не хочется переходить на другие более стабильные но дико неудобные отладчики

Сайт ольги http://ollydbg.de/

Загрузка библиотеки средствами ntdll.LdrLoadDll

Собственно маленький пример загрузки dll через недокументированную LdrLoadDll из Ntdll.dll. Код полностью независим от Kernel32.dll, что даёт возможность использования его в shellcode. Для получения адреса ntdll.dll используется трюк с PEB, а для поиска адреса LdrLoadDll используется самописанный парсер заголовка PE, аналог GetProcAddress. Всё предельно просто, но мало ли кому пригодится.

* код работает только под x86, чуть позже добавлю и для x64

Осторожно, многомерные массивы в С!

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

 #include <stdio.h>  
 #include <stdlib.h>  
 int main()  
 {  
      char ***buf;  
      char arr[5][4][3];  
      int i, a;  
      arr[4][3][2] = 0x21;  
      buf = (char ***)malloc(sizeof(char **) * 5);  
      for (i = 0; i < 5; i++) {  
           buf[i] = (char **)malloc(sizeof(char *) * 4);  
           for (a = 0; a < 4; a++) {  
                buf[i][a] = (char *)malloc(sizeof(char) * 3);  
           }  
      }  
      buf[4][3][2] = 0x21;  
      printf("%x %x", (int)arr[4][3][2], (int)buf[4][3][2]);  
      getchar();  
      return 0;  
 }  

Тут создаются 2 многомерных массива, один в качестве типа char[5][4][3], а другой как char *** и соответственно заполняется динамически. Мне еще в универе внушили что многомерный массив это указатель на указатель и т.д., следуя данной логике можно предположить что arr и buf, посути одно и тоже, однака хрен там :) Несмотря на то что обращение к элементам этих массивов выглядит одинаково, в памяти они укладываются совершенно разными способами. Массив с типом char *** действительно является указателем на указатель и т.д., однако  char[5][4][3] является указателем на сплошной блок данных и для того чтобы обратится к элементы расчитывается только смещение, без всяких прохождений по цепочке указателей. Вот так вот, как говорится доверяй но проверяй.