Исходник Find real syscallNumber by brute-force

[Ahora_technology]

Сделала вчера ночью, поскольку было скучно .
Эта мемная идея пришла при просмотре фильма с @colby57 ,за что ему огромное спасибо ?.
Зачем мапать файл или использовать жёстко закодированные системные номера(Like:VMP) для обхода UM хуков,
когда можно просто получить правильный системный номер , путём брутфорса системного номера и проверки возвращаемого статуса?
Звучит гениально, не правда ли?
Это просто мемный PoC,поэтому не считайте данный код чем-то серьёзным.

Пожалуйста, авторизуйтесь для просмотра ссылки.

NtApi не хукнут:

NtApi хукнут,но нам пофиг на это:

 

[dota]

Здравствуйте, есть ли объяснение на пальцах для чайников зачем это нужно?

 

[Waltzing]

Здравствуйте, есть ли объяснение на пальцах для чайников зачем это нужно?

Когда ты вызываешь системные winapi функции они начинают свое исполнение в юзермоде, затем зачастую код переходит в ядро через системный вызов, чтобы делать более привилегированные штуки, а потом возвращается назад.
У каждого такого системного вызова есть свой номер, для них есть в ядре таблица обработчиков, т.е. так ядро понимает что ты от него хочешь.
Со временем появилась техника прямых системных вызовов, т.е. сам находишь нужный номер, генерируешь шелл и вызываешь, таким образом обходишь системный код, и в теории сложнее перехватить твои вызовы (до тех пор пока не найдут шелл).
Номера вызовов меняются от билда винды, поэтому чтобы их узнать есть два варианта.
Первый простой это хранить таблицу нужных номеров напрямую, но тут встает проблема что ты не можешь предсказать какой он будет на новой винде, поэтому твой код перестанет работать, так хранит например протектор VMProtect, и соответственно его защита частично отваливается на новых билдах.
Второй вариант это подгрузить ntdll.dll себе, спарсить номера из стабов, что более универсально.
Автор темы же, предложил третий упоротый вариант, т.к. ядро сильно валидирует параметры, то плохой системный вызов не приведет к крашу, это почти гарантированно, т.к. такие штуки сильно фаззят, взамен ядро вернет код ошибки NTSTATUS, т.е. формально можно узнать нужный системный вызов по его свойствам, т.е. узнать в каких случаях какие ошибки возвращаются и проверить что это совпадает ожиданиям. На практике метод хуйня, а автор просто порофлил.

 

[Ahora_technology]

Когда ты вызываешь системные winapi функции они начинают свое исполнение в юзермоде, затем зачастую код переходит в ядро через системный вызов, чтобы делать более привилегированные штуки, а потом возвращается назад.
У каждого такого системного вызова есть свой номер, для них есть в ядре таблица обработчиков, т.е. так ядро понимает что ты от него хочешь.
Со временем появилась техника прямых системных вызовов, т.е. сам находишь нужный номер, генерируешь шелл и вызываешь, таким образом обходишь системный код, и в теории сложнее перехватить твои вызовы (до тех пор пока не найдут шелл).
Номера вызовов меняются от билда винды, поэтому чтобы их узнать есть два варианта.
Первый простой это хранить таблицу нужных номеров напрямую, но тут встает проблема что ты не можешь предсказать какой он будет на новой винде, поэтому твой код перестанет работать, так хранит например протектор VMProtect, и соответственно его защита частично отваливается на новых билдах.
Второй вариант это подгрузить ntdll.dll себе, спарсить номера из стабов, что более универсально.
Автор темы же, предложил третий упоротый вариант, т.к. ядро сильно валидирует параметры, то плохой системный вызов не приведет к крашу, это почти гарантированно, т.к. такие штуки сильно фаззят, взамен ядро вернет код ошибки NTSTATUS, т.е. формально можно узнать нужный системный вызов по его свойствам, т.е. узнать в каких случаях какие ошибки возвращаются и проверить что это совпадает ожиданиям. На практике метод хуйня, а автор просто порофлил.

Ну,можно обнаружить такой шеллкод хукая системне вызовы из UM ( Hi,Instrumentation callbacks)
и из-за брутфорса данный метод работает слегка медленно(мы много раз звоним в ядро с неправильными параметрами)
и имеет недостатки , которые я написала в комментариях к коду(например:если нам попадётся системный номер NtTerminateProcess,то GG).
Это мемный PoC,поэтому не считайте данную технику гениальной и вы всё сказали верно(на самом деле извращенка) ,
но данный пример должен работать с windows xp -11.

 

[ohyouagain]

Ну,можно обнаружить такой шеллкод хукая системне вызовы из UM ( Hi,Instrumentation callbacks)
и из-за брутфорса данный метод работает слегка медленно(мы много раз звоним в ядро с неправильными параметрами)
и имеет недостатки , которые я написала в комментариях к коду(например:если нам попадётся системный номер NtTerminateProcess,то GG).
Это мемный PoC,поэтому не считайте данную технику гениальной и вы всё сказали верно(на самом деле извращенка) ,
но данный пример должен работать с windows xp -11.

можно через PEB получить билд винды и просто захаркодить сискалл айди + юзать инлайн сискаллы на clang

 

[Ahora_technology]

можно через PEB получить билд винды и просто захаркодить сискалл айди + юзать инлайн сискаллы на clang

Во-первых,этот метод очень известен. Лучше проверять номер винды через KUSER_SHARED_DATA(поскольку вы не можете переписать это число из UM на своё) и если версия windows >= 10,то читать с NtBuildNumber или юзать RtlGetVersion.
Если номер изменится и вы не добавите проверку- gg.
Во-вторых,если вы про

Пожалуйста, авторизуйтесь для просмотра ссылки.

,то там чтение с адреса и если NtApi хукнут,то вы получите не тот системный номер. Я пыталась сделать PoC без необходимости этого и чтобы это было слегка труднее обнаружить ( мапать файл - хороший вариант,но это очень легко заметить или чтение системного номера у другого процесса,но нам нужно вызвать NtOpenProcess).
В любом случае, каждый видит свои + или - и на эту тему можно долго болтать.