Привет! Может кто сталкивался с Subj - я хочу понять, как при rpc вызове происходит сериализация данных при вызове - пока я делал так: перехватил функцию Alpc и смотрю сами вызовы, вижу сырые данные. С подключением и привязкой я разобрался, вопрос именно по передаче параметров при вызовах. Я их повторил - вызов прошел, потом я начал в idl добавлять параметры и смотреть что поменялось. Для одного входного параметра типа DWORD - добавилось в конец содержимое этого DWORD, всего 4 байта. Но когда я сделал [in] DWORD dwSize, [in, size(dwSize)] BYTE* pData, то увидел: "dwSize 00 00 00 00 dwSize 00 00 00 00 {все байты данных}" Я начал изучать что есть, но ничего явно совпадающего с этим я не нашел. Может кто изучал эту тему или сталкивался с чем-то подобным?
Давно дело было и с rpc over tcp в основном, но думаю с локальным примерно так же. Суть в том что в сервере и клиенте мидлом компилится байтовая format string, по которой клиент сериализует, а сервер десериализует параметры. Формат сложный и хитровыделаный. Дополнительную крипоту придает то что M$ несколько лет назад опубликовали спецификацию (вроде бы по какому-то решению суда), а теперь найти не могу, либо убрали либо хорошо запрятали. Можно смотреть начиная отсюда https://docs.microsoft.com/en-us/windows/win32/rpc/rpc-ndr-engine https://rsdn.org/article/com/marsh.xml Мои заметки 15(20?)летней давности в аттаче.
drem1lin, Для чего так низко лезть, протоколы наверняка изменяются. Рационально отмотать стек до стабильного прототипа апи и тогда работать с аргументами.
Так и есть, емнип оно еще и от версии мидла зависит (ну или раньше зависело), т.е. если сервер был скомпилен одно версией, то клиент другой уже не скомпилить с идентичным набором аргументов и соответственно сервер не вызвать, нужно ручками формировать эти строки либо искать MIDL компилятор нужной версии.
ormoulu, Есть структуры в 2к, но если дебаг инфу вытянуть из старших версий там же будет совсем другое. Во первых откуда управление в интерналс получается. От апи до межпроцессного обмена такие слои абстракций, что лезть туда во внутрь кажется бредом. Разве что поиск уязвимостей в протоколах.
Спасибо за ваши ответы - у меня нет задачи взлома и о общей совместимости тоже дело не стоит. Моя задача проще - есть собственный rpc сервер, с небольшим набором функций, который надо вызвать из моей же программы, но не с уровня RPC, а с уровня ALPC. Соответственно полные результаты MIDL компиляции у меня есть, и даже простейшие вызовы я реализовал - но тут осталось разобраться с передачей параметров - может не в общем случае, но все равно. И желательно в автоматическом режиме - т.е. упаковка структур, значений и т.д. просто делать на наитию я не хочу. Хочется опереться на какую-то документацию, что бы понимать реальное назначение полей в упакованных данных.
drem1lin, Интересно зачем уровень нэйтив протокольный межпроцессный обмен я спрашивал выше, вы пишите сплойт пробить серверный поток ? --- Сообщение объединено, 20 сен 2021 --- Я поискал, сурков нет. Есть только это https://doxygen.reactos.org/db/dd5/ndr__stubless_8c.html#ad142eed4e722ff588efc483d0db56dac ТС так полагаю пытается построить эту атаку https://vx-underground.org/archive/Exploits/CVE-2020-1066/MyComDefine/resolver_c.c - поэтому нужно хардкодить и лазить в нэйтив
Категорически рекомендую забить и действовать строго по инструкции из мсдн. Вам это понимание назначения полей не даст ровным счетом ничего (в рамках поставленной задачи), а времени убьете тонну.
Да не собираюсь я ничего атаковать! Хотя один фиг вы мне не поверите Мне действительно надо вызвать функцию на моем rpc сервере, через alpc. Я просто хочу разобраться с тем, как происходит упаковка параметров, что бы оно потом в случайный момент мне в ногу не стреляло. И я понимаю, что недокументированные пути ведут к проблемам, но голос свыше сказал "Сделай" вот я и делаю)
drem1lin, Во прикол то, что бы сплойт собрать бегут на форумы с вопросами дайте структуры.. самим реверсить взападло. Люди заканчиваются.
