ntcdm >>Почему же у меня меняется эта ДЛЛ-ка в других процессах. потому что сброс бита write protect в CR0 позволяет писать(из kernelmode) в страницы только для чтения без возникновения исключения и вызова MmAccessFault->MiCopyOnWrite, к тому же для секций c атрибутами READ EXECUTE механизм copy on write не работает без (usermode) VirtualProtect(с флагом PAGE_WRITECOPY) или (kernelmode) установки 9 бита(CopyOnWrite) в PTE >>Какие будут предложения чтобы исправить? 1.Этот код убираем __asm{ mov eax,CR0 mov CR0Reg,eax and eax,0FFFEFFFFh mov CR0,eax } __asm { mov eax,CR0Reg mov CR0,eax } 2. читаем данные по виртуальному адресу для того чтобы сделать PTE валидным 3. устанавливаем 9 бит(CopyOnWrite) в PTE 4. пишем по виртуальному адресу
Bazhan Спасибо за подсказку! Наконецто я смогу решить эту проблему. Может быть подскажете как мне усстановить 9 бит(CopyOnWrite) в PTE? Мне потом этот код надо будет портировать на х64 еще.
x86 PTE_BASE = 0xc0000000 x64 PTE_BASE = 0xFFFFF68000000000UI64 pPTE = MiGetPteAddress(va) ((PMMPTE)(((((ULONG)(va)) >> 12) << 2) + PTE_BASE)) pte = *pPTE pte = pte | 0x200 *pPTE = pte
Bazhan Мы рады что у вас есть сурцы венды и знаете как качать пдб, но это бред полнейший. Память разделяема если физическая страница отображена на разные PTE. Это shared-pte механизм. И абсолютно никакого значения не имеют атрибуты доступа к сегментам.
Пробовал вызвать ZwProtectVirtualMemory с изменением NewProtect=PAGE_WRITECOPY, а он дедлочится (там какой-то есть лок который, захватывая функции ZwProtectVirtualMemory и MmMapLockedPagesSpecifyCache лочатся).
попробовал следующий кодес: Код (Text): ULONG uOld = pdwAddressOfFunctions[funcIndex]; PMMPTE pPTE = MiGetPteAddress(&pdwAddressOfFunctions[funcIndex]); MMPTE pte = *pPTE; pte.u |= 0x200; *pPTE = pte; pdwAddressOfFunctions[funcIndex] = (PBYTE)g_pVirtualMemory+4 - (PBYTE)dosHeader; на последней строчке получаю Access Violation Код (Text): kd> .exr -1 ExceptionAddress: 88f67a47 ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 00000001 Parameter[1]: 77113428 Attempt to write to address 77113428 Кстати пробовал я и так как Клерк спрашивал - просто ручками в дебуггере поменял адрес. Код (Text): kd> r ecx ecx=89420004 kd> ed 76c13428 76c13428 00009790 89420004 89420004 76c1342c 00025f85 kd> dd 76c13428 76c13428 89420004 00025f85 00017551 00069239 76c13438 0002608f 0001c5b9 000765f5 000787c3 76c13448 000756ef 00078d04 00078931 00075717 76c13458 0000d3e6 00069380 00065cfb 0000c070 76c13468 00023305 0000b10d 0001a4f1 0005555f 76c13478 00026e17 000768c1 0006aa49 00078ea1 76c13488 00015286 00078ece 0002823c 00028aea 76c13498 00030c55 0001d354 000251da 00028ac0 Все равно экспорт меняется и в других процессах, например внутри lsm.exe: Код (Text): Breakpoint 2 hit 001b:00030004 2000 and byte ptr [eax],al kd> u eip 00030004 2000 and byte ptr [eax],al 00030006 0000 add byte ptr [eax],al 00030008 0100 add dword ptr [eax],eax 0003000a 0000 add byte ptr [eax],al 0003000c 2030 and byte ptr [eax],dh 0003000e 0000 add byte ptr [eax],al 00030010 dc00 fadd qword ptr [eax] 00030012 0000 add byte ptr [eax],al Какие еще будут предложения?
отладчик обычный WinDbg, подключенный через IEEE1394. Я вот тут подумал что мой нотификатор же вызывается из MiMapViewOfImageSection. Может быть к моменту вызова еще не все атрибуты защиты страниц выставлены как надо в процессе?
Обычно секция проецируется два раза, первый раз она не образ. Это происходит в LdrpCheckForLoadedDll(), потом данные в проекциях сравниваются. При этом если из ядра записать в проекцию, то это повлияет на проекцию в другом процессе, но только на туже. Вот только ядро выполняет нотификацию только для образов(SEC_IMAGE), иначе нотификатор не вызывается, поэтому это не то. Нотифи вызывается в конце работы MiMapViewOfImageSection(). Страницы сразу мапятся с возможностью записи в них. Попробуйте из юзермода сделать тоже из другого отладчика.
ntcdm теоретическая часть: Intel Manual Volume 3A part 1 PROTECTION->PAGE-LEVEL PROTECTION и в атаче практическая
Только добрался до тестов предложенного кода. Работает, никаких падений, все четко патчится! Спасибо огромное, Bazhan