Інструментарій хакера

Сучасний хакер має у своєму арсеналі набір різноманітних утиліт для злому.

Їх можна підрозділити на декілька категорій

• Відладчики. Дозволяють переривати виконання програми досягши заздалегідь заданих умов, виробляти покрокове виконання програми, змінювати вміст пам'яті і регістрів і тому подібне. Найбільш популярним, зручним і потужним являється відладчик SoftICE, який при досить примітивному інтерфейсі має пристойні можливості і дуже стабільно працює.

• Дизасемблери. Виробляють дизасемблювання програми для подальшого вивчення отриманого коду. Один з найбільш потужних і популярних - IDA. Від дизасемблера досить легко захиститися - зашифрувати або заархівувати програму. Тоді дизасемблюється тільки архіватор або кодувальник. Проте тот-же IDA має потужну вбудовану скриптовой мову, що дозволяє виробляти розшифровку програми

• Засоби моніторингу. Це набір утиліт, що відстежують операції з файлами, реєстром, портами і мережею.

• Засоби пасивного аналізу програми. Показують різну інформацію про програму - витягають ресурси, показують зв'язки, використовувані бібліотеки. Класичний приклад - утиліта DEPENDS.EXE з комплекту Visual Studio. Вона показує, які бібліотеки використовуються програмою і які функції імпортуються.

• Інші утиліти. Їх велика кількість (можна знайти на диску типу "Усе для хакера", причому удосталь). Це різноманітні редактори, аналізатори ..

Найбільш популярні наступні програми моніторингу :

• FileMon - утиліта, що дозволяє вести моніторинг усіх операцій з файлами. Має зручний фільтр, може зберігати звіт у файлі. Тому немає сенсу робити "секретні" файли де-небудь в Windows/System - їх елементарно знайти.

• RegMon - аналог FileMon, тільки ведеться моніторинг усіх операцій з реєстром. Аналогічно файлам, безглуздо створювати в реєстрі "секретні" ключі - вони відразу впадають у вічі.

• PortMon - моніторинг роботи з портами введення/виводу

• TCP_VIEW - монітор з'єднань по TCP - IP

• RegUtils - набір утиліт для контролю за реєстром - робить копії реєстру, дозволяє порівнювати копії і переглядати зміни.

Утиліти типу FileMon можуть різко спростити злом програми - легко визначити місце, в якому програма звертається до вказаного файлу або ключа реєстру.

Основи побудови захисту - крок за кроком

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

1. Встановлює точку останову на прочитування тексту із стандартного елементу введення (функції GetWindowText, GetGlgItemText модуля KERNEL32)

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

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

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

Розглянь декілька рішень, які можуть утруднити злом на цьому етапі.

Рада _0. Прагніть якомога менше застосовувати стандартні функції (особливо API -шные) і компоненти VCL. Отже Assembler, Assembler і ще раз Assembler ..

Суть цієї ради сподіваюся очевидна - сучасні дизасемблери уміють розпізнавати стандартні процедури високорівневих мов, а API - взагалі окрема розмова - SoftICE має дивовижну можливість - завантажувати символьні імена для будь-яких вказаних бібліотек (особливо для KERNEL32.DLL) - відладка різко спрощується, оскільки ми бачимо імена функцій, що викликаються, і можемо ставити точки останову на виклик функцій по їх імені.

Рада 1. Застосовуйте нестандартний спосіб введення пароля.

Наипростейший шлях - написати свій візуальний компонент для введення реєстраційного коду. Він звичайно повинен буде обробляти події від клавіатури, але момент прочитування коду не можна упіймати побитими методами. Це вже щось, але є другий спосіб злому, заснований на пошуку введеного коду в пам'яті. Для цього в SoftICE є зручна команда "S стартова адреса L довжина 'образец'", яка дозволяє знайти введене значення в пам'яті.

Рада 2. Не зберігаєте введений код в одному місці !

Якщо введений код або реєстраційний номер зберігати в одному місці, то досить легко встановити точку останову на эону пам'яті, в якій зазмещен введений код.

Рада 3. Не зберігаєте введений код відкритим текстом !

Отже, що ж слід зробити. Спершу необхідно завести в програмі 5-10 змінних типу STRING і після введення коду переписати введене значення в них. Робити це краще всього не в одному місці, а розподілити за програмою. Таким чином пошук дасть купу адрес, по яких знаходитиметься введений код. Я у такому разі поступаю так - по таймеру створюю в динамічній пам'яті нову строкову змінну, пишу в неї код. Потім на наступному спрацьовуванні таймера створюю нову змінну, переписую в неї код, а стару знищую. При певній навичці можна заполонити пам'ять значеннями введеного коду і зробити пошук майже даремним. Причому таке копіювання можна поєднати з перевіркою коду або емуляцією цієї перевірки. Потім з ці рядками непогано поробити які-небудь операції - порівняти з чим-небудь ..

Ради 3 і 1 можна об'єднати - створити свій компонент, який дозволить вводити код нестандартним способом з його одночасним шифруванням.

Аналіз реєстраційного коду. Отже, код введений і прийняті заходи для того, щоб його було непросто знайти (хоча знайти те його можна, але цей час, навичка ..). Тепер наступний крок - аналіз. Тому відразу рада:

Рада 4. Ні в якому разі не аналізуйте код відразу після його введення.

Чим далі введення коду від його аналізу, тим краще. Найрозумніше - після введення коду подякувати користувача за співпрацю і повідомити, що з часом буде виконана реєстрація програми. А аналіз коду виробити, наприклад, через 1-2 хвилини в абсолютно іншому місці програми.

Рада 5. Не перевіряйте код тільки в одному місці і не пишіть для перевірки функцію.

Досить знайти і відключити цю перевірку, і захист зламаний. Якщо перевірок декілька, вони різні і розподілені за програмою, то злом утруднюється.

Рада 6. Не перевіряйте пароль одним алгоритмом.

Рекомендується розробити 2-3 алгоритми перевірки, наприклад 1-2 цифри повинні ділитися на 3, а 3-7 накладених по якому-небудь алгоритму на ім'я користувача повинні дати в сумі 4. Ці дві перевірки здійснюємо в різних місцях з досить великим тимчасовим рознесенням - зламавши перший метод хакер не здогадуватиметься про існування ще декількох, які проявляться з часом.

Рада 7. Ні в якому разі не робіть ніяких дій після перевірки. З невідомої причини більшість програм виглядають приблизно так

IF NOT(SuperRegCodeCheck) then

Begin

ShowMessage('Невірний код, подальша робота неможлива');

halt;

end;

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

Рада 8. Відволікаючі маневри.

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

Рада 9. Не зберігаєте результатів перевірки в змінній і не використовуйте її для явного обмеження функцій незареєстрованої програми.

Класичний приклад порушення цього правила

IF NOT(LegalCopy) then

ShowMessage('Збереження працює тільки в зареєстрованій версії')

else

SaveFile;

Таким чином елементарний аналіз показує, що змінна LegalCopy зберігає результат перевірки і поставивши на неї точку останову можна виловити саму перевірку. Відредагувавши це значення в пам'яті можна тимчасово зробити копію "зареєстрованою", а установка точки останову на зміну цієї змінної виведе на місце її перевірки. Та і злом зводиться до того, що функція перевірки коду урізається до двох команд асемблера :

MOV [адреса LegalCopy], 1

RET

Рада 10. (витікає з 9) Не зберігаєте результатів перевірки на диску або в реєстрі.

Типова помилка - з'ясували, що копія зареєстрована і зробили де-небудь мітку. Відловити це досить просто (див. опис REGMON і FILEMON). Найкращий спосіб - зберегти пароль і ім'я користувача в тому виді, в якому він їх ввів. Потім при кожному запуску програми перевіряти коректність цього коду, але не забуваючи Раду _11. Нічого не перевіряйте відразу при запуску додатка або відразу після прочитування збереженого імені або коду. Пам'ятаєте, що прочитування коду і його введення у вікні реєстрації ідентичні по заходах захисту - дублювання в різних областях пам'яті, шифрування ..

Висновки: ми влаштуємо перевірку коду в декількох місцях програми, при цьому застосуємо декілька алгоритмів перевірки, не використовуватимемо API.Крім того, варто виконати декілька відволікаючих маневрів.

• CRC - контрольні суми. Будь-який файл, рядок або блок даних можна захистити контрольною сумою, яку потім можна розрахувати і порівняти з еталоном. При порівнянні з еталоном звичайно слідує звістка обережно - см перші 11 рад. Отже, рада 12. Захищайте програми і дані контрольними сумами. Це допоможе не лише від злому, але і захистить програми від вірусу або впровадження Трої.

• Застосовуйте шифрування програм і даних. Дуже непогано стискувати програму і дані. Я, наприклад, розробив свій власний архіватор - RAR -у і ZIP -у він конкуренції не складе, але стислі їм дані розтискати дуже непросто, доведеться неабияк повозитися. Та і змінити їх проблематично - доведеться розтискати, змінити і стискувати.

• Вилов покрокової відладки програми. Існує багато способів, я свого часу провів ціле дослідження цього питання під DOS, назбирав і придумав не менше 20 методів, але вони мало прийнятні під Windows. Найпростіший і надійніший спосіб - таймер. При роботі програми періодично фіксуємо системний час і розраховуємо час роботи фрагментів коду між ними. І якщо 200-400 команд процесора працюють 2-3 хвилини, то тут є над чим замислитися.

Рада 13. Не визначайте дату і час стандартними способом !! Придумайте що-небудь оригінальне.

Рада 14.Не варто зберігати що-небудь секретне у файлах або реєстрі. Робота з файлами або реєстром може бути детально запротокольована і проаналізована, і усе таємне стане явним.

Рада 15.Не зберігаєте нічого важливого відкритим текстом, особливо повідомлення типу "Це незареєстрована версія ."., "Введений пароль не вірний .".Вони для хакера - як для бика червона ганчірка, і дійсно - знаходимо таке повідомлення, ставимо точку останову на звернення до ділянки пам'яті з цим повідомленням і дістаємо можливість упіймати момент видачі цього повідомлення.

Захист "обмеження часу роботи" полягає в тому, що програма яким чином фіксує момент свого першого запуску і працює встановлений час (звичайно 20-30 днів). Після закінчення цього терміну програма відмовляється запускатися. Як перевірити поточну дату я вже десь тут писав - нестандартним способом, наприклад по даті на файлах реєстру або новоствореному своєму файлі. Увесь фокус в іншому - як зафіксувати на комп'ютері дату першого запуску (природно так, щоб знищення програми і її повторна установка не давали ефекту). Використання "секретних" файлів в системних теках або зміни в існуючих файлах легко відловити за допомогою FILEMON. Реєстр те ж відпадає із-за REGMON. Інші методи (типу запису у ВООТ сектор ..) теж неприйнятні - не ті часи, по Windows усе це не пройде. Найоригінальніше (на мій погляд) прошити дату в саму програму і постійно оновлювати її на своєму сайті (природно, автоматично). Таким чином відлік неявно йде від моменту скачування програми з сайту. Є тут правда і мінус - після завершення терміну можна повторно викачати цю програму і отримати ще 15-20 днів .. . З іншого боку це оригінально - користувачеві рано чи пізно набридне викачувати цю програму і він або відмовиться від неї, або купить. Але при цьому варто пам'ятати, що програму можна викачати кілька разів і порівняти варіанти, виявивши, де лежить дата. Тому варто потурбуватися про те, щоб змінився майже увесь файл (наприклад, змінити пару опцій компілятора)

Формування кодів може вестися по наступних основних напрямах:

• Жорстко фіксовані коди, прошиті в програму. Їх зазвичай небагато і їх розголос зводить захист до нуля.

• Деякий алгоритм перевірки коду. Трохи краще першого, але лише небагато. Візьміть за приклад код Windows - його знає будь-який користувач

• Алгоритм перевірки коду, що використовує ім'я користувача. Очевидно, що для кожного імені буде унікальний номер (чи номери - їх може бути декілька, залежно від алгоритму). Це вже краще, але нелегальне поширення тримається на егоїзмі зареєстрованих користувачів - ніщо не заважає їм зрадити ім'я/пароль розголосу, але тоді хоч би можна вичислити винуватця і заблокувати його код

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

• On - Line реєстрація. Полягає в тому, що програма в On - Line зв'язується з сайтом розробників (чи компанії, що здійснює продужу софтвера) і передає туди ревизиты користувача. У відповідь програмі передається реєстраційна інформація. Цей метод може і хороший для ряду програм, але на мій погляд не витримує ніякої критики з двох міркувань: 1. Ніхто не може гарантувати, що конкретно передасть програма в Инет. А передати вона може усе, що завгодно - параметри комп'ютера, паролі, будь-які дані і тому подібне2. Конкретний користувач може не мати доступу до Инет. Це особливо важливо для програм, робота яких не пов'язана безпосередньо з Мережею. І зареєструвати таку програму його практично ніхто до себе на комп'ютер не пустить (з міркувань п.п. 1)

Рекомендувати тут що-небудь даремне, але я наприклад використовую різновиди методу 3.

Що і як закривати

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

З демо-версиями усе просто. Двома словами, принцип такий: ви сильно урізаєте можливості програми, просто "викидаючи" частини коду з початкового тексту, перекомпілюєте і викладаєте результат як демо-версию. (Тим же, хто виявляє бажання заохотити вас матеріально, ви просто посилаєте повну версію програми, або повідомляєте, де її можна узяти, - вказавши, наприклад, "приховане" посилання на вашій сторінці.) Обмовлюся відразу, що цей спосіб - гірший з усіх. По-перше, по демо-версии користувач не завжди може зрозуміти, наскільки програма йому підходить. По-друге, один з тих, що сплатили може підкласти вам свиню і розповісти іншим, де можна поживитися повною версією "на халяву" (чи просто почати роздавати її усім своїм знайомим), - все одно у вас немає способу дізнатися, хто ж зробив "добру" справу. А якщо ви посилатимете повну версію звичайною (чи навіть електронною) поштою, то у вас різко збільшаться накладні витрати.

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

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

Так, до речі, не перешкодить ще і така річ, як reminder (чи "nag screen", як завгодно). Це зовсім просто: при запуску програма визначає, зареєстрована вона або ні; у останньому випадку користувачеві ненав'язливо нагадують, що не погано б і честь знати, тобто заплатити.

Як це зробити

Можна, звичайно, скористатися послугами третіх фірм - просто купити програмний пакет, що забезпечує перехід від незареєстрованої версії до зареєстрованої після оплати і введення деякого пароля (см, наприклад, www.timelock.com/product/ або www.dataet.com/products/isr 2/). Проблема в тому, що якщо цю систему купило хоч би декілька розробників і захищені у такий спосіб продукти вже є, то можете бути упевнені, що в цьому захисті вже хто-небудь "длубався" і використовувані в ній трюки давно усім відомі. Отже доведеться вам потрудитися самому.

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

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

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

Тепер про те, що повинно відбуватися після оплати. Тут знову ж таки є дві дороги: "статичні" паролі і генератор ключів.

У першому випадку програма "розблоковується" при введенні пароля, відповідного деяким критеріям. При цьому сам пароль не є індивідуальним. Я думаю, що вже ні для кого не є секретом, як це зробила компанія Microsoft зі своїми CD - keys: сума цифр повинна ділитися на 7. Простіше нікуди. Природно, ви можете придумати що-небудь поскладніше, наприклад, робити деякі обчислення, які повинні призводити до певного результату. Як варіант - можна зберігати усі правильні ключі усередині самої програми.

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

Що стосується генератора ключів, то це елегантніший спосіб: знаючи ім'я користувача, ви можете шляхом яких-небудь перетворень згенерувати з нього деякий ключ. Тут вже включайте свою фантазію: краще всього, якщо перетворення буде одностороннім і досить заплутаним.

Не можна не згадати і ще про один спосіб захисту - за допомогою апаратних ключів, що підключаються до паралельного порту комп'ютера (типу HASP). Звичайно, для програми вартістю п'ять доларів це не дуже підходить (занадто дорого; не усі люблять; з деякими пристроями не досягається повна сумісність і т. д.), але проте. Можете спробувати.

Маленький сюрприз

Якщо ваша програма дійсно хороша, то через два-три дня після її випуску вас чекає сюрприз: в Інтернеті з'явиться "халявный" реєстраційний код, або crack, або patch, або зламана версія. До речі, якщо вам не знайомі ці терміни, то от як їх можна визначити (узято з news: alt.cracks) : "Crack: Any method used to defeat protection applied to a software program to allow its full unencumbered use without paying the author for it. Patch: An executable software program that, when aimed at another software program, modifies the target program for some specific purpose". Загалом, ідея ясна: вашою програмою тепер можуть користуватися усі охочі, причому платити для цього зовсім не обов'язково.

Звичайно, ви можете про це і не дізнатися, якщо звикли економити на доступі до Інтернету і/або якщо не знаєте, де шукати, але я вас запевняю - якщо програма цікава не лише вам і вашим друзям, то її обов'язково зламають. Сто відсотків.

Повинен вас засмутити (чи обрадувати?) : 99% відсотків защит, вживаних в shareware -программах, ламаються за 10-15 хвилин. Для цього навіть не потрібно бути хакером. Усе, що вимагається, - це декілька програм: потужний відладчик типу SoftICE, дизасемблер типу IDA плюс пара утиліт типу FileMon, RegMon, VxdMon. Іноді навіть цього багато. Ну і ще, звичайно, хоч би базове знання асемблера.

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

Отже. Зазвичай реєстрація виглядає таким чином: користувач натискає на кнопку "Зареєструвати"! (чи звертається до відповідного пункту меню)і перед ним з'являється віконце з пропозицією ввести реєстраційний ключ. При закритті цього віконця (після введення ключа) відбувається верифікація. Верифікація може бути жахлива складною і заплутаною, але врешті-решт вона приходить до закономірного результату, а саме операції порівняння (введеного ключа з правильним або вичисленого значення з деяким зразком) або запису в стек (чи регістр) результату верифікації.

Усе до геніальності просто: усі операції роботи з рядками (якщо ви пишете мовою високого рівня) використовують виклики відповідних функцій (API) ядра Windows (kernel) або звернення до Run - Time Library. І ті і інші легко відстежуються відладчиком, а частенько і розпізнаються дизасемблером. Якщо ж ви використовували генератор ключів, то рано чи пізно в пам'яті з'явиться "правильний" рядок - тобто та, яка має бути, якщо користувач чесно сплатив нелегку працю програміста. Тому найчастіше хакер має можливість зареєструвати програму "На себе" і роздати пароль таким, що усім бажає (так, наприклад, було зроблено з прекрасним антивірусом AVP від дуже шанованого мною Євгенія Касперского).

Хто такий (точніше, такі) PhrozenCrew, ви, напевно, знаєте, а якщо (поки) не знаєте, то двома словами: це найбільша (хоча і не найстаріша) "крэкерская" група, що займається зломом shareware -программ (на їх рахунку більше трьох тисяч "постраждалих" авторів); налічує близько сорока активних членів, включаючи засновника (The Keyboard Caper, родом з Південної Африки), президента і віце-президента (Archimede і TeRaPhY, відповідно), власне "крэкеров", кур'єрів, тестувальників і ін. Втім, це вже тема для окремої статті.

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

Якщо ваша програма - time - limited, то тут все ще простіше (ну прямо як в старому анекдоті про невдачливого єврея - або акула попадеться глуха, або свисток для відлякування будезламаний :). Річ у тому, що час першого запуску потрібно десь зберігати (при цьому залишаючи незмінним при переинсталляциях). Зберігати можна тільки в двох місцях: в Registry або у файлі на диску (варіанти типу невживаних доріжок я з обуренням відмітаю - хлопці, це ж вам не DOS, самі ж намучитеся, а то і кінцевому користувачеві диск споганите). За допомогою згаданих вище програм (деякі з яких абсолютно безкоштовні) будь-який охочий з легкістю може побачити, які саме ключі Registry ви пишете або читаєте і до яких файлів звертаєтеся. Далі, знайти відповідні виклики в самій програмі - справа техніки, на те відладчики/дизасемблери і існують. Усі відомі мені shareware -программы із захистом цього класу (наприклад, Bounds Checker Professional) вже давно розкриті.

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

""Джентльменський набір" хакера

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

З усіх відомих мені дизасемблерів найпотужнішим є IDA (Interactive DisAssembler), см www.datarescue.com/ida.htm; він далеко не безкоштовний (149 доларів), але, повірте, вкладені в нього гроші окупляться з лишком. До речі, ця програма написана нашими співвітчизниками. Однією з її відмінних рис є "многоплатформность" - він "розуміє" безліч форматів файлів, включаючи DOS COM/EXE, NE (New Executable), LE (Linear Executable, PE (Portable Executable), COFF (Common Object File Format), NLM (NetWare Loadable Modules), LIB, AR і навіть Java -классы. Спектр підтримуваних процесорів теж дуже широкий: Intel (від 8080 - пам'ятаєте такий? - до Pentium Pro і Pentium MMX, і навіть i860), а також Motorola 68xxx, ARM, TMS і багато інших. Причому користувачі можуть розширювати цей список, додаючи підтримку інших процесорів самостійно.

Є у IDA і багато інших чудових можливостей, частина з яких дійсно унікальні. Наприклад, FLIRT (Fast Library Identification and Recognition Technology); за допомогою цієї технології дизасемблер здатний розпізнавати виклики бібліотечних функцій (наприклад, для мови C - printf, strcmp і т. д.), включаючи ті, які ви написали самі. Мало того, IDA ще і уміє ідентифікувати звернення до масивів і структур, роблячи асемблерний текст значно більш читаним. Не можу не згадати і про "autocommenting" - результуючий текст виходить добре закоментованим! І остання маленька, але важлива деталь: в IDA ви можете "підправити" текст програми (замінюючи початкові інструкції асемблера на свої власні) і зберегти результуючий EXE -файл, так що навіть patch робити не доведеться.

Якщо все ж IDA вас чим-небудь не влаштовує, сходите за адресою www.csee.uq.edu.au/csm/decompilation/disasm.html, - там зібрана ціла колекція посилань на різні дизасемблери. Рекомендую також відвідати www.eccentrica.org/Mammon/disasm.html, де окрім дизасемблерів є ще і посилання на утиліти для редагування бінарних файлів - теж згодяться.

Далі - хороший відладчик. Забудьте про Borland Turbo Debugger і Microsoft WinDbg! Ці програми хороші тільки для "лову бліх", тобто помилок. Кращий вибір - SoftICE від NuMega (www.numega.com/products/sys/sys.htm). З його допомогою ви можете робити буквально усе! Власне, головне його призначення - це все-таки пошук помилок, але і як хакреський інструмент він просто незамінний.

Не обійтися і без вже згаданих утиліт FileMon, RegMon і (можливо) VxDMon, написаних Марком Руссиновичем, відомим експертом в області низькорівневого програмування для Windows (саме він розповів всьому світу про те, що різниця між Windows NT Workstation і Windows NT Server - це усього лише декілька додаткових програм і значення одного ключа в Registry). FileMon показує детальну інформацію про усі звернення до файлової системи; є можливість встановлювати різні фільтри і навіть відстежувати роботу з swap -файлом.

RegMon (як ви вже, напевно, здогадалися) робить приблизно те ж саме, але не з файловою системою, а з Registry.