Долой импорт!

Николай «GorluM» Андреев

Хакер, номер #080, стр. 080-116-1

(gorlum@real.xakep.ru)

Пишем приложение, не использующее таблицу импорта, на Си

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

[ищем функции сами]

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

a) ее не будет в таблице импорта, а следовательно, исследователю придется прилично покопаться, чтобы понять, что делает ее вызов;

b) поиск может осуществляться не только по имени, но например, и по хэшу, посчитанному от имени (в этом случае в программе вообще не фигурирует имени API, что серьезно затрудняет процесс исследования алгоритма работы программы… ну, конечно, не для всех серьезно, но все же).

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

[ищем ядро и модули]

Ядро, то есть дескриптор, то есть хэндл библиотеки keel32.dll найти очень просто (она подгружается к каждому процессу, поэтому не надо никак дополнительно извращаться - только найти). Этим всю жизнь занимаются вирмейкеры и поэтому метод, где только не описан. Заключается он в том, что дескриптор модуля ядра извлекается в общей сложности из структуры PEB, блока окружения процесса, ссылку на который можно получить, если обратиться к регистру fs по смещению 30h.

Содержание  Вперед на стр. 080-116-2
ttfb: 2.9399394989014 ms