Аналіз захищеності технології INTEL SMEP на базі Windows 8
НАЦІОНАЛЬНИЙ АВІАЦІЙНИЙ УНІВЕРСИТЕТ
ІНСТИТУТ
ІНФОРМАЦІЙНО-ДІАГНОСТИЧНИХ
КАФЕДРА КОМП’ЮТЕРИЗОВАНИХ СИСТЕМ ЗАХИСТУ ІНФОРМАЦІЇ
КУРСОВА РОБОТА
з дисципліні: “ Безпека інформаційних та комунікаційних систем ”
на тему: “ Аналіз захищеності технології INTEL SMEP
на базі OS Windows 8”
Виконав студент 442 групи, ІІДС
Ващук Володимир Олександрович
Прийняв:
Павлов Валерій Георгійович
Київ 2012
ЗМІСТ
ТЕРМІНИ ТА ВИЗНАЧЕННЯ 3
КІЛЬЦЯ ЗАХИСТУ 5
РЕЖИМ РОБОТИ CPU – SUPERVISOR 7
INTEL SMEP -- SUPERVISOR MODE EXECUTION PREVENTION 9
АПАРАТНА СКЛАДОВА ТЕХНОЛОГІЇ INTEL SMEP 10
Контролюючі регістри 10
Режим вибору сторінок 11
Свопінг модифікатори 11
Перелік особливостей свопінгу в CPUID 12
Обробка винятків та переривань 12
ПРОГРАМНА ПІДТРИМКА ТЕХНОЛОГІЇ SMEP 13
СПОСОБИ ОБХОДУ SMEP НА ОС WINDOWS І ПРОТИДІЯ ЙОМУ 14
Недолік конфігурації 14
Практична реалізація 16
х64 17
Інші напрямки атак для обходу SMEP 18
ВИСНОВОК 19
ВИКОРИСТАНА ЛІТАРЕТУРА ТА РЕСУРСИ 20
ТЕРМІНИ ТА ВИЗНАЧЕННЯ
Режим супервізора -- привілейований режим роботи процесора, як правило використовується для виконання ядра операційної системи.
Захищений
режим (режим захищеного віртуального
адресу) — режим роботи процесора. Розроблений фірмою Digital Equipment (DEC) для 32-розрядних
комп'ютерів VAX-11, а також фірмою Intel для своїх процесорів, починаючи
з 32-розрядних процесорів 80386. Хоча захищений
режим частково було реалізовано вже у
процесорі 80286, але там істотно відрізнявся
спосіб роботи з пам'яттю, бо процесори
ще були 16-бітні і не була реалізована
сторінкова організація пам'яті. Використовується
в процесорах інших виробників. Цей режим
дозволив створити багатозадачні операці
Лінійна адресація пам'яті - схема адресації пам'яті комп'ютера в захищеному режимі (починаючи з Intel 80386 і інших сумісних x86-процесорах). Використовується більшістю сучасних багатозадачних ОС.
Завдяки
механізму лінійної адресації можна
створювати будь-яке (обмежене тільки
розмірами оперативної пам'яті) кількість
незалежних віртуальних адресних просторів.
Причому кожна сторінка лінійного
адресного простору може знаходитися
по будь-якій фізичній адресою або
навіть бути вивантажені на діск.Лінейная
адресація пам'яті - схема адресації
пам'яті комп'ютера в
Завдяки механізму лінійної адресації можна створювати будь-яке (обмежене тільки розмірами оперативної пам'яті) кількість незалежних віртуальних адресних просторів. Причому кожна сторінка лінійного адресного простору може знаходитися по будь-якій фізичній адресою або навіть бути вивантажені на диск.
Кільця захисту -- архітектура інформаційної безпеки та функціональної відмовостійкості, що реалізує апаратнsq поділ системного й користувацького рівнів привілеїв.
CPUID (CPU Identification) - асемблерна мнемоніка інструкції процесорів x86, використовується для отримання інформації про процесор. Використовуючи її, програма може визначити тип ЦП і його можливості (наприклад, можна визначити, які розширення підтримуються процесором).
Інструкція CPUID вперше з'явилася в процесорах i486. Потім вона почала підтримуватися всіма процесорами починаючи з Intel 486DX/SX/DX2 SL, AMD 486DX4, Cyrix 6x86 (M1), UMC U5S.
Intel SMEP -- режим захисту в режимі супервізора.
Шелл-код (англ. shellcode, код запуску оболонки) - це двійковий виконуваний код, який зазвичай передає управління командному процесору, наприклад '/ bin / sh' в Unix shell, command.com в MS-DOS і cmd.exe в операційних системах Microsoft Windows. Шелл-код може бути використаний як корисне навантаження експлойта, що забезпечує зломщикові доступ до командної оболонки (англ. shell) в комп'ютерній системі.
При експлуатації віддаленої уразливості шелл-код може відкривати заздалегідь заданий порт TCP уразливого комп'ютера, через який буде здійснюватися подальший доступ до командної оболонки, такий код називається прив'язуючий до порту (англ. port binding shellcode). Якщо шелл-код здійснює підключення до порту комп'ютера атакуючого, що проводиться з метою обходу брандмауера або NAT, то такий код називається зворотної оболонки (англ. reverse shell shellcode).
Сво́пінг (від англ. swap), або підкачка сторінок (англ. paging) — один з механізмів віртуальної пам'яті, при якому окремі фрагменти пам'яті (зазвичай неактивні) переміщуються з ОЗП на жорсткий диск, звільняючи ОЗП для завантаження інших фрагментів пам'яті. Такими фрагментами в сучасних ЕОМ є сторінки пам'яті.
Тимчасово вивантажені з пам'яті
сторінки можуть зберігатися на зовнішніх
запам'ятовуючих пристроях як у файлі,
так і в спеціальному розділі на жорсткому
диску (англ.partition), звані відповідно swap-файл і
swap-розділ. У разі відкачування сторінок,
що відповідають вмісту будь-якого файлу
(наприклад, англ. memory-
Коли додаток звернеться до відкачаної сторінки, відбудеться виняткова ситуація PageFault. Оброблювач цієї події повинен перевірити, чи була раніше відновлено запитана сторінка, і, якщо вона є в свопі, завантажити її назад в пам'ять.
КІЛЬЦЯ ЗАХИСТУ
Кільця захисту -- архітектура інформаційної безпеки та функціональної відмовостійкості, що реалізує апаратнsq поділ системного й користувацького рівнів привілеїв. Структуру привілеїв можна зобразити у вигляді кількох концентричних кіл. У цьому випадку системний режим (режим супервізора або нульове кільце, так зване «кільце 0»), що забезпечує максимальний доступ до ресурсів, є внутрішнім колом, тоді як режим користувача з обмеженим доступом - зовнішнім. Традиційно сімейство мікропроцесорів x86 забезпечує чотири кільця захисту.
- Режим супервізора
- Режим гіпервізора
- Режим системного управління
- Режим користувача
Архітектурі кілець захисту зазвичай протиставляють системи, засновані на мандатній адресації, що забезпечує доступ до об'єкта за його опису (англ. Capability-based security).
РЕЖИМ РОБОТИ CPU – SUPERVISOR
В даному режимі процесор обслуговує всі переривання, немасковані переривання і виключення в режимі супервізора.
Режимі супервізора має повний необмежений доступ до всіх ресурсів системи процесора, включаючи ресурси емуляції, за умови, що не використовується CPLB, конфігурований відповідним чином. Тільки в режимі супервізора можливе використання альтернативного імені регістра USP, що визначає положення в пам'яті Покажчика Користувацького Стека. Використання цього альтернативного імені необхідно, так як в режимі супервізора по імені SP виконується звернення до покажчика стека ядра операційної системи, а не до покажчика користувальницького стека.
Нормальна робота процесора починається при переході зі стану Reset в режимі супервізора по зняттю активного рівня сигналу RESET. Процесор знаходиться в режимі супервізора до тих пір, поки емуляція або виклик команди повернення не змінять режим роботи. Перед викликом команди повернення в регістр RETI необхідно завантажити достовірний адрес повернення.
Цей режим по функціональності відповідає 0-му кільцю захисту (Ring 0) в x86 процесорах, тобто надає необмежений доступ до всіх можливостей процесора, роботі з периферією і так далі. Код, що працює в даному режимі, як правило, займається управлінням доступними апаратними ресурсами, поділом їх використання між окремими завданнями (процесами) і так далі, що і призвело до такої назви режиму.
Деякі фірми-розробники і виробники процесорів, наприклад ARM, не використовують класифікацію режимів роботи процесора у вигляді кілець захисту. Тим не менш, у більшості сучасних процесорів (крім найпростіших) як правило присутні декілька режимів роботи відрізняються один від одного доступними в даному режимі привілеями.
У багатьох типах процесорів це найбільш привілейований режим з усіх доступних режимів.
Відомо одне виключення з даного правила: у деяких сучасних процесорів може бути присутнім ще більш привілейований режим гіпервізора, як правило, використовуваний з метою віртуалізації тобто забезпечення паралельної роботи відразу декількох операційних систем на одному процесорі. У цьому випадку налаштування, зроблені з режиму гіпервізора можуть вносити деякі обмеження на прямий доступ до системних ресурсів і периферії з режиму супервізора з метою надати гіпервізора можливість арбітражу і розмежування доступу до системних ресурсів і периферії непомітно для працюючих паралельно операційних систем.
Як
правило при використанні даного
режиму повний доступ до всіх ресурсів
можливий саме з режиму гіпервізора.
У такому випадку режим супервізора
вже не є максимально привілейованим
і обмежує багато привілейовані
операції. При виконанні привілейованих
операцій операційними системами в
режимі супервізора управління передається
спеціальній програмі - гіпервізора.
Гіпервізор здійснює арбітраж використання
наявних апаратних ресурсів декількома
операційними системами аналогічно
тому як самі операційні системи здійснюють
розподіл ресурсів між кількома завданнями.
По суті, гіпервізор зазвичай є невеликим
ядром, яке управляє розподілом ресурсів
між декількома операційними системами
і працює рівнем нижче, ніж самі операційні
системи. В силу цього в термінології x86
даний режим як правило називають кільцем
-1 (Ring -1).
INTEL SMEP -- SUPERVISOR MODE EXECUTION PREVENTION
З приходом нового покоління процесорів Intel на базі архітектури Ivy Bridge було представлено новий засіб безпеки. Воно називається Intel SMEP, що розшифровується як "Supervisor Mode Execution Prevention" - запобігання виконання коду в режимі супервізора. Технологія полягає в запобіганні виконання коду, розташованого на користувацької сторінці, при поточному рівні привілеїв рівному 0. З точки зору атакуючого, даний засіб значно ускладнює експлуатацію вразливостей режиму ядра, тому як в даних умовах відсутнє місце для зберігання шелл-коду. Зазвичай при експлуатації уразливості режиму ядра атакуючий виділяє буфер з шелл-кодом в режимі користувача і потім активує уразливість, отримуючи контроль над виконанням коду і перевизначаючи точку виконання на вміст підготовленого буфера. Таким чином, якщо атакуючий не може виконати свій шелл-код, вся атака безглузда. Звичайно, існують різні техніки, такі як зворотно-орієнтоване програмування (ROP) для експлуатації вразливостей з корисним навантаженням. Однак бувають і такі випадки, коли середа виконання дозволяє обходити обмеження безпеки при некоректній конфігурації. Розглянемо докладніше технологію Intel SMEP, а також її програмну підтримку, заявлену в ОС Windows 8.
АПАРАТНА СКЛАДОВА ТЕХНОЛОГІЇ INTEL SMEP
Даний розділ включає в себе огляд технології Intel SMEP на основі документації Intel. SMEP є частиною механізму захисту сторінок пам'яті. Насправді вона використовує вже існуючий прапор в записі таблиці сторінок - прапор U / S (прапор User / Supervisor, 2-й біт). Цей прапор указує на те, є дана сторінка сторінкою користувацького режиму або режиму ядра. Власник сторінки визначає наявність доступу до даної сторінки пам'яті, тобто, якщо сторінка належить ядру операційної системи, яка виконує код в привілейованому режимі, доступ до неї з користувальницького додатка неможливий. SMEP включається і вимикається за допомогою керуючого регістру CR4 (20-й біт). Установка даного біта змінює вплив прапора U / S на доступ до сторінок пам'яті. При спробі виконання коду, розташованого на користувацької сторінці, в привілейованому режимі апаратно генерується помилка сторінки (page fault) в результаті порушення прав доступу (права доступу описані в главі 4.6 томи 3 [1]). Як видно, SMEP генерує не виняток загального порушення захисту (# GP), але помилку сторінки (# PF). Таким чином, ОС повинна обробити порушення механізму SMEP в обробнику помилок сторінок. Ця деталь нам знадобиться надалі при аналізі програмної підтримки механізму SMEP.
Контролюючі регістри
Контролюючі регістри
WP захист від запису (біт 16 з CR0) - Коли встановленій, пригнічує процедуру Супервізора від написання на сторінках читання, коли пустий, дозволяє процедурі Супервізор запис в доступні тільки для читання сторінки (незалежно від того, біту U / S налаштування). Цей прапор сприяє здійсненню методу copy-onwrite, створення нового процесу (розгалуження), використовуючи операційні системи, таких як UNIX.
Режим вибору сторінок
Включення і зміна режиму підкачки сторінок
Свопінг модифікатори
CR0.WP дозволяє сторінкам бути захищеними від запису в режимі supervisor. Якщо CR0.WP = 0, в режимі супервізора доступ дозволяється лінійній адресації тільки для читання прав доступу, якщо CR0.WP = 1, їх немає. (У режимі користувача доступ для запису не надається лінійна адресація, тільки для читання прав доступу, незалежно від значення CR0.WP.).
CR4.SMEP дозволяє сторінкам бути захищеними від отримання інструкцій в режимі supervisor. Якщо CR4.SMEP = 1, програмне забезпечення працює в режимі супервізора не може отримати інструкції від лінійної адресації, яка доступна в режимі користувача.
Перелік особливостей свопінгу в CPUID
SMEP:
в режимі супервізора
Якщо CPUID (EAX
= 07h, ECX = 0H). EBX.SMEP [біт 7] = 1, CR4.SMEP може бути
встановлений в 1, що дозволяє в режимі
супервізора запобіганню
Обробка винятків та переривань
ПРОГРАМНА ПІДТРИМКА ТЕХНОЛОГІЇ SMEP
Підтримка SMEP може бути визначена за допомогою інструкції "cpuid". Результат виконання запиту "cpuid" для рівня 7 з підрівнем 0 (вхідні параметри EAX = 7, ECX = 0) вказує на підтримку SMEP на даному процесорі - для цього необхідно перевірити 7-й біт регістра EBX. 64-розрядна версія Windows 8 перевіряє підтримку SMEP при ініціалізації завантажувальних структур, заповнюючи змінну "KeFeatureBits":
KiSystemStartup () → KiInitializeBootStructures () → KiSetFeatureBits ()
Те ж саме відбувається в x86 версії Windows 8:
KiSystemStartup () → KiInitializeKernel () → KiGetFeatureBits ()
Змінна "KeFeatureBits" в подальшому використовується при обробці помилок сторінок. Якщо процесор підтримує технологію SMEP, ОС включає її, встановлюючи 20-й біт регістра CR4. На x86 версії вона включається також під час старту системи, в фазі 1 у функції KiInitMachineDependent () і потім ініціалізується для кожного ядра процесора, ініціюючи міжпроцесорних переривання, яке в підсумку викликає функцію KiConfigureDynamicProcessor (). Те ж саме відбувається на x64 версії ОС, за винятком того, що в ній відсутня функція
KiInitMachineDependent
(). Таким чином, включення SMEP і ініціалізація
змінної "KeFeatureBits" відбувається при
старті системи. Іншою частиною програмної
підтримки SMEP є код обробника помилок
сторінок. У Windows 8 була додана нова функція
- MI_CHECK_KERNEL_NOEXECUTE_
"ATTEMPTED_EXECUTE_OF_
KiTrap0E () / KiPageFault () → MmAccessFault () → ... →
→
MI_CHECK_KERNEL_NOEXECUTE_
Дана функція реалізована тільки в Windows 8.
СПОСОБИ ОБХОДУ SMEP НА ОС WINDOWS І ПРОТИДІЯ ЙОМУ
Логічно припустити, що якщо не можна зберігати шелл-коду в користувальницькому адресному просторі, необхідно знайти спосіб його впровадження в простір ядра. Найбільш очевидним рішенням в даному випадку є використання об'єктів Windows, таких як WinAPI (таймери, події, секції і т.д.) або GDI (контексти пристроїв, палітри і т.д.). Доступ до них здійснюється непрямим чином через функції WinAPI, які в свою чергу використовують системні виклики. Суть в тому, що тіло об'єкту зберігається в пам'яті ядра, а його поля можуть бути змінені в режимі користувача. Таким чином, атакуючий здатний передати необхідні байти шелл-коду з простору користувача в простір ядра. Також очевидно, що атакуючому необхідно знати, де саме в просторі ядра знаходиться тіло використовуваного ним об'єкта. Для цього необхідний метод розкриття інформації про просторі ядра, оскільки, як ми пам'ятаємо, користувальницькому додатком недоступні страніципамяті ядра, в тому числі і для читання. Такі методи існують в ОС Windows [2].
З описаного вище випливає, що теоретично можливо обійти SMEP завдяки розкриттю інформації про просторі ядра в ОС Windows. Однак SMEP доповнюється таким механізмом захисту, як використання пулів, помічених як неісполняемимі, для виділення пам'яті для об'єктів в Windows 8. У рамках даної роботи були перевірені на придатність для впровадження шелл-коду в простір ядра різні об'єкти Windows. Об'єкти WinAPI зберігаються в підкачувати і неподкачіваемом пулах. Об'єкти GDI зберігаються в підкачувати пулі сесії (session pool). Всі вони є неісполняемимі в Windows 8. Більш того, відповідно до результатом сканування таблиць сторінок кількість використовуються сторінок з виконуваних пулів тепер вкрай мало. Всі буфери даних тепер є неісполняемимі. Більшість виконуваних сторінок (наприклад, образи драйверів) недоступні для запису.
Недолік конфігурації
Як згадувалося вище, всі об'єкти в Windows 8 тепер зберігаються в невиконуваних пулах. Це твердження справедливе для х64 версії і частково для х86 версії ОС. Недоліком є пул сесії. Він позначений як виконуваний на x86 версії Windows 8. Отже, можна використовувати відповідний об'єкт GDI для зберігання шелл-коду в пам'яті ядра. Найбільш підходящим об'єктом для цієї мети є GDI Palette - об'єкт палітри. Він створюється за допомогою функції CreatePalette () і відповідної заповненої структури LOGPALETTE. Дана структура містить в собі масив структур PALETTEENTRY, які визначають кольори і їх використання в логічній палітрі [5]. Сенс у тому, що на відміну від інших об'єктів GDI при створенні палітри немає валідації на вміст масиву кольорів. Атакуючий може зберігати будь-які кольори в своїй палітрі. Таким же чином він може зберігати байти шелл-коду. Адреса тіла об'єкта палітри може бути отриманий за допомогою розділяється таблиці GDI. Вміст палітри зберігається по деякому зміщенню (в нашому випадку 0x54). Однак даний зсув знати не обов'язково, оскільки шелл-код можна зберігати де-небудь після заповнення палітри інструкціями NOP. Схема обходу SMEP представлена на малюнку 1.
Малюнок 1. Схема обходу SMEP на x86 версії Windows 8
Об'єкт палітри надає достатню кількість байт для зберігання об'ємного шелл-коду. Однак насправді все, що потрібно атакуючому, це відключити SMEP. Це можна зробити простим скиданням 20-го біта керуючого регістру CR4, після чого атакуючий отримає можливість виконання коду з користувальницького буфера вже без будь-яких обмежень на размер.Разумеется, при використанні пулу сесії існують деякі обмеження. По-перше, він є підкачувати, отже, необхідно враховувати рівень запиту на переривання (IRQL) при експлуатації уразливості режиму ядра. По-друге, пул сесії проектується відповідно до поточної користувальницької сесією, значить, також необхідно враховувати поточну сесію. І по-третє, в багатопроцесорної середовищі керуючі регістри присутні на кожному ядрі, отже, необхідно використовувати прив'язку потоку до ядра для відключення SMEP на конкретному ядрі процесора.
Практична реалізація
Наприклад, коли ми відкриваємо файл функцією CreateFile (), ми отримуємо дескриптор відкритого файлу. Якщо додатком потрібно вважати пару байт цього файлу в буфер, то ми викликаємо функцію ReadFile (), яка за допомогою системного виклику передає управління в ядро ОС, де за таблицею описувачів знаходить потрібний об'єкт файлу. В даному випадку об'єкт має тип _FILE_OBJECT, і змінним полем в ньому є ім'я файлу. Тобто теоретично можна створити файл з ім'ям "xBAADC0DE", яке буде містити наш шелл-код. Потім ми експлуатуємо якусь уразливість режиму ядра і передаємо управління на наш шелл-код.
0: kd> dt nt! _FILE_OBJECT
+0 × 000 Type: Int2B
+0 × 002 Size: Int2B
...
+0 × 050 Flags: Uint4B
+0 × 058 FileName: _UNICODE_STRING
+0 × 068 CurrentByteOffset: _LARGE_INTEGER
...
+0 X0c0 IrpList: _LIST_ENTRY
+0 X0d0 FileObjectExtension: Ptr64 Void
Успіх? Поки ще не зовсім. Справа в тому, що SMEP на Windows 8 доповнюється іншим механізмом захисту. Незважаючи на те, що код розташований на сторінці режиму ядра, ця сторінка має позначку (біт NX) про те, що вона не виконувана, тобто на цій сторінці не може виконуватися код! Виходить, що об'єкти Windows захищені від виконання, отже, теж не підходять для зберігання шелл-коду. Це твердження вірне для х64 версії Windows 8. Однак в x86 версії тіла графічних об'єктів розташовуються у виконуваній пам'яті!
Найбільш підходящим об'єктом для доставки шелл-коду виявилася палітра. Створюється вона за допомогою функції CreatePalette () і структури LOGPALETTE, вміст якої і наповнюється шелл-кодом. Ще б пак, як валідувати кольору в палітрі? Адже в нашій палітрі будуть саме ті кольори, які ми захочемо! А ми захочемо багато байт NOP (0 × 90), і багато байт шелл-коду. Ось така виходить «зла» палітра ...
Разом маємо схему обходу SMEP на Windows 8 x86:
1. Створюємо «злу» структуру LOGPALETTE, наповнюючи її шелл-кодом.
2.
Створюємо палітру через
3.
Знаходимо адресу об'єкта
4.
Передаємо управління по
5. PROFIT!
х64
Обхід SMEP на Windows 8 x64. SMEP на x64 обходиться
за допомогою зворотно-
Звичайно, можливості атакуючого при
складанні корисного
HvlEndSystemInterrupt ():
...
pop rax
pop rcx
retn
KiConfigureDynamicProcessor ():
...
mov cr4, rax
add rsp, 28h
retn
/ / ROP chain to refresh cr4 value
/ / VTrash vROPChain
DWORD_PTR dwRopStack [7 + 10] = {0};
/ / HvlEndSystemInterrupt gadget
dwRopStack [7 + 0] = dwKernelBase + HvlGadgetOffset;
/ / New CR4 value
dwRopStack [7 + 1] = 0x00000000000506F8;
/ / KiConfigureDynamicProcessor
dwRopStack [7 + 3] = dwKernelBase + Cr4GadgetOffset;
/ / Out address (shellcode)
dwRopStack [7 + 9] = (DWORD_PTR) pTestBuf;
Інші напрямки атак для обходу SMEP
Як згадувалося вище, зворотно-орієнтоване програмування може успішно використовуватися для обходу засобів захисту SMEP, оскільки в даному варіанті необов'язково зберігати підготовлений заздалегідь шелл-код. Замість цього можна використовувати фрагменти коду, які вже зберігаються в пам'яті ядра (наприклад, драйвера). Також існує можливість експлуатації драйверів сторонніх виробників, які поки не використовують невиконуємі пули для зберігання даних.
ВИСНОВОК
У даному корсовому проекті був описаний принцип роботи технології Intel SMEP і її програмна підтримка в Windows 8. Також був показаний варіант обходу даної технології в певних випадках зважаючи на можливість розкриття інформації про адресний простір ОС і часткового застосування механізмів захисту. Тим не менш, в тому вигляді, в якому реалізована підтримка SMEP на x64 версіях Windows 8, вона може вважатися достатньо надійною та здатною запобігти різні атаки з використанням вразливостей режиму ядра.
ВИКОРИСТАНА ЛІТАРЕТУРА ТА РЕСУРСИ
- [1] Intel: Intel® 64 and IA-32 Architectures Developer's Manual: Combined Volumes. Intel Corporation, 2012.
- [2] Mateusz “j00ru” Jurczyk: Windows Security Hardening Through Kernel Address Protection.
http://j00ru.vexillium.org/
- [3] Mateusz
“j00ru” Jurczyk, Gynvael Coldwind: SMEP: What is it, and how
to beat it on Windows. http://j00ru.vexillium.org/?p=
783 - [4] Ken Johnson, Matt Miller: Exploit Mitigation Improvements in Windows 8. Slides, Black Hat USA, 2012.
- [5] MSDN: Windows GDI.
http://msdn.microsoft.com/
- [6] Feng Yuan: Windows Graphics Programming Win32 GDI and DirectDraw®. Prentice Hall PTR, 2000.
- [7] Mark Russinovich, David A. Solomon, Alex Ionescu: Windows® Internals: Including Windows Server 2008 and Windows Vista, Fifth Edition. Microsoft Press, 2009.
- http://lenzfire.com/2011/09/
intel-introduces-smep-for-ivy- bridge-a-new-security-feature- 80649/ Intel Introduces SMEP for Ivy Bridge, A New Security Feature - http://www.pvsm.ru/windows/
15936/print/ Windows 8 – да будет SMEP! - http://www.intel.ua/content/
dam/www/public/us/en/ documents/manuals/64-ia-32- architectures-software- developer-vol-3a-part-1- manual.pdf Intel® 64 and IA-32 Architectures Developer's Manual: Vol. 3A - http://ru.wikipedia.org/wiki/%
D0%9A%D0%BE%D0%BB%D1%8C%D1%86% D0%B0_%D0%B7%D0%B0%D1%89%D0%B8 %D1%82%D1%8B -- Кольца защиты - http://ru.wikipedia.org/wiki/%
D0%A0%D0%B5%D0%B6%D0%B8%D0%BC_ %D1%81%D1%83%D0%BF%D0%B5%D1% 80%D0%B2%D0%B8%D0%B7%D0%BE%D1% 80%D0%B0 -- Режим супервизора - http://ru.wikipedia.org/wiki/
CPUID -- CPUID (CPU Identification) - http://www.ptsecurity.ru/downl
oad/Technology_Overview_Intel_ SMEP_and_partial_bypass_on_Win dows_8.pdf -- Positive Research -- Обзор технологии Intel SMEP и её частичный обход на ОС Windows 8
- Аналіз збалансованості вхідного і вихідного грошового потоку
- Аналіз ЗЕД ВАТ «Дніпрометиз»
- Аналіз зобов’язань комерційного банку
- Аналіз зовнішнього боргу України та шляхи його реструктуризації
- Аналіз зовнішнього середовища підприємства
- Аналіз зовнішнього середовища підприємства
- Аналіз зовнішнього середовища підприємства
- Аналіз залучення позикових коштів
- Аналіз залучення прямих іноземних інвестицій в економіку України
- Аналіз запасів підприємства та їх оптимізація
- Аналіз запасу фінансової стійкості (зони безпеки) підприємства
- Аналіз засобів вираження синтаксичних відносин на прикладі твору Гі де Мопассана «Заповіт»
- Аналіз застосування відеосистем на об’єктах, що охороняються
- Аналіз захищеності контрольованого приміщення від витоку інформації по акустичному каналу
