У меня появилась идея как можно получить доступ объектам к которым запрещён доступ каким-либо методом. Допустим есть файл, к которму запрещён доступ на запись. Мы открываем файл с минимальным доступом. потом находим структуру, в которой этот объект описан в ядре. Потом устанавливаем нужные нам флаги в этой структуре, в нашем случае устанавливаем флаг доступа на запись. И записать в файл то что нам требуется. Разумеется всё это делать в Ring0 (в драйвере режима ядра). В связи с этим вопрос: является ли поле Код (Text): //ZwQuerySystemInformation typedef struct _SYSTEM_HANDLE_INFORMATION { // Information Class 16 ULONG ProcessId; UCHAR ObjectTypeNumber; UCHAR Flags; USHORT Handle; PVOID Object; //<-- -------------ВОТ ЭТО ПОЛЕ-------------------- ACCESS_MASK GrantedAccess; } SYSTEM_HANDLE_INFORMATION, *PSYSTEM_HANDLE_INFORMATION; указателем на структуру в ядре описывающую данный объект? Главное: где есть описание этих структур (хотя бы для файлов и процессов) ? и вообще будет ли работать такой метод получения максимального доступа к запрещённому объекту? Заранее благодарен.
тема боян=/ по теме - да, является. понимаешь в чем дело.. если ты уже в ринг0, никакие проверки тебе не страшны. во многих функциях в винде даже стоит чтото типа if( KeGetPreviousMode() != KernelMode ) { SeSinglePrivilegeCheck(...); } и все такое. то есть если захочешь в вринг0 можно уже сделать че хочешь. главное чтобы было возможно в принципе. так что такие темы это имхо бред. Зачем? Делаем сразу референс обжект , получаем FILE_OBJECT и далее слегка подправить там поля 339 BOOLEAN ReadAccess; 340 BOOLEAN WriteAccess;
получается что : указатель полученный таким образом это тоже самое что и Код (Text): typedef struct _SYSTEM_HANDLE_INFORMATION { // Information Class 16 .... PVOID Object; //<-- -------------ВОТ ЭТО ПОЛЕ-------------------- ..... } SYSTEM_HANDLE_INFORMATION, *PSYSTEM_HANDLE_INFORMATION; я правильно понял?
Да. Это указатель на объект ядра, именно этими объектами манипулируют все части ядра. Основные типы объектов это: KEVENT а так же прочие синхронизационные и др. объекты Ke-части ядра: KDPC, KTIMER, KGUARDED_MUTEX, KMUTEX, KFAST_MUTEX. FILE_OBJECT DEVICE_OBJECT DRIVER_OBJECT EPROCESS PCALLBACK_OBJECT И другие. Основная идея заключается в том, что этими объектами манипулируют большинство функций ядра. А те функции, которые должны общаться с пользователем, очевидно, не должны манипулировать указателями ядра из соображений безопасности. Поэтому для процесса строится таблица хендлов, в этой таблице при создании хендла вписывается указатель на объект ядра, с какими правами доступа он открыт и его флаги. Хендл - почти что индекс в этой таблице, точнее, просто индекс, сдвинутый на два бита влево, а младшие два (кажется) бита содержат тоже дополнительные флаги. В общих чертах: когда юзеру нужно как-то оперировать с некоторым объектом, например, открыть файл, он вызывает NtCreateFile (в общем случае, так же может быть вин32 обертка CreateFileA/W и так далее), передавая ей имя файла для открытия. Она создает FILE_OBJECT нового файла, посылает файловой системе в стек IRP запрос ввода-вывода типа IRP_MJ_CREATE на открытие файла, передавая так же аттрибуты доступа. Файловая система ищет файл, решает, разрешить ли открытие файла и т.д. производит еще некоторые проверки, В результате чего сообщает ответ NtCreateFile'у. Он решает соответственно - удалить ли FILE_OBJECT и вернуть статус ошибки, если что не так, или продолжать удерживать FILE_OBJECT, создать юзеру хендл через ObOpenObjectByPointer, например, и передать его пользователю, сигнализируя об успехе. Так вот к чему я это все... Да, указатель там один ))
понятно. т.е. права доступа хендла хранятся не в самом объекте, а в таблице хендлов. Следовательно достаточно редактировать только таблицу хендлов чтобы поставить для хендла максимальный доступ.
