Подякувати Студентському архіву довільною сумою
Admin
26.02.2023 12:38
Дякуємо, що користуєтесь нашим архівом!
Захист файлів від несанкціонованого копіювання.
Інформація про навчальний заклад
ВУЗ:
Національний університет Львівська політехніка
Інститут:
Не вказано
Факультет:
Не вказано
Кафедра:
Кафедра САПР
Інформація про роботу
Рік:
2024
Тип роботи:
Курсова робота
Предмет:
Системне програмування та операційні системи
Частина тексту файла (без зображень, графіків і формул):
Міністерство освіти і наукиУкраїни
Національний університет “Львівська політехніка”
Кафедра САПР
Курсова робота
З дисципліни
“Системне програмування та операційні системи”
На тему :
“Захист файлів від несанкціонованого копіювання ”
Львів 200*р
Анотація
Курсова робота з курсу “Системного програмування та операційні системи”.
Захист файлів від несанкціонованого копіювання /**********, Львів: Національний університет “Львівська політехніка”, 200*.-34 с.
Обсяг даної курсової роботи включно із кодом програм становить 34 сторінок. Курсова робота складається з 3-ох розділів, у яких наведено основні теоретичні відомості про систему захисту файлів від несанкціонованого копіювання. Описано основні функції та модулі, з яких складається система.
Курсова робота ставить ціль – програму для захисту файлів від несанкціонованого копіювання.
ЗМІСТ
Анотація…...………………………………………………………………………...2
Вступ 6
2. Описовий розділ 8
2.1. Структура системи захисту від несанкціонованого копіювання. 8
2.2. Підсистема впровадження механізмів, що управляють. 10
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
3.2.5. Робота з НГМД. 22
4. Висновки 23
5. Література 23
6. Додаток 24
6.1. Вимоги до апаратури. 24
6.2. Вимоги до програмного забезпечення. 24
6.3. Фрагменти програм. 25
Вступ
Моя програма написана на мові програмування Ассемблер. У цій пояснювальній записці я описую такі розділи і пункти: описовий розділ, в якому я в деталях представляю структуру системи захисту від несанкціонованого копіювання, яку я використав для написання цієї програми. Пунктами цього розділу є підсистема впровадження механізмів, що управляють, в якому описується класифікація системи захисту від несанкціонованого копіювання і способои впровадження захисного механізму в програми. Дальше йде пункт – блок визначення характеристик середовища, потім – вибір структури системи для реалізації системи захисту. Наступним розділом є конструктивний – це загальна структура програми, в якій описується принцип роботи програми. В кінці висновки.
Бурхливий розвиток інформаційних технологій і використання їх в самих різних, у тому числі і критичних областях людської діяльності привело до того, що крім завдань передачі, зберігання і обробки інформації виникла не менше, а у ряді випадків і важливіше завдання захисту інформації. Відповідно до прийнятої класифікації виділяють шість напрямів діяльності по захисту інформації:
1. Захист від несанкціонованого доступу в автоматизованих інформаційних системах, що має як програмну, так і апаратну реалізацію.
2. Захист інформації при передачі по каналах зв'язку і в засобах їх комутації (зокрема в локальних (ЛОМ) і розподілених обчислювальних мережах).
3. Захист юридичної значущості так званих «електронних» документів (у системі електронної пошти (e-mail) і ін.)
4. Захист від витоку інформації у вигляді побічних електромагнітних випромінювань і наведень (ПЕМВН).
5. Захист від програмних засобів прихованої інформаційної дії (окремим випадком яких є комп'ютерні віруси).
6. Захист від несанкціонованого копіювання і розповсюдження програм і баз даних.
В даний час у зв'язку з складним характером взаємин на ринку програмних продуктів проблема захисту від несанкціонованого копіювання є одним з найбільш гострих в області розробки програмних засобів. Економічний базис даної проблеми – несанкціоноване копіювання здійснюється тоді, коли у користувача існує потреба в експлуатації якогось програмного продукту, а витрати на копіювання істотно менше витрат на придбання легальної копії, яка коливається від 200$ для комп'ютерів домашнього використання до декількох тисяч доларів для професійних систем.
Для протидії спробам несанкціонованого копіювання використовуються різні методи захисту програмного забезпечення: організаційні, юридичні, програмні і програмно-апаратні. Найбільш популярними (принаймні в нашій країні є технічні, тобто програмні і програмно-апаратні методи, оскільки тільки вони забезпечують протидію у момент несанкціонованого копіювання програмного продукту, на відміну від інших, де санкції за нелегальне використання або відсутні, або рознесені в часі з моментом експлуатації нелегальної копії.
До теперішнього часу розроблені достатньо ефективні методи протидії несанкціонованому копіюванню, проте варто підкреслити, що не існує такого захисту, який було б неможливо (крім волі автора) зняти. Не повинно викликати сумнівів те, що досвідчений програміст, що володіє відповідними навиками, завжди зможе знайти те місце (ті місця) в захищеній програмі, де ухвалюється рішення про легальність копії, і, змінивши декілька байт (або навіть один єдиний байт) в коді програми може позбавити її можливості до самозахисту. Саме з цієї причини провідні фірми-виробники масового програмного забезпечення практично ніколи не ставлять захист на свої програми, справедливо вважаючи, що не варто витрачати сили і засобу на створення системи захисту (тим паче, що ці системи, як правило, заподіюють користувачеві певні незручності), якщо все одно програма буде розкрита.
2. Описовий розділ
2.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. Структура програми
Програма складається з трьох модулів:
1) Модуль Frozen - готує ключову дискету і записує на неї инсталлятор, в який включає програму, що захищається.
Frozen
Install
Ind
Task
Install
Ind
Task
На дискету
2) Модуль Install, який перевіряє дискету і, якщо вона є ключовою, встановлює на вінчестер призначену для користувача програму (Task), захищену модулем Ind.
Install
З дискети
Ind
Task
Ind
Task
3) Модуль Ind, який при першому запуску визначає характеристики середовища і зберігає їх, а при всіх подальших запусках порівнює поточні характеристики середовища з визначеними при першому запуску. Якщо характеристики не змінилися, то модуль розшифровує і запускає Task. Після відробітку Task віддаляється з вінчестера.
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 байт.
Визначення типу центрального процесора і інформації, характеризуючій його можливості.
Для визначення процесорів молодше Pentium використана методика, викладена в [14].
Спосіб розпізнавання процесорів 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 кодується таким чином:
Визначення версії VBE, об'єму відеопам'яті і інформації виробника відеокарти.
Визначення даних характеристик дає нам можливість ідентифікувати відеоадаптер комп'ютера.
MOV AX, 4F00h
ES:DI повинні указувати на буфер розміром 256, перші чотири байти якого повинні містити «VBE2»
INT 10h
Як результат виконання даної функції поля буфера заповнені інформацією, що характеризують відеоадаптер. У числі інших параметрів там міститься версія VBE, об'єм відеопам'яті, представлений в блоках розміром по 64 кілобайти, покажчик на рядок формату ASCIIZ, що містить інформацію фірми виробника відеокарти.
Групи характеристик.
Використання індивідуальних характеристик заподіює користувачеві певні незручності, пов'язані з неможливістю зміни (у тому числі і розширення) складу апаратних засобів. І це обмеження є істотним, оскільки у наш час для того, щоб встигати за прогресом, потрібний постійний upgrade. Автор програми спробував декілька пом'якшити цю незручність.
Всі індивідуальні характеристики розділені на групи. Кожна група характеристик ідентифікує який-небудь компонент комп'ютера (відеокарту, материнську плату (Motherboard), дисководи (FDD) і т.д.) При зміні характеристик в межах однієї групи не робиться висновку про незаконність копії, а здійснюється запам'ятовування змінених параметрів. Такий підхід дозволить користувачеві після заміни якогось одного (!) компоненту ЕОМ продовжити роботу із захищеною програмою. Якщо змінюється більш, ніж одна група, то в цьому випадку робиться висновок про несанкціоноване перенесення програми на інший комп'ютер.
Зберігання індивідуальних характеристик.
Зберігання індивідуальних характеристик організоване так, що їх не можна скопіювати стандартними засобами. Крім того, індивідуальні характеристики зберігаються в зашифрованому вигляді. Застосовується шифрування методом 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.
4. Висновки
Дана програма системи захисту файлів від несанкціонованого копіювання працює наступним чином:
Модуль Frozen - готує ключову дискету і записує на неї инсталлятор, в який включає програму, що захищається. Модуль Install, який перевіряє дискету і, якщо вона є ключовою, встановлює на вінчестер призначену для користувача програму (Task), захищену модулем Ind. Модуль Ind, який при першому запуску визначає характеристики середовища і зберігає їх, а при всіх подальших запусках порівнює поточні характеристики середовища з визначеними при першому запуску. Якщо характеристики не змінилися, то модуль розшифровує і запускає Task. Після відробітку Task віддаляється з вінчестера.
1) Проаналізована загальна структура системи захисту від несанкціонованого копіювання і на основі цього аналізу вибрана структура системи для реалізації.
2) Розроблена система захисту від копіювання відповідно до завдання на курсовий проект.
3) Прив'язка до конкретного комп'ютера здійснена з використанням безлічі його індивідуальних характеристик. (Як показано в п. 3.2.3 одній такої характеристики недостатньо.)
4) Розроблена концепція об'єднання індивідуальних характеристик в групи, використання якої зменшує незручності користувача системи. (Див. п. 3.2.3.)
5) Використано програмування контроллера НГМД на фізичному рівні, за допомогою чого організована робота з ключовою дискетою.
Література
1) Абель П. Язык Ассемблера для IBM PC и программирования / Пер. с англ. Ю.В. Сальникова. - М.: Высш. шк., 1992. - 447 с.: ил.
2) Бродин В.Б., Шагурин И.И. Микропроцессор i486. Архитектура, программирование, интерфейс. - М.: «ДИАЛОГ-МИФИ», 1993. - 240 с.
3) Григорьев В.Л. Микропроцессор i486. Архитектура и программирование (в 4-х книгах). Книга 1. Программная архитектура. Книга 2. Аппаратная архитектура. Книга 3. Устройство с плавающей точкой. Книга 4. Справочник по системе команд. - М., ГРАНАЛ, 1993. - с. 382, ил. 54
4) Касперский Е. Компьютерные вирусы в MS-DOS. М.: Издательство «ЭДЭЛЬ», 1992. - 176 с.
5) Нортон П., Соухэ Д. Язык ассемблера для IBM PC: Пер. с англ., - М.: Издательство «Компьютер»; Финансы и статистика, 1992. - 352 с.: ил.
6) Пильщиков В.Н. Программирование на языке ассемблера IBM PC. - М.: «ДИАЛОГ-МИФИ», 1996. - 288 с.
7) Правиков Д.И. Ключевые дискеты. Разработка элементов систем защиты от несанкционированного копирования. – М.: Радио и связь, 1995. – 128 с.: ил.
8) Скляров В.А. Применение ПЭВМ. В 3 кн. Кн. 1. Организация и управление ресурсами ПЭВМ: Практ. пособие. - М.: Высш. шк., 1992. 158 с.: ил.
9) Скляров В.А. Применение ПЭВМ. В 3 кн. Кн. 2. Операционные системы ПЭВМ: Практ. пособие. - М.: Высш. шк., 1992. 144 с.: ил.
10) Скэнлон Л. Персональные ЭВМ IBM PC и XT. Программирование на языке ассемблера: Пер. с англ. - 2-е изд., стереотип. - М.: Радио и связь. 1991. - 336 с.: ил.
11) Фодор Ж., Бонифас Д., Танги Ж. Операционные системы - от PC до PS/2: Пер. с франц. - М.: Мир, 1992. - 319 с., ил.
12) Фаронов В.В. Турбо Паскаль (в 3-х книгах). Кн. 3. Практика программирования. Часть 2. - М.: Учебно-инженерный центр «МВТУ - ФЕСТО ДИДАКТИК», 1993. - 304 с., ил.
13) Финогенов К.Г. Самоучитель по системным функциям MS-DOS. - Изд. 2, перераб. и дополн. - М.: Радио и связь, Энтроп, 1995. - 382 с., ил.
14) Фролов А.В., Фролов Г.В. Аппаратное обеспечение персонального компьютера. - М.: ДИАЛОГ-МИФИ, 1997. - 304 с. - (Библиотека системного программиста; Т. 33)
15) Хоган Т. Аппаратные и программные средства персональных компьютеров: Справочник. В 2-х кн. Кн.1. - М.: Радио и связь, 1995. - 384 с.
16) 2B ProGroup: Вегнер В.А., Крутяков А.Ю., Серегин В.В., Сидоров В.А., Спесивцев А.В. Аппаратура персональных компьютеров и её программирование. IBM PC/XT/AT и PS/2. - М: Радио и связь, 1995. - 224 с. - (Библиотека системного программиста).
17) 2B Programmers Group: Спесивцев А.В., Вегнер В.А., Крутяков А.Ю., Серегин В.В., Сидоров В.А. Защита информации в персональных ЭВМ. - М.: Радио и связь, МП «Веста», 1992. - 192 с.: ил. - (Библиотека системного программиста)
6. Додаток
6.1. Вимоги до апаратури.
1) Програма працює тільки з дискетами розміром 3.5” об'ємом 1.44 мегабайта, які форматовані стандартним чином.
6.2. Вимоги до програмного забезпечення.
1) Програми комплексу повинні бути запущені в реальному режимі з-під DOS версії 6.22.
2) Оскільки програми комплексу відмірюють величини затримок, використовуючи вбудований інтервальний таймер, він повинен бути запрограмований стандартним чином.
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...
Ділись своїми роботами та отримуй миттєві бонуси!
0%
Оголошення від адміністратора