Сис­колы (они же сис­темные вызовы) — очень боль­шая и инте­рес­ная тема. Я пос­тарал­ся вкрат­це опи­сать, что это и зачем они нуж­ны. Если ты захочешь более глу­боко пог­рузить­ся в тему, ниже най­дешь нес­коль­ко полез­ных ссы­лок.

www

• 
  Direct Syscalls: A journey from high to low
  


• 
  Direct Syscalls vs Indirect Syscalls
  

Итак, сис­кол мож­но счи­тать переход­ной ста­дией меж­ду поль­зователь­ским режимом (User Mode) и режимом ядра (Kernel Mode). Это как бы переход из одно­го мира сис­темы в дру­гой. Если еще про­ще, то сис­кол — прос­то обра­щение к ядру.

Вы­зовы ядра край­не важ­ны для кор­рек­тно­го фун­кци­они­рова­ния сис­темы. Нап­ример, имен­но заложен­ные в ядре фун­кции поз­воля­ют соз­давать фай­лы. Каж­дый сис­кол однознач­но иден­тифици­рует­ся по сво­ему номеру. Этот номер называ­ется по‑раз­ному, где‑то Syscall Id, где‑то Syscall Number, где‑то SSN — System Service Number. Номер сис­кола под­ска­зыва­ет ядру, что ему нуж­но делать. Он заносит­ся в регистр eax, пос­ле чего выпол­няет­ся инс­трук­ция syscall, которая осу­щест­вля­ет переход в режим ядра.

Проб­лема в том, что средс­тва защиты могут ста­вить хуки непос­редс­твен­но перед вызовом инс­трук­ции syscall. Нап­ример, как на сле­дующем скрин­шоте.

Это может сви­детель­ство­вать о наличии хука. Нич­то не меша­ет нам нап­рямую вызывать инс­трук­цию syscall из адресно­го прос­транс­тва сво­его про­цес­са, такая тех­ника называ­ется Direct Syscall. Мы даже можем обра­щать­ся к инс­трук­ции syscall, най­дя ее адрес в смап­ленной в наш про­цесс биб­лиоте­ке ntdll.dll (такая тех­ника называ­ется Indirect Syscall). Проб­лема лишь одна — нужен SSN. Без номера сис­кола, сох­ранен­ного в регис­тре eax, ничего не получит­ся.

Техника поиска SSN

SSN раз­лича­ется от сис­темы к сис­теме. Он зависит от вер­сии Windows. Есть отличная таб­лица акту­аль­ных сис­колов, но каж­дый раз хар­дко­дить SSN вооб­ще не вари­ант. Поэто­му дав­но при­дума­ны спо­собы динами­чес­ки дос­тавать номера сис­колов, а затем уже с эти­ми номера­ми выпол­нять Direct- или Indirect-вызовы.

Да­вай раз­берем один из самых извес­тных методов — Hell’s Gate, а затем перепи­шем его под Tartarus Gate.

Тех­ника обна­руже­ния SSN дос­таточ­но прос­та. Сна­чала, что­бы получить заг­ружен­ный в про­цесс адрес ntdll.dll, прог­рамма дос­тает адре­са TEB (Thread Environment Block), за ним PEB (Process Environment Block). А пос­ле извле­кает из таб­лицы PEB_LDR_DATA базовый адрес заг­рузки ntdll.dll.

Прог­рамма, зная базовый адрес заг­рузки биб­лиоте­ки, получа­ет адрес EAT (Export Address Table). В этой таб­лице содер­жатся адре­са всех экспор­тиру­емых из биб­лиоте­ки фун­кций.

Пос­ле успешно­го получе­ния всех адре­сов идет ини­циали­зация спе­циаль­ной струк­туры — струк­туры VX_TABLE.

Таб­лица VX_TABLE сос­тоит из дру­гих струк­тур VX_TABLE_ENTRY. Внут­ри них будут запол­нены эле­мен­ты pAddress, dwHash и wSystemCall, которые отве­чают соот­ветс­твен­но за адрес нуж­ной фун­кции, хеш от име­ни фун­кции (он пот­ребу­ется для API Hashing) и номера сис­темно­го вызова.

Для обна­руже­ния сис­кола исполь­зует­ся фун­кция GetVxTableEntry(), но перед этим пред­варитель­но ини­циали­зиру­ется эле­мент dwHash опи­сан­ной выше струк­туры. Хеш рас­счи­тыва­ется заранее. Для это­го исполь­зует­ся алго­ритм djb2, вынесен­ный в отдель­ную фун­кцию.

GetVxTableEntry() пар­сит EAT и обна­ружи­вает адрес нуж­ной фун­кции с помощью API Hashing.

Пос­ле обна­руже­ния нуж­ной фун­кции ее адрес записы­вает­ся в таб­лицу, а затем ищет­ся номер сис­кола для этой фун­кции. Hell’s Gate ищет пат­терн, харак­терный для вызова сис­кола.

Для это­го Hell’s Gate ска­ниру­ет память на наличие соот­ветс­тву­ющих опко­дов.

Ес­ли пат­терн най­ден, начина­ется выч­ленение номера сис­кола. Для наг­ляднос­ти возь­мем сис­кол с «длин­ным» номером, нап­ример 10F. В дизас­сем­бле­ре уви­дим инте­рес­ную кар­тину.

Инс­трук­ция, сох­раня­ющая номер сис­кола в регистр eax, выг­лядит вро­де бы нор­маль­но, но если мы пос­мотрим вни­матель­нее, то уви­дим, что номер сис­кола пред­став­лен как бы в перевер­нутом виде.

Hell’s Gate зна­ет о таком поведе­нии сис­темы, поэто­му выч­леня­ет сис­колы с исполь­зовани­ем спе­циаль­ного алго­рит­ма.

Ес­ли мы пос­тавим бряк на пред­послед­нюю строч­ку кода, то уви­дим, что в high попада­ет «вер­хняя» часть, а в low — «ниж­няя».

Со­ответс­твен­но, если алго­ритм выч­леня­ет SSN 10F, то перемен­ные ини­циали­зиру­ются как 0x1 и 0xF.

В wSystemmCall заносит­ся зна­чение high со сдви­гом вле­во на 8 байт. Это при­водит к получе­нию из 0000 0001 зна­чения 1 0000 0000. Сле­дующим шагом выпол­няет­ся побито­вая опе­рация ИЛИ со зна­чени­ем 0000 1111 (0xF в дво­ичной сис­теме счис­ления), в резуль­тате мы получа­ем 1 0000 1111. А это, в свою оче­редь, рав­но 10F. 10F как раз и есть номер сис­кола.

До­пол­нитель­но прог­рамма про­веря­ет, не ушли ли мы в поис­ке номера сис­кола слиш­ком далеко. Для это­го так­же исполь­зуют­ся опко­ды.

Изменение алгоритма хеширования

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

Ко­неч­но, мож­но было прос­то поменять SEED-зна­чение и рас­счи­тыва­емый хеш в фун­кции djb2(), но мы все‑таки решили пол­ноцен­но перепи­сать инс­тру­мент, а не баловать­ся, меняя перемен­ные.

Для удобс­тва вызова и авто­мати­чес­кого при­веде­ния к нуж­ному типу соз­дадим мак­рос.

Так как мы пока нез­накомы с Compile-Time API Hashing, напишем прог­рамму для перес­чета хешей от нуж­ных нам фун­кций.

Изменение GetVxTableEntry

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

Для ини­циали­зации дос­таточ­но один раз выз­вать фун­кцию InitNtdllConfigStructure().

Са­му фун­кцию GetVxTableEntry() сле­дует пере­име­новать в FetchNtSyscall(). Мы оста­вим все­го два парамет­ра: dwSysHash (хеш‑зна­чение от име­ни фун­кции, которую нуж­но засис­колить) и pNtSys — ука­затель на струк­туру NT_SYSCALL, которая будет содер­жать всю необ­ходимую информа­цию для осу­щест­вле­ния сис­кола.

Фун­кцию InitNtdllConfigStructure() сле­дует вызывать из фун­кции FetchNtSyscall(). Пред­лагаю прос­то про­верять, ини­циали­зиро­ван ли эле­мент, содер­жащий базовый адрес заг­рузки ntdll.dll. Если нет, то вызыва­ем фун­кцию, если этот эле­мент уже име­ет какое‑то зна­чение, то вызов не тре­бует­ся. Алго­ритм для поис­ка сис­кола пока что не меня­ем.

Изменение логики поиска сискола

Hell’s Gate — один из прос­тей­ших спо­собов нахож­дения сис­кола. Проб­лема в том, что он прос­то про­бега­ет по памяти в одном нап­равле­нии, пыта­ясь обна­ружить сис­кол. К сожале­нию, в сов­ремен­ных реалиях этот вари­ант, мяг­ко говоря, не самый рабочий. Что меша­ет анти­вирус­ному про­дук­ту внес­ти некото­рые изме­нения? Нап­ример, добавить лиш­нюю инс­трук­цию, что­бы сло­мать поиск Hell’s Gate.

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

Теги: CSS