0xC0000022 до RtlUserThreadStart

Я ввожу некоторый код для подключения API к процессам, но у меня есть некоторые проблемы в некоторых приложениях, таких как chrome.exe.

Мое тестовое приложение запускает приостановленный процесс, выполняет инъекцию и перехват API, а затем возобновляет его.

CreateProcessW перехватывается, чтобы иметь возможность перехватывать дочерние процессы. Если вызывается CreateProcessW, он принудительно создается приостановленным, перехватывает дочерний процесс и возобновляет его.

Внедряемый код зависит только от API ntdll, поэтому, хотя перехваченные процессы еще не полностью инициализированы, ntdll.dll присутствует всегда.

Код вводится с помощью вспомогательного потока с помощью CreateRemoteThread или NtCreateThreadEx с флагом CREATE_SUSPENDED. (Независимо от того, какой из них, проблема все еще там)

После этого введения проблема заключается в том, что в некоторых процессах, таких как некоторые дочерние элементы Chrome, CreateRemoteThread возвращает TRUE, но когда я возобновляю поток инжектора, он завершается с кодом 0xC0000022, и процесс также завершается.

Если я присоединю WinDbg к дочернему процессу chrome.exe, который приостановлен, прежде чем я что-либо сделаю, он тоже выйдет из строя, и chrome.exe завершится с таким же поведением.

Кажется, О.С. код, выполненный до RtlUserThreadStart, генерирует ошибку, но я не знаю, как ее отлаживать.

Как я могу отлаживать код, который запускается до RtlUserThreadStart? Есть ли отладчик или опция Windbg, которая позволяет мне это сделать?

ИЗМЕНИТЬ:

Следуя последнему сообщению из здесь, я смог получить следующую информацию:

0a88:0814 @ 02688302 - LdrpInitializeProcess - INFO: Beginning execution of chrome.exe (c:\Program Files (x86)\Google\Chrome\Application\chrome.exe)
    Current directory: C:\Windows
    Search path: C:\Windows\SYSTEM32 0a88:0814 @ 02688318 - LdrpInitializeProcess - ERROR: Initializing the current directory to "C:\Windows" failed with status 0xc0000022
0a88:0814 @ 02688334 - LdrLoadDll - ENTER: DLL name: C:\Windows\SYSTEM32\wow64.dll DLL path: NULL 0a88:0814 @ 02688349 - LdrpLoadDll - ENTER: DLL name: C:\Windows\SYSTEM32\wow64.dll DLL path: C:\Windows\SYSTEM32
0a88:0814 @ 02688365 - LdrpLoadDll - INFO: Loading DLL C:\Windows\SYSTEM32\wow64.dll from path C:\Windows\SYSTEM32 0a88:0814 @ 02688380 - LdrpFindOrMapDll - ENTER: DLL name: C:\Windows\SYSTEM32\wow64.dll DLL path: C:\Windows\SYSTEM32
0a88:0814 @ 02688396 - LdrpSearchPath - ENTER: DLL name: C:\Windows\SYSTEM32\wow64.dll DLL path: C:\Windows\SYSTEM32
0a88:0814 @ 02688412 - LdrpResolveFileName - ENTER: DLL name: C:\Windows\SYSTEM32\wow64.dll
0a88:0814 @ 02688427 - LdrpResolveFileName - RETURN: Status: 0xc0000022
0a88:0814 @ 02688443 - LdrpSearchPath - RETURN: Status: 0xc0000022
0a88:0814 @ 02688458 - LdrpFindOrMapDll - RETURN: Status: 0xc0000022
0a88:0814 @ 02688474 - LdrpLoadDll - RETURN: Status: 0xc0000022
0a88:0814 @ 02688490 - LdrLoadDll - RETURN: Status: 0xc0000022
0a88:0814 @ 02688505 - LdrpInitializeProcess - ERROR: Loading WOW64 image management DLL "C:\Windows\SYSTEM32\wow64.dll" failed with status 0xc0000022
0a88:0814 @ 02688521 - _LdrpInitialize - ERROR: Process initialization failed with status 0xc0000022
0a88:0814 @ 02688536 - LdrpInitializationFailure - ERROR: Process initialization failed with status 0xc0000022

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

Я могу предположить, что API-интерфейсы ntdll еще не подключены к хрому (в данном случае), потому что внедрение происходит до того, как CreateProcess вернется в хром.

Может ли неограниченный токен в моем потоке каким-то образом конфликтовать с токеном процесса?


person Mauro H. Leggieri    schedule 18.03.2014    source источник


Ответы (2)


Взгляните на Debugging WinLogon в справке Windbg (debugger.chm). Просто замените «chrome.exe» на «winlogon.exe». Этот метод управляет отладчиком пользовательского режима (ntsd) из отладчика режима ядра. Я считаю, что это позволит вам отладить инициализацию процесса chrome.exe намного раньше, чем использовать только отладчик пользовательского режима.

person Marc Sherman    schedule 18.03.2014
comment
хотя я пока не могу решить проблему с ntsd, мне удалось получить больше информации (сообщение отредактировано выше). Спасибо за открытие моего разума. - person Mauro H. Leggieri; 19.03.2014
comment
Похоже на файловую систему. Возможно, Process Monitor покажет больше информации. Кстати, из той ветки OSR, на которую вы ссылались, предложение какого автора вы использовали для получения этого вывода загрузчика? Джейк Ошинс или Алекси Р.? - person Marc Sherman; 19.03.2014
comment
Последний пост, выполняющий команду EB. Сначала я подозревал адрес (кажется, жестко запрограммированный), но он работал по крайней мере на Win7 x64. Я рекомендую изменить значение, когда вы находитесь на экране рабочего стола, потому что это слишком сильно замедляет работу ОС. - person Mauro H. Leggieri; 19.03.2014
comment
Интересно, предназначены ли эти адреса для символа ShowSnaps. Что x ntdll!ShowSnaps выводит на той же машине? Адрес совпадает? - person Marc Sherman; 19.03.2014
comment
Поскольку команда !address не работает в Win7, я скачал это: ссылка и с !kvas она получает 1000 (4 КБ) SharedSystemPage. Это область памяти ядра. - person Mauro H. Leggieri; 19.03.2014
comment
Спасибо @Marc за помощь, когда я застрял. - person Mauro H. Leggieri; 20.03.2014

Проблема в хроме заключалась в следующем:

Chrome запускает дочерние процессы с очень ограниченными привилегиями (из-за песочницы), но перед возобновлением основного потока он олицетворяет основной поток с токеном с большими привилегиями, чтобы позволить процессу инициализироваться.

Мой поток инжектора не олицетворял себя, поэтому токен ограниченного процесса вызывал код выхода 0xC0000022 при выполнении подпрограммы LdrpInitializeProcess.

person Mauro H. Leggieri    schedule 20.03.2014