Для спрощення викладу розглянемо модельну ситуацію.
Ви розробили для своєї організації програму на Access, яка успішно експлуатується. У програмі клієнтська частина відокремлена від даних і встановлена на кожному комп'ютері. Системи захисту від цікавих юзерів встановлені. Все це означає, що ви явно не програміст. (Тому в статті дані тільки ідеї, а їх програмна реалізація залишена за вами.)
Одного разу шеф викликає вас і повідомляє, що його приятель-конкурент зацікавився вашою програмою і готовий її купити на п'ять комп'ютерів, при наявних у нього восьми. Правда, приятель хоче, щоб спочатку його співробітники познайомилися з демонстраційною версією і надали йому свої зауваження.
Далі шеф, охоплений мріями про нове джерело доходів, каже, що знає ще два десятка фірм, куди можна запропонувати програму. А якщо виставити її на продаж через Інтернет, то.
У нього паморочиться голова від величини передбачуваних доходів, якими він, з властивою йому щедрістю, готовий поділитися з вами. І голова починає кружляти у вас.
І що для вас це означає роботу, приблизно вдвічі більшу, ніж початкова розробка програми. Роботу, яка включає в себе багато, не тільки доопрацювання програми. Але і її теж. Зокрема, в програмі треба зробити:
- спеціальний режим демоверсії;
- захист від несанкціонованого копіювання.
2. Режим демоверсії.
Для створення режиму демоверсії зазвичай застосовується один з двох методів:
- обмеження часу роботи програми (стандарт - місяць);
- обмеження функцій програми. Для Access найчастіше застосовується обмеження кількості записів в деяких таблицях.
В обох випадках слід десь зберігати дані, що задають режим демо. І написати програму перекладу вашої бази зі стану демо в робоче.
Так що, забудьте про продажі в форматі mdb. Без формату mde в Shareware базах вам не обійтися. Але так чи він надійний, цей формат mde? Чи не можна його перевести в формат mdb? Це питання настільки часто повторюється на форумах по Access, що це вже є пропозиції - повісити на вході в форум відповідь: "Не можна!". Але багато хто цікавиться подробицями - "А чому, власне, не можна?".
3. Про переведення формату mde в формат mdb.
Microsoft розробив формат mde саме як засіб захисту об'єктів бази даних. Ідея - дати формат бази, позбавлений вихідних кодів і швидше виконуваний. Начебто формату exe в порівнянні з програмою в початкових кодах, написаної на С ++.
Отже, формат mde захистить вашу базу від нахабного розкрадання і не дасть перевести її в робочий режим з стані демоверсії. Друге - тільки в тому випадку, якщо ви добре заховали дані, які визначають режим демо. Про те, як їх добре заховати - нижче.
Але він ніяк не захистить від установки вашої програми саме на п'ять, а не на вісім комп'ютерів. Що ще гірше, він так само не захистить від передачі вашої програми в інші фірми. Наприклад, ваш перший покупець візьме і подарує (або продасть за безцінь) вашу програму ще одній фірмі. А та - далі.
Тут треба вживати заходів захисту. А захист є тільки одна - прив'язка програми до комп'ютера.
4. Як прив'язати програму до комп'ютера.
Перше, що спадає на думку - це помітити як-небудь комп'ютер і перевіряти при старті цю позначку. Однак все методи позначки або долаються відомими способами, або створюють багато ускладнень. Перерахуємо їх з короткими характеристиками.
1. Внести запис про програму та її стані до реєстру.
Це стандартний підхід. Однак є програми, які відстежують всі звернення до реєстру і дозволяють знайти і скопіювати роздільну запис. Далі ваша програма поширюється разом файлом записи в реєстр. Цим прийомом часто користуються, наприклад, при несанкціонованому ліцензування елементів ocx.
2.Создать в захованих місцях файл (и), що виконують ту ж роль, що і запис до реєстру.
І на цей випадок є програми, які відстежують всі звернення до файлів, і дозволяють знайти потрібні і скопіювати. Цей метод нічим не краще запису до реєстру.
3.Внесті запис в нестандартне місце (флеш-пам'ять, запасні треки на диску, порожні кластери на диску, помітивши з як зіпсовані, дописати свою інформацію до стандартних програм і т.д).
Це шлях вірусів. Йти разом з ними не слід. До того ж ви неминуче попадаєте жертвою антивірусних програм.
Зупинимося на SerialNumber диска С. Будемо запам'ятовувати і перевіряти його. Тим більше, що уникнути ситуації зміни характеристик комп'ютера неможливо в принципі. Наприклад, фірма купила новий комп'ютер і бажає переставити на нього вашу програму. Для програми це і є принципова зміна всіх характеристик комп'ютера. Це повинно бить обязательно допустімо. Так що треба подумати про логічної схемою роботи з SerialNumber.
Зауваження. Литовський в свій статті рекомендує використовувати SerialNumber диска, на якому встановлена програма. Це знижує гнучкість системи, так як забороняє вільний перенесення програми з диска на диск навіть в межах одного комп'ютера.
5. Основна схема роботи системи реєстрації копій.
Основна схема придумана давно:
- демоверсія повідомляє покупцеві код комп'ютера;
- покупець посилає його продавцю разом зі своїми даними;
- продавець генерує ключ перекладу програми в робочий стан і посилає його покупцеві;
- покупець вводить ключ і програма переходить в робочий стан.
Але це основна схема. Різних варіантів її реалізації можна зробити дуже багато.
Нижче буде зроблено ще кілька зауважень за пропозиціями С. Литовського. Тому, якщо ви ще не прочитали його статтю, то зробіть це зараз.
Спочатку дрібниця. Сосем не обов'язково при видачі коду комп'ютера шифрувати його SerialNumber. Ніякої унікальної інформації він не несе. Тому код комп'ютера може бути просто йому дорівнює.
Ще про SerialNumber:
- в деяких випадках SerialNumber має негативний знак. Видавайте його абсолютну величину. Плутанини менше, а надійність та ж.
- для читання SerialNumber краще використовувати функцію з kernel32.dll GetVolumeInformation (у Литовського саме так - правильно), а не FileSystemObject. FSO працює не завжди (NT4).
Тепер основне зауваження. З тексту "Приклад процедури для стартової форми" слід, що кожна клієнтська частина по Литовському має свій реєстраційний номер. І кожна прив'язана до свого комп'ютера. Назвемо це статичної прив'язкою. В цьому випадку вам доведеться запитувати код і висилати ключ для кожного комп'ютера окремо. При цій прив'язці перенесення клієнтської частини з комп'ютера на комп'ютер без вас теж обійтися не може.
Але головна трудність не в цьому. Здалеку вам не розібратися, чи то ваш покупець замінює парк комп'ютерів, запросивши п'ять нових ключів замість старих, то він його просто нарощує, злегка обманюючи вас, то чи взагалі передає вашу програму іншій фірмі, обманюючи вас вже по крупному. Старі ключі-то у нього залишаються завжди.
Нижче викладається інша схема, яку можна назвати схемою динамічної прив'язки програми до комп'ютерів. Суть полягає в наступному. Замість запиту кодів всіх комп'ютерів слід отримати код одного (будь-якого) комп'ютера з мережі. Потім згенерувати ключ перекладу програми в робочий стан, включивши в нього наступну інформацію:
- присланий вам SerialNumber;
- кількість куплених ліцензій (на скількох комп'ютерах програма буде працювати);
- повна назва організації, можливо з місцем її знаходження.
Ключ перекладу повинен бути обов'язково зашифрований.
Програма обробки ключа повинна:
- дешифрувати ключ;
- порівняти SerialNumber з реальним;
- при збігу записати в захищену область (про неї нижче) бази з даними всю отриману контактну інформацію, доповнивши SerialNumber ім'ям комп'ютера. Ім'я комп'ютера має допоміжне значення і використовується для проведення деінсталяції.
Назва організації - покупця можна виводити в формі - заставці і в формі "Про програму".
Далі, при старті кожна клієнтська частина повинна прочитати SerialNumber свого комп'ютера і знайти його в захищеній області. Якщо він є, то програма мовчки працює далі. Інакше вона порівнює кількість записаних SerialNumber і кількість ліцензій. Якщо кількість ліцензій не вичерпалося, то, після питання про правильність даної інсталяції, записує новий SerialNumber і ім'я комп'ютера в захищену область.
Таким чином, система обліку дасть можливість встановити програму на будь-яких п'яти комп'ютерах мережі і не дозволить встановити на шостий. Всі клієнтські частини ідентичні, що в свою чергу робить їх Upgrade легко здійсненним.
Тепер потрібно вирішити проблему перенесення програми з комп'ютера на комп'ютер. Як вказано вище, вона еквівалентна зміни SerialNumber будь-якого комп'ютера. Для цього доповнимо нашу програму системою деінсталяції. У програму включимо форму, яка ніколи список імен комп'ютерів, на яких інстальована ваша програма. Список формується, природно, з даних, взятих з захищеної області. У формі зробимо кнопку "Деінсталювати вказаний комп'ютер". При її натисканні з захищеної області видаляємо вказаний комп'ютер і його SerialNumber. Тепер, коли ліцензія звільнилася, покупець може скопіювати вашу програму на інший комп'ютер і запустити її там. Програма проведе інсталяцію, ніж та буде завершений процес перенесення. Таким чином, всі переміщення покупець може зробити сам, не звертаючись до вас. У тому числі може сам боротися з наслідками зміни SerialNumber будь-якого комп'ютера. Він його деінсталює і встановить заново. Турбот у вас при застосуванні динамічної прив'язки стане трохи менше.
Два зауваження:
- видалення останньої ліцензії повинно переводити програму знову в стан демоверсії;
- якщо куплена ліцензія тільки на один комп'ютер, то статична і динамічна прив'язки збігаються. Але для Access робота на одному комп'ютері - нетиповий випадок. Та й дозвіл на перенесення (новий ключ) ви даєте тільки на один комп'ютер, ризикуючи не надто багатьом.
При динамічної прив'язці непомітно опинилася вирішена ще одна, що раніше не зазначена проблема: реєстрація докупкі ліцензій. Якщо покупець введе ключ із збільшеною кількістю ліцензій, то програма замінить вміст захищеної області та буде заново інсталювати комп'ютери. Хоча тут можливо інше рішення: використання ключа іншого формату, відпрацьовуючи який, програма просто збільшить кількість ліцензій, допускаючи нові інсталяції.
Тепер ви готові вести динамічний облік комп'ютерів в мережі. І програму, здається, можна ставити покупцеві.
Однак, що буде, якщо він вирішить подарувати її дружній фірмі? Для цього він деінсталює всі комп'ютери, крім одного, і в цьому вигляді передасть базу іншій фірмі. Далі інсталює свої комп'ютери знову і буде працювати як раніше. А дружня фірма проведе інсталяцію своїх комп'ютерів. Тобто ця схема не захищена від незаконного копіювання з дозволу законного власника. Проблему треба вирішувати. Відзначимо, що і в разі статичної прив'язки вона існує, тільки переноситься на ваш розсуд при зверненні власника за новими ключами замість старих. А ваше рішення, як це не сумно, в разі віддаленості від фірми-покупця може бути тільки одне: дати їй нові ключі. Тобто, в статичної схемою від цієї ситуації по суті захисту немає.
6. Захист від незаконного копіювання з дозволу законного власника.
Логіка схеми: якщо все в порядку, то програма обов'язково запускається зі стартового (початкового) комп'ютера, що призводить до "вічної" установці всіх комп'ютерів і робить їх рівнозначними.
Якщо ваш покупець передав програму в іншу організацію, деінсталювати всі комп'ютери, крім одного, то в іншого організації запуску з цього єдиного "вічного" комп'ютера ніколи не буде. А всі інші комп'ютери, інстальовані в іншій організації отримають ненулевую дату. Далі спрацює захист від незаконного копіювання по даті інсталяції.
Діру в схемі знайдіть самі.
7. Захист від хакера.
Вся система захисту побудована на використанні SerialNumber. Але ж можна визначити і перехопити звернення до читання цього номера, і підсунути програмі відомий правильний номер, маючи ліцензію хоча б на один комп'ютер. Далі програму можна вільно поширювати разом з примочкою, підсовують правильний номер. Для програми це буде виглядати як робота на одному комп'ютері при реальній роботі багатьох. Не обманюйте себе думкою, що збільшивши число зчитувальних характеристик, ви захиститеся від підміни. Можна перехопити і підмінити читання будь-яких характеристик.
Але є захист і від підміни. При запуску ваша програма отримує номер процесу, який змінити не можна, не порушивши роботу Windows. Давайте запам'ятаємо і його при старті програми, доповнивши поточні характеристики комп'ютера. І будемо його перевіряти, скажімо, через кожні дві хвилини. Якщо він зміниться, то для програми це буде означати, що на одному комп'ютері ваша програма запущена двічі. Залишилося заборонити такий запуск, попередивши про це покупця. Тим самим ви захиститеся і від хакера.
8. Зберігання облікової інформації (захищена область).
Захист баз mde від незаконного копіювання - необхідна, але не сама трудомістка частина перетворення вашої програми в товарний продукт. Ось ще деякі інші: відновлення зруйнованих баз ваших клієнтів, рішення проблем роботи на моніторах з різним дозволом, Upgrade не тільки клієнтської частини, а й самої структури даних і забезпечення роботи зі старими структурами, автоматизація Upgrade в великих мережах, система налаштування зовнішнього вигляду форм під смаки різних користувачів, і, нарешті, сама ненависна програмістами частина - докладний контекстний хелп програми, що враховує невисоку кваліфікацію ваших майбутніх користувачів.
Так що: "Не поспішайте розділити радість шефа".