Как узнать по какому адресу промаплена секция в удаленном процессе?Ест

Есть к примеру секция BaseNamedObjects\ShimSharedMemory в ХП.
Как узнать по какому адресу она промаплена в другие процессы? Есть хэндл на чтение процессов и так далее.

Функции NtQuerySection работают для текущего процесса(внедрять свой код что бы узнать по какому адресу секция - нецелесообразно). Полистал мсдн, ничего нужного не нашел.
Кто такое уже делал, интересно как сделали - поделитесь.

 

DuplicateHandle->QuerySection ?

 

Возможно как то сделать по другому, если у нас нет PROCESS_DUP_HANDLE к примеру?

 

ziral2088
Записать маркер и найти его.

 

Clerk
А если маркер измениться?(То есть процесс активно работает с секцией).
Мне такая идея тоже в голову приходила, на крайний вариант сойдет и она.

 

хе-хе... вспоминаю одну тему с вирустека))) чтобы искать маркер нужно иметь права на VM_READ, здается мне, что комодо таких прав не даст)))

 

Rel
Вы хотите невозможного. Дайте нам ядро.)

 

да я согласен))) но если есть права на VM_READ, то в шаренную секцию вставлять маркер не обязательно... проще перечислить страницы, и зачитывать энное количество байт с начала страницы и сравнивать с тем же количеством байт в начале шаренной секции в своем процессе... так просто есть какая-то синхронизация между итерациями чтения, и не нужно беспокоиться, что маркер затрется другим процессом... канеш тут есть определенные проблемы с тем, что какой-то процесс может изменить байты во время итерации, но можно что-нить покрутить с приоритетами потока, чтобы эта тема была достаточно устойчива... и, я думаю, можно не все страницы читать, а только MEM_IMAGE...

ziral2088
а ты не смотрел, может у этой секции нет прав на выполнение?... а то может ты зря мучаешься)))

 

Rel
Я это для ХП делаю, там же нет разницы, как Клерк заметил между PAGE_EXECUTE_READWRITE и PAGE_READWRITE.
Для Висты+ думаю использовать ALPC, но Комодо при использовании ALPC выдает желтый алерт. Такое впечатление что скоро если у прогаммы не будет цифровой подписи то на системе с Комодо она даже не запуститься...

Попробую тогда сделать через перечисление страниц.

 

а, я не обратил внимание на xp... но вообще, я думал, что на включенный DEP можно нарваться на XP SP3 и выше... может спутал что-то...

скоро все программы будут подписываться поголовно... вопрос лишь в том, сколько сил надо будет потратить, чтобы эту подпись подделать...

 

Rel

Память гранулярна, буфера же имеют чёткие границы. Тоесть свободное пространство за пределами буфера свободно.

 

да, но "буфер" может занимать/работать со всей памятью в пределах гранулярности... а как узнать размер "буфера"? в MEMORY_BASIC_INFORMATION есть RegionSize, но вроде там как раз размер с учетом гранулярности...

 

Rel
Не может быть размер буфера равен N*PAGE_SIZE, всегда меньше.

Эта инфа не системная, она только коду известна использующему буфер.

 

эмм... когда я, допустим, создаю секцию NtCreateSection или CreateFileMapping и указываю функциям размер секции равный ровно одну страницу, то что в реальности произойдет? будет "выделено" 2 страницы?

но как тогда определить безопасное для данных место в конце страницы? или это невозможно?

 

а зачем?

Код (Text):

1. SYSTEM_BASIC_INFORMATION sbi;
2. DWORD retlen=0;
3. NtQuerySystemInformation(SystemBasicInformation,&sbi,sizeof(sbi),&retlen);
4. sbi.uAllocationGranularity - гранулярность;

 

RET
То есть: sbi.uAllocationGranularity - RegionSize = свободное место в конце буфера?

 

Rel
Вот вы например знаете размер системного хипа - нет, вы юзаете только требуемый размер, хотя физически он выделяется по страницам.

 

RET
ziral2088
Clerk
да...

но я не об этом... мы разговариваем с вами о шаренной секции... если мы маппируем ее к себе в процесс, то мы имеем доступ к шаренной памяти размером равным размеру шаренной секции... размер шаренной секции кратен размеру страницы (RegionSize), хоть и при создании секции процесс и не планировал использовать весь этот размер... память же выделена с учетом грануляерности (у меня 16 x PAGE_SIZE) вопрос: разве мы сможем записывать что-либо в шаренную память в интервале [SectionBase + RegionSize, SectionBase + uAllocationGranularity]? и будет ли это вообще шаренная память? я вообще думал сначала, что вы имеете ввиду под "записью за буффер" - запись в неиспользуемую процессом память между концом буффера и ближайшем концом страницы...

 

Rel
Я поэкспериментировал - сделал маппирование файла размером 10байт
PBYTE pbFile = (PBYTE) MapViewOfFile(hFileMapping, FILE_MAP_READ|FILE_MAP_WRITE, 0,0, Size);

Size = 10.

Так вот - по полученному адресу доступна только одна страница памяти (никак не 64К).

Понятие гранулярности относится (как я понимаю) к адресу в файле(относ-му смещению) с которого начнется проецирование.

 

Базовая единица памяти это страница. Какиебы манипуляции с ней не выполнялись(аллокация, изменение атрибутов и пр.) они сразу для всей страницы применяются, ну так как регион это N страниц, то ко всему региону.
Используемый буфер - запрошенная область памяти указанного размера. Остальная память за пределами буфера свободна и туда можно записать свои данные Rel, всё верно.
gorodon
Если секция проецируется не со смещения выравненного на границу страницы, то проецируется страница в которой находится это смещение, тоесть было Offset в файле или секции, в проекции смещение будет Offset & (PAGE_SIZE - 1).