- Прямий розпил реєстру Windows Зміст статті
- Впроваджується в святая святих системи минаючи стандартні механізми
- INFO
- WWW
- Прямий розпил реєстру Windows
- Впроваджується в святая святих системи минаючи стандартні механізми
- INFO
- WWW
- Прямий розпил реєстру Windows
- Впроваджується в святая святих системи минаючи стандартні механізми
- INFO
- WWW
Прямий розпил реєстру Windows Зміст статті
Впроваджується в святая святих системи минаючи стандартні механізми
Сьогодні ми спробуємо залізти в реєстр Windows з чорного ходу, без використання штатних WinAPI-функцій, для цього призначених. Що нам це дасть в результаті? Можливість писати і читати з реєстру безпосередньо, в обхід обмежень, встановлених розробниками антивірусних рішень!
Забігаючи вперед, відзначу: тема ця цікава, але тут цілий набір серйозних проблем. Хоча хто сказав, що нам це не під силу? 🙂
З точки зору операційної системи Windows, реєстр - це унікальна комора. У цій своєрідно вибудуваної ієрархічної базі даних зберігаються настройки, дані, реєстраційна інформація і інша хрень майже про все в системі, починаючи з програм і закінчуючи налаштуваннями конкретного користувача. У реєстрі зберігається практично все. Незважаючи на те що деякі програми вважають за краще зберігати свої настройки в ini-конфігах (особливо програми, написані для Win 3.11. - Прим. Ред.), Сама Windows всю потрібну інформацію про саму себе зчитує з реєстру. Справедливості заради відзначимо, що в * nix-like операційних системах досі панує система зберігання налаштувань у всіляких конфігах.
Новачків - системних адміністраторів при початку роботи з реєстром старші товариші лякають, що неправильне налаштування і внесення змін до реєстру можуть геть завалити систему з подальшою її перевстановлення. І це дійсно так.
Наприклад, так звані точки відновлення - це копії реєстру. Вони широко застосовуються користувачами при виникненні різних проблем як з операційною системою, так і з програмним і апаратним забезпеченням.
Треба сказати, що 99% інформації про реєстр Windows - це опис основних ключів плюс поради, як з ними працювати. Але як працює з реєстром сама операційна система? І чи зможемо ми емулювати її дії? Давай поміркуємо.
Реєстр - одночасно і сильна і слабка сторона Windows. Сильна сторона реєстру в тому, що для розробників програмного забезпечення відпадає необхідність маніпулювати Туєв хучей конфігов, як це, наприклад, реалізовано в Нікс. Зручний реєстр і для творців COM-компонентів - система автоматично реєструє такий компонент в реєстрі і полегшує завдання щодо його подальшого використання.
Слабкість реєстру в тому, що доступ до модифікації чутливих областей реєстру дозволяє управляти Windows будь-якій програмі, написаної якимось новоявленим малварщіком. Згадай хоча б найвідомішу гілку реєстру Windows, що дозволяє запускати програми на старті ОС :).
Як Windows працює з реєстром
Якщо в Windows 98 реєстр могли лагодити все, кому це спаде на думку, то починаючи з Windows XP доступ до реєстру мають тільки користувачі з обліковим записом адміністратора. У Vista + доступ до реєстру знаходиться під захистом UAC. Воно й зрозуміло.
Треба визнати, що з виходом Win7 концепції безпеки при роботі з реєстром були переглянуті в кращий бік. Наприклад, під захистом знаходиться ключова гілка реєстру HKEY_LOCAL_MACHINE. У загальному випадку спроба щось записати в неї буде перенаправлено в відповідну гілку HKEY_CURRENT_USER для поточного користувача.
Для роботи з реєстром безпосередньо Windows пропонує програмісту цілий набір WinAPI, які повинні бути відомі кожному системному розробнику, - це Reg * -функції, такі як RegOpenKey, RegQueryValue і так далі. В ядрі Win це NtOpenKey, NtQueryValueKey і цілий ряд інших. Описувати їх особливого сенсу немає - всю документацію щодо належного використання цих функцій можна знайти в MSDN.
Тут варто наголосити ось на чому. Антивіруси і проактівкі для контролю за призначеними для користувача діями встановлювали перехоплення на згадані функції, як в ядрі, так і в юзермоде.
З виходом Win7 x64 ситуація змінилася, і я вже про це якось писав. Розробники Windows вирішили відмовитися від можливості перехоплювати потенційно небезпечні функції в ядрі Win. Тепер змінна KeServiceDescriptorTable в x64 більше експортується, та й переписати потрібну ділянку коди не вийде - PatchGuard не дасть. Є, звичайно, садомазохистские рішення по обходу цих обмежень - але там гемора буде більше, ніж профіту. Тим більше що Microsoft пропонує зручні колбек ObRegisterCallbacks для контролю за реєстром.
INFO
Інформації в Мережі про структурах, що описують основні файли реєстру, дуже мало. І майже всі вони англійською. Початкові знання можна знайти тут . Крім цього, добре про реєстр написано в біблії системщика «Внутрішній устрій Windows» від товаришів М. Руссиновича і Д. Соломона.
Але що ж таке реєстр насправді? Якщо заглянути в папку WINDOWSsystem32config, то можна побачити там кілька файлів: system, software, security, SAM і кілька інших.
Це файли реєстру.
Файли реєстру Windows
Однак несправедливо буде говорити про реєстр просто як про якийсь поєднанні файлів, завантажених в пам'ять. Багато що з того, що містить реєстр, носить динамічний характер, тобто ряд значень вираховується на етапі завантаження самої системи, в першу чергу це стосується певних параметрів заліза. Наприклад, такий підрозділ реєстру HKEY_DYN_DATA, дані якого при завантаженні операційної системи розміщуються в оперативній пам'яті і знаходяться там аж до завершення роботи операційної системи. Те ж, до речі, можна сказати і про ключове підрозділі HKEY_LOCAL_MACHINE, який не має свого відповідного файлу на диску, але фактично формується з інших файлів реєстру, таких як software, system і інші.
Таким чином, реєстр зсередини можна дуже приблизно назвати «віртуальним поєднанням файлів реєстру». Після старту системи ці файли знаходяться як у файлі підкачки (paged pool), так і в невивантажуваного пам'яті (nonpaged).
Для того щоб навчитися працювати з реєстром безпосередньо, без знань його внутрішньої структури не обійтися ніяк. В цілому Microsoft ніколи не розкривала таємниці внутрішньої структури файлів, складових реєстр, оскільки це загрожує безпеці. За моїми спостереженнями, все наявні описи файлів реєстру і його структури (а їх, до речі зовсім чуть-чуть) - результати досліджень піонером-дослідників. Найбільш закінчене, на мій погляд, таке «дослідження» можна взяти тут , Належить воно товаришеві Пітеру Норрісу.
Не будемо вдаватися зараз в подробиці організації і структури реєстру, справа це довга й нудна в рамки статті точно не вписується. Тут важливо усвідомити, що реєстр - ієрархічна деревоподібна структура, іноді також кажуть, що вона схожа на бджолині стільники.
Відразу засмучу: запросто пошаманити безпосередньо з реєстром в юзермоде не вийде, система не дасть цього зробити, як це зазвичай буває з файлами, зайнятими іншими процесами. Якщо спробувати викрутитися, то можна тільки прочитати такий «зайнятий» файл, і то якщо вгадати з прапорами, з якими він був відкритий. На жаль, записати в цікавий для нас «файл реєстру» інформації не вийде. До речі, фіча із записом потрібної інформації до реєстру може прокатати, якщо писати в реестровскіе * .BAK-файли, вони точно доступні під запис.
А ось з ядра не те що прочитати, а й записати потрібну інформацію в файли реєстру дуже навіть можна.
Отже, стеж за рукою :).
Перше, що може прийти в твою світлу голову, - відкрити файл реєстру безпосередньо і щось туди записати.
Теоретично так зробити можна, для цього потрібно, по-перше, вміти працювати з «зайнятими» файлами (способи шукай в Мережі) і, по-друге, як я вже говорив вище, треба знати внутрішню структуру файлів реєстру. Метод цей досить сокирний, але, не дивлячись на свою божевільною, він цілком життєздатний, хоча його і важко реалізувати на практиці (спробуй поекспериментувати з ним самостійно).
Тут же я запропоную два способи, які допоможуть тобі розпиляти реєстр на дрібні шматочки.
Перший спосіб полягає в тому, що для конфігураційного менеджера (Configuration Manager, частина операційної системи, якщо ти не в курсі) реєстр є не більше ніж набір строго визначених структур в операційній пам'яті, з якими, як виявляється, дуже навіть легко працювати. Які це структури, запитаєш ти? HBASE_BLOCK, HHIVE, HBIN, HCELL, HMAP_ENTRY, HMAP_DIRECTORY, купа CM_ * структур, які використовуються конфиг-менеджером для управління реєстром. З точки зору операційної системи, реєстр - це просто набір регламентованих структур в оперативній пам'яті. Наприклад, сигнатура «regf», яка визначає «файл реєстру», є заздалегідь певна константа:
define HBASE_BLOCK_SIGNATURE 0x66676572 typedef struct _HBASE_BLOCK {ULONG Signature; // 0x66676572 ULONG Sequence1; ULONG Sequence2; LARGE_INTEGER TimeStamp; ....} 
Тобто сенс всього цього мого монологу в тому, що існує шикарна можливість маніпуляції з реєстром на рівні операційної системи, але при цьому не використовуючи її штатні засоби. Як це можливо? Ми просто семуліруем дії самої операційної системи, точно так, як вона сама працює з реєстром! Важливо, як я вже говорив, зрозуміти, що для самої ОС реєстр не більше ніж набір відповідних структур в пам'яті.
Якщо у нас буде доступ до файлів реєстру на рівні ядра, то чим ми гірші самої ОС, щоб встановити свій порядок?
І тут на сцені з'являється найбільш цікаве питання - як знайти ці самі структури в пам'яті? Вірно, штатних засобів системи для вирішення цього питання немає, тому доведеться викручуватися по-хитрому.
Знаючи, як виглядають структури, потрібно згадати, що кожен файл, вулик реєстру, має свою константну сигнатуру. Наприклад, «regf» - це 0x66676572. Для вулика сигнатура буде дорівнює 0xBEE0BEE0. Маючи доступ до пам'яті з ядра, ми можемо досить легко знайти ці сигнатури в пам'яті, просто просканів її. Ще можна просканіть пам'ять в пошуках сигнатури «CM10» - саме вона присвоюється конфиг-менеджером блоку підкачувати пам'яті, який виділяється під структуру CMHIVE. Вважаю, знайшовши в пам'яті цікавий для нас елемент, ти придумаєш, що робити з ним далі :).
Як, наприклад, змінити значення комірки реєстру? Значення зберігається в поле CM_KEY_VALUE-> Data, тому, якщо у тебе виникне завдання змінити будь-яке поле в конкретному ключі реєстру, шукай значення саме там:
typedef struct _CM_KEY_VALUE {WORD Signature; // #define CM_KEY_VALUE_SIGNATURE 0x6B76 WORD NameLength; ULONG DataLength; ULONG Data; // <---------- дані осередки будуть тут ULONG Type; WORD Flags; WORD Spare; WCHAR Name [1]; } CM_KEY_VALUE, * PCM_KEY_VALUE;
Другий варіант є своєрідною модифікацією першого. Якщо знаєш, існує одна особливість при роботі з реєстром - все зміни, тобто «створення нових ключів / запис / видалення ключів», як правило, вступають в силу після перезавантаження системи (ну або після перезавантаження експлорера, це такий хак-метод). До цього всі зміни знаходяться немов у підвішеному, «dirty» -стан. Мало того, система при поводженні з реєстром спілкується з ним через кеш файлової системи. Це зрозуміло - звернень до реєстру може бути сотні в секунду, відповідно, покладатися при цьому на швидкодію файлової системи нерозумно, тут ніяке швидкодію не врятує. Тому система і працює з реєстром, що називається, віртуально, через кеш файлової системи. І тут, щоб витягнути кишки реєстру на світло, треба залізти в кеш! Як це робиться, вже описувалося в тирнета, в тому числі і в www.xakep.ru .
Що сказати в підсумку? Запропонована читачеві в статті варіація на тему прямого контролю за реєстром носить виключно експериментальний характер. Не спорю, вона важкувата для практичної реалізації, і багато хто скаже, що вже краще використовувати нормальні WinAPI-функції, призначені для роботи з реєстром, - і будуть в чомусь мають рацію. Однак реалізована die_hard на ділі Ліба, заснована на наведених в статті принципах, буде мати воістину термоядерної силою, непідвладною ні АВЕР, ні самій операційній системі.
Потім того закінчу. Вдалого компілювання і щоб із тобою Сила!
WWW
Обов'язкова до прочитання стаття Марка Руссиновича про реєстр «Inside the Registry», знайшовся навіть російський переклад . Чудова тулза для збору інформації про реєстр: http://goo.gl/iSSVy .
Олександр Еккерт, [email protected]
Прямий розпил реєстру Windows
Зміст статті
Впроваджується в святая святих системи минаючи стандартні механізми
Сьогодні ми спробуємо залізти в реєстр Windows з чорного ходу, без використання штатних WinAPI-функцій, для цього призначених. Що нам це дасть в результаті? Можливість писати і читати з реєстру безпосередньо, в обхід обмежень, встановлених розробниками антивірусних рішень!
Забігаючи вперед, відзначу: тема ця цікава, але тут цілий набір серйозних проблем. Хоча хто сказав, що нам це не під силу? 🙂
З точки зору операційної системи Windows, реєстр - це унікальна комора. У цій своєрідно вибудуваної ієрархічної базі даних зберігаються настройки, дані, реєстраційна інформація і інша хрень майже про все в системі, починаючи з програм і закінчуючи налаштуваннями конкретного користувача. У реєстрі зберігається практично все. Незважаючи на те що деякі програми вважають за краще зберігати свої настройки в ini-конфігах (особливо програми, написані для Win 3.11. - Прим. Ред.), Сама Windows всю потрібну інформацію про саму себе зчитує з реєстру. Справедливості заради відзначимо, що в * nix-like операційних системах досі панує система зберігання налаштувань у всіляких конфігах.
Новачків - системних адміністраторів при початку роботи з реєстром старші товариші лякають, що неправильне налаштування і внесення змін до реєстру можуть геть завалити систему з подальшою її перевстановлення. І це дійсно так.
Наприклад, так звані точки відновлення - це копії реєстру. Вони широко застосовуються користувачами при виникненні різних проблем як з операційною системою, так і з програмним і апаратним забезпеченням.
Треба сказати, що 99% інформації про реєстр Windows - це опис основних ключів плюс поради, як з ними працювати. Але як працює з реєстром сама операційна система? І чи зможемо ми емулювати її дії? Давай поміркуємо.
Реєстр - одночасно і сильна і слабка сторона Windows. Сильна сторона реєстру в тому, що для розробників програмного забезпечення відпадає необхідність маніпулювати Туєв хучей конфігов, як це, наприклад, реалізовано в Нікс. Зручний реєстр і для творців COM-компонентів - система автоматично реєструє такий компонент в реєстрі і полегшує завдання щодо його подальшого використання.
Слабкість реєстру в тому, що доступ до модифікації чутливих областей реєстру дозволяє управляти Windows будь-якій програмі, написаної якимось новоявленим малварщіком. Згадай хоча б найвідомішу гілку реєстру Windows, що дозволяє запускати програми на старті ОС :).
Як Windows працює з реєстром
Якщо в Windows 98 реєстр могли лагодити все, кому це спаде на думку, то починаючи з Windows XP доступ до реєстру мають тільки користувачі з обліковим записом адміністратора. У Vista + доступ до реєстру знаходиться під захистом UAC. Воно й зрозуміло.
Треба визнати, що з виходом Win7 концепції безпеки при роботі з реєстром були переглянуті в кращий бік. Наприклад, під захистом знаходиться ключова гілка реєстру HKEY_LOCAL_MACHINE. У загальному випадку спроба щось записати в неї буде перенаправлено в відповідну гілку HKEY_CURRENT_USER для поточного користувача.
Для роботи з реєстром безпосередньо Windows пропонує програмісту цілий набір WinAPI, які повинні бути відомі кожному системному розробнику, - це Reg * -функції, такі як RegOpenKey, RegQueryValue і так далі. В ядрі Win це NtOpenKey, NtQueryValueKey і цілий ряд інших. Описувати їх особливого сенсу немає - всю документацію щодо належного використання цих функцій можна знайти в MSDN.
Тут варто наголосити ось на чому. Антивіруси і проактівкі для контролю за призначеними для користувача діями встановлювали перехоплення на згадані функції, як в ядрі, так і в юзермоде.
З виходом Win7 x64 ситуація змінилася, і я вже про це якось писав. Розробники Windows вирішили відмовитися від можливості перехоплювати потенційно небезпечні функції в ядрі Win. Тепер змінна KeServiceDescriptorTable в x64 більше експортується, та й переписати потрібну ділянку коди не вийде - PatchGuard не дасть. Є, звичайно, садомазохистские рішення по обходу цих обмежень - але там гемора буде більше, ніж профіту. Тим більше що Microsoft пропонує зручні колбек ObRegisterCallbacks для контролю за реєстром.
INFO
Інформації в Мережі про структурах, що описують основні файли реєстру, дуже мало. І майже всі вони англійською. Початкові знання можна знайти тут . Крім цього, добре про реєстр написано в біблії системщика «Внутрішній устрій Windows» від товаришів М. Руссиновича і Д. Соломона.
Але що ж таке реєстр насправді? Якщо заглянути в папку WINDOWSsystem32config, то можна побачити там кілька файлів: system, software, security, SAM і кілька інших.
Це файли реєстру.
Файли реєстру Windows
Однак несправедливо буде говорити про реєстр просто як про якийсь поєднанні файлів, завантажених в пам'ять. Багато що з того, що містить реєстр, носить динамічний характер, тобто ряд значень вираховується на етапі завантаження самої системи, в першу чергу це стосується певних параметрів заліза. Наприклад, такий підрозділ реєстру HKEY_DYN_DATA, дані якого при завантаженні операційної системи розміщуються в оперативній пам'яті і знаходяться там аж до завершення роботи операційної системи. Те ж, до речі, можна сказати і про ключове підрозділі HKEY_LOCAL_MACHINE, який не має свого відповідного файлу на диску, але фактично формується з інших файлів реєстру, таких як software, system і інші.
Таким чином, реєстр зсередини можна дуже приблизно назвати «віртуальним поєднанням файлів реєстру». Після старту системи ці файли знаходяться як у файлі підкачки (paged pool), так і в невивантажуваного пам'яті (nonpaged).
Для того щоб навчитися працювати з реєстром безпосередньо, без знань його внутрішньої структури не обійтися ніяк. В цілому Microsoft ніколи не розкривала таємниці внутрішньої структури файлів, складових реєстр, оскільки це загрожує безпеці. За моїми спостереженнями, все наявні описи файлів реєстру і його структури (а їх, до речі зовсім чуть-чуть) - результати досліджень піонером-дослідників. Найбільш закінчене, на мій погляд, таке «дослідження» можна взяти тут , Належить воно товаришеві Пітеру Норрісу.
Не будемо вдаватися зараз в подробиці організації і структури реєстру, справа це довга й нудна в рамки статті точно не вписується. Тут важливо усвідомити, що реєстр - ієрархічна деревоподібна структура, іноді також кажуть, що вона схожа на бджолині стільники.
Відразу засмучу: запросто пошаманити безпосередньо з реєстром в юзермоде не вийде, система не дасть цього зробити, як це зазвичай буває з файлами, зайнятими іншими процесами. Якщо спробувати викрутитися, то можна тільки прочитати такий «зайнятий» файл, і то якщо вгадати з прапорами, з якими він був відкритий. На жаль, записати в цікавий для нас «файл реєстру» інформації не вийде. До речі, фіча із записом потрібної інформації до реєстру може прокатати, якщо писати в реестровскіе * .BAK-файли, вони точно доступні під запис.
А ось з ядра не те що прочитати, а й записати потрібну інформацію в файли реєстру дуже навіть можна.
Отже, стеж за рукою :).
Перше, що може прийти в твою світлу голову, - відкрити файл реєстру безпосередньо і щось туди записати.
Теоретично так зробити можна, для цього потрібно, по-перше, вміти працювати з «зайнятими» файлами (способи шукай в Мережі) і, по-друге, як я вже говорив вище, треба знати внутрішню структуру файлів реєстру. Метод цей досить сокирний, але, не дивлячись на свою божевільною, він цілком життєздатний, хоча його і важко реалізувати на практиці (спробуй поекспериментувати з ним самостійно).
Тут же я запропоную два способи, які допоможуть тобі розпиляти реєстр на дрібні шматочки.
Перший спосіб полягає в тому, що для конфігураційного менеджера (Configuration Manager, частина операційної системи, якщо ти не в курсі) реєстр є не більше ніж набір строго визначених структур в операційній пам'яті, з якими, як виявляється, дуже навіть легко працювати. Які це структури, запитаєш ти? HBASE_BLOCK, HHIVE, HBIN, HCELL, HMAP_ENTRY, HMAP_DIRECTORY, купа CM_ * структур, які використовуються конфиг-менеджером для управління реєстром. З точки зору операційної системи, реєстр - це просто набір регламентованих структур в оперативній пам'яті. Наприклад, сигнатура «regf», яка визначає «файл реєстру», є заздалегідь певна константа:
define HBASE_BLOCK_SIGNATURE 0x66676572 typedef struct _HBASE_BLOCK {ULONG Signature; // 0x66676572 ULONG Sequence1; ULONG Sequence2; LARGE_INTEGER TimeStamp; ....}
Тобто сенс всього цього мого монологу в тому, що існує шикарна можливість маніпуляції з реєстром на рівні операційної системи, але при цьому не використовуючи її штатні засоби. Як це можливо? Ми просто семуліруем дії самої операційної системи, точно так, як вона сама працює з реєстром! Важливо, як я вже говорив, зрозуміти, що для самої ОС реєстр не більше ніж набір відповідних структур в пам'яті.
Якщо у нас буде доступ до файлів реєстру на рівні ядра, то чим ми гірші самої ОС, щоб встановити свій порядок?
І тут на сцені з'являється найбільш цікаве питання - як знайти ці самі структури в пам'яті? Вірно, штатних засобів системи для вирішення цього питання немає, тому доведеться викручуватися по-хитрому.
Знаючи, як виглядають структури, потрібно згадати, що кожен файл, вулик реєстру, має свою константну сигнатуру. Наприклад, «regf» - це 0x66676572. Для вулика сигнатура буде дорівнює 0xBEE0BEE0. Маючи доступ до пам'яті з ядра, ми можемо досить легко знайти ці сигнатури в пам'яті, просто просканів її. Ще можна просканіть пам'ять в пошуках сигнатури «CM10» - саме вона присвоюється конфиг-менеджером блоку підкачувати пам'яті, який виділяється під структуру CMHIVE. Вважаю, знайшовши в пам'яті цікавий для нас елемент, ти придумаєш, що робити з ним далі :).
Як, наприклад, змінити значення комірки реєстру? Значення зберігається в поле CM_KEY_VALUE-> Data, тому, якщо у тебе виникне завдання змінити будь-яке поле в конкретному ключі реєстру, шукай значення саме там:
typedef struct _CM_KEY_VALUE {WORD Signature; // #define CM_KEY_VALUE_SIGNATURE 0x6B76 WORD NameLength; ULONG DataLength; ULONG Data; // <---------- дані осередки будуть тут ULONG Type; WORD Flags; WORD Spare; WCHAR Name [1]; } CM_KEY_VALUE, * PCM_KEY_VALUE;
Другий варіант є своєрідною модифікацією першого. Якщо знаєш, існує одна особливість при роботі з реєстром - все зміни, тобто «створення нових ключів / запис / видалення ключів», як правило, вступають в силу після перезавантаження системи (ну або після перезавантаження експлорера, це такий хак-метод). До цього всі зміни знаходяться немов у підвішеному, «dirty» -стан. Мало того, система при поводженні з реєстром спілкується з ним через кеш файлової системи. Це зрозуміло - звернень до реєстру може бути сотні в секунду, відповідно, покладатися при цьому на швидкодію файлової системи нерозумно, тут ніяке швидкодію не врятує. Тому система і працює з реєстром, що називається, віртуально, через кеш файлової системи. І тут, щоб витягнути кишки реєстру на світло, треба залізти в кеш! Як це робиться, вже описувалося в тирнета, в тому числі і в www.xakep.ru .
Що сказати в підсумку? Запропонована читачеві в статті варіація на тему прямого контролю за реєстром носить виключно експериментальний характер. Не спорю, вона важкувата для практичної реалізації, і багато хто скаже, що вже краще використовувати нормальні WinAPI-функції, призначені для роботи з реєстром, - і будуть в чомусь мають рацію. Однак реалізована die_hard на ділі Ліба, заснована на наведених в статті принципах, буде мати воістину термоядерної силою, непідвладною ні АВЕР, ні самій операційній системі.
Потім того закінчу. Вдалого компілювання і щоб із тобою Сила!
WWW
Обов'язкова до прочитання стаття Марка Руссиновича про реєстр «Inside the Registry», знайшовся навіть російський переклад . Чудова тулза для збору інформації про реєстр: http://goo.gl/iSSVy .
Олександр Еккерт, [email protected]
Прямий розпил реєстру Windows
Зміст статті
Впроваджується в святая святих системи минаючи стандартні механізми
Сьогодні ми спробуємо залізти в реєстр Windows з чорного ходу, без використання штатних WinAPI-функцій, для цього призначених. Що нам це дасть в результаті? Можливість писати і читати з реєстру безпосередньо, в обхід обмежень, встановлених розробниками антивірусних рішень!
Забігаючи вперед, відзначу: тема ця цікава, але тут цілий набір серйозних проблем. Хоча хто сказав, що нам це не під силу? 🙂
З точки зору операційної системи Windows, реєстр - це унікальна комора. У цій своєрідно вибудуваної ієрархічної базі даних зберігаються настройки, дані, реєстраційна інформація і інша хрень майже про все в системі, починаючи з програм і закінчуючи налаштуваннями конкретного користувача. У реєстрі зберігається практично все. Незважаючи на те що деякі програми вважають за краще зберігати свої настройки в ini-конфігах (особливо програми, написані для Win 3.11. - Прим. Ред.), Сама Windows всю потрібну інформацію про саму себе зчитує з реєстру. Справедливості заради відзначимо, що в * nix-like операційних системах досі панує система зберігання налаштувань у всіляких конфігах.
Новачків - системних адміністраторів при початку роботи з реєстром старші товариші лякають, що неправильне налаштування і внесення змін до реєстру можуть геть завалити систему з подальшою її перевстановлення. І це дійсно так.
Наприклад, так звані точки відновлення - це копії реєстру. Вони широко застосовуються користувачами при виникненні різних проблем як з операційною системою, так і з програмним і апаратним забезпеченням.
Треба сказати, що 99% інформації про реєстр Windows - це опис основних ключів плюс поради, як з ними працювати. Але як працює з реєстром сама операційна система? І чи зможемо ми емулювати її дії? Давай поміркуємо.
Реєстр - одночасно і сильна і слабка сторона Windows. Сильна сторона реєстру в тому, що для розробників програмного забезпечення відпадає необхідність маніпулювати Туєв хучей конфігов, як це, наприклад, реалізовано в Нікс. Зручний реєстр і для творців COM-компонентів - система автоматично реєструє такий компонент в реєстрі і полегшує завдання щодо його подальшого використання.
Слабкість реєстру в тому, що доступ до модифікації чутливих областей реєстру дозволяє управляти Windows будь-якій програмі, написаної якимось новоявленим малварщіком. Згадай хоча б найвідомішу гілку реєстру Windows, що дозволяє запускати програми на старті ОС :).
Як Windows працює з реєстром
Якщо в Windows 98 реєстр могли лагодити все, кому це спаде на думку, то починаючи з Windows XP доступ до реєстру мають тільки користувачі з обліковим записом адміністратора. У Vista + доступ до реєстру знаходиться під захистом UAC. Воно й зрозуміло.
Треба визнати, що з виходом Win7 концепції безпеки при роботі з реєстром були переглянуті в кращий бік. Наприклад, під захистом знаходиться ключова гілка реєстру HKEY_LOCAL_MACHINE. У загальному випадку спроба щось записати в неї буде перенаправлено в відповідну гілку HKEY_CURRENT_USER для поточного користувача.
Для роботи з реєстром безпосередньо Windows пропонує програмісту цілий набір WinAPI, які повинні бути відомі кожному системному розробнику, - це Reg * -функції, такі як RegOpenKey, RegQueryValue і так далі. В ядрі Win це NtOpenKey, NtQueryValueKey і цілий ряд інших. Описувати їх особливого сенсу немає - всю документацію щодо належного використання цих функцій можна знайти в MSDN.
Тут варто наголосити ось на чому. Антивіруси і проактівкі для контролю за призначеними для користувача діями встановлювали перехоплення на згадані функції, як в ядрі, так і в юзермоде.
З виходом Win7 x64 ситуація змінилася, і я вже про це якось писав. Розробники Windows вирішили відмовитися від можливості перехоплювати потенційно небезпечні функції в ядрі Win. Тепер змінна KeServiceDescriptorTable в x64 більше експортується, та й переписати потрібну ділянку коди не вийде - PatchGuard не дасть. Є, звичайно, садомазохистские рішення по обходу цих обмежень - але там гемора буде більше, ніж профіту. Тим більше що Microsoft пропонує зручні колбек ObRegisterCallbacks для контролю за реєстром.
INFO
Інформації в Мережі про структурах, що описують основні файли реєстру, дуже мало. І майже всі вони англійською. Початкові знання можна знайти тут . Крім цього, добре про реєстр написано в біблії системщика «Внутрішній устрій Windows» від товаришів М. Руссиновича і Д. Соломона.
Але що ж таке реєстр насправді? Якщо заглянути в папку WINDOWSsystem32config, то можна побачити там кілька файлів: system, software, security, SAM і кілька інших.
Це файли реєстру.
Файли реєстру Windows
Однак несправедливо буде говорити про реєстр просто як про якийсь поєднанні файлів, завантажених в пам'ять. Багато що з того, що містить реєстр, носить динамічний характер, тобто ряд значень вираховується на етапі завантаження самої системи, в першу чергу це стосується певних параметрів заліза. Наприклад, такий підрозділ реєстру HKEY_DYN_DATA, дані якого при завантаженні операційної системи розміщуються в оперативній пам'яті і знаходяться там аж до завершення роботи операційної системи. Те ж, до речі, можна сказати і про ключове підрозділі HKEY_LOCAL_MACHINE, який не має свого відповідного файлу на диску, але фактично формується з інших файлів реєстру, таких як software, system і інші.
Таким чином, реєстр зсередини можна дуже приблизно назвати «віртуальним поєднанням файлів реєстру». Після старту системи ці файли знаходяться як у файлі підкачки (paged pool), так і в невивантажуваного пам'яті (nonpaged).
Для того щоб навчитися працювати з реєстром безпосередньо, без знань його внутрішньої структури не обійтися ніяк. В цілому Microsoft ніколи не розкривала таємниці внутрішньої структури файлів, складових реєстр, оскільки це загрожує безпеці. За моїми спостереженнями, все наявні описи файлів реєстру і його структури (а їх, до речі зовсім чуть-чуть) - результати досліджень піонером-дослідників. Найбільш закінчене, на мій погляд, таке «дослідження» можна взяти тут , Належить воно товаришеві Пітеру Норрісу.
Не будемо вдаватися зараз в подробиці організації і структури реєстру, справа це довга й нудна в рамки статті точно не вписується. Тут важливо усвідомити, що реєстр - ієрархічна деревоподібна структура, іноді також кажуть, що вона схожа на бджолині стільники.
Відразу засмучу: запросто пошаманити безпосередньо з реєстром в юзермоде не вийде, система не дасть цього зробити, як це зазвичай буває з файлами, зайнятими іншими процесами. Якщо спробувати викрутитися, то можна тільки прочитати такий «зайнятий» файл, і то якщо вгадати з прапорами, з якими він був відкритий. На жаль, записати в цікавий для нас «файл реєстру» інформації не вийде. До речі, фіча із записом потрібної інформації до реєстру може прокатати, якщо писати в реестровскіе * .BAK-файли, вони точно доступні під запис.
А ось з ядра не те що прочитати, а й записати потрібну інформацію в файли реєстру дуже навіть можна.
Отже, стеж за рукою :).
Перше, що може прийти в твою світлу голову, - відкрити файл реєстру безпосередньо і щось туди записати.
Теоретично так зробити можна, для цього потрібно, по-перше, вміти працювати з «зайнятими» файлами (способи шукай в Мережі) і, по-друге, як я вже говорив вище, треба знати внутрішню структуру файлів реєстру. Метод цей досить сокирний, але, не дивлячись на свою божевільною, він цілком життєздатний, хоча його і важко реалізувати на практиці (спробуй поекспериментувати з ним самостійно).
Тут же я запропоную два способи, які допоможуть тобі розпиляти реєстр на дрібні шматочки.
Перший спосіб полягає в тому, що для конфігураційного менеджера (Configuration Manager, частина операційної системи, якщо ти не в курсі) реєстр є не більше ніж набір строго визначених структур в операційній пам'яті, з якими, як виявляється, дуже навіть легко працювати. Які це структури, запитаєш ти? HBASE_BLOCK, HHIVE, HBIN, HCELL, HMAP_ENTRY, HMAP_DIRECTORY, купа CM_ * структур, які використовуються конфиг-менеджером для управління реєстром. З точки зору операційної системи, реєстр - це просто набір регламентованих структур в оперативній пам'яті. Наприклад, сигнатура «regf», яка визначає «файл реєстру», є заздалегідь певна константа:
define HBASE_BLOCK_SIGNATURE 0x66676572 typedef struct _HBASE_BLOCK {ULONG Signature; // 0x66676572 ULONG Sequence1; ULONG Sequence2; LARGE_INTEGER TimeStamp; ....}
Тобто сенс всього цього мого монологу в тому, що існує шикарна можливість маніпуляції з реєстром на рівні операційної системи, але при цьому не використовуючи її штатні засоби. Як це можливо? Ми просто семуліруем дії самої операційної системи, точно так, як вона сама працює з реєстром! Важливо, як я вже говорив, зрозуміти, що для самої ОС реєстр не більше ніж набір відповідних структур в пам'яті.
Якщо у нас буде доступ до файлів реєстру на рівні ядра, то чим ми гірші самої ОС, щоб встановити свій порядок?
І тут на сцені з'являється найбільш цікаве питання - як знайти ці самі структури в пам'яті? Вірно, штатних засобів системи для вирішення цього питання немає, тому доведеться викручуватися по-хитрому.
Знаючи, як виглядають структури, потрібно згадати, що кожен файл, вулик реєстру, має свою константну сигнатуру. Наприклад, «regf» - це 0x66676572. Для вулика сигнатура буде дорівнює 0xBEE0BEE0. Маючи доступ до пам'яті з ядра, ми можемо досить легко знайти ці сигнатури в пам'яті, просто просканів її. Ще можна просканіть пам'ять в пошуках сигнатури «CM10» - саме вона присвоюється конфиг-менеджером блоку підкачувати пам'яті, який виділяється під структуру CMHIVE. Вважаю, знайшовши в пам'яті цікавий для нас елемент, ти придумаєш, що робити з ним далі :).
Як, наприклад, змінити значення комірки реєстру? Значення зберігається в поле CM_KEY_VALUE-> Data, тому, якщо у тебе виникне завдання змінити будь-яке поле в конкретному ключі реєстру, шукай значення саме там:
typedef struct _CM_KEY_VALUE {WORD Signature; // #define CM_KEY_VALUE_SIGNATURE 0x6B76 WORD NameLength; ULONG DataLength; ULONG Data; // <---------- дані осередки будуть тут ULONG Type; WORD Flags; WORD Spare; WCHAR Name [1]; } CM_KEY_VALUE, * PCM_KEY_VALUE;
Другий варіант є своєрідною модифікацією першого. Якщо знаєш, існує одна особливість при роботі з реєстром - все зміни, тобто «створення нових ключів / запис / видалення ключів», як правило, вступають в силу після перезавантаження системи (ну або після перезавантаження експлорера, це такий хак-метод). До цього всі зміни знаходяться немов у підвішеному, «dirty» -стан. Мало того, система при поводженні з реєстром спілкується з ним через кеш файлової системи. Це зрозуміло - звернень до реєстру може бути сотні в секунду, відповідно, покладатися при цьому на швидкодію файлової системи нерозумно, тут ніяке швидкодію не врятує. Тому система і працює з реєстром, що називається, віртуально, через кеш файлової системи. І тут, щоб витягнути кишки реєстру на світло, треба залізти в кеш! Як це робиться, вже описувалося в тирнета, в тому числі і в www.xakep.ru .
Що сказати в підсумку? Запропонована читачеві в статті варіація на тему прямого контролю за реєстром носить виключно експериментальний характер. Не спорю, вона важкувата для практичної реалізації, і багато хто скаже, що вже краще використовувати нормальні WinAPI-функції, призначені для роботи з реєстром, - і будуть в чомусь мають рацію. Однак реалізована die_hard на ділі Ліба, заснована на наведених в статті принципах, буде мати воістину термоядерної силою, непідвладною ні АВЕР, ні самій операційній системі.
Потім того закінчу. Вдалого компілювання і щоб із тобою Сила!
WWW
Обов'язкова до прочитання стаття Марка Руссиновича про реєстр «Inside the Registry», знайшовся навіть російський переклад . Чудова тулза для збору інформації про реєстр: http://goo.gl/iSSVy .
Олександр Еккерт, [email protected]
Що нам це дасть в результаті?Хоча хто сказав, що нам це не під силу?
Але як працює з реєстром сама операційна система?
І чи зможемо ми емулювати її дії?
Але що ж таке реєстр насправді?
Які це структури, запитаєш ти?
Як це можливо?
Якщо у нас буде доступ до файлів реєстру на рівні ядра, то чим ми гірші самої ОС, щоб встановити свій порядок?
І тут на сцені з'являється найбільш цікаве питання - як знайти ці самі структури в пам'яті?
Як, наприклад, змінити значення комірки реєстру?
