Где можно посмотреть примеры ассемблера ARM64 на MASM?

Хочу драйвер перенести на Windows 11 ARM, но примеров найти не могу.

Конкретнее, эти два файла:
— https://github.com/tnodir/fort/blob/master/src/driver/proxycb/fortpcb_dst_x86.asm
— https://github.com/tnodir/fort/blob/master/src/driver/proxycb/fortpcb_src_x86.asm

нет смысла в ваших оптимизациях на асме
пишите на с

Здравствуйте, reversecode, Вы писали:

R>нет смысла в ваших оптимизациях на асме
R>пишите на с

Я бы рад, но это не оптимизации, а необходимое зло

Как можно переписать это для ARM64?

.DATA
PUBLIC g_proxyCallbacksArray
g_proxyCallbacksArray QWORD 64 DUP(?)

.CODE

ProxyCallbackProc MACRO index:REQ
    jmp QWORD PTR [g_proxyCallbacksArray + index * 8]
ENDM

proxyCallback0 PROC
ProxyCallbackProc(0)
proxyCallback0 ENDP

END

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

Здравствуйте, reversecode, Вы писали:

R>обоснуйте что ваши коллбеки это не обходимое зло
R>и что это _никак_ не переделывается на С
R>хотя их аналоги у вас рядом лежат на С

Напр., мне надо указать коллбек для KeInitializeDpc() на адрес функции, которая сгенерена вручную как JIT.
Но адрес коллбека должен быть внутри адресов драйвера, иначе будет bug-check из-за PatchGuard-а.

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

Поэтому написаны они на ассемблере, т.е. просто делают JMP по таблице на нужную функцию.

Здравствуйте, reversecode, Вы писали:

R>обоснуйте что ваши коллбеки это не обходимое зло
R>и что это _никак_ не переделывается на С
R>хотя их аналоги у вас рядом лежат на С

Можно было бы наверное сделать с помощью __attribute__((musttail)), но MSVC его не поддерживает.

https://stackoverflow.com/questions/55656938/why-noreturn-builtin-unreachable-prevents-tail-call-optimization

Здравствуйте, reversecode, Вы писали:

R>https://stackoverflow.com/questions/55656938/why-noreturn-builtin-unreachable-prevents-tail-call-optimization

Нет гарантии, что всегда будет tail-call.

сбилдите и проверте с __assume(0)
https://docs.microsoft.com/en-us/cpp/intrinsics/assume?view=msvc-170
годболд показывает что все ок

Здравствуйте, reversecode, Вы писали:

R>сбилдите и проверте с __assume(0)
R>https://docs.microsoft.com/en-us/cpp/intrinsics/assume?view=msvc-170
R>годболд показывает что все ок

Я не буду использовать C для этого, т.к. компилятор может что угодно сотворить.

в пределах одного компилятора это всегда будет одно и тоже поведение

компилируете свои С примеры в arm64
дизассемблируете
и выбираете нужные вам инструкции

Здравствуйте, nodir.temir, Вы писали:

NT>Напр., мне надо указать коллбек для KeInitializeDpc() на адрес функции, которая сгенерена вручную как JIT.
NT>Но адрес коллбека должен быть внутри адресов драйвера, иначе будет bug-check из-за PatchGuard-а.

Немного не по теме...

JIT? В kernel mode?!?
MS ведь давно блочит такие вещи. Я имею в виду, что на Windows 10 попытки в ядре работать с памятью с правами на исполнение
блокируются при включенном Device Guard / HVCI (ну или при активной проверке "Code Integrity Checks" в Driver Verifier).

Здравствуйте, nodir.temir, Вы писали:

NT>Я бы рад, но это не оптимизации, а необходимое зло

NT>

NT>.DATA
NT>PUBLIC g_proxyCallbacksArray
NT>g_proxyCallbacksArray QWORD 64 DUP(?)

NT>.CODE

NT>ProxyCallbackProc MACRO index:REQ
NT>    jmp QWORD PTR [g_proxyCallbacksArray + index * 8]
NT>ENDM

NT>proxyCallback0 PROC
NT>ProxyCallbackProc(0)
NT>proxyCallback0 ENDP

NT>END
NT>

Этож банальный массив function pointers

CC>Этож банальный массив function pointers

у него в одном и том же поинтере может лежать функции с разным количеством аргументов
соответственно можно сделать на него только jmp
и нельзя call
в С с ходу не придумалось как это можно обойти
кроме как заюзать __assume(0) что бы компиллер емитил jmp вместо call
но эму это не нравится, типа в мсвц это не документированно
хотя как по мне там жирный намек и годболд это на тестовом примере подтверждает

ну пуст дальше асмы компилит

Здравствуйте, reversecode, Вы писали:

R>у него в одном и том же поинтере может лежать функции с разным количеством аргументов
R>соответственно можно сделать на него только jmp и нельзя call
Что то мне кажется что у него там всё таки ограниченное число вариантов количества аргументов, пусть нагенерит несколько разных стабов и не морочит себе голову.

R>ну пуст дальше асмы компилит
Или так, да.

если указатели заранее можно все перечислить
то можно это загнать в union на С

Здравствуйте, okman, Вы писали:

O>JIT? В kernel mode?!?
O>MS ведь давно блочит такие вещи. Я имею в виду, что на Windows 10 попытки в ядре работать с памятью с правами на исполнение
O>блокируются при включенном Device Guard / HVCI (ну или при активной проверке "Code Integrity Checks" в Driver Verifier).

Да, для HVCI надо будет интерпретатор завести.
См. https://github.com/microsoft/ebpf-for-windows

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, reversecode, Вы писали:

R>>у него в одном и том же поинтере может лежать функции с разным количеством аргументов
R>>соответственно можно сделать на него только jmp и нельзя call

CC>Что то мне кажется что у него там всё таки ограниченное число вариантов количества аргументов, пусть нагенерит несколько разных стабов и не морочит себе голову.

Да, пока ограниченное.
Но я хочу сделать гарантированно рабочий код для любого кол-ва аргументов.

После истечения EV сертификата, не смогу менять загрузчик драйвера.

вообще хорошо подумав
в asm можно загнать только jmp
а таблицу и вызовы из таблицы итд в С держать
ну и вызывать каким нибудь jump_from(&g_table[0]);