С. А. Середа
У статті описується узагальнена процедура аналізу та деактивації систем захисту програмного забезпечення (ПЗ) від несанкціонованого використання та копіювання. Знання методик, які використовуються зловмисниками ('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 Σ i = 1 αi ki,
де ki - приватний критерій стійкості, αi - ваговий коефіцієнт приватного критерію стійкості, що визначає його важливість, а n - кількість приватних критеріїв стійкості.
Таким чином, за допомогою методу експертних оцінок стає можливим порівнювати між собою різні варіанти захисту одного програмного продукту або порівнювати реалізації захисту різних програмних продуктів одного класу. Сама реалізація методу експертних оцінок може бути здійснена двома основними способами:
Якщо відсутня статистика попередніх оцінок, можливо лише порівняння різних варіантів між собою. У цьому випадку за єдиною методикою оцінюються різні варіанти реалізації захисту програмних продуктів. Кращим вважається варіант з максимальним значенням комплексного критерію.
При наявності статистики попередніх оцінок можливе виділення інтервалів значень приватних і сукупного критеріїв. Тоді варіанти, але вони не попадають в необхідний інтервал значень відкидаються. Хоча і в даному випадку кращим вважається варіант з максимальним значенням комплексного критерію, даний спосіб дозволяє оцінити єдиний варіант реалізації захисту, не розглядаючи його альтернатив.
Серед можливих напрямків подальших досліджень в даній сфері, на нашу думку, слід відзначити докладне вивчення окремих етапів подолання систем програмного захисту; виявлення залежності між строком подолання систем захисту різних типів і набором використовуваного зловмисником програмного інструментарію; збір статистичних даних по стійкості систем захисту різних типів; розробку методик оцінки стійкості систем захисту ПЗ і термінів гарантованої стійкості подібних систем до атак.
Список літератури
Касперски Кріс. Техніка й філософія хакерских атак. - М.: Солон-Р, 1999.
Майерс Гленфорд Дж. Мистецтво тестування програм. - М.: Фінанси і статистика, 1982.
Расторгуєв С.П., Дмитрієвський М.М. Мистецтво захисту та роздягання програм. - М.: Совмаркет, 1991. - 94 с.
Семьянов П.В., Зегжда Д.П. Аналіз засобів протидії дослідженню програмного забезпечення та методи їх подолання. / / КомпьютерПресс. - 1993. № 11.
Середа С.А. Аналіз засобів подолання систем захисту програмного забезпечення. / / Інформ: Радіоелектроніка та Телекомунікації. - 2002. № 4 (22). С. 11-16.
Середа С.А. Оцінка ефективності систем захисту програмного забезпечення. / / КомпьЛог. - 2000. № 2.
1 Під атакою нами розуміється комплекс дій, спрямованих на порушення захисту ПЗ від копіювання та використання.