Обектно ориентиране в Windows

И така, смятам да започна една поредица от постинги относно Object Manager-a в Windows и по-специално каква е неговата идея и какво интересно може да се случи с него в контекста на един rootkit. Само ще направя една вметка, че тук няма да става въпрос за обектно ориентирано програмиране :)

Обекти в Windows

Windows, като всяка модерна операционна система му се налага да оперира върху голям на брой обекти, като най-близката аналогия би била тази с data structures - обект е на практика съвкупност от променливи, които описват  даден ресурс в системата и съответно има прилежащи операции към тези ресурси - например файловете в Windows са ресурси (описани са тук), прозорците също са ресурс, процесите са ресурс, thread-овете също са ресурс, колкото и странно да звучи драйвърите също са ресурс за Windows, различните устройства като хард диск, усб флашове etc. Сега, както сами разбирате в Windows (а и в Линукс) има доста обекти и логиката би диктувала, че една голяма част от тях ще имат общи свойства и характеристики и не би имало смисъл те да бъдат дефинирани за абсолютно всеки тип. Именно този, но не само, проблем се опитва да реши Object Manager-а в Windows. 

Може би няма Win програмист на този свят, който да не е запознат с концепцията за HANDLE. И как това е един от начините Windows  да предостави абстрактен достъп до почти всички обекти - например handle към динамично заредена библиотека, handle към remote  процес, handle към пайп, handle към файл. В Windows е възможно към даден обект (например файл) да бъдат отворени няколко различни handle-и от няколко различни процеса, които не е задължително да знаят един за друг. Например би било доста лошо ако в един момент даден процес реши да изтрие този файл, без да се интересува дали някой друг го чете или ползва в момента, в тази ситуация се притича Object Manager-а на помощ - всеки път когатo handle бива даден  то Object Manager се грижи затова в една специална (_OBJECT_HEADER) структура да бъде увеличен handle count-а с едно и респективно, когато даден handle бъде освободен чрез някое от API-тата, то този handle count бива намален с едно. И тук има една малка уловка - докато в user-space ресурсите на системата са достъпни чрез handles,  то в kernel space  е възможно даден обект да бъде достъпен и чрез pointer - тоест да се получи директен достъп до "тялото" на обекта (в следваща публикация мисля да засегна по-подробно как точно изглеждат структурите), което означава, че дори handle count-а да е 0, то все пак е възможно да има драйвъри или части от системата, които да работят с този обект и изтриването му най-вероятно би предизвикало BSOD. 

Друг аспект, който всички обекти имат е security. Тоест кой потребител какви права има върху дадент обект. И вместо абсолютно всяка подсистема на windows сама да грижи за сигурността си, тази задача е делегирана на object manager-а. Когато се опитаме да достъпим даден обект (от user space), то OM  се грижи да направи необходимите проверки, за да види дали имаме достатъчни права да достъпим обекта.

Друга важна отговорност на OM е да се грижи за resource marshalling, тоест при всяко създаване на обект да следи, за това какви ресурси се използват и съответно отбелязва - един вид го играе счетоводител.

Ами като въведение общо взето е това. В следваща публикация ще обърна повече внимание на някои от структурите, които ОМ ползва, и които се грижат системата да е в изрядно състояние.