Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Захист файлів від несанкціонованого копіювання
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Інститут комп’ютерних наук та інформаційних технологій
Факультет:
Не вказано
Кафедра:
Кафедра систем автоматизованого проектування
Інформація про роботу
Рік:
2008
Тип роботи:
Курсова робота
Предмет:
Системне програмування та операційні системи
Група:
КН-24
Частина тексту файла (без зображень, графіків і формул):
Міністерство освіти і науки України
Національний університет «Львівська політехніка»
Інститут комп’ютерних наук та інформаційних технологій
Кафедра систем автоматизованого проектування
ПОЯСНЮВАЛЬНА ЗАПИСКА
до курсової роботи
з дисципліни “Системне програмування та операційні системи”
на тему: «Захист файлів від несанкціонованого копіювання»
Допущено до захисту: Оцінка: ________________
Дата: ______________ Залікова книжка № 0608425
Дата: __________________
Виконав:
студент групи КН-24
Прийняв:
Львів 2008
Анотація
Курсова робота з курсу “Системного програмування та операційні системи”.
Захист файлів від несанкціонованого копіювання, Львів: Національний університет “Львівська політехніка”, 2008.-37 с.
Обсяг даної курсової роботи включно із кодом програм становить 37 сторінки. Курсова робота складається з 3-ох розділів, у яких наведено основні теоретичні відомості про систему захисту файлів від несанкціонованого копіювання. Описано основні функції та модулі, з яких складається система.
Курсова робота ставить ціль – розуміння потреби захисту файлів від несанкціонованого копіювання і написання програми для цього.
Національний університет “Львівська політехніка”
Кафедра САПР
Дисципліна Системне програмування та операційні системи
Спеціальність Системи автоматизованого проектування
Курс 2 Група КН – 24 Семестр 2
Завдання на курсовий проект (роботу) студента
Зарічного Романа Ярославовича
1. Тема проекту /роботи/
Захист файлів від несанкціонованого копіювання
2. Термін здачі студентом закінченого проекту /роботи/
3. Вихідні дані для проекту /роботи/
4. Зміст розрахунково-пояснювальної записки /перелік питань, які підлягають розробці/
Короткі теоретичні відомості
Алгоритм виводу графічних файлів на екран
Текст програми
Висновок
5. Перелік графічного матеріалу / з точним зазначенням обов’язкових креслень/
Блок-схема алгоритму
6. Дата видачі завдання 18.03.2008
Календарний план
№ п/п
Назва етапів курсового проекту (роботи )
Термін виконання етапів проекту (роботи )
Примітки
1
Вибір та отримання завдання
18.03
Кафедра
2
Складання плану роботи над завданням
18.03 – 20.03
Дім
3
Пошук літератури для роботи над завданням
21.03 – 27.03
Бібліотека, інтернет
4
Опрацювання літератури
27.03 – 29.03
5
Повторне опрацювання усієї зібраної літератури та вибір найбільш корисної її частини
5.04 – 8.04
Під час вихідних дома
6
Вияснення найважливіших питань, що виникли в результаті опрацювання літератури
9.04 – 12.04
Викладач
7
Написання фрагментів програми на мові низького рівня Асемблер для реалізації задачі курсового проекту
16.04 – 21.04
8
Об’єднання фрагментів та написання повної програми для реалізації задачі курсового проекту
22.04 – 5.05
9
Оформлення курсового проекту
8.05 – 9.05
На вихідних дома
Студент
Зарічний Роман Ярославович
( підпис )
( прізвище, ім’я, по-батькові )
Керівник
Фармага Ігор Вірославович
( підпис )
( прізвище, ім’я, по-батькові )
____________________2008 р.
Зміст
Анотація…………………………………………………………………………... 2
Вступ……………………………………………………………………………… 6
2. Відомості по захисту файлів від несанкціонованого копіювання…..…….. 8
2.1. Структура системи захисту від несанкціонованого копіювання… 8
2.2. Підсистема впровадження механізмів, що управляють………….. 9
2.3. Блок визначення характеристик середовища……………………... 11
2.4. Вибір структури системи для реалізації…………………………… 12
3. Розробка програми захисту файлів від несанкціонованого копіювання…... 13
3.1. Вибір і обґрунтування мови програмування……………………… 13
3.2. Структура програми………………………………………………… 14
3.2.1. Модуль Frozen………………………………………………... 16
3.2.2. Модуль Install………………………………………………… 16
3.2.3. Модуль Ind…………………………………………………… 16
3.2.4. Запуск зовнішньої програми………………………………... 21
4. Фрагменти програми……………………………………………………….. 22
5. Висновок…………………………………………………………………….. 36
6. Література………………………………………………………………........ 36
Вступ
Моя програма написана на мові програмування Ассемблер. У цій пояснювальній записці я описую такі розділи і пункти: описовий розділ, в якому я в деталях представляю структуру системи захисту від несанкціонованого копіювання, яку я використав для написання цієї програми. Пунктами цього розділу є підсистема впровадження механізмів, що управляють, в якому описується класифікація системи захисту від несанкціонованого копіювання і способи впровадження захисного механізму в програми. Дальше йде пункт – блок визначення характеристик середовища, потім – вибір структури системи для реалізації системи захисту. Наступним розділом є конструктивний – це загальна структура програми, в якій описується принцип роботи програми. В кінці висновки.
Бурхливий розвиток інформаційних технологій і використання їх в самих різних, у тому числі і критичних областях людської діяльності привело до того, що крім завдань передачі, зберігання і обробки інформації виникла не менше, а у ряді випадків і важливіше завдання захисту інформації. Відповідно до прийнятої класифікації виділяють шість напрямів діяльності по захисту інформації:
1. Захист від несанкціонованого доступу в автоматизованих інформаційних системах, що має як програмну, так і апаратну реалізацію.
2. Захист інформації при передачі по каналах зв'язку і в засобах їх комутації (зокрема в локальних (ЛОМ) і розподілених обчислювальних мережах).
3. Захист юридичної значущості так званих «електронних» документів (у системі електронної пошти (e-mail) і ін.)
4. Захист від витоку інформації у вигляді побічних електромагнітних випромінювань і наведень (ПЕМВН).
5. Захист від програмних засобів прихованої інформаційної дії (окремим випадком яких є комп'ютерні віруси).
6. Захист від несанкціонованого копіювання і розповсюдження програм і баз даних.
В даний час у зв'язку з складним характером взаємин на ринку програмних продуктів проблема захисту від несанкціонованого копіювання є одним з найбільш гострих в області розробки програмних засобів. Економічний базис даної проблеми – несанкціоноване копіювання здійснюється тоді, коли у користувача існує потреба в експлуатації якогось програмного продукту, а витрати на копіювання істотно менше витрат на придбання легальної копії, яка коливається від 200$ для комп'ютерів домашнього використання до декількох тисяч доларів для професійних систем.
Для протидії спробам несанкціонованого копіювання використовуються різні методи захисту програмного забезпечення: організаційні, юридичні, програмні і програмно-апаратні. Найбільш популярними (принаймні в нашій країні є технічні, тобто програмні і програмно-апаратні методи, оскільки тільки вони забезпечують протидію у момент несанкціонованого копіювання програмного продукту, на відміну від інших, де санкції за нелегальне використання або відсутні, або рознесені в часі з моментом експлуатації нелегальної копії.
До теперішнього часу розроблені достатньо ефективні методи протидії несанкціонованому копіюванню, проте варто підкреслити, що не існує такого захисту, який було б неможливо (крім волі автора) зняти. Не повинно викликати сумнівів те, що досвідчений програміст, що володіє відповідними навиками, завжди зможе знайти те місце (ті місця) в захищеній програмі, де ухвалюється рішення про легальність копії, і, змінивши декілька байт (або навіть один єдиний байт) в коді програми може позбавити її можливості до самозахисту. Саме з цієї причини провідні фірми-виробники масового програмного забезпечення практично ніколи не ставлять захист на свої програми, справедливо вважаючи, що не варто витрачати сили і засобу на створення системи захисту (тим паче, що ці системи, як правило, заподіюють користувачеві певні незручності), якщо все одно програма буде розкрита.
Задачі в курсовій роботі:
Аналіз літератури.
Розробка алгоритму.
Реалізація та тестування програми.
Оформлення курсового проекту.
У курсовій роботі розроблено програму для захисту файлів від несанкціонованого копіювання. У ній містяться: анотація, зміст, вступ, короткі теоретичні відомості по системі захисту файлів від несанкціонованого копіювання, структура програми, сама програма, висновок і використана література.
2. Відомості по захисту файлів від несанкціонованого копіювання
2.1. Структура системи захисту від несанкціонованого копіювання
У загальному випадку система захисту від несанкціонованого копіювання є комплексом засобів, призначеним для ускладнення (у ідеалі – запобігання) нелегального копіювання (виконань) програмного модуля, що захищається, з яким вона асоційована.
Узагальнивши відомості з різних джерел можна запропонувати наступну структуру системи захисту від несанкціонованого копіювання (Рис. 1 Структура системи захисту від несанкціонованого копіювання)
Рис. 1 Структура системи захисту від несанкціонованого копіювання
Підсистема впровадження механізмів, що управляють, є комплексом програмних засобів, призначеним для підключення впроваджуваного захисного коду до програмного модуля, що захищається. Впроваджуваний захисний код – це програмний модуль, завдання якого полягає в протидії спробам запуску (виконань) нелегальної копії програми, що захищається.
Підсистема реалізації захисних функцій є програмною секцією, вирішальною завдання розпізнавання легальності запуску програми, що захищається.
Підсистема протидії нейтралізації захисних механізмів призначена для боротьби з можливими спробами нейтралізації системи захисту від несанкціонованого копіювання і/або її дискредитації.
Блок установки характеристик середовища відповідає за отримання характеристик, що ідентифікують обчислювальне середовище.
Блок порівняння характеристик середовища встановлює факт легальності запуску програми, що захищається.
Блок відповідної реакції реалізує у відповідь дії системи захисту на спроби несанкціонованого виконання програми, що захищається.
Наявність системи захисту передбачає наявність зловмисника, який намагатиметься якимсь чином нейтралізувати захист для вирішення завдання несанкціонованого копіювання. При цьому необхідно виразно розуміти, що не існує абсолютно стійкого захисту, а існують захисти, час подолання яких за витратами праці і машинного часу порівнянні з розробкою системи, аналогічні захищеній. Дане положення приводить до парадоксального на перший погляд результату – вірогідність нейтралізації захисту у елементарних програмних продуктів з середнім рівнем захищеності набагато нижче, ніж у складних програм з високим рівнем захисту.
В окремих випадках, при порівняно невисокій ціні однієї копії, кінцевому користувачеві буває вигідніше купити необхідне число інсталяцій, чим оплачувати кваліфіковану працю хакера.
Оскільки стійкість системи захисту визначається стійкістю кожного її елементу, то як об'єкт атаки може використовуватися будь-яка з описаних підсистем. Тут необхідно відзначити неоднорідний рівень як самих ідей, покладених в основі тієї або іншої підсистеми, так і їх реалізацій, що, в першу чергу пов'язано з розвитком прийомів, методів і засобів для нейтралізації систем захисту. Враховуючи сучасний стан питання, найбільш актуальним завданням, є розробка підсистеми впровадження механізмів системи захисту і підсистеми установки характеристик середовища, що управляють, хоча решта підсистем повинні бути розроблені не менш ретельно. Показовим прикладом є блок у відповідь реакції, який може як просто виводити повідомлення про незаконність копії (що вмить видає присутність системи захисту), так і робити складніші дії, що дозволяють на певний час замаскувати наявність захисту, збільшуючи тим самим час атаки.
Але якщо функціонування блоку у відповідь реакції може впливати на надійність системи лише непрямим чином, то часто найслабкішим місцем всієї системи є блок порівняння характеристик середовища і саме проти нього в першу чергу направлені атаки зловмисників.
2.2. Підсистема впровадження механізмів, що управляють
Системи захисту від несанкціонованого копіювання можна класифікувати за способом впровадження захисного механізму:
- вбудована (впроваджується при створенні програмного продукту);
- пристиковуюча (підключається до вже готового програмного продукту).
Найбільшу популярність останнім часом придбали системи другого типу. Це обумовлено рядом переваг, які дає їх використання:
- простота тиражування програмних систем захисту на об'єкти замовника і розробника;
- простота технології застосування;
- забезпечення достатнього рівня захищеності даних через спеціалізацію розробників;
- більш оптимальне співвідношення «надійність функціонування/витрати на розробку» в порівнянні з вбудованими системами, підготовленими непрофесіоналами.
Розглянемо способи установки захисних механізмів в програмні модулі, що захищаються.
Одним з варіантів вбудовування пристиковуваного модуля у виконуваний модуль є дописування його за вірусним принципом. (Природно, з розгляду виключаються варіанти, при яких програма перестає працювати або порушується логіка її роботи.) При цьому код захисту дописується в деяку область файлу, що захищається, і файл, що захищається, модифікується так, щоб управління передавалося на пристикований модуль захисту, який перевіряє легальність копії, і у разі позитивної відповіді передає управління на виконуваний модуль. Такий підхід до впровадження у виконувані файли має ряд істотних недоліків. По-перше, початковий код програми, що захищається, залишається практично в незмінному вигляді, що значно спрощує нейтралізацію захисту. По-друге, якщо передбачається захищати файли великого розміру і, як наслідок, з складною (може бути і з оверлейною) структурою, то необхідно враховувати те, що код, що знаходиться в кінці завантажений не буде, а значить програмний модуль не буде відпрацьований. Деякі недоліки можна усунути, якщо писати в початок програми не одну команду переходу, у весь код захисту. При цьому необхідно модифікувати таблицю переміщення (яка знаходиться в кінці заголовка EXE-файлу), у випадку якщо захищається файл типа EXE.
Основним недоліком захистів такого типу є те, що вони можуть бути нейтралізовані динамічно, шляхом визначення моменту, коли захисна частина вже відпрацювала і почав виконуватися сам код, що захищався. Прикладом такого підходу до нейтралізації захистів є програми SNAPSHOT і INTRUDER. Основна ідея методу, реалізованого в подібних програмах, полягає в двократному завантаженні досліджуваного модуля за різними адресами пам'яті з подальшим обчисленням всієї необхідної інформації на основі аналізу дампів пам'яті (під необхідною інформацією тут розуміється заголовок EXE-файлу, що містить всю інформацію, яка потрібна операційній системі для завантаження програми).
Іншим важливим недоліком описаних методів впровадження є те, що існуючі захисні механізми даного типу не можуть забезпечити коректний захист програм, що самомодифікуються, які в процесі виконання змінюють свій образ, що зберігається на диску.
Виходячи з вказаних недоліків, можна сформулювати наступні вимоги до пристиковуваних модулів:
- пристиковуваний модуль повинен підключатися до файлів будь-якого розміру;
- результуючий файл, отриманий після підключення пристиковуваного модуля, повинен бути влаштований так, щоб максимально ускладнити виділення початкової програми, що захищається;
- пристиковуваний модуль не повинен накладати обмежень на функціонування захищеної програми, зокрема, він повинен дозволяти модифікувати в процесі роботи свій власний дисковий файл.
2.3. Блок визначення характеристик середовища
Якщо структура системи захисту від несанкціонованого копіювання практично не залежить від вживаних способів захисту, то конкретна реалізація блоку установки характеристик середовища залежить від багатьох параметрів, серед яких можна виділити спосіб передбачуваної організації розповсюдження програмного забезпечення.
У загальному випадку програмне забезпечення може розповсюджуватися:
- безкоштовно (з альтруїзму і міркувань самореклами);
- умовно безкоштовно (за принципом «спробуй і купи» (try and buy), коли оплата проводиться добровільно і лише тоді, коли користувач погоджується з реальною користю для себе даного продукту);
- на комерційній основі.
Останній випадок (розповсюдження програмного продукту на комерційній основі) передбачає наявність захисту, який може включати або не включати технічні заходи.
За наявності технічних заходів захисту виробник може поширювати свій програмний продукт трьома основними способами, які визначають конкретну реалізацію блоку установки характеристик середовища:
- за допомогою спеціальної служби розповсюдження;
- через торгові організації;
- через вільне розповсюдження дистрибутивних (демонстраційних) пакетів з подальшою реєстрацією.
За наявності спеціальної служби розповсюдження контроль за дистрибутивними носіями замість технічних заходів здійснюється організаційними заходами. Співробітники служби розповсюдження виїжджають з дистрибутивними комплектами до замовників, де проводять установку програмного забезпечення на жорсткий диск. Оскільки наявність у користувача резервних копій не передбачається, то у разі збою потрібний повторний виїзд співробітника служби розповсюдження, що зазвичай розглядається як певна незручність. При даному способі блок установки характеристик середовища повинен уміти ідентифікувати тільки параметри комп'ютера, завдяки чому розробка блоку декілька спрощується.
У разі розповсюдження програмних продуктів через торгові організації можливі наступні варіанти:
- програма асоціює (зв'язує) себе з дистрибутивним носієм без «прив'язки» до конкретного комп'ютера;
- програма асоціює себе із спеціальним апаратним пристроєм, що підключається до комп'ютера і входить в дистрибутивний комплект;
- програма асоціює себе як з дистрибутивним носієм (при інсталяції), так і з параметрами комп'ютера (у робочому режимі).
Перші два варіанти зручні тим, що дозволяють переносити захищені програми з комп'ютера на комп'ютер, але як плату за це вимагають постійної присутності або ключової дискети, або спеціального апаратного пристрою.
Вільний від цих недоліків третій варіант вимагає крім забезпечення надійності ключової дискети рішення далеко не простій проблеми лічильника інсталяцій.
Достатньо цікавий третій спосіб розповсюдження програмного забезпечення – за допомогою вільного розповсюдження дистрибутивних (демонстраційних) пакетів. Суть цього способу краще всього описати наступним сценарієм. Користувач, все одно яким способом, отримує програму і запускає її на своєму комп'ютері. При запуску йому повідомляється деякий код, який разом з квитанцією про оплату він повинен передати розробникові. У відповідь йому повідомляється інший код, що є паролем для реєстрації копії програми і асоціації її з комп'ютером. За таким способом, наприклад, захищений колись популярний текстовий процесор «Слово і Справа».
Таким чином, залежно від вибраного способу розповсюдження програмного продукту, блок установки характеристик середовища повинен уміти ідентифікувати параметри комп'ютера, дистрибутивного носія, або спеціального апаратного пристрою.
2.4. Вибір структури системи для реалізації
У цьому параграфі на основі аналізу загальної структури системи захисту від несанкціонованого копіювання, проведеного в п. 2.1 – 2.3, вибирається структура системи для реалізації.
Для реалізації вибрана пристиковувала система захисту від несанкціонованого копіювання. Цей вибір визначили переваги, що даються її використанням, які перераховані в п. 2.2.
Враховуючи вимоги до пристиковуваних модулів, сформульовані в п. 2.2, в програмі реалізована наступна схема пристиковки. Файл, що захищається, шифрується і дописується в пристиковуваний модуль як дані. Коли пристикованому модулю необхідно передати управління на захищену програму, він розшифровує її в тимчасовий файл і запускає за допомогою функції DOS Exec. Після відробітку тимчасовий файл віддаляється.
Як стало ясно з п. 2.3, реалізація блоку установки характеристик середовища залежить від способу розповсюдження захищеного програмного продукту. При цьому при інсталяції програма асоціює себе з дистрибутивним носієм (ключовою дискетою), а в робочому режимі з параметрами комп'ютера. Такий спосіб не вимагає постійної присутності ключової дискети.
3. Розробка програми захисту файлів від несанкціонованого копіювання
3.1. Вибір і обґрунтування мови програмування
Мови програмування не можна порівнювати між собою поза зв'язком з вирішуваними задачами. Адже кожна мова спочатку проектувалася для максимально ефективного вирішення якогось свого класу завдань. Мова Фортран (Fortran - FORmula TRANslator – транслятор формул) – для чисельних обчислень, мова Лісп (Lisp –LISt Processing – обробка списків) – для вирішення завдань штучного інтелекту, Пролог (Prolog – PRO LOGic) – для програмування в термінах логіки і т.д. Таким чином ще до написання програми встає питання вибору мови програмування, яка б представляла найбільш відповідні засоби для вирішення поставленого завдання. Постановка завдання повинна бути ясна з вищесказаного. Нижче я постарався сформулювати основні вимоги до програмної реалізації і на основі як постановки завдання, так і цих вимог вибрати мову програмування.
Вимоги до програмної реалізації:
- Як можна менший об'єм коду, що дописується до програмного продукту, що захищається.
- Як можна менший час роботи коду захисту перед передачею управління основній (що захищається) програмі.
Для реалізації програми мною вибрана мова програмування асемблер (Assembler). Підкреслимо ті особливості мови, які і визначили цей вибір:
1) Асемблер є мовою низького (машинного) рівня, на відміну від мов високого рівня (ЯВУ), з яких найчастіше вживаними останнім часом є Бейсік (Basic), Паскаль (Pascal), Сі (С). Отже мова Асемблера максимально наближена до апаратних засобів комп'ютера і його «натуральних» можливостей, що дозволяє організувати безпосереднє управління апаратурою.
2) Програми на мові асемблера дуже детальні. Мова асемблера вимагає планування буквально кожного кроку ЕОМ. Людина, яка знайома тільки з мовами високого рівня, ймовірно, віднесе цю обставину до недоліку мови. Його можна зрозуміти, оскільки, по-перше, при великому об'ємі початкового тексту різко зростає вірогідність помилки, а по-друге, нескінченне число деталей може перешкодити добитися оптимальності програми в цілому. Проте, максимальна деталізація (адже одна мнемоніка мови асемблера відповідає одній машинній команді) дозволяє вирішувати задачі управління апаратурою максимально ефективно, тобто при невеликому об'ємі коду (це не означає маленького розміру початкового тексту) за мінімальний час.
3.2. Структура програми
Програма складається з трьох модулів:
Модуль Frozen - готує ключову дискету і записує на неї інсталятор, в який включає програму, що захищається.
Модуль Install, який перевіряє дискету і, якщо вона є ключовою, встановлює на вінчестер призначену для користувача програму (Task), захищену модулем Ind.
Модуль Ind, який при першому запуску визначає характеристики середовища і зберігає їх, а при всіх подальших запусках порівнює поточні характеристики середовища з визначеними при першому запуску. Якщо характеристики не змінилися, то модуль розшифровує і запускає Task. Після відробітку Task віддаляється з вінчестера.
3.2.1. Модуль Frozen
Модуль Frozen готує ключову дискету таким чином. На дискеті форматується доріжка з номером 80 (нумерація доріжок починається з нуля). Оскільки DOSом на дискетах об'ємом 1.44 мегабайта використовуються тільки доріжки з номерами від 0 до 79, ця дія ніяк не вплине на інформацію, що зберігається звичайним способом. Доріжки, що знаходяться за стандартним полем форматування (у разі дискети 1.44 мегабайта – це доріжки з номерами не меншого 80), називають інженерними циліндрами. У перший сектор восьмидесятої доріжки (довжина сектора – 512 байт, нумерація секторів ведеться з одиниці) записується лічильник копій і сигнатура. Лічильник копій є байт, який містить число інсталяцій захищеної програми, що залишилося. Програма Frozen запрошує у користувача кількість копій і отриманим числом ініціалізував лічильник копій. Сигнатурою є рядок «Copyright © KES_Company, 1998». Після цього на підготовлену дискету записується модуль Install, що включає програму Task, що захищається.
3.2.2. Модуль Install
Отже, модуль Frozen записує на ключову дискету модуль Install.
Модуль Install здійснює інсталяцію модуля Ind на жорсткий диск тільки при одночасному виконанні двох умов:
1) програма Install повинна бути запущена з ключової дискети – дискети, підготовленої модулем Frozen;
2) лічильник копій не повинен бути рівний нулю.
Отже, одним із завдань модуля Install є визначення факту достовірності ключової дискети. Дане завдання вирішується таким чином. Програма Install читає перший сектор восьмидесятої доріжки і, якщо він містить сигнатуру, то робиться висновок про достовірність ключової дискети. Після кожної інсталяції лічильник копій декрементируется. Якщо значення лічильника виявиться рівним нулю, то це означає те, що кількість інсталяцій (задане при підготовці дискети програмою Frozen) з даної дискети вичерпана. Після запису на жорсткий диск модуля Ind модуль Install запускає його на виконання. Сенс цієї дії буде зрозумілий з нижченаведеного опису модуля Ind.
3.2.3. Модуль Ind
При першому запуску програми Ind здійснюється прив'язка до індивідуальних характеристик комп'ютера для запобігання копіюванню програми на інший комп'ютер. Програма запам'ятовує характеристики комп'ютера, на якому вона була запущена вперше у внутрішніх полях і при подальших запусках порівнює їх з поточними. При неспівпаданні робиться висновок про несанкціоноване копіювання. Для того, щоб прив'язатися до конкретного комп'ютера не достатньо визначення який-небудь однієї характеристики (наприклад, процесора), оскільки по одному параметру не можна з достатньою упевненістю ідентифікувати комп'ютер (абсолютно очевидно, що в світі дуже багато комп'ютерів з однаковими процесорами).
Навіть, враховуючи те, що в світі існує безліч комп'ютерів з абсолютно однаковими характеристиками, ідентифікація комп'ютера безліччю його характеристик дає нам цілком надійну прив'язку.
Індивідуальні характеристики.
Індивідуальні характеристики, використовувані при роботі модулем Ind:
1) FDDCount – число накопичувачів на гнучких магнітних дисках (НГМД);
2) FDDType – тип накопичувачів НГМД;
3) BaseMemory – об'єм базової пам'яті;
4) ExtMemory – об'єм розширеної пам'яті (пам'яті понад 1 мегабайт);
5) BIOSData – дата видання ROM-BIOS;
6) CPUType – тип центрального процесора;
7) CPUFeature – інформація, що характеризує можливості центрального процесора;
8) VESAVersion – версія VBE (VESA BIOS Extension);
9) VideoMemory – об'єм відеопам'яті;
10)VESAOEMString – інформація виробника відеокарти.
Розглянемо тепер процес визначення цих характеристик.
Визначення числа НГМД
В області даних BIOS за адресою 0:0410h зберігається змінна подвійного слова, звана списком устаткування. Список устаткування включає число НГМД. Список устаткування заповнюється комп'ютером під час POST (Power-On Self-Test), ROM-програми, що виконується під час включення ПЕВМ. Біти 6-7 містять число НГМД, зменшене на одиницю.
Визначення типа накопичувачів НГМД, об'єму базової і розширеної пам'яті
У сучасних комп'ютерах для зберігання поточної конфігурації апаратних засобів використовується незалежна пам'ять CMOS. Ця пам'ять з погляду програміста складається з набору осередків, доступ до яких для читання і записи виконується через порти введення-висновку з адресами 70h і 71h. Процедура читання осередку CMOS складається з двох кроків. На першому кроці програма записує у вихідний порт з адресою 70h номера осередку, з якого необхідно прочитати інформацію. На другому кроці програма читає вміст даного осередку з вхідного порту з адресою 71h. У пам'яті CMOS зберігається поточний час і дата, зведення про конфігурацію системи, результат тестування при включенні живлення і інша інформація. Зокрема в осередку з адресою 10h зберігається тип накопичувачів НГМД, в осередках з адресами 15h-16h – об'єм основної пам'яті і в осередках з адресами 17h-18h – об'єм розширеної пам'яті (це значення дублюється в осередках 30h-31h).
Визначення дати видання ROM-BIOS
Дата видання ROM-BIOS в коді ASCII зберігається в області даних BIOS за адресою F000:FFF5 і займає 8 байт.
Визначення типу центрального процесора і інформації, характеризуючий його можливості
Спосіб розпізнавання процесорів Intel 8086/8088 заснований на тому факті, що біти 12-15 регістра FLAGS завжди встановлені в одиницю. Перш за все програма переписує поточний вміст регістра FLAGS в регістр AX. Для цього використовується стек:
PUSHF
POP AX
Далі програма намагається записати нульові значення в біти 12-15 регістра FLAGS:
AND AX,0FFFh
PUSH AX
POPF
Тепер потрібно перевірити, чи змінився вміст вказаних бітів регістра FLAGS. Для цього новий вміст регістра FLAGS переписується через стек в регістр AX, а потім після накладення маски 0F000h, порівнюється із значенням 0F000h:
PUSHF
POP AX
AND AX,0F000h
CMP AX,0F000h
JE this_8086
Якщо біти 12-15 залишилися встановленими в одиничне значення, програма працює на процесорі Intel 8086/8088, якщо немає – в комп'ютері встановлена більш старша модель процесора.
Програмні коди для визначення інших типів процесора не приводяться, оскільки вони аналогічні приведеним.
У процесорі Intel 80286, коли він працює в реальному режимі адресації, біти 12-15 регістра FLAGS завжди скинуті в нуль, що можна використовувати для виявлення цієї моделі процесора.
Для того, щоб відрізнити процесор Intel 80386 від процесорів старших моделей, можна спробувати встановити в регістрі EFLAGS біт 18. Цей біт був вперше визначений в процесорі Intel 80486 для сигналізації помилки вирівнювання. Його неможливо встановити в процесорі Intel 80386.
Відмітна особливість процесора Intel 80486 – неможливість зміни стану біта 21 регістра EFLAGS. Цей біт використовується процесорами Intel Pentium і більш старшими моделями процесорів Intel для визначення можливості виклику команди ідентифікації процесора CPUID.
У нових процесорах фірми Intel (включаючи всі процесори Pentium і старше) з'явилася нова команда CPUID, спеціально призначена для визначення моделі процесора. У програмі цю команду можна визначити у вигляді макросу таким чином:
CPUID MACRO
DB 0Fh
DB 0A2h
ENDM
Для визначення моделі процесора слід викликати команду CPUID, завантаживши заздалегідь в регістр EAX значення 1:
MOV EAX,1
CPUID
При цьому в регістр EAX буде завантажене слово сигнатури, по якому можна буде визначити модель процесора, а в регістр EDX – слово, що складається з окремих прапорів, що характеризують можливості процесора (feature flags). Саме вміст цих двох регістрів (EAX, EDX) і зберігається в полях CPUType (EAX) і CPUFeature (EDX) програми у випадку, якщо процесор не молодше Pentium. У решті випадків значення CPUFeature рівне нулю, а CPUType кодується таким чином:
CPUType
Процесор
1
Intel 8086/8088
2
Intel 80286
3
Intel 80386
4
Intel 80486
Визначення версії VBE, об'єму відеопам'яті і інформації виробника відеокарти
Визначення даних характеристик дає нам можливість ідентифікувати відеоадаптер комп'ютера.
MOV AX, 4F00h
ES:DI повинні указувати на буфер розміром 256, перші чотири байти якого повинні містити «VBE2»
INT 10h
Як результат виконання даної функції поля буфера заповнені інформацією, що характеризують відеоадаптер. У числі інших параметрів там міститься версія VBE, об'єм відеопам'яті, представлений в блоках розміром по 64 кілобайти, покажчик на рядок формату ASCIIZ, що містить інформацію фірми виробника відеокарти.
Групи характеристик
Використання індивідуальних характеристик заподіює користувачеві певні незручності, пов'язані з неможливістю зміни (у тому числі і розширення) складу апаратних засобів. І це обмеження є істотним, оскільки у наш час для того, щоб встигати за прогресом, потрібний постійний upgrade.
Всі індивідуальні характеристики розділені на групи. Кожна група характеристик ідентифікує який-небудь компонент комп'ютера (відеокарту, материнську плату (Motherboard), дисководи (FDD) і т.д.) При зміні характеристик в межах однієї групи не робиться висновку про незаконність копії, а здійснюється запам'ятовування змінених параметрів. Такий підхід дозволить користувачеві після заміни якогось одного (!) компоненту ЕОМ продовжити роботу із захищеною програмою. Якщо змінюється більш, ніж одна група, то в цьому випадку робиться висновок про несанкціоноване перенесення програми на інший комп'ютер.
Група
Компонент
Характеристики
FDD
Дисковод
FDDCount
FDDType
RAM
ОЗУ
BaseMemory
ExtMemory
BIOS
Материнська плата, ПЗП
BIOSData
CPU
Процесор
CPUType
CPUFeature
Video
Відеоадаптер
VESAVersion
VideoMemory
VESAOEMString
Зберігання індивідуальних характеристик
Зберігання індивідуальних характеристик організоване так, що їх не можна скопіювати стандартними засобами. Крім того, індивідуальні характеристики зберігаються в зашифрованому вигляді. Застосовується шифрування методом XOR з константою 0ABh. Відомо, що найменшою порцією інформації, що зберігається на жорсткому диску є кластер. Якщо програма займає не ціле число кластерів, то за логічними межами файлу залишається деякий простір, який і використовується для зберігання індивідуальних характеристик. При цьому виникає проблема – якщо дисковий простір за логічними межами файлу не вистачає для розміщення там індивідуальних характеристик. Дана проблема вирішується подовженням файлу на таку кількість байт, щоб гарантовано забезпечити необхідний простір. Ідея не копіювання розташованої таким чином інформації полягає в тому, що стандартні утиліти копіювання (Copy) не копіюють такий простір, орієнтуючись по реальній довжині файлу. При використанні даного методу, виявляється, не можна «законно» копіювати програму не тільки на інший комп'ютер, але і на комп'ютер, на який програма була встановлена. Таким чином на жорсткому дозволяється зберігати тільки одну працюючу копію програми. Проте, завдяки алгоритму переміщення операційної системи DOS (при переміщенні файлу переписується тільки номер початкового кластера, без копіювання файлу на нове місце), дозволяється переносити (Move) програму в інший каталог того ж диска без втрати працездатності.
Шифрування програми, що захищається
Програма (Task), що захищається, зберігається в модулі Ind в зашифрованому вигляді. З міркувань швидкодії (адже Task розшифровується при кожному “законному” запуску Ind) вибраний надзвичайно простій метод шифрування – метод XOR з константою 0A5h.
3.2.4. Запуск зовнішньої програми
У двох випадках нам доводилося запускати з програм інші програми:
1) з Install програму Ind;
2) з Ind програму Task.
Розглянемо цю процедуру детальніше. Під час роботи програми їй виділяється максимально доступна кількість оперативної пам'яті. Для того, щоб запустити зовнішню (по відношенню до поточної) програму необхідно звільнити таку кількість пам'яті, щоб вона вистачило для нормальної роботи програми, що запускається. Оскільки ми наперед не знаємо скільки пам'яті буде потрібно програмі, що захищається, звільнимо максимально можливий її об'єм. Це досягається таким чином. Сегменти програми розташовуються так, щоб кодовий сегмент виявився першим. На самому початку кодового сегменту кодується команда JMP. За нею розташовані тільки ті дані які необхідні для запуску зовнішнього процесу. Потім коди, які необхідні для запуску зовнішньої програми і завершальних дій після поверненні з неї. Безпосередньо перед запуском розмір виділеного батьківській програмі блоку пам'яті (за допомогою функції DOS 4Ah) зменшується так, що в пам'яті залишається розміщеною тільки запускаюча ділянка коду і його дані. Наступним кроком на нього передається управління.
3.2.5. Робота з НГМД
Всі дії, пов'язані з роботою з критичною інформацією ключової дискети, як те форматування доріжки з номером 80, читання/запис сектора 1 на 80 доріжці здійснюються, використовуючи програмування контроллера НГМД на фізичному рівні. Робота з НГМД ведеться через порти. Фрагменти програми, що реалізовують роботу з НГМД на фізичному рівні приводяться в додатку 6.3.
6.3. Фрагменти програм
Фрагменти програм комплексу, що реалізовують роботу з НГМД на фізичному рівні.
1) Макроси, що полегшують роботу з процедурами нижнього рівня, що безпосередньо здійснюють управління НГМД. (Файл ngmd.mac.)
;Передача байта в контроллер НГМД
out_ngmd MACRO byte
LOCAL @Ok
mov AH,byte
call OUTFDC
jnc @Ok
FatalError
@Ok:
ENDM
; Прийом байта з контроллера НГМД
in_ngmd MACRO Mem
LOCAL @Ok
push AX
call INFDC
jnc @Ok
jmp @ErrFatal
@Ok: IFNB <Mem>
mov Mem,AL
ENDIF
pop AX
ENDM
; Очікування переривання від контроллера НГМД
WaitInt MACRO
LOCAL @Ok
call _WaitInt
jnc @Ok
FatalError
@Ok:
ENDM
; Критична помилка
FatalError MACRO
jmp @ErrFatal
ENDM
; Позиціонування головки дисковода
; Вхід:
; D – номер накопичувача
; HDS – номер головки
; NCN – номер доріжки
ngmdSeek MACRO D,HDS,NCN
LOCAL @Ok
mov DL,D
mov DH,HDS
mov CH,NCN
shl DH,2
or DL,DH
call _ngmdSeek
jnc @Ok
FatalError
@Ok:
ENDM
; Читання сектора
; D – номер дисковода
; HDS – номер головки (сторони)
; NCN – номер доріжки
; R – номер сектора
; Buf - буфер
ngmdRead MACRO D,HDS,NCN,R,Buf
mov DL,D
mov DH,HDS
mov CH,NCN
mov CL,R
mov AX,DS
mov ES,AX
lea DI,Buf
call _ngmdRead
ENDM
; Запис сектора
; D – номер дисковода
; HDS – номер головки (сторони)
; NCN – номер доріжки
; R – номер сектора
; Buf - буфер
ngmdWrite MACRO D,HDS,NCN,R,Buf
mov DL,D
mov DH,HDS
mov CH,NCN
mov CL,R
mov AX,DS
mov ES,AX
lea DI,Buf
call _ngmdWrite
ENDM
2) Фрагмент модуля Frozen, що демонструє форматування доріжки. (Файл frozen.asm.)
; Змінна для зберігання старого вектора 8h
Old_8h dd 0
; Змінна для організації затримок
RtCounter dw 0
; Власний обробник переривання 8h (Timer)
; для організації затримок
Int_8h PROC
push AX
cmp CS:RtCounter,0
je New08IRet
dec CS:RtCounter
New08IRet:
; Стандартні дії по коректуванню часу
push DS
mov AX,40h ;Настройка на область даних BIOS
mov DS,AX
add WORD PTR DS:[6Ch],1
adc WORD PTR DS:[6Eh],0
cmp WORD PTR DS:[6Eh],0018h
jne New08Time
cmp WORD PTR DS:[6Ch],00B0h
jne New08Time
mov BYTE PTR DS:[70h],1
mov WORD PTR DS:[6Ch],0
mov WORD PTR DS:[6Eh],0
New08Time: pop DS
mov AL,20h
out 20h,AL
jmp SHORT $+2
pop AX
iret
Int_8h ENDP
; Прапор для установки факту приходу переривання
f_Int0Eh db 0
; Змінна для зберігання старого вектора 0Eh
Old_0Eh dd 0
; Власний обробник переривання 0Eh
; для визначення факту приходу переривання від НГМД
Int_0Eh PROC
push AX
mov CS:f_Int0Eh,1
mov AL,20h
out 20h,AL
jmp SHORT $+2
pop AX
iret
Int_0Eh ENDP
Main PROC
; Пропущено (skip)
; Настроювання ES на таблицю векторів переривань
xor AX, AX
mov ES,AX
; Збереження вектора 8h (Timer)
GetIntVec 8h,CS:Old_8h
; Установка свого обробника переривання 8h
SetIntVec 8h
; Збереження вектора 0Eh (переривання від НГМД)
GetIntVec 0Eh,CS:Old_0Eh
; Установка свого обробника переривання 0Eh
SetIntVec 0Eh
; Установка швидкості передачі даних між контроллером і накопичувачем
xor AX, AX ;500 килобит/сек
mov DX,03F7h ;CCR
out DX,AL
jmp SHORT $+2
; Скидання контроллера НГМД
call _ngmdReset
; Підготовка таблиці формату
lea SI,FormatBuf
mov BYTE PTR DS:[SI],4Dh ;Код команди FORMAT
mov BYTE PTR DS:[SI+1],0 ;головка 0, накопичувач A:
mov BYTE PTR DS:[SI+2],2 ;Розмір сектори – 512 байт
mov BYTE PTR DS:[SI+3],18 ;Кількість секторів
mov BYTE PTR DS:[SI+4],108 ;Розмір GAP3
mov BYTE PTR DS:[SI+5],066h ;Символ-заповнювач
add SI,2
mov CX,18
xor AX, AX
PrepForFormat:
inc AL
add SI,4
mov BYTE PTR DS:[SI],80 ;Циліндр
mov BYTE PTR DS:[SI+1],0 ;Поверхність
mov BYTE PTR DS:[SI+2],AL ;Номер сектори
mov BYTE PTR DS:[SI+3],2 ;Код довжини сектора
loop PrepForFormat
; Позиціонування головки дисковода A:
; головка - 0
; доріжка - 80
ngmdSeek 0,0,80
push DS
pop ES
mov AL,4Ah
mov CX,18*4
lea DI,FormatBuf
add DI...
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора