Добрый день. Не поделитесь значениями четвертого параметра CsrClientCallServer при создании процесса под Windows 2003/Vista, может кто пробовал и знает? Для 2000 SP4, Windows XP это значения 0x28 и 0х2C соответственно. CsrClientCallServer(&csrmsg, NULL, 0x10000, Flag); Спасибо.
0xC0000142 на Windows 2003 при подобном переборе. Вроде бы там должно быть значение 0x90, но что-то не получается все равно
да 0x90 для SP1. Для SP0 может быть другим. Есть такая вероятность что формат сообщений может быть различен в разных версиях.
Если кому интересно, вот 0x20 для Windows XP SP3, только что проверил. n0name Я как раз смотрел kernel32.dll от оригинального 2003, там 0х90. И я так понимаю, посмотреть этот формат никак нельзя Хотя в принципе же ядро 2003, основано на XP, вот может быть в Viste крупные изменения... Между прочим, если попробовать перебор, то эта функция иногда будет возвращать STATUS_SUCCESS и при этом ничего происходить не будет.
последний параметр это размер сообщения NTSTATUS CsrClientCallServer ( IN OUT PCSR_API_MSG m, IN OUT PCSR_CAPTURE_HEADER CaptureBuffer OPTIONAL, IN CSR_API_NUMBER ApiNumber, IN ULONG ArgLength ) Definition at line 25 of file csrutil.c. References CsrPortHandle, CsrPortMemoryRemoteDelta, CsrServerApiRoutine, CsrServerProcess, DbgPrint, FALSE, IF_DEBUG, NT_SUCCESS, NtRequestWaitReplyPort(), NTSTATUS(), NULL, and Status.
Это размер данных, для каждого сервиса свой. Например для GetConsoleScreenBufferInfo это размер структуры { ConsoleHandle HANDLE ? ConsoleScreenBuffer HANDLE ? }
PCSR_API_MSG содержит структуру сервиса, уникальную для него и эта структура включает размер ArgLength
Clerk Это и так ясно. Неясно почему не работает выше XP. Может кто пробовал создавать процесс под Windows 2003, Vista через native api? У кого-нибудь получилось?
Clerk При чем тут ntdll? Вызов этой функции с подготовкой параметров проходит в kernel32.dll, ну если хочешь - валяй. n0name Оно то понятно, неужто механизм взаимодействия с клиентсерверным приложением притерпел такие изменения... А структур то этих не найти.
Ок, оказывается это совершенно неисследованная часть API. А ведь на самом деле здесь очень много интересного, эта функция поддерживает отсылку различных сообщений csrss, которые могут делать довольно интересные вещи, мониторить, запрещать создание процессов, инжектить длл и т.п. Похоже что CSR_API_MSG это основанный на обычном LPC протокол, который очень разнится для различных действий. И эти структуры совершенно недокументированны и меняются от билда к билду, причем даже отпаченный XP SP2 отличается от оригинального SP2 (вот где действительно opaque принцип). Кроме того при правильно составленном запросе можно вытащить внутренние данные csrss касающиеся процессов и потоков, чем не метод поиска скрытых процессов, тем более, что ни один руткит не чистит данные csrss. Общение ведется через Port объект, называемый Windows\ApiPort, в следующей последовательности kernel32.dll -> CreateProcessInternalW -> ntdll.dll -> CsrClientCallServer->NtReplyWaitReceivePort. Пока не понятно, что там дальше делается к сожалению нет такой утилитки как CSRMon, а она была бы здесь кстати. Небольшие эксперименты показали, что процесс и поток может спокойно существовать без дескрипторов в csrss (на vista правда возникли небольшие проблемы, но там все работает через одно место). Соотвественно возникает вопрос, а так ли нужно это уведомление и нельзя ли сделать, то что делает клиент-сервер самостоятельно?
Общение ведётся через \Windows\ApiPort, а вот данные туда-сюда передаются через разделяемую область памяти CsrSrvSharedSection. На базе которой создаётся специальная куча функциями из ntdll. Кстати, узнать её расположение можно многими разными способами: a) Конкретные значения: base=0x7F6F0000, size=0x100000 - других вариантов я ещё не видел, хотя особо на разных системах не присматривался b) Из реестра: базовый ключ HKLM\System\CurrentControlSet\Control\Session Manager\SubSystems базовый адрес в процессе инициализации записывается в CSRSS\CsrSrvSharedSectionBase, размер в процессе инициализации берётся из значения Windows (первый параметр из SharedSection, в Kb) c) Nt[Secure]ConnectPort на \Windows\ApiPort, на выходе дополнительные данные: dword+C = dword+14 = базовый адрес, размер определяется по VirtualQuery d) Из результатов вызова NtSecureConnectPort из kernel32 на стадии загрузки приложения: PEB.ReadOnlySharedMemoryBase(+4C) = PEB.ReadOnlySharedMemoryHeap(+50) = базовый адрес По поводу того, что происходит внутри процесса csrss: приёмник к NtReplyWaitReceivePort - csrsrv.dll!CsrApiRequestThread коннект обрабатывает csrsrv.dll!CsrApiHandleConnectionRequest в сообщениях указывается номер сообщения, состоящий из двух word'ов: младшее - номер функции, старшее - номер dll. Обрабатывающие всё это DLL берутся из значения уже упомянутого параметра HKLM\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 (dll под номером 0 - это сама csrsrv.dll) Кстати, интересный вопрос, что произойдёт, если грохнуть этот параметр или убрать оттуда какие-нибудь параметры. Лично я склонен считать, что после перезагрузки полетит вся Win32-подсистема, так что эксперимент не проводил и никому не советую Что дальше копать, понятно?
Да, и ещё: на обмене сообщениями держится как минимум вся работа с консолью и, полагаю, ещё много чего. Так что просто убирать вряд ли стоит.
