Прямий розпил реєстру Windows - «Хакер»

  1. Прямий розпил реєстру Windows Зміст статті
  2. Впроваджується в святая святих системи минаючи стандартні механізми
  3. INFO
  4. WWW
  5. Прямий розпил реєстру Windows
  6. Впроваджується в святая святих системи минаючи стандартні механізми
  7. INFO
  8. WWW
  9. Прямий розпил реєстру Windows
  10. Впроваджується в святая святих системи минаючи стандартні механізми
  11. INFO
  12. 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; ....} define HBASE_BLOCK_SIGNATURE 0x66676572 typedef struct _HBASE_BLOCK {ULONG Signature;  // 0x66676572 ULONG Sequence1;  ULONG Sequence2;  LARGE_INTEGER TimeStamp; А ось і сигнатура «regf» ...

Тобто сенс всього цього мого монологу в тому, що існує шикарна можливість маніпуляції з реєстром на рівні операційної системи, але при цьому не використовуючи її штатні засоби. Як це можливо? Ми просто семуліруем дії самої операційної системи, точно так, як вона сама працює з реєстром! Важливо, як я вже говорив, зрозуміти, що для самої ОС реєстр не більше ніж набір відповідних структур в пам'яті.

Якщо у нас буде доступ до файлів реєстру на рівні ядра, то чим ми гірші самої ОС, щоб встановити свій порядок?

І тут на сцені з'являється найбільш цікаве питання - як знайти ці самі структури в пам'яті? Вірно, штатних засобів системи для вирішення цього питання немає, тому доведеться викручуватися по-хитрому.

Знаючи, як виглядають структури, потрібно згадати, що кожен файл, вулик реєстру, має свою константну сигнатуру. Наприклад, «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; ....} define HBASE_BLOCK_SIGNATURE 0x66676572 typedef struct _HBASE_BLOCK {ULONG Signature;  // 0x66676572 ULONG Sequence1;  ULONG Sequence2;  LARGE_INTEGER TimeStamp; А ось і сигнатура «regf» ...

Тобто сенс всього цього мого монологу в тому, що існує шикарна можливість маніпуляції з реєстром на рівні операційної системи, але при цьому не використовуючи її штатні засоби. Як це можливо? Ми просто семуліруем дії самої операційної системи, точно так, як вона сама працює з реєстром! Важливо, як я вже говорив, зрозуміти, що для самої ОС реєстр не більше ніж набір відповідних структур в пам'яті.

Якщо у нас буде доступ до файлів реєстру на рівні ядра, то чим ми гірші самої ОС, щоб встановити свій порядок?

І тут на сцені з'являється найбільш цікаве питання - як знайти ці самі структури в пам'яті? Вірно, штатних засобів системи для вирішення цього питання немає, тому доведеться викручуватися по-хитрому.

Знаючи, як виглядають структури, потрібно згадати, що кожен файл, вулик реєстру, має свою константну сигнатуру. Наприклад, «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; ....} define HBASE_BLOCK_SIGNATURE 0x66676572 typedef struct _HBASE_BLOCK {ULONG Signature;  // 0x66676572 ULONG Sequence1;  ULONG Sequence2;  LARGE_INTEGER TimeStamp; А ось і сигнатура «regf» ...

Тобто сенс всього цього мого монологу в тому, що існує шикарна можливість маніпуляції з реєстром на рівні операційної системи, але при цьому не використовуючи її штатні засоби. Як це можливо? Ми просто семуліруем дії самої операційної системи, точно так, як вона сама працює з реєстром! Важливо, як я вже говорив, зрозуміти, що для самої ОС реєстр не більше ніж набір відповідних структур в пам'яті.

Якщо у нас буде доступ до файлів реєстру на рівні ядра, то чим ми гірші самої ОС, щоб встановити свій порядок?

І тут на сцені з'являється найбільш цікаве питання - як знайти ці самі структури в пам'яті? Вірно, штатних засобів системи для вирішення цього питання немає, тому доведеться викручуватися по-хитрому.

Знаючи, як виглядають структури, потрібно згадати, що кожен файл, вулик реєстру, має свою константну сигнатуру. Наприклад, «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]

Що нам це дасть в результаті?
Хоча хто сказав, що нам це не під силу?
Але як працює з реєстром сама операційна система?
І чи зможемо ми емулювати її дії?
Але що ж таке реєстр насправді?
Які це структури, запитаєш ти?
Як це можливо?
Якщо у нас буде доступ до файлів реєстру на рівні ядра, то чим ми гірші самої ОС, щоб встановити свій порядок?
І тут на сцені з'являється найбільш цікаве питання - як знайти ці самі структури в пам'яті?
Як, наприклад, змінити значення комірки реєстру?