Молчи и скрывайся. Прячем IAT от антивируса

Все написан­ные под Windows прог­раммы име­ют IAT (Import Address Table) — это таб­лица, которая содер­жит фун­кции, импорти­руемые прог­раммой из DLL-биб­лиотек. Зачас­тую нам, как ата­кующим, сле­дует скры­вать импорты, что­бы анти­вирус­ным при­ложе­ниям было слож­нее иден­тифици­ровать исполь­зуемые в прог­рамме фун­кции. В этой статье разоб­раны некото­рые спо­собы скры­тия таб­лицы импортов.

Простейшее скрытие

Итак, пусть у нас есть прос­тень­кая прог­рамма, которая, нап­ример, выводит MessageBox.

Ес­ли мы пос­мотрим на то, что лежит у нее в IAT, то будем неп­рият­но удив­лены. Здесь и CRT, и какие‑то левые фун­кции, которые мы даже не вызыва­ем.

Пред­лагаю сра­зу же изба­вить­ся от CRT. Common Language Runtime — набор фун­кций и мак­росов для прог­рамм на С. Фун­кции обыч­но свя­заны с управле­нием памятью (memcpy()), откры­тием и зак­рыти­ем фай­лов (fopen()) и работой со стро­ками (strcpy()).

Биб­лиоте­ки DLL, которые реали­зуют CRT, называ­ются vcruntimeXXX.dll, где XXX — номер вер­сии исполь­зуемой биб­лиоте­ки CRT. Это пра­вило при­меня­ется не ко всем биб­лиоте­кам CRT, встре­чают­ся так­же DLL c име­нами api-ms-win-crt-stdio-l1-1-0.dll, api-ms-win-crt-runtime-l1-1-0.dll и api-ms-win-crt-locale-l1-1-0.dll. Каж­дая DLL слу­жит для опре­делен­ной цели и экспор­тиру­ет нес­коль­ко фун­кций. Эти биб­лиоте­ки DLL ком­пону­ются ком­пилято­ром во вре­мя ком­пиляции и поэто­му находят­ся в IAT сге­нери­рован­ных прог­рамм.

Что­бы зас­тавить ком­пилятор сде­лать ста­тичес­кую лин­ковку (в этом слу­чае биб­лиоте­ка не импорти­рует­ся, а уже как бы зашита в прог­рамму), сле­дует изме­нить свой­ства про­екта. Сна­чала откры­ваем раз­дел в «Про­ект → Свой­ства».

От­туда перехо­дим в «C/C++ → Соз­дание кода → Биб­лиоте­ка вре­мени выпол­нения → Мно­гопо­точ­ная (/MT) → При­менить → ОК».

За­тем переком­пилиру­ем про­ект и про­веря­ем IAT.

От­лично, от CRT в IAT мы изба­вились. Теперь приш­ло вре­мя погово­рить о скры­тии импорта фун­кции MessageBoxW(). Сама фун­кция пред­став­лена в биб­лиоте­ке user32.dll, поэто­му мы можем исполь­зовать API GetProcAddress() для получе­ния адре­са этой фун­кции и ее вызова.

Здесь hModule — хендл на DLL, в которой реали­зова­на фун­кция, а lpProcName — имя этой фун­кции. Для успешно­го вызова MessageBoxW() нуж­но лишь соз­дать про­тотип фун­кции в нашем коде.

Ком­пилиру­ем, про­веря­ем IAT и видим, что фун­кция про­пала.

Ка­залось бы, неп­лохо? Всем спа­сибо, конец статьи.

Но не тут‑то было. Давай нас­тро­им ком­пилятор так, что­бы он импорти­ровал не все фун­кции из kernel32.dll, а лишь нуж­ные, то есть те, которые в явном виде при­сутс­тву­ют в коде. Для это­го сна­чала отклю­чаем SDL.

За­тем отклю­чаем опти­миза­цию прог­раммы.

От­клю­чаем исклю­чения C++, дела­ем ста­тичес­кую лин­ковку, отклю­чаем про­вер­ку безопас­ности.

Вклю­чаем игно­риро­вание стан­дар­тных биб­лиотек.

От­клю­чаем файл манифес­та, уби­раем соз­дание дебаг‑информа­ции.

За­тем уста­нав­лива­ем точ­ку вхо­да.

Пе­реком­пилиру­ем про­ект, про­веря­ем IAT и видим, что любой жела­ющий смо­жет опре­делить исполь­зование LoadLibrary() и GetProcAddress() в нашем коде.

От этих фун­кций никак не изба­вить­ся (через GetProcAddress() тем более не выз­вать — рекур­сия), поэто­му при­дет­ся при­думать какую‑то аль­тер­нативу.

Собственные LoadLibrary() и GetProcAddress()

Нач­нем с написа­ния собс­твен­ной GetProcAddress(). У каж­дой DLL-биб­лиоте­ки есть раз­дел EAT (Export Address Table), в котором содер­жатся экспор­тиру­емые из этой биб­лиоте­ки фун­кции. Бук­валь­но — методы, которые могут быть выз­ваны при вклю­чении этой DLL в прог­рамму.

Прос­мотреть экспор­ты поз­воля­ет тот же dumpbin, но с фла­гом /exports.

Нам нуж­но лишь как‑то получить базовый адрес заг­рузки биб­лиоте­ки, а затем от него мож­но доб­рать­ся до EAT. Пока для прос­тоты экспе­римен­та базовый адрес заг­рузки пред­лагаю получать через LoadLibrary(). Эта фун­кция поз­воля­ет заг­рузить биб­лиоте­ку в текущий про­цесс, а затем получить на нее хендл.

Этот хендл явля­ется базовым адре­сом заг­рузки DLL в память про­цес­са. Пос­ле получе­ния базово­го адре­са сле­дует начать пар­сить EAT, до него мож­но доб­рать­ся по пути IMAGE_DOS_HEADER → IMAGE_NT_HEADERS → IMAGE_OPTIONAL_HEADER → IMAGE_DATA_DIRECTORY → IMAGE_EXPORT_DIRECTORY. Под­робнее о пар­синге PE мож­но про­читать в раз­личных пуб­ликаци­ях, вот нес­коль­ко ссы­лок.

Те­перь ныр­нем в пучины интерне­та и поищем кас­томную реали­зацию GetProcAddress(). Я выб­рал самый акку­рат­ный и милый вари­ант.

Фун­кция дос­таточ­но прос­та: при­нима­ет базовый адрес заг­рузки биб­лиоте­ки, а так­же имя фун­кции, адрес которой надо получить. Работа­ет так, как нам и нуж­но, — путем пар­синга EAT.

Пом­нишь, мы отклю­чили CRT? Поэто­му исполь­зование фун­кции strcmp() из это­го кода невоз­можно. К счастью, срав­нение двух строк — базовый алго­ритм, который пишут еще на пас­кале в седь­мом клас­се. На C++ я вынес его в отдель­ную фун­кцию custom_strcmp().

Ра­зоб­равшись, как и что делать, получа­ем сле­дующий код.

Ком­пилиру­ем, запус­каем. Видим, что остался лишь один импорт.

Чем же заменить LoadLibrary()? Если мы гля­нем на пос­ледова­тель­ность вызовов фун­кций, то уви­дим, что LoadLibrary() вызыва­ет LdrLoadDll(), она — LdrpLoadDll(), а та — еще одну фун­кцию... Про­цесс, ска­жу чес­тно, дос­таточ­но слож­ный. Вот кар­тинка, которая хорошо опи­сыва­ет пос­ледова­тель­ность вызовов при заг­рузке DLL.