Чем заменить API Monitor?

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

 

GwasmG, начиная с вин10 (или мб и раньше) нереально открыть с юзермода системные процессы. Кроме как того, что находится в той же сессии и только с правами PROCESS_QUERY_LIMITED_INFORMATION. Для таких подходит вроде как smss.exe, но не подходит csrss.

 

А ProcessExplorer открывает csrss? Не спец по ядру, но мб заюзать его драйвер для открытия процесса? ProcessExplorer именно так и делает, сначала пытается открыть через OpenProcess, если облом то посылает запрос драйверу:

Код (ASM):

1. .text:0048C4CC                 push    eax             ; dwProcessId
2. .text:0048C4CD                 push    0               ; bInheritHandle
3. .text:0048C4CF                 push    410h            ; dwDesiredAccess
4. .text:0048C4D4                 mov     [ebp-2584h], eax
5. .text:0048C4DA                 call    ds:OpenProcess
6. .text:0048C4E0                 mov     [ebp-251Ch], eax
7. .text:0048C4E6                 mov     [ebp-261Ch], eax
8. .text:0048C4EC                 test    eax, eax
9. .text:0048C4EE                 jnz     loc_48C5A5
10. .text:0048C4F4                 call    ds:GetLastError
11. .text:0048C4FA                 cmp     eax, 5
12. .text:0048C4FD                 jnz     short loc_48C52B
13. .text:0048C4FF                 push    0               ; lpOverlapped
14. .text:0048C501                 lea     eax, [ebp-2654h]
15. .text:0048C507                 push    eax             ; lpBytesReturned
16. .text:0048C508                 push    4               ; nOutBufferSize
17. .text:0048C50A                 lea     eax, [ebp-261Ch]
18. .text:0048C510                 push    eax             ; lpOutBuffer
19. .text:0048C511                 push    4               ; nInBufferSize
20. .text:0048C513                 lea     eax, [ebp-2584h]
21. .text:0048C519                 push    eax             ; lpInBuffer
22. .text:0048C51A                 push    8335003Ch       ; dwIoControlCode
23. .text:0048C51F                 push    hDevice         ; hDevice
24. .text:0048C525                 call    ds:DeviceIoControl
25. .text:0048C52B
26. .text:0048C52B loc_48C52B:

В драйвере процесс по запросу 8335003Ch открывается с GENERIC_ALL правами:

Код (C):

1.     case (int)0x8335003C:
2.       if ( a4 != 8 || Sizea != 8 )
3.         goto LABEL_7;
4.       v10 = (void *)*a3;
5.       _mm_storeu_si128((__m128i *)&v24, (__m128i)0i64);
6.       v19.UniqueProcess = v10;
7.       v19.UniqueThread = 0i64;
8.       v20 = 48;
9.       v21 = 0i64;
10.       v23 = 0;
11.       v22 = 0i64;
12.       v11 = ZwOpenProcess(Dsta, GENERIC_ALL, &v20, &v19);

 

Ну на них и защита висит. Это понятно.

--- Сообщение объединено, 9 янв 2022 ---

Разные проги (у которых есть драйвер) открывают процесс, но с инжектом - другой вопрос.

 

В API мониторе DLL инжектится через VirtualAllocEx, WriteProcessMemory, CreateRemoteThread / NtCreateThreadEx + в целевом процессе вызывается LoadLibrary с нужной DLL. Вот если через драйвер откроешь csrss то должно все сработать, хотя сама LoadLibrary в контексте csrss может зафейлится, ХЗ как там на новых системах. У меня просто нет под рукой подобной так бы я сам глянул.

 

GwasmG,

> Чем? Если для таких целей есть удобный инструмент

Без обид, я таких называю кнопкодавами. Это люди никакого отношения к коденгу не имеют, а ищут инструменты чем решить задачу. Студия товарищ тебя спасёт. Вот ты и признался.

 

Если что я имел в виду перехватить OpenProcess в мониторе и подсунуть ему свою реализацию (смещение 0x54946 от начала секции .text в 64 битном билде)

 

Я посмотрел. Win11, на которой наблюдается проблема: различные методы инжекта в csrss завершаются с ошибками "Отказано в доступе".

Сами процессы PPL/WinTcb, плюс несколько Mitigation policies, которые тоже влияют на инжект.

--- Сообщение объединено, 9 янв 2022 ---

Всё нормально. Так и есть, и я считаю это нормальным. Не свою же операционную систему всем писать, и паять процессоры с божьей помощью, дома, на табуретке.

 

Я имел в виду что будет ли процесс csrss загружать неподписанные МС DLL'ки. Если у тебя есть хендл с нужными правами ты и так сможешь код заинжектить, только больше головной боли будет, просто нужно глянуть открывает ли драйвер ProcessExplorer'а процесс CSRSS по запросу 8335003C. Можно искусственно в самом ProcessEcplorer'е зафейлить первый вызов OpenProcess чтобы DeviceIoControl сработал и глянуть возвращаемое значение. В случае успеха можно уже встроить код в API Monitor и глянуть как он отработает уже.

 

Разве что какой-нибудь байпасс, который и так можно сделать самостоятельно (точнее, взять из интернетов этих наших), без правок в апи мониторе.
Естественно, эт нарушает безопасность системы, но чёрт с ней...

 

Я не понимаю тебя. Я имею в виду, у тебя API Monitor пытается сделать OpenProcess(), фейлится с ACCESS_DENIED и репортит об ошибке, т.к. не может выделить память в системном процессе и заинжектить туда шеллкод. OpenProcess в любом случае будет фейлится, с этим ты ничего не поделаешь, т.к. процесс защищенный, об этом и в документации написано. Что я предлагаю, посмотреть откроет ли ProcessExplorer этот процесс, но не через OpenProcess а через свой драйвер (PROCEXP152 у меня). Если он его откроет, то этот хендл подойдет для API Monitor'а, т.к. в драйвере он открывается с правами GENERIC_ALL. Если все так и есть, можно подгрузить в API Monitor маленькую DLL которая загрузит драйвер ProcessExplorer'а и перехватит вызов OpenProcess (смещение я написал), выполнит DeviceIoControl и возвратит хендл монитору. Далее уже будет видно, мб все заработает если в самом CSRSS не будет никаких проблем.

 

Thetrik, я понял. Просто есть способы вообще снять защиту с csrss, тоже через драйверы.

--- Сообщение объединено, 9 янв 2022 ---

Thetrik, и я понять не могу, в какой версии у Process Explorer'а драйвер? У себя не наблюдаю.

 

Такой драйвер нужно писать / подписывать, я предлагаю способ с уже готовым, подписанным драйвером.

--- Сообщение объединено, 9 янв 2022 ---

У меня 16.22.0.0 в ресурсах лежит драйвер.

 

Да, в этой версии есть.. (И в новой нашёл уже)

--- Сообщение объединено, 9 янв 2022 ---

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

--- Сообщение объединено, 9 янв 2022 ---

Хотя, он и без форсирования так работает. Потому что для csrss GetLastError() -> 0x5.

 

Ну пробуй теперь в API Monitor вставлять этот вызов - все должно заработать, хотя не факт.

 

Но в чём основная мысль? Хендл с полным доступом и так возвращается в приложения, использующие драйвер.
Такие приложения не могут загружать длл в csrss, а цель ведь заключается в этом?

 

В том что для работы нужно чтобы DLL была в CSRSS, как минимум там идет перехват CsrCreateProcess для того чтобы иметь возможность мониторить момент создания процессов.

При чем тут другие приложения? Речь идет об API Monitor'е. Вот ему нужно чтобы его DLL'ка была внутри CSRSS тогда инициализация не будет фейлится.

Почему не могут? В CSRSS создается удаленный поток который и загружает DLL уже в контекста CSRSS, получается сама CSRSS загружает либу.[/QUOTE]

 

Просто в качестве проверки теории.

Это верно. Но если защита процесса препятствует этому? Так сказать, различные инжекторы не смогли загрузить длл, хотя получали хендл с полным доступом.

 

Ну тут много причин. DLL была подписана? У API Monitor'а подписанные либы, но не факт что они тоже будут грузится - нужно смотреть что происходит.

 

Разные пробовал, в том числе и саму длл от Апи Монитора.