Прощай, кейген: захищаємо софт від генераторів ключів

1. Зміст статті Привіт всім кодерам і хакерам! Стаття здебільшого адресується першим, але і другим...
2. Як ламають програми
3. Що таке превентивна фізичний захист?
4. Як боротися: спосіб номер один
5. Принцип написання генератора
6. Як боротися: спосіб номер два
7. Трохи про переваги формалізації
8. Коротше, Скліфосовський!

Зміст статті

Привіт всім кодерам і хакерам! Стаття здебільшого адресується першим, але і другим непогано було б послухати. Отже, уяви: збацав ти супермегапрограммку, яка контролює процес приготування курячої яєчні з приправою. Запатентував. Вирішив продавати. На наступний день заходиш в інет, а там повно посилань: «Ліки до супермегапрограммке" Яйця "», «Кейген до супермегапрограммке" Яйця "» - і ще тисячі дві способів її брухту описано. І від цього всього тобі доведеться захищатися. Я ж тобі розповім, як по-людськи (тобто на віки вічні) позбутися такого гидкого способу злому твоїх програм, як написання кейгена.

ліричний наступ

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

Як ламають програми

Способи злому програмних захистів ти і без мене знаєш (підкреслюю, що ми будемо говорити про програмні захистах, так як всякі хаспа простому смертному кодеру з його програмою «Яйця" не дуже доступні). А якщо не знаєш, то в двох словах: патчат двійкового коду або пишуть кейген. Можливі й інші методи злому, я тобі назвав два основних, знайомих всім нам на практиці. Відчуваєш, що ці два методи принципово різні? Кожен з них окремо може привести до необхідного результату - несанкціонованого використання твоїх «Яєць».

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

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

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

Схема захисту від тиражування за допомогою даних користувача

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

Але такий метод нелегального поширення, звичайно, майже ніколи не застосовується - несолідно це в той час, коли в світі є тисячі хакерів, спраглих слави і визнання. Ті сідають за свої суперкомп'ютери і за короткий час з'ясовують, як же на підставі слова «Пупкін» обчислюється страшний серійний номер 111. Потім пишуть кейген, який працює за цим алгоритмом, і ось користувачеві вже не треба вводити якісь там фіктивні дані, вводь собі свої рідненькі, а кейген, замість постачальника ПО, зробить зовнішній серійник.

Що таке превентивна фізичний захист?

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

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

Як боротися: спосіб номер один

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

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

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

Схема захисту від тиражування програмного забезпечення з прив'язкою до апаратної частини ПК

Але щось все одно не радісно. Від простого тиражування-то ми захистилися. Але хакери ... вони ж так і будуть продовжувати писати свої бридкі генератори, через які продажу «Яєць» падають нижче плінтуса. Що ж робити?

Принцип написання генератора

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

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

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

Як боротися: спосіб номер два

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

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

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

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

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

Трохи про переваги формалізації

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

Тут ти і попався! Суть пропонованого мною загального формалізованого методу створення програмних захистів (будь-якого призначення) полягає в розбитті системи захисту на дві частини, і перша з них - фізичний захист від модифікацій коду (подивись-но в розділ «Як ламають програми»). Це її функція - оберігати від змін двійкового коду ПО. Як ти цю частину реалізуєш - справа твоє, але вона має бути присутня в будь-який програмної захисту.

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

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

Таким чином, запропонована формалізована методика побудови програмних захистів. Два ланки: логічне і фізичне. Реалізовуватися вони можуть по-різному.

Модель пропонованої комплексної захисту

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

Що ж, підхід простий. Два ланки - захист від двох загроз, відповідно. Гарна у мене класифікація загроз, велика :-). Рекомендую ознайомитися і з іншими класифікаціями загроз програмному забезпеченню, пропонованими, наприклад, Microsoft. Для цього шукай в інеті DREAD і / або STRIDE. Подивися, скільки там загроз розглядається. А чи сприяє це якось створенню захистів (у чому і полягає мета будь-якої класифікації загроз) - вирішуй сам.

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

Коротше, Скліфосовський!

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

Крім розробки всяких там антігенераторов і схем захисту, стаття покликана також трохи розбурхати громадськість, викликати палкі суперечки, ворушіння сірої речовини. Вітаються будь-які думки, навіть критика Мене. Особливо - посилання на схожі методики захисту. Скажу тільки, що перед подачею свого патенту я довго рився в російській ( www.fips.ru ), Української ( www.ukrpatent.org ) І європейської ( www.espacenet.com ) Базах патентів і нічого схожого на мою просунуту схему не знайшов. Тому сподіваюся, що моя стаття принесе кому-небудь
реальну користь.