автоматизация перевода программы на чисто ядерные вызовы

то что любая хорошая защита пасёт программы в r0 - это и ежу понятно.
но в разных местах поднимаются вопросы о номерах системных вызовов,
с целью вызова их из r3 для опхода каких-то поделок, значит это ещё немного актуально.
появилась такая интересная идея, постараюсь её последовательно и подробно описать.
взять опенсорс ассемблер, лучший кандидат это FASM, в принципе идею можно продолжить
и на каком-то опенсорс "C", типа WATCOM, но не отвлекаемся и рассматриваем FASM.
опенсорс нужен, так как мы будем переделывать принцип компиляции.

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

format PE GUI 4.0 ntbuild 2600 ; под какой билд работаем

ntimport kernel32,\
ExitProcess, ; что и откуда заменяем

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

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

 

wsd
Извините, я не совсем понял для чего это все.

 

Aspire
обход перехватов юзермодных защит

 

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

 

Aspire

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

в принципе можно сделать несколько OBJ с билдзависимым функционалом и слинковать с главным модулем выбирающем что вызывать по реальной системе

 

У меня была идея взять библиотеку импорта kernel32.lib, и заменить его статической библиотекой, которая дублировала бы весь юзермодный код kernel32+ntdll, и использовала бы прямые вызовы сервисов ядра. Тогда прога не зависела бы от юзермодной части ядра ОС.
Такую kernel32.lib можно было бы использовать и в масме и в С\С++.
(И в фасме, если юзать внешний линкер)

 

GoldFinch
тоже вариант, но у него, как и у моего, свои недостатки.

не совсем понял, а так чем зависит?

 

wsd
импортами. обычно прога импортирует, статически или динамически, функции kernel32, ntdll
их можно перехватить, по ним прогу можно реверсировать

 

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

 

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

 

Rockphorr

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

да, хороший вариант

 

Для fasm должно хватить макросов, причем можно обеспечить поддержку всех известных ОС. Но кода придется написать прилично и он никому не будет нужен.

 

J0E

да, вариант хороший. и уже не первый человек предлогает.

да и вообще к "автоматизация перевода программы на чисто ядерные вызовы" в любом виде что-то не очень здесь прёт)
действительно не актуально. а я надеялся что

 

Вся защита будет строиться на том, что вы напрямую будете вызывать sysenter/int 0x2e с нужными номерами сисколов?
а) задолбаетесь писать врапперы. очень задолбаетесь.
б) вы уверены, что найдете списки сисколов под КАЖДЫЙ билд винды? а вдруг один-два пропустите?
в) хук можно будет поставить в ядре и тогда вся идея пролетает как фанера над Парижем, ага.

А вообще я не очень понял при чем тут еще и р0 защита. Или вы хотите вызывать как-то хитро ф-ии р0 защиты у себя?

 

Great

нет конечно, это не от чего нормального не защитит, имелось в виду

а) да задолбаюсь
б) согласен
в) так я про это и писал в

и на вопрос

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

 

wsd
Просто Грейт забыл(или не знал ?) что можно переносить код в памяти. По мойму впервые это дроппер рустока юзал(ну либо я в нём это впервые увидел). Перенос кода в памяти - простой морфинг. Вы дизасмите нужный код, затем пересобираете его с другой базы.

 

Clerk
интересный вариант
Грейт не забыл и не незнал, просто обсуждали чуть другой способ

 

wsd
o Есть два типа переменных. Первый это фиксированные в кодосекциях, по сути это константы, обращение к которым происходит через ссылки: калбэки, текстовые строки и тп. Второй тип это изменяемые переменные. В отличае от первого типа, для которого по большей части переменные находятся в кодосекциях, для второго типа переменные находятся в памяти R/W, тоесть в секциях данных. На основе этого можно их разделить просто проверкой к какой секции модуля они принадлежат.
o Для всех ссылок на переменные определены фиксапы(релоки). Это позволяет находить переменные.
o Переменные находящиеся в секциях данных не могут быть переопределены, так как обычно повторная инициализация модуля не возможна и обращение к этим переменным производится не только из целевой процедуры. Поэтому можно изменить адрес переменной, но нельзя изменить её значение. При этом имеется основная проблема, которая и препятствует качественной пермутации - размер переменной не известен(тут только для кодосекций). В контексте данной задачи незачем выполнять полный реверс модуля, достаточно переместить секцию с переменными в иную область памяти просто копированием её целиком. Тогда дельта для двух переменных не изменится. Такое перемещение требует последующую релокацию. Тут может быть два решения:
1. Проецируем модуль на другой адрес. Выполняем релокацию, причём для секций данных ссылки измяняются таким образом, дабы указывали в первый модуль.
2. Используем разделяемую память. Секция данных оригинального модуля заменяется на проекцию обьекта секция(section object). Во второй проекции модуля секция данных заменяется на вторую проекцию созданной секции, в которой находится первая секция данных. Тоесть в об.секцию копируется секция данных первого модуля, потом она проецируется на оба модуля. В этом случае фиксапы для второго модуля стандартные, просто загрузка по иной базе.
3. Использовать морфинг. При этом ссылки остаются не изменными, либо изменяются как в 2. Этот способ я юзал как наиболее приемлимый. Причём в этом случае просто изменять стабы, так как граф содержит непосредственно ссылки на них.
o Поправка ссылок на стабы. Так как необходимо изменить Sysenter на Int 0x2E(KiFastSystemCall -> KiIntSystemCall в простейшем случае), без обращения к USD, то стаб полностью переписывается и ссылки на него правяться.
o Изменять поток инструкций. Это различного рода махинации связанные с обработкой исключений. Например инвалидация ссылок на стабы с последующим редиректом потока на свой стаб.

 

wsd
цитата из хелпника к ваткому

void mode4(void);
#pragma aux mode4 = \
0xb4 0x00 /* mov AH,0 */ \
0xb0 0x04 /* mov AL,4 */ \
0xcd 0x10 /* int 10H */ \
modify [ AH AL ];

или

void mode4(void);
#pragma aux mode4 = \
"mov AH,0", \
"mov AL,4", \
"int 10H" \
modify [ AH AL ];

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

Great

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

 

qqwe
Для примера возьмите ExitProcess(). Как её вызвать, заменив все вызываемые стабы на свои ?