Статья ASM для х86. (4.0) Системные механизмы Windows

Marylin · 26.06.2019

4.1. Адресное пространство процесса

4.1.0. Виртуальная память

Для каждого процесса система Win32 выделяет отдельную память размером ~2Gb, из имеющихся в наличии 4Gb. Пространство это виртуальное и к физической памяти DDR имеет лишь посредственное отношение, поэтому в ОЗУ одновременно могут находиться сразу несколько 2-гигабайтных процессов. По большому счёту, в Р-моде понятие ‘физическая память’ отсутствует как-таковое - им оперирует только ядро ОСи. На машине может быть одна планка DDR размером 512Мб, но для винды всё-равно будет 4Gb виртуальной. От куда берётся столько памяти? Давайте разбираться..

В основе виртуальной памяти лежит идея, что у каждой программы имеется собственное адресное пространство, которое разбивается страницы. Эти страницы отображаются на физ.память, но для запуска программы одновременное присутствие в памяти всех страниц необязательно – большая часть из них ожидают своей очереди на диске. Когда программа ссылается на часть своего пространства, которого на данный момент нет в физ.памяти, ОС генерит исключение Page-Fault и отсутствующая страница подгружается в память с диска, после чего потерпевшая неудачу команда повторяется. Отработавшие страницы выгружаются обратно на диск, в т.н. файл-подкачки ‘pagefile.sys’.

Все линейки NT работают в 'гибридном режиме', когда на сегментную модель накладывается страничная. Размеры страниц могут быть двух типов – 4Кб (стандартная) или 4Мб, если включён режим РАЕ – Physical Address Extension. В большинстве случаях страницы 4К-байтные. Такой размер позволяет менеджеру памяти более гибко управлять общим пространством. Размеры сегментов больше, чем размеры страниц и ОС имеет отдельные аллокаторы памяти для каждого из слоёв: Virtual, Local и Heap Alloc. VirtualAlloc() требует выравнивания выделяемых блоков памяти на 64К-байтную границу, т.е. ориентируется на сегменты. LocalAlloc() выделяет память страницами, а HeapAlloc() уже произвольное кол-во байт.

4.1.1. Аппаратная поддержка виртуальной памяти

Страничная трансляция включается битом(31) управляющего регистра CR0. На вход транслятора страниц приходит линейный адрес, который MMU разбивает на 3 части: старшие 10-бит выделяются под каталог страниц (10-бит = 1024 записи PDE), средние 10-бит под таблицу страниц (одна из 1024 страниц PTE), и младшие 12-бит выбирают смещение в странице физической памяти. Страницу физ.памяти назвали Physical Frame, или страничный кадр в памяти DDR-SDRAM. Размеры страничных кадров всегда равны страницам виртуальной памяти, т.е. 4Кб.

Так адресуется глобальное пространство памяти процесса: 1024*1024*4096=4Gb. У каждого процесса свой каталог-страниц, линейный адрес которого лежит в его регистре CR3 (PDBR) - Page Directory Base Register. Схематически это выглядит так:

При такой схеме памяти, все запускаемые процессы получают одинаковые виртуальные адреса, например базу загрузки образа в память 0х00400000. Если-бы это была не виртуальная память а физическая, то процесс(А) мог-бы запросто затереть данные процесса(В), ведь адрес у них совпадает.

Чтобы исключить такую ситуацию, система ведёт список адресов физических DRAM-страниц, выделенных для каждого процесса. Этот список назвали MDL - Memory Descriptor List, или ‘таблица распределения физической памяти’. Важно понять, что виртуальный адрес 0х00400000 процесса(А) отображается на одну физическую страницу DDR, а тот-же адрес процесса(В) отображается уже на другую физическую страницу памяти. Таким образом, процесс(А) никогда не затерёт данные процесса(В), хоть у них и одинаковый виртуальный адрес. Общая схема трансляции адреса от процессора и до физической DRAM, представлена ниже:

4.1.2. Секции программы

Пространство каждого процесса делится на секции, по аналогии с сегментами реального режима. Распространённый их список в формате fasm’a приводится ниже:

C-подобный:

section '.code'    code (атрибуты) - исполняемый код;
section '.data'    data (атрибуты) - инициал.данные (строки и переменные);
section '.bss'     data (атрибуты) - неинициал.данные ('0' или '?');
section '.idata'   data (атрибуты) - импорт функций;
section '.edata'   data (атрибуты) - экспорт функций;
section '.reloc'   data (атрибуты) - релокация адресов при смене ImageBase;
section '.rsrc'    data (атрибуты) - ресурсы (иконки, курсоры и пр.);
section '.tls'     data (атрибуты) - локальная память потока (Thread Local Storage);
section '.rdata'   data (атрибуты) - отладочная информация;
section '.marylin' data (атрибуты) - своя секция под барахло.

Обратите внимание, что исполняемой является только секция-кода, которой нужно выставить флаг 'executable'. Политика безопасности Win рекомендует запрещать в неё запись, чтобы предотвратить модификацию кода, но как-всегда это написано ‘вилами на воде’. Fasm – один из немногих компиляторов, который позволяет задавать атрибуты секциям. Эти атрибуты можно комбинировать нужным образом:

C-подобный:

executable  - исполняемая секция;
readable    - секция доступна на чтение;
writable    - секция доступна на запись;
discardable - при ограниченной физ.памяти, это первый кандидат на выгрузку в своп;
notpageable - из физ.памяти секцию сбрасывать нельзя! (невыгружаемая);
fixups      - авто/коррекция адресов и ошибок;
shareable   - расшаренная секция (вреда от которой больше, чем пользы).

На форумах можно встретить советы, мол нужно закрывать доступ на запись в секцию-кода, и если авер обнаружит обратное, мы у него точно окажемся под колпаком. Он посчитает, что код нашей программы занимается само/модификацией, а это присуще вирусам. Попробуем опровергнуть этот миф, и напишем пример такой программы. Это просто смена байта с нуль на 90h, после чего байт превратится в инструкцию NOP (опкод 0x90).

C-подобный:

include 'win32ax.inc'
.data
text    db  'Самомодификация!',0
;// Открываем секции-кода доступ на запись ---------------------
section '.code' code executable writable     ;<-- волшебный атрибут
start:  nop
        mov     byte[@01],90h                ; запись в секцию-кода!
@01:    db      0                            ; модифицируемый байт
        invoke  MessageBox,0,text,0,0
        invoke  ExitProcess,0
.end start

Теперь идём на

Ссылка скрыта от гостей

и проверяем этот код на малвару.
Как видим, из 15-ти антивирусов никто-ничего не заподозрил и это доказывает,
что само/модифицируемый код и под виндой имеет место быть, а не только под досом:

CKAP · 26.06.2019

> Запускаем WinDbg в локальном режиме ядра [Ctrl+K --> Local] и ищем структуры:

Я наверное сильно погорячился, что поставил Хрюшку.. ну хорошо не далеко ушли, пойду её сносить.. а то чет проблемы на проблеме.

Marylin · 27.06.2019

CKAP сказал(а):
пойду её сносить

Системы х64 запускают 32-битные процессы через подсистему WOW64 (Windows-on-Windows). Соответственно х32 выше XP запускают 16-битные программки через WOW32. В вашей ошибке говорится, что:

Система не поддерживает локальную отладку ядра.
Отладка ядра WinXP должна иметь Административные привилегии, и не поддерживается в WOW64. Локальный сеанс отладки отключён по умолчанию в Vista, и нужно запустить "bcdedit -debug on" и перезагрузиться, чтобы включить её.

Так-что смена системы с хрюши на другую в вашем случае думаю не даст результата. Видимо отладку ядра нужно проводить только с реальной машины, а не ВМ и с административными правами.

А в обычном режиме с ВМ у вас запускается WinDbg? чз Ctrl+E или F6..
Может это только в ядро не пускает, а обычная отладка поддерживается.

CKAP · 27.06.2019

Marylin сказал(а):
Так-что смена системы с хрюши на другую в вашем случае думаю не даст результата. Видимо отладку ядра нужно проводить только с реальной машины, а не ВМ и с административными правами.

Оу, ну я не зря спрашивал ранее про ВМ и Физическую машину.. Я дето уже слышал, что у ВМ есть проблемы... точно не вспомню какие, но точно помню что советовали юзать физическую машину.

По остальному.. ХРюшу уже снес, на ней и инстайлеры устаревшие. Вобчем гемора хвает по мимо. А семку есче не поставил. Возможно вечером.

Marylin · 27.06.2019

4.1.3. Карта памяти процесса

Запущенный на исполнение файл представляет из-себя процесс, который может иметь до 2000 подчинённых потоков ‘Thread’. Треды одного процесса могут свободно общаться между собой, сигнализируя о том или ином событии посредством системных объектов Event, Semaphore, Mutex. Однако один процесс не может вмешаться в работу другого, что собственно и подразумевает защищённый режим. Ясно, что это всё условности и можно без проблем преодолеть это ограничение - тут главное не спалиться антивирусу.

Если в общих чертах, то когда система создаёт процесс, в первую очередь в пространстве ядра для него создаётся структура EPROCESS, затем список MDL отведённых процессу физ.страниц памяти. С этого момента виртуальное пространство процесса готово, и система копирует в юзерскую область пространства дисковый файл Ntdll.dll, который представляет из-себя загрузчик образа программ. Помимо загрузчика (функции с приставками Ldr), Ntdll.dll выдаёт на экспорт огромное кол-во Win32-API, общее число которых на XP равно 1.316 штук. Причём сама эта DLL не импортирует ни одной функции с других библиотек, т.е. у неё отсутствует секция-импорта.

Теперь загрузчик подгружает с диска в память образ запускаемой программы и просканировав его секцию-импорта, подтягивает в ОЗУ остальные библиотеки типа Kernel32.dll, User32.dll и GDI32.dll. После того-как все библиотеки импорта загрузятся в память, загрузчик передаёт управление на Entry-Point программы и она стартует. Загрузчик Ntdll.dll и три указанные библиотеки х32.dll остаются в памяти процесса на всё время его исполнения и ждут, когда программа вызовет из них API-функции. Мало того, система всегда загружает их по одному-и-тому-же адресу.

Такая картина предначертана судьбою одному процессу. Когда наступит время запустить следующий процесс, система полностью повторит описанный алгоритм, и новый процесс получит свою копию загрузчика Ntdll.dll, и остальных библиотек с функциями Win32-API. То-есть у каждого процесса свой набор ‘отображаемых в память’ системных файлов, что создаёт определённые проблемы при перехвате API. Например, перехват функции из библиотеки Kernel32.dll, которая находится в моём пространстве, никак не повлияет на эту-же функцию, которая находится в пространстве соседнего процесса.

Выше упоминался тип секций с атрибутом ‘Shareable’ – расшаренная. Такой тип имели системные библиотеки оси Win-98. Эта система загружала свои библиотеки в глобальную память и открывала к ним доступ всем-желающим, тем-самым расшаривая их. У программ была только одна общая Kernel32.dll в памяти, и её перехват действовал на глобальном уровне, приводя все процессы в ступор. Начиная с Win2000 Microsoft отказалась от раздачи секций на шару, посчитав это брешью в системе безопасности. Так, каждый процесс получил свою порцию системных файлов.

Загрузим свой ‘HelloWorld’ в отладчик OllyDbg и нажав на пимпу (М) получим карту памяти процесса (на скрине Оля версии 2). Здесь, я выделил синим принадлежащие моему коду адреса, а красным – это регион системных библиотек, которые были подгружены лоадером Ntdll.dll в моё пространство. Видно, что для них выделяется верхний регион памяти. 12К-байтный стек по-умолчанию, занял позиции наоборот в подвале, начиная с адреса 0х0006d000 (три страницы). 1000h байт – это одна 4К-байтная страница виртуальной памяти. Мой процесс HelloWorld называется Example.exe, и каждая его секция – размером в страницу:

Обратите внимание на атрибуты ‘Access’ системных файлов. На запись(W) доступны только их секции данных, в которых нет ничего интересного. Чтобы записать в них исполняемый шелл-код, нужно будет переназначить атрибуты функцией VirtualProtect(). Эта функция позволяет манипулировать атрибутами памяти в своём процессе, а VirtualProtectEx() – способна устанавливать эти атрибуты и в чужих страницах, не принадлежащих нашему процессу.

Позже мы ещё вернёмся к ним, а пока напишем код, который вытащит базы системных библиотек в памяти, что получить к ним доступ на программном уровне. Получив базу, мы можем через GetProcAddress() узнать смещение нужной функции в любой из библиотек, чтобы потом перехватить их. Базу возвращает GetModuleHandle(), которой и воспользуемся:

C-подобный:

include 'win32ax.inc'
.data
capt    db  'mMap v0.1',0
text    db  'База в памяти системных библиотек',13,10
        db  '---------------------------------',13,10
buff    db   256 dup(0)
frmt    db  'GDI32.dll....: %08x',13,10       ;// спецификаторы для wsprintf()
        db  'Kernel32.dll.: %08x',13,10
        db  'Ntdll.dll....: %08x',13,10
        db  'USER32.dll.... %08x',0
;-------
.code
start:
;// Получаем базы модулей,
;// и сохраняем их в стеке в нужном порядке
        invoke  GetModuleHandle,<'user32.dll',0>
        push    eax
        invoke  GetModuleHandle,<'ntdll.dll',0>
        push    eax
        invoke  GetModuleHandle,<'kernel32.dll',0>
        push    eax
        invoke  GetModuleHandle,<'gdi32.dll',0>
        push    eax
;// Преобразуем числа из стека в строку
;// все пуши считаются аргументами wsprintf()
        invoke  wsprintf,buff,frmt

        invoke  MessageBox,0,text,capt,0
        invoke  ExitProcess,0
.end start

Чтобы убедиться в валидности результата этого кода, сравним его со-скрином выше, или запросим у WinDbg командой lmi информацию о модулях Load-Module-Info. Как видим, весь софт возвращает одну-и-ту-же базу, что подтверждает загрузку системных библиотек всегда по фиксированному адресу:

CKAP · 28.06.2019

Marylin сказал(а):
А в обычном режиме с ВМ у вас запускается WinDbg? чз Ctrl+E или F6..
Может это только в ядро не пускает, а обычная отладка поддерживается.

Ctr + E

И по F6

С ядром таже хрень, как вы и говорили.. хм.. не критично для учебы?
зы. ОС на Виртуал Бокс от Оракле.

SearcherSlava · 28.06.2019

CKAP сказал(а):
Ctr + E
Посмотреть вложение 31239
И по F6
Посмотреть вложение 31241

С ядром таже хрень, как вы и говорили.. хм.. не критично для учебы?
зы. ОС на Виртуал Бокс от Оракле.

Гуглоуточка: project oracle cia pdf
Машина - виртуальная, наши данные - реальные.

Ссылка скрыта от гостей

CKAP · 28.06.2019

Хоспади, как же все сложно с этими вашими Ядерными делами.
Пересел уже за физ машину.

В консоле от рута bcdedit /debug on + ребут
И на выходе

Балин может я что то не то делаю. Просто с этой прогой не знаком. Но уже хоть консолька появилась.

Marylin · 28.06.2019

CKAP сказал(а):
может я что то не то делаю.

Ну вот.. консолька есть.. теперь нужно настроить в WinDbg приём 'отладочных символов'. Эти символы с расширением *.pdb хранятся на сервере Microsoft и позволяют придавать осмысленные имена функциям, служебным структурам и т.п. Вам нужно создать в родительской папке WinDbg подпапку SYM, если таковой там нет по-умолчанию. Позже все скаченные символы будут сбрасываться в неё. У меня путь такой: C:\Program Files\Debugging Tools for Windows (x86)\sym\

При первом запуске отладчика, в данном хранилище ничего нет - оно будет пополняться динамически с сервера Microsoft (вы должны быть On-line). Для настройки символов, нужно запустить WinDBG в Kernel-режиме [Ctrl+K-->Local] и в окне меню "File-->Symbol_File_Path" прошить путь до локального хранилища, и через разделитель(*) указать дополнительный сервер символов Microsoft. В конечном итоге, адрес должен иметь следующий формат:

SRV*C:\Program Files\Debugging Tools for Windows (x86)\sym*

Ссылка скрыта от гостей

Если на данном этапе вы находитесь в On-line, то после нажатия ОК отладчик начнёт скачивать в своё/локальное хранилище символы основных файлов ядра - это 'ntoskrnl.exe' и 'ntdll.dll'. Для начала этого набора символов будет достаточно, а остальные будут загружаться по мере необходимости, о которой WinDBG будет сам нас оповещать.

Проверить символы можно командой .sympath, и если указанный выше путь прописан, то проверить символы конкретно модуля NT можно командой !lmi nt. В отчёте будет строка Symbol Type: PDB, по которой и можно сделать вывод о наличии отладочных символов. Ну или просто заглянуть в указанную папку \SYM.. там должен быть файл *.pdb.

Marylin · 28.06.2019

что-то ссылка на сервер мелкософта сама поменялась..
нужно задать адрес как на скрине

Marylin · 28.06.2019

у меня этих символов уже набралось 146 папок, для каждого модуля (драйвера) отдельно. Чтобы не потерять их, периодически делаю из этой папки бэкап. Это позволит при переустановки системы не качать их заново, а просто восстановить в папку sym

CKAP · 28.06.2019

Marylin сказал(а):
что-то ссылка на сервер мелкософта сама поменялась..
нужно задать адрес как на скрине

Дааа.. черт возьми.. каталог sym начал наполнятся.. Благодарю.
И да.. каталога не было.

Marylin · 28.06.2019

Как пополнится, можете просмотреть например структуру eprocess командой dt _eprocess
Поскольку отладчик у вас на реальной машине, вам придётся компилировать примеры fasm'a на виртуалке, а тестить их на реальной машине.

Компилировать х32 приложения на системе х64 не получится, т.к. код использует библиотеки х32, а на системе эти библиотеки в формате х64. Как я говорил, функции у них разные, например тот-же MessageBox на х64 требует аргументы в регистрах, а в х32 они передаются через стек.

CKAP · 28.06.2019

Marylin сказал(а):
Поскольку отладчик у вас на реальной машине, вам придётся компилировать примеры fasm'a на виртуалке, а тестить их на реальной машине.

Да не.. я полностью перетащил все на физ 32 битную машину. Вы тут рассказываете как руками дотянутся до важных мест. Так что, на хрен ВМ.

Marylin · 28.06.2019

Ну тогда проблем вообще не будет..

CKAP · 28.06.2019

Я потерялся где то тут

> т.к. при подключении к процессу WinDbg останавливается далеко не на точке-входа в отлаживаемый процесс. Если поставить бряк на Е-Рoint и запустить отладчик командой Go

Не понял куда чё ставить.. хм.
------------
И вот есче..

Чет много всего весит на одних адресах..
прога эта
----------------------
include 'win32ax.inc'
;-------
.data
text db 'Hello World!',0
;-------
.code
start: invoke MessageBox,0,text,0,0
invoke ExitProcess,0
.end start
-----------

Зы. Пробираюсь по вашему посту как по непроходимым джунглям (

Marylin · 28.06.2019

CKAP сказал(а):
Я потерялся где то тут

Для начала вам нужно сменить дефолтный фейс WinDbg, чтобы он отображал регистры, память, стек и прочее в своём окне. По-молчанию у него этого нет, и некоторые схемы лежат в папке %WinDbg%\themes. Значит сейчас вам нужно проделать следующие шаги:

Закрыть отладчик WinDBG.
Запускаем "regedit" и идём по пути: HKCU\Software\Microsoft\Windbg\..
Удаляем в этой папке весь раздел "Workspaces", co-всей подноготной.
Теперь из дира C:\Program Files\Debugging Tools for Windows\themes\ запускаем файл-реестра "standardvs.reg", подтверждая свои намерения буттоном "ОК".
Запускаем WinDBG и видим уже несколько (выстроенных каскадом) окон. Остаётся из меню "View-->Font" выбрать подходящий шрифт (у меня "Courier New") и подвигав за маркеры окон, настроить их в удобное расположение.
Чтобы запомнить ново/испечённый Workspace нужно сохранить его с расширением *.wew, для чего проследуем в меню "File-->Save_Workspace_to_File" и задав ему имя, сохраним в той-же папке "..\themes". После этого можно загнать его и в локальное хранилище, через "Save_Workspace_As..".

Теперь отладчик будет стартовать в приглядном виде,
преобразившись от полного нуля до старшего майора - у меня получилось так:

Для просмотра структур PEB/TEB текущего процесса можно воспользоваться командами !peb и !teb соответственно.

CKAP · 29.06.2019

> Это просто смена байта с нуль на 90h

Очень интересный момент... хотя минут пять тупил в регистры, но там кроме указателя команды не чего не меняется.

Marylin · 29.06.2019

4.1.4. Системные объекты, Handle, PID процессов и связные списки

Рассматривая системные механизмы, нельзя пропустить такую важную их часть как ‘объекты ядра’. Без доли сарказма объекты можно назвать основой-основ многозадачных систем. Ими управляет Object Manager (диспетчер), который создаёт объекты только для разделяемых ресурсов ОСи, и если ресурс используется в рамках одного процесса, назначать его в виде объекта не имеет смысла. Объектный подход позволяет в будущем добавлять ещё системных ресурсов, не переписывая при этом код ядра Ntoskrnl.exe.

4.1.4.0. Объекты ядра

В пространстве ядра имеется каталог объектов, с под/каталогами для каждого типа объектов. На этапе загрузки системы каталог пуст и заполняется он динамически, по мере обращения системы к различным своим ресурсам. В качестве ресурсов могут выступать: процессы, потоки, файлы, устройства, и всё остальное. Марк Руссинович написал утилиту WinObj для изучения объектов ядра, хотя лично я предпочитаю аналогичную программу от хакера Four-F, который внёс огромный вклад в область исследования драйверов - она называется WinObjExplorer. 64-битную её версию можно стянуть с гитхаба, а для х32 я прицепил её в скрепке:

В данной директории каталога объектов, представлены все имеющиеся типы-объектов ‘Type’. Объекты создаются для того, чтобы один раз собрав информацию о нём, запомнить эту инфу в соответствующей структуре данных. Тогда при следующем обращении достаточно будет возвратить только указатель на структуру объекта, без повторного сбора информации. Например, при обнаружении устройства, для его представления создаётся объект устройства Device-Objects. Для управления этим устройством загружается драйвер и создаётся объект драйвера Driver-Object, в котором представлены свойства данного устройства и даны указатели на реализованные в нём функции ввода-вывода. После этого, к драйверу обращаются через его именованный объект, например Device\HardDisk0.

На физ.уровне, объект представляет из-себя просто структуру в памяти, в которой описываются свойства данного объекта. Всякий объект имеет одинаковый для всех заголовок ‘Header’, и привязанное к типу объекта - тело ‘Body’. Заголовками управляет диспетчер-объектов, а телами – исполняющая подсистема ядра Executive (в файле Ntoskrnl.exe). Посмотрим на эти структуры в отладчике WinDbg, для чего достаточно дать команду на отображение структур dt _object_header:

Код:

lkd> dt _object_header
nt!_OBJECT_HEADER
   +0x000 PointerCount       : Int4B
   +0x004 HandleCount        : Int4B
   +0x004 NextToFree         : Ptr32 Void
   +0x008 Type               : Ptr32 _OBJECT_TYPE
   +0x00c NameInfoOffset     : UChar
   +0x00d HandleInfoOffset   : UChar
   +0x00e QuotaInfoOffset    : UChar
   +0x00f Flags              : UChar
   +0x010 ObjectCreateInfo   : Ptr32 _OBJECT_CREATE_INFORMATION
   +0x010 QuotaBlockCharged  : Ptr32 Void
   +0x014 SecurityDescriptor : Ptr32 Void
   +0x018 Body               : _QUAD

0x00 – число процессов, использующих данный объект;
0x04 – счётчик дескрипторов на объект;
0x08 – информация о типе объекта;
0x0С – указатель на имя каталога, в котором живёт объект (в Unicode, в ядре нет ASCII-строк);
0х0Е – квота на объект (ограничение на использование ресурса процессами);
0x0F – флаги доступа к объекту;
0х14 – что позволено делать с объектом (чтение/запись/удаление);
0х18 – указатель на тело объекта.

Эта информация является общей для всех объектов, а характеристики конкретно взятого объекта, лежат в структуре Object_Type, указатель на которую хранится по смещению(08) в заголовке:

Код:

lkd> dt _object_type
nt!_OBJECT_TYPE
   +0x000 Mutex                    : _ERESOURCE
   +0x038 TypeList                 : _LIST_ENTRY
   +0x040 Name                     : _UNICODE_STRING
   +0x048 DefaultObject            : Ptr32 Void
   +0x04c Index                    : Uint4B
   +0x050 TotalNumberOfObjects     : Uint4B
   +0x054 TotalNumberOfHandles     : Uint4B
   +0x058 HighWaterNumberOfObjects : Uint4B
   +0x05c HighWaterNumberOfHandles : Uint4B
   +0x060 TypeInfo                 : _OBJECT_TYPE_INITIALIZER
   +0x0ac Key                      : Uint4B
   +0x0b0 ObjectLocks              : [4] _ERESOURCE

4.1.4.1 Handle (дескрипторы) процессов

С понятием объект тесно связан ‘дескриптор объекта’ – система возвращает его нам в ответ, например, открытия файла. В момент, когда мы открываем файл, ядро создаёт дубликат своего объекта типа "File", и оформив его в виде дескриптора, вручает нам. Процедура оформления состоит из сброса/установки определённых полей в заголовке-объекта, исходя из наших привилегий в системе. Дескриптор, который нам возвращают функции API, на самом деле никакой не дескриптор, а порядковый номер записи в таблице-дескрипторов объектов ObjectTable:

Следующий код открывает файл и выводит на экран его дескриптор, который возвращает API:

C-подобный:

include 'win32ax.inc'
.data
fName   db  'C:\boot.ini',0           ;// файл для открытия
capt    db  'Handle v0.1',0
text    db  'Дескриптор файла: %08X',0
buff    db  32 dup(0)
;-------
.code
start:  invoke  _lopen,fName,0        ; открыть файл
        or       eax,eax              ; проверка на ошибку
        jns      @ok                  ; если не отрицательно, иначе..
        invoke   MessageBox,0,<'Нет такого файла!'>,0,0
        jmp      @exit
@ok:    push     eax                  ;// запомнить дескриптор файла
       cinvoke   wsprintf,buff,text   ; преобразовать его в символы
        pop      eax                  ;
        invoke  _lclose,eax           ;// закрыть файл по дескриптору

        invoke  MessageBox,0,buff,capt,0
@exit:  invoke  ExitProcess,0
.end start

Команда в WinDbg позволит ознакомится с дескрипторами объектов текущего процесса, где 0 7 это флаги фильтрации вывода. То-есть открываем любой экзешник по Ctrl+E и получаем выделенные для него дескрипторы, причём пока отлаживаемая программа не обратится к объекту, информации о нём не будет в этом списке, т.к. объекты создаются динамически:

C-подобный:

0:000> !handle 0 7
Handle 00c
  Type             File
  Attributes       0
  GrantedAccess    0x100020:   Synch,Execute/Traverse
  HandleCount      3
  PointerCount     4
Handle 7ec
  Type             Port
  Attributes       0
  GrantedAccess    0x1f0001:   Delete,ReadControl,WriteDac,WriteOwner,Synch,Connect
  HandleCount      2
  PointerCount     4
  Name             <none>
Handle 7f0
  Type             Directory
  Attributes       0x10
  GrantedAccess    0xf000f:    Delete,ReadControl,WriteDac,WriteOwner,Query,Traverse,Create,CreateSubdir
  HandleCount      28
  PointerCount     33
  Name             \Windows
Handle 7f8
  Type             Directory
  Attributes       0x10
  GrantedAccess    0x3:        Query,Traverse
  HandleCount      29
  PointerCount     68
  Name             \KnownDlls
Handle 7fc
  Type             KeyedEvent
  Attributes       0x10
  GrantedAccess    0xf0003:    Delete,ReadControl,WriteDac,WriteOwner,Wait,Wake
  HandleCount      29
  PointerCount     31
  Name             \KernelObjects\CritSecOutOfMemoryEvent
;-----------------
5 Handles
Type               Count
File               1
Port               1
Directory          2
KeyedEvent         1

4.1.4.2. PID процесса

PID – это идентификатор процесса. Его формирует планировщик ОСи, и он всегда кратен 4. Система записывает PID текущего процесса в его структуру EPROCESS по смещению 0х84 ‘UniqueProcessID’. Все Win32-API работающие с процессами, требуют в качестве одного из аргументов именно PID процесса, к которому обращаются. Поскольку для отладчика WinDbg все процессы это клиенты, порой он обзывает идентификатор Cid’ом, что означает ClientID. Узнать свой PID в отладчике можно так:

Функция GetCurrentProcessId() возвращает идентификатор своего процесса, но в большинстве случаях нам нужен будет PID чужого. Узнав PID можно получить дескриптор (handle) любого процесса функцией OpenProcess(), через который можем вытворять с процессом, что угодно. Код ниже выводит свой PID, а чужой попытаемся получить позже, сканированием всех процессов в памяти. Обратите внимание, что PID процесса не статичен и назначается планировщиком от фонаря, при каждом запуске программы:

C-подобный:

include 'win32ax.inc'
.data
capt    db  'PID v0.1',0
text    db  'Идентификатор текущего процесса: %08X',0
buff    db  64 dup(0)
;-------
.code
start:  invoke   GetCurrentProcessId        ;// запросить у системы свой ид.
       cinvoke   wsprintf,buff,text,eax     ; преобразовать его в символы

        invoke  MessageBox,0,buff,capt,0
        invoke  ExitProcess,0
.end start

Больше функций по работе с процессами и их потоками можно

Ссылка скрыта от гостей

4.1.4.3. Связные списки LIST_ENTRY

Разработчики операционных систем садятся на шпагат при выборе между статическими и динамическими структурами данных. Статические легче прогать, динамические обладают большей гибкостью. Очевидный пример – таблица процессов. В Win98 для каждого процесса просто выделялся фиксированный массив структур. Если таблица-процессов состояла из 64 элементов, то в любой момент могло существовать в памяти не более 64 процесса, т.к. для 65-го просто не было места в таблице. Аналогичные соображения были справедливы и для таблицы открытых файлов. Такой лимит назвали квотой.

Альтернативная стратегия заключается в создании таблицы-процессов в виде связного списка LIST_ENTRY, начиная с единственной мини-таблицы. Когда эта таблица заполняется, в глобальном пуле выделяется память под следующую таблицу, которая связывается с первой таблицей при помощи указателей. Таким образом, таблица процесса не переполнится, пока не закончится вся память у ядра.

Другой вариант – использовании таблицы фиксированного размера, но с выделением (когда эта таблица заполнится) новой таблицы фиксированного размера, в два раза большей. При этом текущие записи копируются из старой таблицы в новую, а память (которая была занята старой таблицей) возвращается в пул. Таким образом, таблица всегда остаётся непрерывной, а не связной. Недостаток этого подхода – требуется менеджер таблиц, + адрес таблицы будет переменным вместо константы.

Современные винды всех мастей используют только динамические структуры в виде связных списков LIST_ENTRY, поэтому в большинстве структурах присутствует указанное поле – например в той-же EPROCESS:

Тело любого/связного списка LIST_ENTRY хранит два указателя – Flink и Blink.
Первое поле от слова ‘Forward’ указывает на следующую структуру EPROCESS в цепочке процессов в памяти, а второе поле от ‘Backward’ – это указатель на предыдущую структуру в цепочке. Таким образом, если найти хоть одну/любую структуру EPROCESS в ядерной памяти, можно потянув за LIST_ENTRY вытянуть структуры всех процессов, получив тем-самым полный список запущенных процессов. Рисунок ниже наглядно демонстрирует устройство данного механизма. В последнем разделе этой части мы рассмотрим это дело подробней.

Все сервисы Codeby

Поиск

Поиск

Статья ASM для х86. (4.0) Системные механизмы Windows

Marylin

Mod.Assembler

CKAP

Marylin

Mod.Assembler

CKAP

Marylin

Mod.Assembler

CKAP

SearcherSlava

CKAP

Marylin

Mod.Assembler

Marylin

Mod.Assembler

Marylin

Mod.Assembler

CKAP

Marylin

Mod.Assembler

CKAP

Marylin

Mod.Assembler

CKAP

Marylin

Mod.Assembler

CKAP

Marylin

Mod.Assembler

Вложения