Пишу от имени PavPS, которому было лень искать эту тему.
***



Собственно – это обещеные результаты измучивания ntoskrnl.exe и NtFlushBuffersFile

Для тех кто против создания этой темы в виде новой: извиняюсь сразу, знаю, что мог продолжать в старой, но в списке и меня её уже нет, а лазить в другую ссылку влом. А коль уж обещал доложить о результатах (пусть даже некому и ненадо), то вот они (строго не судить)

1) Про базу ntoskrnl.exe.
Сказано было сразу, что грузится явно по разным адресам. По друзьям не ходил, но вот у меня уже отличается от указанной CARDINAL-ом константы :804D0000h. Но тут не особо интересно.
2) Про NtFlushBuffersFile. Да метод действенный, но из user-a И действительно, аналог есть в ядре. Из ntdll.dll он вызавается через KeServiceDescriptorTable с номером 4Dh. И действительно принимает 2 параметра. Конечно же можно его вызвать, но не просто так. Низя передовать handle файла, открытого без определенных флагов. У меня лично были загоны, что возвращалась ошибка ACCESS_DENIED если открыт без флага FILE_APPEND_DATA. Черт его знает почему. И наблюдался такой парадокс: Передаю handle только что измененного файла, типа сдампить. И ведь он дампит только как: читаю содержимое ч/з F3:TotalCommander – вижу, что файл изменен: изменены флаги, пересчитана checksum, а вот запускаю – то wind-овский лодер PE формата загружает старую версию файла в память – исполняет старый код. Типа как будто данные и не менялись. А если этот файл перенести на другой диск и обратно, то загружается уже в измененном виде. Все дело окозалось в флаге FILE_NO_INTERMEDIATE_BUFFERING.
3) А что касается использования просто флагов, то не фига не работает: изменяю данные, нажимаю Reset, загружаюсь – ничерта не сохранено, а вот если : (FILE_SYNCHRONOUS_IO_NONALERT OR FILE_NON_DIRECTORY_FILE OR FILE_WRITE_THROUGH OR FILE_NO_INTERMEDIATE_BUFFERING) + (FILE_WRITE_ATTRIBUTES OR FILE_APPEND_DATA) + NtFlushBuffersFile, то всё OK.

Всем бальшое спасиба!!!

Так что вот. IF чё не так, извиняйте.

мерси :-)))