Подскажите, существует ли нормальный способ уведомить csrss о потоке из этого потока. т.е. мы имеет в UserMode Native поток и из него системе надо сообщить о его существовании. Желательно чтобы метод работал вплоть до win 7.
Как я понял там используется спец запрос. И там передается номер функции полученный через CSR_MAKE_API_NUMBER но вот что-то самих номеров не нашел. Они же вроде как на разных версиях винды разные номера имеют (или я ошибаюсь?).
slesh Универсальный поиск переменных, констант и пр., тоесть выделение из кода необходимой части решается нормально только посредством графов. GPE вам поможет сделать это, либо будет являться хорошим примером. Кстате исправте ошибки в дизасме длин, на вашем блоге на ачате я отписал. LDE не может использоваться при не выравненном стеке.
Clerk Спасибо что подсказал насчет дизасма длин. Хотя если его будут использовать в Си программах, то очень маловероятно что стек будет не выравнен. Кстати, прогнал через IDA kernelbase от Win 7. А также kernel32 от Win XP и Win 2k3 везде при создании потока CsrClientCallServer вызывается с одним и тем же кодом команды 0x10001 так что теоретически можно считать что это прокатит везде. Если учесть что #define CSR_MAKE_API_NUMBER( DllIndex, ApiIndex ) \ (CSR_API_NUMBER)(((DllIndex) << 16) | (ApiIndex)) То выходит что DllIndex = BASESRV_SERVERDLL_INDEX = 1 и ApiIndex = BasepCreateThread = 1 Так что вполне вероятно что будет работать нормаль. Только сейчас нашел список: http://j00ru.vexillium.org/csrss_list/api_list.html И там видно что BasepCreateThread всегда имеет индекс 1
slesh То что первые два сервиса постоянны можно догадаться логически. Но это не универсальный способ, для других сервисов, например консольных номера их будут различными. Для определения парсится код содержащий в себе вызов необходимого сервиса, причём NL задаётся на основе допустимого максимального уровня вложенности, так как это очень сильно сказывается на производительности(если например для 3 будет несколько сот инструкций, то для 5 их может быть уже десятки тысяч и соответственно время анализа и память очень сильно увеличивается. Подобная проблема возникала при разборе многих нтюзер функций, где изза сех-пролога(_SEH_Prolog()) в анализ вовлекалась большая часть модуля и пришлось это присечь проверкой адреса). Инструкция загружающая номер сервиса в стек сцеплена в графе: [push ArgN(R/M)] - [Line] - [push ArgN +1] - [Line] - [push Id] - ... - [Call CsrClientCallServer]. Причём в универсальном способе необходимо определять не загрузку аргумента, а баланс стека, тоесть загрузка аргумента определяется по изменению стека. Баланс стека нарушается LDE. Тоесть гдето ранее(при его инициализации) формируется стековый фрейм и удаляется он при возврате из движка. На всё время работы стек смещён на два байта и любое исключение в нём завершится крахом, например если возникнет #PF/#DB при чтении инструкции. Например в следующей модели: [Push ax] [SEH_PROLOG] [#XCPT] [SEH_EPILOG] [Pop ax] Возникнет багчек, сех цепочка не будет раскручена. Это ошибка в реализации менеджера.
Clerk спс на счет LDE, нашел уже место где стек смешается, уже исправил. Тут в принципе надо было только именно для потоков найти номера команд, так что поиск особо не нужен будет.
в 7й винде ввели - RtlRegisterThreadWithCsrss со списком аргументов я не разбирался - там толи 3 толи 4 дворда) в гугле нашел только свой пост на мсдне) ап - 3, есть кроссрефы в адвапи32 (на нем и тормознул), начинаются как локи, но под хотпатчи mov edi,edi push reg32 push reg32 push reg32 call RtlRegister...
