привет, блин, короче такая фигня: твердо помню, что есть какая-то засада с мэппингом win32k на память вроде как процессов без гуи потоков.., точно с таким сталкивался пару лет назад, гугл молчит, сокровенные знания забыты =), а нужно из DriverEntry прочитать память Win32k.sys, кто-нить помнит в чем там дело и как побороть?
Ну так а все уже же написали, только после конвертации в гуи процесс, в ап процесса мапится соответствующий session space, тут и тут вроде нормально описано.
Ересь какаято, никуда оно не мапится. Никаких проблем для чтения session space нет, любой процесс находится в той или иной сессии, кроме system и smss, у них нет session space, в таких случаях достучаться до нее можно через MiAttachSession, как уже написал клерк.
Извиняюсь за дизинформацию =), почему-то всегда казалось, что маппинг win32k.sys связан именно с гуишностью процесса.
Связан разве что косвенно, т.к. при конвертации потока в gui-шный вызываются коллауты, добавляющие поток/процесс в списки win32k.sys, вот тут можно почитать кое-какую инфу об этом: http://kitrap08.blogspot.com/2011/03/blog-post.html
Ага, сенкс, я уже и прочитал, я кстати и подозревал что, что-то не то, перед тем как написать просмотрел ядро в иде, врк, а там не в _KiBBTUnexpectedRange, не в PsConvertToGuiThread нету никакого мапинга, а они ж напрямую из _KiFastCallEntry дергаются, когда индекс большой, вот только то, что из PsConvertToGuiThread уже win32k дергается, меня почему-то не смутило и я подумал, что просто где-то что-то упустил =)
TSS [offtop]Ну по сабжу уже всё сказано. Немного заофтопим. Тут обнаружилась интересная тема в инетах "К вопросу о поиске неэкспортируемых символов". В частности "приводит к проблеме отделения кода от данных ( не решаемой в общем случае статическим анализом ).". Так вот поправлю - задача решается в любом случае. Трудно найти используемую Case-ветвлением(это условное ветвление, где условие определяет регистр(ага, не только регистр флагов может определять выбираемую ветвь) и в зависимости от него выбирается из массива определённая ветвь(тоесть участок графа на который имеются ссылки в ветвлениях)) часть массива, а не сам массив. Только в этом случае задача в общем не решаема(без виртуализации, тоесть исполнения или полноценного анализа, который есчо не реализован приемлимым образом). Для примера можите рассмотреть NtUserCall*, использующие один массив, но разные его часть - поиск массива прост, тоесть отделение данных от кода, но для определения частей используемых каждой функцией нужен синтаксический анализ кода. Для не Case-ветвлений, а простых данных отделение их от кода весьма просто.[/offtop]
f34534 Возможно, но я говорил про общий случай. К примеру, высокоуровневый seh может быть представлен ввиде куска scopetable внутри ф-ции, тогда в графе этот кусок будет отсутствовать, причем даже трейсером его можно пропустить, если исключения не было. Тут нужно полное покрытие чтобы такие случаи ловить, то бишь динамический анализ с откатом состояний.
