Етапи подолання систем захисту програмного забезпечення

С. А. Середа

У статті описується узагальнена процедура аналізу та дезактивації систем захисту програмного забезпечення (ПЗ) від несанкціонованого використання та копіювання. Знання методик, які використовуються зловмисниками ( 'crackers') для подолання систем програмного захисту, дозволяє більш точно визначити слабкі місця існуючих систем, а також проектувати нові, більш стійкі до атак 1. Нами пропонується опис уніфікованої методики аналізу та подолання систем програмного захисту, що є результатом узагальнення і систематизації численних прийомів "злому" програм, які публікуються в сучасній літературі [1], а також, доступних в глобальній мережі. За підсумками проведеного дослідження запропоновано комплексний критерій оцінки стійкості систем захисту програмного продукту.

В даний час найбільш популярним засобом боротьби з нелегальним розповсюдженням комерційних програмних продуктів залишається програмний захист їх двійкового коду. Існують системи захисту програмного забезпечення різних типів [4, 6], всі вони постійно розвиваються. У той же час, є й засоби, що дозволяють досліджувати захищені програми і відключати системи їх захисту [5]. В умовах такого динамічної рівноваги важливим фактором, що впливає на стійкість систем захисту, є методичне забезпечення як фахівців із захисту ПЗ, так і зловмисників.

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

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

Аналіз прийомів подолання систем програмного захисту різних типів дозволив виявити ряд загальних закономірностей. У даному випадку, позитивну роль відіграло різноманіття описуваних зловмисниками методик, різний рівень їх складності, а також їх приналежність до різних стадіях аналізу систем захисту ПЗ. Таким чином, стало можливим систематизувати інформацію з даного питання і описати узагальнену процедуру аналізу та подолання систем захисту програмних продуктів.

На нашу думку, будь-які прийоми та методи аналізу і подолання систем захисту ПЗ можна звести до ряду стандартних етапів. (Див. блок-схему на Рис.1)

Перший етап -- визначення мети атаки. У першу чергу зловмисникові необхідно визначити мету, для досягнення якої він буде атакувати систему захисту програмного продукту. Серед можливих цілей можна виділити наступні три: особисте використання програмного продукту; розповсюдження засобів, відключають систему захисту продукту ( 'crack-files'); несанкціоноване розповсюдження самого програмного продукту ( 'warez'). У залежності від перерахованих цілей підхід до "злому" системи захисту того чи іншого програмного продукту може варіюватися. Зокрема, якщо зловмисник планує використовувати програмний продукт в особистих цілях, він може скористатися методами, потребують високої кваліфікації користувача, необхідної для роботи з відключеною системою захисту. Якщо передбачається розповсюдження засобів відключення системи захисту конкретного продукту зловмисникові необхідно орієнтуватися на некваліфікованого в питаннях захисту ПО користувача. Це може потребувати додаткових зусиль і витрат часу. Нарешті, якщо зловмисник планує поширювати "зламаний" програмний продукт, він, як правило, необхідно здійснити пряме відключення системи захисту, що значно складніше, ніж просто її обхід.

Другий етап -- пошук проявів системи захисту. Прояви роботи систем захисту можуть мати наступний вигляд:

обмеження часу використання продукту ( 'trial/evaluation');

обмеження функціональності продукту ( 'demo/crippled');

регулярні нагадування про необхідність реєстрації ( 'nag screens');

запит реєстраційного коду ( 'regcode');

генерація системних помилок ( 'crash/GPF');

збір та передача персональних даних ( 'spyware');

шкідливі дії ( 'malware');

внесення помилок в обробку даних і ін

Можливі й комбінації перерахованих проявів.

Залежно від цих проявів зловмисник може застосовувати різні підходи до дослідженню системи захисту, а також витрачати різний час і зусилля на її подолання. Наприклад, нагадування про необхідність реєстрації спрямовані на чисто психологічний вплив і їхнє відключення зазвичай не представляє великої складності. Програмні продукти з обмеженнями часу використання завжди уразливі для атак. Продукти з обмеженнями функціональності уразливі, якщо є можливість зняти обмеження з допомогою реєстраційного коду, і відключені підпрограми не зашифровано. Системи, вимикають захист при введенні вірного реєстраційного номера, можна подолати за відсутності шифрування коду ПО стійкими криптоалгоритмами (DES, RSA, IDEA, etc.). Що ж стосується систем, що генерують внутрішні або системні помилки, які збирають персональні дані або здійснюють шкідливі дії, їх аналіз та подолання, як правило, вимагають додаткових витрат часу, тому що подібні прояви систем захисту носять неявний і нелокалізованний характер.

Третій етап -- попередній аналіз роботи захищеного продукту. На початковому рівні дослідження системи захисту зловмисник відстежує активність програми, пов'язану з створенням і видаленням звичайних і прихованих файлів; зверненням до системних файлів, портів введення/виводу. Також контролюється рядок запуску програми, використовувані сервіси операційної системи та інші параметри. За допомогою подібного моніторингу роботи програмного продукту зловмисник отримує загальне уявлення про використаний механізм захисту та можливі шляхи її подолання. Як правило, системи захисту підключені через один із зазначених видів активності програми для реалізації своїх функцій. Наприклад, для реалізації обмеження часу використання продукту використовується або створення прихованих файлів, або запис даних в системні файли. У цьому випадку моніторинг роботи захищеного додатки з різними файлами дає важливу інформацію для подальшого дослідження системи захисту. Деякі системи захисту записують дані в область ППЗУ, в невживані ділянки доріжок жорсткого диска або використовують електронний ключ. Моніторинг роботи програми з портами введення/виводу дає можливість виявити подібні факти. Аналогічним чином, системи захисту, що використовують реєстраційний код, як правило, зберігають його у власних або системних файлах. Відстеження невдалих спроб знайти файл або знайти запис міститься в системному файлі також дає зловмисникам попередню інформацію про механізм захисту програмного продукту.

Четвертий етап - Попередній аналіз коду програмного продукту, визначення типу захисту і локалізація системи захисту. Проводячи поверхневе дослідження коду програмного продукту, в більшості випадків зловмисник визначає тип, а іноді і виробника системи захисту. Стає можливим встановити найбільш ймовірне фізичне розташування коду системи захисту в коді програмного продукту. Для подібного дослідження коду програми зазвичай використовується шістнадцятковий редактор з можливістю дізассемблірованія машинних інструкцій, пошуку заданих байтових послідовностей та ін Але, крім засобів перегляду машинного коду, зловмисники використовують і автоматичні аналізатори виконуваних файлів. Ці програмні засоби з закладеним у них сигнатурах здатні розпізнавати більшість популярних систем захисту ПЗ, а також визначати виробника і версію компілятора, за допомогою якого програма була зібрана.

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

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

Оцінивши стійкість системи захисту, зловмисник потім вибирає один або кілька ефективних способів її подолання. На цей вибір впливає і початкова постановка мети, як це було зазначено вище. Зокрема, для випадку з обмеженням часу функціонування продукту зловмисник може обрати три різні шляхи:

якщо він планує самостійно використовувати продукт, можливо, буде достатньо вручну змінювати системну дату або встановлювати заново програмний продукт за закінчення дозволеного терміну його використання, стираючи приховані файли та/або записи в системних файлах, зроблені системою захисту;

при бажанні в надалі поширювати засіб зняття захисту з продукту зловмисникові буде потрібно дослідити алгоритми системи захисту та розробити програмне засіб її статичного чи динамічного подолання;

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

Залежно від обраного способу подолання захисту змінюється і подальше її дослідження.

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

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

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

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

Сьомий етап -- подолання системи захисту. На фінальному етапі, з огляду на поставлену мету, обраний спосіб подолання захисту та знайдену технічну процедуру її обходу або подолання, зловмисник реалізує подолання захисту на практиці. Під обходом системи захисту розуміються дії, прямо не пов'язані з протидії системі захисту атакується програмного продукту. В якості приклад можна навести періодичну реінсталляцію програмних продуктів з обмеженим терміном використання; зміна системної дати до запуску програми та встановлення коректної дати після завершення її роботи; видалення/заміну прихованих файлів з лічильниками запуску; видалення/заміну відповідних рядків у системних файлах; написання та використання генераторів реєстраційних кодів; відстеження і автоматичне завершення діалогів з нагадуванням про необхідності реєстрації продукту і т.п.

Подолання системи захисту може здійснюватися трьома основними шляхами:

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

Динамічна модифікація коду програмного продукту під час його виконання.

Емуляція ключового файла, диска або електронного ключа захисту.

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

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

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

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

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

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

На основі висловлених вище міркувань можна сформулювати приватні критерії стійкості захищається продукту до атак. На нашу думку, можна запропонувати наступні критерії:

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

Стійкість до пошуку проявів системи захисту (маскування факту спрацьовування системи захисту);

Стійкість до попереднім аналізом захищеного продукту (маскування функціональності системи захисту);

Стійкість до попереднім аналізом програмного коду (маскування фізичного розташування системи захисту в коді продукту);

Наявність вразливостей в системі захисту;

Стійкість до статичного і динамічного аналізу коду (протидія аналізу алгоритмів системи захисту);

Стійкість до обходу системи захисту (наявність логічних помилок в алгоритмах захисту);

Стійкість до подолання системи захисту (трудність статичної та динамічної модифікації коду продукту).

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

Kкомпл. = N