CPU Disasm
Address Hex dump Command Comments
71A94C27 8BFF MOV EDI,EDI
71A94C29 55 PUSH EBP
71A94C2A 8BEC MOV EBP,ESP
71A94C2C 83EC 10 SUB ESP,10
71A94C2F 56 PUSH ESI
71A94C30 57 PUSH EDI
71A94C31 33FF XOR EDI,EDI
71A94C33 813D 5040AA71 292CA971 CMP DWORD PTR DS:[71AA4050],71A92C29
71A94C3D 0F84 256A0000 JE 71A9B668
71A94C43 8D45 F8 LEA EAX,[EBP-8]
71A94C46 50 PUSH EAX
71A94C47 E8 67F0FFFF CALL 71A93CB3 <--- here
CPU Disasm
Address Hex dump Command Comments
71A968FA 8BFF MOV EDI,EDI
71A968FC 55 PUSH EBP
71A968FD 8BEC MOV EBP,ESP
71A968FF 51 PUSH ECX
71A96900 51 PUSH ECX
71A96901 813D 5040AA71 292CA971 CMP DWORD PTR DS:[71AA4050],71A92C29
71A9690B 56 PUSH ESI
71A9690C 0F84 CD4D0000 JE 71A9B6DF
71A96912 8D45 F8 LEA EAX,[EBP-8]
71A96915 50 PUSH EAX
71A96916 E8 98D3FFFF CALL 71A93CB3 <--- here
CPU Disasm
Address Hex dump Command Comments
71A93CB3 8BFF MOV EDI,EDI
71A93CB5 55 PUSH EBP
71A93CB6 8BEC MOV EBP,ESP
71A93CB8 FF75 08 PUSH DWORD PTR SS:[EBP+8]
71A93CBB 8D45 08 LEA EAX,[EBP+8]
71A93CBE 50 PUSH EAX
71A93CBF FF15 5040AA71 CALL DWORD PTR DS:[71AA4050] <--- here
71A93CC5 5D POP EBP
71A93CC6 C2 0400 RETN 4
CMP DWORD PTR DS:[71AA4050],71A92C29
..
JE ...
Вы не понимаете сути, как и BarackИМХО: плюсов и применений в описаной технике много. из минусов видно только одно: нужен индивидуальный подход к каждой функе + искать совместимость под разными платформами, универсально хукать таким методом не получится.
Скачать|Downloadбудем ждать с нетерпением, очень интересно глянуть.Мне нужно время чтобы собрать сэмплы. На днях выложу.
в вашем сэмпле ничего непонятно что перехватывается , что логируется или подменяетсяКасательно send/WSASend - есть несколько старых семплов, сейчас я не буду описывать, думаю описать это в виде пакета далее, но вы можите посмотреть если хотите:
я уже сейчас вижу как все кодеры закинули сплайсы и начали такой мозгоеблей заниматьсяКод:CreateProcessInternalA: CreateProcessInternalW() Ret CreateProcessInternalW: ... ZwCreateProcessEx() ZwCreateThread() CsrClientCallServer(BasepCreateProcess) ZwResumeThread() Ret В CsrClientCallServer() проверяется, является ли текущий процесс серверным(Csrss), если это так, то вызывается колбек ntdll!CsrServerApiRoutine. Сигнализируем переменную CsrServerProcess и регистрируем колбек в CsrServerApiRoutine. Из этого колбека выполняем следующие действия: - Проверяем причину вызова. Нас интересует сервис BasepCreateProcess. - Если это так, то выполняем стековую маршрутизацию. Находим адрес возврата из CreateProcess(), выполнив бактрейс и заменяем в найденном фрейме ссылку на свой код. - Сигнализируем в локальном фрейме процедуры CreateProcessInternalW флаг CREATE_SUSPENDED. После этого процесс будет создан остановленным и при возврате из CreateProcess() управление получит наш код. Также можно перенести в буфер CreateProcessInternalW() и туда передать управление, тогда не будет проблем с поиском флагов, так как можно затереть ZwResumeThread().
но пока дойдет до нашего обработчика уже произойдут нежелательные вызовы (из примера CreateProcess) -> ZwCreateProcessEx() ZwCreateThread() , ну хотя это мелочь если там вернуть какое-то fail значение то хэндлы почистяться или допустим задача следующая, перехватить(CreateProcess) и дать создаться процессу (контроль после ZwResumeThread()), но вернуть какое-то fail значение - опять же нет той универсальности и технологичности , и полного контроля выполнения апишки на всех этапах - поставил сплайс и ты уверен как слон, что все сработает как надо.Это может быть место в коде, расположенное в стопяцот вызовов апи от целевого.
Вы знаете что ws2_32 это обёртка для mswcok, где WSA* сводятся к WSP*, это заглушки, которые выполняют коммуникацию посредством NtDeviceIoControlFile с \Afd.в вашем сэмпле ничего непонятно что перехватывается , что логируется или подменяется
А никто и не говорил, что будет просто. Эффективное решение оно сложное. Это в отличие от патчей не палится и не выпиливается какимнибудь гмером.все красиво , но требует нехилого знания недокументированных внутренностей и нестандартного кодеса
Я просто пример с Csr привёл чтобы показать принцип, это далеко не лучшее решение. Я бы менеджер хипа использовал для этой цели, так как до его вызова никакие обьекты не создаются. Про нежелательные вызовы - я имел ввиду стопяцот апи не внутри опред функи, а до её вызова. Тоесть есть у вас гдето в коде LoadLibrary() и далеко от неё CreateProcess(), первая станет обьектом, который будет изменён и даст управление при переходе ко второй функе. Это отложенный вызов опятьже.но пока дойдет до нашего обработчика уже произойдут нежелательные вызовы (из примера CreateProcess) -> ZwCreateProcessEx() ZwCreateThread()
Способ есть - например сегмент усекается до USD, тогда при вызове шлюза возникнет фолт Тут и /SysIcp.zip, но это совершенно не имеет отношения к данной теме. Стабы это заглушки к ядру, там нет мест, на которых можно получить управление. При такой необходимости оно получается ранее, чем вызывается необходимый сервис. Тоесть используется ZwMapViewOfSection, ранее есчо чтото юзается и на этом чтото мы получаем управление.Следующий вопрос как таким образом перехватывать Zw* функции, например из кодеса вызывается напрямую юзермодная ZwMapViewOfSection ?
Скачать|Download
Скачать|Downloadочень интересно было бы увидеть вашу логику в этом методе, отпишите когда у вас возможность появиться.Я просто пример с Csr привёл чтобы показать принцип, это далеко не лучшее решение. Я бы менеджер хипа использовал для этой цели, так как до его вызова никакие обьекты не создаются.