VxDMon, відповідно, здійснює моніторинг викликів різних сервісів VxD, що в деяких випадках теж може виявитися корисним.

FileMon і RegMon існують у версіях для Windows 95 і Windows NT (у тому числі і для процесора Alpha); VxDMon, природно, працює тільки під Windows 95. Усі три утиліти можна завантажити з вузла "NT Internals" (www.ntinternals.com), причому разом з початковими текстами на C.

Якщо вам раптом знадобиться щось ще або просто стане цікаво, якими іншими інструментами користуються хакери, заходите на www.nettaxi.com/citizens/caligo/cracking.htm - там зібрана велика колекція посилань на усілякі корисні (не лише для розтину) програми.

Як не потрібно робити

Одна з найпримітивніших і ненадійних защит - прив'язка до комп'ютера. Будь-який програміст знає, як отримати деякі унікальні для цього комп'ютера характеристики - наприклад, серійний номер вінчестера, і (здавалося б) - ось воно! Навіть якщо користувач, що реєструється, передасть свій ключ комусь іншому, працювати програма не буде. Якщо ви коли-небудь встановлювали "Лексикон", то знаєте, про що йде мова.

Схема, наприклад, може бути наступною: програма обчислює згадані унікальні дані і показує їх користувачеві; він посилає їх авторові, який (при підтвердженні оплати) обчислює на їх основі відповідний пароль і посилає його назад. У програмі "прошитий" той же самий алгоритм, і робиться звіряння ключів - введеного з правильним.

Рекомендую відмовитися від цієї ідеї. Нічого, окрім незручностей для легальних користувачів, вона вам не принесе. Що, якщо користувач поміняє комп'ютер? Чи хоч би жорсткий диск? У наш час поголовній модернізації таке трапляється часто-густо. Сломать-то такий захист - як два байти переслати, а ось у вас головного болю буде на порядок більше.

Якщо ви використовуєте статичні ключі, то хоч би постарайтеся, щоб їх не було видно "неозброєним" поглядом при перегляді EXE -файла. Не потрібно робити таких "подарунків". Навіть якщо ви зберігатимете коди "задом наперед" і/або "зашифруєте" їх "потужною" функцією XOR (особливо на C або Паскале), то це не допоможе. Асемблер - краща мова! Як мовиться, "закордон нам допоможе" - читайте документацію по процесорах Intel (причому не лише на сервері Intel - www.intel.com; не полінуєтеся зайти також на сайт "Intel Secrets" : www.x 86.org). Один із законів Мерфи свідчить: "Якщо нічого не виходить - прочитайте, нарешті, інструкцію". Алгоритмів шифрування в природі багато, і ви навіть можете придумати свій власний (природно, навряд чи ви скажете нове слово в математиці, але така мета і не ставиться).

Якщо ж вас притягнув кодогенератор, то зробити його потрібно як можна складніше, щоб любителям "халяви" життя медом не здавалося. Більшість бачених мною защит, побудованих на подібному принципі, "колються" в два рахунки - можна просто "вирізувати" частину коду із захищеної програми (сам алгоритм генерації ключів) і зробити програмку, яка працюватиме за тим же принципом, але вже як окреме застосування, даючи таким чином не дуже чесним користувачам можливість згенерувати правильний код абсолютно безкоштовно.

До речі, якщо/коли ви (у програмі) визначили, що вона працює з-під відладчика або що хтось вже нацькував на неї patch (так, що файл змінився, - детальніше про це див. нижче), то не варто кричати про це на усю Івановську: упіймав, упіймав! Це найбезглуздіше, що ви можете зробити, - ця перевірка тут же буде локалізована і знищена.

А як потрібно?

Кінцева мета - зробити абсолютно "непробивний" захист - на жаль, недосяжна, але ви повинні до цього прагнути. Програма-мінімум - це забезпечити неможливість підбору пароля (реєстраційного ключа). Якщо у хакерів не буде іншого виходу, окрім як написати crack (patch), то це вже дуже непогано: з випуском чергової версії їм знову доведеться напружуватися. Скажімо, до поштової програми The Bat! (www.ritlabs.com/the bat/) crack є, а ось кодогенератор зробити не вдалося.

Повторюся ще раз: вивчите, нарешті, асемблер. Усі ці новомодні RAD -средства хороші тільки для малювання віконець, кнопочок і інших "фенечек", але ніяк не для потужного захисту. Повірте, знання асемблера не заважало ще нікому.

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

До речі, рекомендую вам спробувати стискувати свою програму яким-небудь пакувальником. Пам'ятаєте старий добрий PkLite? Так от, подібних програм для Win32 вже досить багато. Майже для усіх з них існують ті, що "розпаковують", але проте застосування цього способу декілька утруднить злом.

З'явилися і "інтелектуальні" пакувальники, які серйозно можуть допомогти вам захистити вашу програму. Наприклад, Shrinker (www.blickinc.com) - для нього (поки) того, що розпаковує не існує, і я не упевнений, що такий може бути написаний взагалі (упакований ці пакетом EXE -файл розпаковується динамічно невеликими блоками, причому використовуваний алгоритм досить складний; крім того, використовуються і деякі методи захисту від проходження коду відладчиком).

Не зайвим буде і код, що розпізнає активність відладчика, причому робити це потрібно на "ранній" стадії, а не безпосередньо перед перевіркою введеного пароля. Пустите вашу програму по "помилковому шляху", здійснюючи дії, відмінні від тих, які виконуються при нормальній роботі. Чи встановите який-небудь прапорець, який може бути використаний пізніше (звичайно, використовуючи hardware breakpoints, його рано чи пізно відловвлять, але це у будь-якому випадку ще одне очко на вашу користь).

Якщо у вас є досвід програмування драйверів, то можна "зашити" захист і у віртуальний драйвер. Порпатися в драйвері набагато складніше, ніж в звичайному виконуваному файлі, і далеко не кожен хакер на це здатний. Відлагоджувати драйвер під Windows NT - взагалі суща морока (для цього потрібний другий комп'ютер з debug -версией NT, або хоч би другий монітор, або наворочений відладчик типу SoftICE, не кажучи вже про високу кваліфікацію).

Втім, усе це нісенітниця. Головне - підходите до справи творчо! Включите свою фантазію, бийте хакерів їх же зброєю! Врешті-решт, якщо ви цілий рік писали програму і відноситеся до неї як до своєї дитини - не полінуєтеся витратити пару тижнів на вивчення всіляких систем захисту і, головне, методів їх злому.

""Шкідливі ради", або Як зіпсувати життя хакерові

Отже, чому ваш захист настільки примітивний і може бути легко розкрита? Зазвичай з двох простих причин: по-перше, ви не знаєте, як захисту "ламаються" (після прочитання цього матеріалу, сподіваюся, знаєте). І по-друге: ви не умієте програмувати на асемблері; практично усе захисту, написані на мовах високого рівня, можна обійти в два рахунки. Частіше всього досить буває поміняти всього пару байт.

Ось декілька рад, які, сподіваюся, дозволять вам хоч трохи забезпечити свою програму від злому (щонайменше, початківцями і/або не занадто кваліфікованими хакерами).

1. Пишіть захист на асемблері.

2. Ніколи не давайте осмислені імена важливим функціям, типу IsValidSerialNum.

3. Не попереджайте (відразу) користувача про те, що захист порушений. Краще зробіть це через два-три дня - хакери це ненавидять. Дрібничка, а приємно.

4. Використовуйте "перехресні" перевірки CRC -кодов ваших EXE - і DLL -файлов.

5. Робіть паузу (одной-двух секунд цілком вистачатиме) після введення пароля (серійного номері) перед поверненням результату. При цьому підібрати правильний пароль шляхом прямого перебору (за допомогою спеціально написаної програми) буде абсолютно неможливо.

6. Зберігайте паролі в якому-небудь "незвичайному" місці, наприклад, у властивостях поля бази даних.

7. Не прив'язуйтеся до системної дати. Обчислюйте поточну дату з часу створення яких-небудь системних файлів, наприклад SYSTEM.DAT або USER.DAT (Windows Registry).

8. Зберігайте пароль в декількох місцях одночасно.

9. Не використовуйте "статичні" (тобто жорстко прошиті у вашу програму) строчки тексту для повідомлення користувача про те, що пароль правильний (чи неправильний). Це перше, на що дивиться хакер. Генеруйте ці строчки динамічно, або використовуйте шифрування, хоч би найпростіше.

10. Використовуйте "дрібні хитрощі" для захисту від дизасемблювання і відладки.

11. Нарешті, нікому ніколи не розповідайте про те, як побудований ваш захист :)

Усі ці рекомендації узяті з Web -сайта "Fravia' s Page of Reverse Engineering" (fravia.org). Дуже рекомендую, обов'язково зайдіть: тут є чому повчитися. Окрім опису стратегій злому різних защит, ви знайдете немало рад для shareware -программистов, які допоможуть вам написати дійсно хороший захист. І ще: подивитеся, кому і за що там присудили "Most Stupid Protection Award" - отримаєте масу задоволення. Я сподіваюся, що самі в цьому списку ви ніколи не виявитеся. До речі, сайт досить добре оформлений і легкий в навігації; само по собі це не заслуговувало б на увагу, але звернете увагу на логотип "Created with MS - DOS EDIT.COM" (ось тобі, бабуся, і Юрьев день - читай: FrontPage).

Деякі пункти, можливо, вимагають пояснення. Детальніші рекомендації ви зможете знайти усе на тому ж сайті, але від вас знову-таки буде потрібно хороше знання асемблера. Зупинюся лише на пункті 4. Що таке CRC, я думаю, ви знаєте, чи не так? Відразу попереджаю, при обчисленні CRC -кода виконуваного файлу ви зіткнетеся з деякими труднощами: якщо "правильний" CRC зберігається в самому файлі (а саме так і варто робити - якщо він лежить в зовнішньому файлі або в Registry, то його виявлять в момент), то його доведеться якимсь чином враховувати при обчисленнях. Вихід наступний: просто виключите сам CRC -код з обчислень. Як це зробити, детально описано в книзі Лу Гринзоу "Філософія програмування для Windows 95/NT" (видавництво "Символ", 1997 рік). До речі, там же ви знайдете і безліч інших корисних рад, так що рекомендую.

Що стосується захисту від дизасемблерів і відладчиків, то це, чесно кажучи, допомагає не сильно, - кваліфікований хакер все одно вас перехитрить. Як би не був високий ваш професійний рівень, все одно знайдеться хто-небудь сильніше за вас. Проте, ніж більше подібних "примочок" ви використовуєте, тим менше буде круг хакерів, здатних зламати захист. Насправді, фахівців "вищого пілотажу" в області злому не так вже і багато - в усякому разі, менше, ніж ви припускаєте (більшість тих, що вважають себе такими насправді ними не є, як би їм цього ні хотілося). Коли людина починає розбиратися в асемблері як Бог, йому стає не до таких дурощів, як злом чужих програм, - за це, врешті-решт, грошей не платять. Ламати shareware -программы - заняття невдячне, і фахівець високого класу без проблем знайде собі високооплачувану і цікаву роботу до душі.

Лекція 7. Тема: Забезпечення безпеки при роботі в середовищі Windows XP

Операційна система Microsoft Windows XP вийшла на ринок 25-го листопада 2001-го року. Співробітники компанії покладали на неї великі надії і, як виявилось, не помилилися. За заявою самих розробників, новоспечена на той момент XP включала в собі досвід, накопичений за багато років побудови операційних систем.

Як і очікувалося, перед виходом, користувачам було дано безліч обіцянок (приміром, непробивний захист від несанкціонованого доступу, небачену раніше стабільність і "багоустойчивость"), але не усе виявилося настільки вже гладко.

Але досить ліричних відступів, сьогодні на порядку денному - підвищення безпеки операційної системи. Покроковий формат вибраний не з проста - так найпростіше виконувати інструкції, описані в статті.