Захист виконуваного файлу від зворотного проектування?

Я роздумував над тим, як захистити свій код C / C ++ від розбирання та зворотної інженерії. Зазвичай я ніколи не потураю собі такої поведінки у своєму коді; однак діючий протокол, над яким я працював, ніколи не повинен перевірятися чи зрозуміти, для безпеки різних людей.

Тепер це нова тема для мене, і Інтернет не дуже ресурсний для запобігання проти зворотної інженерії, але, скоріше, зображує багато інформації про те, як повернути інженера

Деякі речі, про які я думав поки що:

• Введення коду (виклик фіктивних функцій до і після фактичних викликів функції)
• Заглушення коду (маніпулює розбиранням двійкового)

• Напишіть мої власні процедури запуску (важче зв’язати налагоджувачів)

  void startup();  
  int _start()   
  {  
      startup( );  
      exit   (0)   
  }  
  void startup()  
  {  
      /* code here */  
  }

• Перевірка налагодження для відладчиків (і примусовий вихід, якщо виявлений)

• Функціонуючі батути

   void trampoline(void (*fnptr)(), bool ping = false)  
   {  
     if(ping)  
       fnptr();  
     else  
       trampoline(fnptr, true);  
   }

• Безглузді асигнування та угоди (стек сильно змінюється)

• Безглузді виклики манекенів і батути (тонни стрибків у розбиранні)
• Тон лиття (для прихованого розбирання)

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

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

Це сказало, що найкращі методи реверсивної інженерії, які я бачив, зосереджувались не на ослабленні коду, а на розбитті інструментів, які люди зазвичай використовують, щоб зрозуміти, як працює код. Пошук творчих способів розбити демонтажників, налагоджувачів тощо, ймовірно, буде більш ефективним, а також більш інтелектуально задовольняючим, ніж просто генерувати пачки жахливого коду спагетті. Це не робить нічого для блокування рішучого нападника, але це збільшує ймовірність того, що J Random Cracker замість себе скинеться і працюватиме на щось легше.

але вони можуть бути вирішені чи розібрані аналізаторами кодів з урахуванням правильних часових рамків.

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

Безпечний чистий Sentinel (раніше Аладдін). Caveats, хоча - їх API відсмоктує, документація смокче, і обидва вони чудові порівняно зі своїми інструментами SDK.

Я багато років використовував їх апаратний метод захисту ( Sentinel HASP HL ). Для цього потрібен фірмовий USB-ключ, який діє як "ліцензія" на програмне забезпечення. Їх SDK шифрує та обшиває ваші виконувані файли та бібліотеки та дозволяє прив’язувати різні функції у вашому додатку до функцій, записаних у ключ. Без ключа USB, наданого та активованого ліцензіаром, програмне забезпечення не може розшифруватися, а значить, не запуститься. Ключ навіть використовує індивідуальний протокол зв'язку USB (поза моєю сферою знань, я не є драйвером драйвера пристрою), щоб ускладнити побудову віртуального ключа або підробити зв'язок між обгорткою виконання та ключем. Їх SDK не дуже зручний для розробників, і досить болісно інтегрувати додавання захисту з автоматизованим процесом збирання (але можливо).

Перш ніж ми застосували HASP HL-захист, було відомих 7 піратів, які позбавили «захист» дотфускатора від виробу. Ми додали захист HASP одночасно з основним оновленням програмного забезпечення, яке виконує важкі обчислення відео у режимі реального часу. Як найкраще я можу сказати з профілювання та бенчмаркінгу, захист HASP HL ​​лише уповільнив інтенсивні розрахунки приблизно на 3%. Оскільки це програмне забезпечення було випущено близько 5 років тому, не знайдено жодного нового пірата продукту. Програмне забезпечення, яке він захищає, користується великим попитом у своєму ринковому сегменті, і клієнт знає про декількох конкурентів, які активно намагаються змінити інженера (без успіху поки що). Ми знаємо, що вони намагалися звернутися за допомогою до декількох груп у Росії, які рекламують послугу з порушення захисту програмного забезпечення,

Нещодавно ми спробували їх ліцензійне рішення для програмного забезпечення (HASP SL) на меншому проекті, який був достатньо простий для роботи, якщо ви вже знайомі з продуктом HL. Здається, працює; не було зафіксовано випадків піратства, але цей товар є значно нижчим попиту ..

Звичайно, жоден захист не може бути ідеальним. Якщо хтось достатньо мотивований і має серйозні гроші, щоб спалити, я впевнений, що захист, який надає HASP, можна обійти.

Найкращі хитрощі щодо розбирання, зокрема щодо наборів інструкцій зі змінною довжиною слова, містяться в асемблері / машинному коді, а не C.

CLC
BCC over
.byte 0x09
over:

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

Я думаю, що це було майже на початку мови «Збірки мови Майкла Абраша», де він показав простий трюк проти розбирання та проти налагодження. У 8088/6 була черга попереднього вибору, що ви робили, - це була інструкція, яка змінювала наступну інструкцію або пару вперед. Якщо одноразовим кроком було виконано модифіковану інструкцію, якщо ваш симулятор набору інструкцій повністю не імітував обладнання, ви виконали модифіковану інструкцію. На звичайному апаратному забезпеченні, що працює нормально, реальна інструкція вже буде в черзі, і змінене місце пам’яті не призведе до будь-яких збитків, якщо ви не виконали цю рядок інструкцій ще раз. Можливо, ви все ще можете використовувати такий трюк сьогодні, коли конвеєрні процесори отримують наступну інструкцію. Або якщо ви знаєте, що обладнання має окрему кеш інструкцій та даних, ви можете змінити кількість байтів наперед, якщо правильно вирівняти цей код у рядку кешу, модифікований байт записується не через кеш інструкцій, а в кеш даних та тренажер набору інструкцій, який не мав належних тренажерів кешу, не вдалося виконати належним чином. Я думаю, що тільки програмні рішення не дадуть вам дуже далеко.

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

Раніше було, що хакерам знадобиться близько 18 місяців, щоб щось розробити, наприклад DVD. Зараз вони в середньому становлять від 2 днів до 2 тижнів (якщо вони вмотивовані) (блакитний промінь, iphone тощо). Це означає для мене, якщо я витрачаю більше ніж кілька днів на безпеку, я, швидше за все, витрачаю свій час. Єдина реальна безпека, яку ви отримаєте, - це апаратне забезпечення (наприклад, ваші інструкції шифруються, і лише ядро ​​процесора добре всередині чіпа розшифровується безпосередньо перед виконанням таким чином, що він не може викрити розшифровані інструкції). Це може купувати вас місяцями замість днів.

Також прочитайте книгу Кевіна Мітніка «Мистецтво обману». Людина, що подобається, може забрати телефон і дозволити вам або колезі роздати секрети системі, думаючи, що це менеджер або інший колега або інженер-апаратник в іншій частині компанії. І ваша безпека підірвана. Безпека - це не все в управлінні технологією, треба керувати і людьми.

Візьмемо, наприклад, алгоритм AES . Це дуже, дуже публічний алгоритм, і він ДУЖЕ безпечний. Чому? Дві причини: Його переглядали багато розумних людей, а "секретна" частина - це не сам алгоритм - секретна частина - це ключ, який є одним із входів алгоритму. Це набагато краще підходи до проектування вашого протоколу з генерованим "секретом", який знаходиться поза вашим кодом, а не робити сам код таємним. Код завжди можна інтерпретувати незалежно від того, чим ви займаєтесь, і (в ідеалі) створений секрет може бути поставлений під загрозу лише шляхом масового підходу грубої сили або через крадіжку.

Думаю, цікаве запитання: " Чому ви хочете придушити свій код?" Ви хочете ускладнити зловмисникам зламати алгоритми? Щоб їм було складніше знаходити помилки, що експлуатуються, у вашому коді? Вам не потрібно буде придушувати код, якби коду в першу чергу було неможливо. Корінь проблеми - це програмне забезпечення, яке може бути важким. Виправте корінь вашої проблеми, не просто придушуйте її.

Крім того, чим більш заплутаним ви будете робити свій код, тим важче буде ВАС знайти помилки безпеки. Так, хакерам буде важко, але вам також потрібно знайти помилок. Код повинен бути простим у дотриманні років відтепер, і навіть добре написаний чіткий код може бути важким у дотриманні. Не гіршайте.

Складність коду для реверсивного інженера називається обфускуванням коду.

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

Для ефективної обфузації потрібно зробити поведінку вашої програми залежною від марних бітів, які виконуються. Наприклад, а не робити це:

a = useless_computation();
a = 42;

зробити це:

a = complicated_computation_that_uses_many_inputs_but_always_returns_42();

Або замість цього робити:

if (running_under_a_debugger()) abort();
a = 42;

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

a = 42 - running_under_a_debugger();

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

some_function();

зробіть це, коли вам трапиться знати точний очікуваний макет бітів у some_data_structure:

goto (md5sum(&some_data_structure, 42) & 0xffffffff) + MAGIC_CONSTANT;

Якщо ви серйозно ставитеся до затухання, додайте до свого планування кілька місяців; опухання не дешеве. І вважайте, що на сьогоднішній день найкращим способом уникнути зворотної інженерії людей ваш код - це зробити його марним, щоб вони не турбувались. Це простий економічний розгляд: вони реверсують, якщо вартість для них більша, ніж вартість; але підвищення їх вартості також збільшує ваші витрати, тому спробуйте знизити їх вартість.

Тепер, коли я сказав вам, що затуплення важке і дороге, я все одно скажу, що це не для вас . Ви пишете

Поточний протокол, над яким я працював, ніколи не повинен перевірятися або зрозуміти, для безпеки різних людей

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

Рекомендоване читання:

• Біблія про безпеку: Техніка безпеки Росса Андерсона
• Біблія опустошення : приховане програмне забезпечення Крістіана Колберга та Жасвіра Награ

Багато разів страх того, що ваш продукт буде інженерно-реверсивним, не вдається. Так, це може отримати реверс; але чи стане він настільки відомим за короткий проміжок часу, що хакерам виявиться, що варто перевернути engg. це? (ця робота не є невеликою часовою діяльністю для значних рядків коду).

Якщо це дійсно стає заробітком грошей, то ви повинні зібрати достатньо грошей, щоб захистити їх, використовуючи законні способи, як, патент та / або авторські права .

ІМХО, прийміть основні запобіжні заходи, які ви збираєтесь вжити, і відпустіть його. Якщо це стане точкою зворотної інженерії, що означає, що ви зробили дійсно хорошу роботу, ви самі знайдете кращі способи її подолання. Удачі.

Ознайомтесь з http://en.wikipedia.org/wiki/Security_by_obscurity#Arguments_against . Я впевнений, що інші, ймовірно, також можуть дати кращі джерела того, чому безпека через неясність - це погана річ.

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

Починаючи з липня 2013 року, знову поціновується інтерес до криптографічно стійкої обфускуції (у вигляді нерозрізненої обтурації ), яка, здається, випливала з оригінальних досліджень Аміта Сахая .

• Сахай, Гарг, Шляхта, Халеві, Райкова, Води, Замешкання Кандидату, Нерозрізнення та функціональне шифрування для всіх контурів (21 липня 2013 р.).
• Сахай, Води, як використовувати нерозрізнення припухлості: заперечне шифрування тощо .
• Сахай, Барак, Гарг, Калай, Панет, захищаючи обтурацію від нападу алгебраїки (4 лютого 2014 р.).

Ви можете знайти дестильовану інформацію в цій статті журналу Quanta та в цій статті IEEE Spectrum .

В даний час кількість ресурсів, необхідних для використання цієї методики, робить її непрактичною, але AFAICT консенсус досить оптимістично оцінює майбутнє.

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

Для того, щоб поінформувати себе, прочитайте наукову літературу з приводу коду . Крістіан Колберг з університету Арізони є поважним науковцем у цій галузі; Саліл Вадхан з Гарвардського університету також зробив добру справу.

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

Існує нещодавній документ під назвою " Програма затухання та одноразові програми ". Якщо ви дійсно серйозно ставитеся до захисту своєї програми. У статті загалом ідеться про теоретичні результати неможливості шляхом використання простого та універсального обладнання.

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

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

Оновлення: нове поняття припухлості, яке називається нерозрізненою припухлістю, може пом’якшити результат неможливості (папір)

Якщо хтось хоче витратити час, щоб перетворити ваш бінарний файл, ви не можете зробити нічого, щоб зупинити їх. Ви можете зробити це помірно складніше, але це з цього приводу. Якщо ви дійсно хочете дізнатися про це, то отримайте копію http://www.hex-rays.com/idapro/ і розберіть кілька бінарних файлів.

Те, що ЦП потребує виконання коду, - це ваше скасування. Процесор виконує лише машинний код ... а програмісти можуть читати машинний код.

Якщо говорити ... у вас, ймовірно, є інше питання, яке можна вирішити іншим способом. Що ви намагаєтесь захистити? Залежно від проблеми ви можете скористатися шифруванням для захисту свого продукту.

Щоб вибрати правильний варіант, слід подумати про наступні аспекти:

1. Ймовірно, що "нові користувачі" не хочуть платити, а користуються Вашим програмним забезпеченням?
2. Чи ймовірно, що існуючим клієнтам потрібно більше ліцензій, ніж вони?
3. Скільки потенційні користувачі готові платити?
4. Ви хочете дати ліцензії на кожного користувача / одночасних користувачів / робочу станцію / компанію?
5. Чи потрібне ваше програмне забезпечення для навчання / налаштування, щоб бути корисним?

Якщо відповідь на питання 5 - "так", тоді не хвилюйтеся щодо незаконних копій. Вони б не були корисні в будь-якому випадку.

Якщо відповідь на питання 1 - «так», то спочатку подумайте про ціноутворення (див. Питання 3).

Якщо ви відповідаєте на питання 2 "так", то модель "оплата за користування" може підійти для вас.

З мого досвіду, оплата за використання + налаштування та навчання є найкращим захистом вашого програмного забезпечення, оскільки:

• Нових користувачів приваблює модель ціноутворення (мало використання -> мало оплати)
• «Анонімних користувачів» майже немає, адже вони потребують навчання та налаштування.
• Жодні програмні обмеження не відлякують потенційних клієнтів.
• Існує безперервний потік грошей від існуючих клієнтів.
• Ви отримуєте цінний відгук для розвитку від Ваших клієнтів через довгострокові ділові відносини.

Перш ніж подумати про введення DRM або обфускування, ви можете подумати про ці моменти та чи вони стосуються вашого програмного забезпечення.

Захищений код у віртуальній машині спочатку здавався неможливим повернути інженеру. Теміда Пакер

Але це вже не так безпечно. І як би ви не упакували свій код, ви завжди можете зробити дамп пам'яті будь-якого завантаженого виконуваного файлу та розібрати його з будь-яким розбиральником, як IDA Pro.

IDA Pro також поставляється з чудовим асемблерним кодом до трансформатора вихідного коду C, хоча згенерований код буде більше схожий на математичний безлад вказівника / адреси.

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

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

Можливо, найкращою вашою альтернативою все ж є використання віртуалізації, яка запроваджує інший рівень опосередкованості / затуманення, який потрібно обійти, але, як заявив SSpoke у своїй відповіді , ця методика також не є 100% безпечною.

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

Що б людина не збирала, її можна розібрати.

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

Якщо ви хочете захистити щось від РЕ, ви повинні знати принаймні загальні методи, якими користуються РЕ.

Таким чином слова

Інтернет насправді не є ресурсоємним для запобігання реверсивній інженерії, але, скоріше, містить багато інформації про те, як повернути інженеру

проявляйте своє погане ставлення. Я не кажу, що щоб використовувати або вбудовувати захист, ви повинні знати, як його зламати, але щоб розумно користуватися ним, ви повинні знати його слабкі сторони та підводні камені. Ви повинні це зрозуміти .

(Є приклади програмного забезпечення, що використовує захист неправильним чином, роблячи такий захист практично відсутнім. Щоб уникнути розпливчастого розмови, я наведу вам коротко описаний приклад в Інтернеті: Oxford English Dictionary Second Edition на CD-ROM v4. Ви можете прочитати про невдале використання SecuROM на наступній сторінці: Оксфордський словник англійської мови (OED) на компакт-диску в 16-, 32- або 64-бітному середовищі Windows: Установка жорсткого диска, помилки, макроси обробки текстів, мережа, шрифти та ін. т.д )

На все потрібен час.

Якщо ви новачок у цій темі і у вас немає місяців, а точніше років, щоб належним чином вникнути в RE речі, то знайдіть доступні рішення, зроблені іншими. Проблема тут очевидна, вони вже є, тому ви вже знаєте, що вони не на 100% захищені, але створення власного нового захисту дасть вам лише помилкове відчуття захисту, якщо ви не знаєте справді сучасного рівня зворотна інженерія та захист (але ви цього не зробите, принаймні в цей момент).

Сенс захисту програмного забезпечення полягає в тому, щоб відлякати новачків, зупинити загальні ЗНО та поставити посмішку на обличчя досвідченого РЕ після її / його (сподіваємось цікавої) подорожі до центру вашої заявки.

У ділових розмовах ви можете сказати, що справа в тому, щоб затримати конкуренцію, наскільки це можливо.

(Погляньте на приємну презентацію « Срібна голка» в Skype Філіпа Біонді та Фабрис Дескло, показану на Black Hat 2006).

Ви знаєте, що Є багато речей про РЕ там, тому починайте його читати. :)

Я говорив про віртуалізацію, тому я надам вам посилання на одну зразкову нитку з EXETOOLS FORUM : Найкращий захисник програмного забезпечення: Themida або Enigma Protector? . Це може трохи допомогти вам у подальших пошуках.

Я не вважаю, що будь-який код є незмінним, але винагорода повинна бути великою, щоб хтось захотів його спробувати.

Сказавши, що ви повинні зробити такі речі, як:

• Використовуйте максимально можливий рівень оптимізації (зворотна інженерія - це не лише отримання послідовності складання, а й розуміння коду та перенесення його на мову вищого рівня, наприклад C). Високооптимізований код може бути дотриманий b --- h.
• Зробіть структури щільними, не маючи більших типів даних, ніж потрібно. Переставити члени структури між офіційними випусками коду. Впорядковані бітові поля в структурах - також те, що ви можете використовувати.
• Ви можете перевірити наявність певних значень, які не слід змінювати (наприклад, повідомлення про авторські права). Якщо байтовий вектор містить "vwxyz", ви можете мати інший байтовий вектор, що містить "abcde", і порівняти відмінності. Функція, яка виконує її, не повинна передавати покажчики на вектори, а використовувати зовнішні покажчики, визначені в інших модулях як (псевдо-C код) "char * p1 = & string1 [539];" та "char p2 = & string2 [-11731];". Таким чином, не буде жодних покажчиків, що вказують саме на два рядки. У коді порівняння ви порівнюєте для " (p1-539 + i) - * (p2 + 11731 + i) == деяке значення". Зломщик подумає, що безпечно змінити string1, оскільки, здається, ніхто не посилається на нього. Похойте тест в якомусь несподіваному місці.

Спробуйте зламати код складання самостійно, щоб побачити, що легко, а що важко зробити. Слід з’явитись ідеї, з якими можна експериментувати, щоб зробити код інженером складнішим і зробити його налагодженням складніше.

Як уже багато хто говорив: У звичайному процесорі ви не можете їх зупинити, ви можете просто затримати їх. Як сказав мій старий вчитель криптовалюти: Вам не потрібно ідеальне шифрування, порушення коду повинно бути дорожче, ніж виграш. Те ж саме стосується і вашої затуманення.

Але 3 додаткові примітки:

1. Можна зробити зворотну інженерію неможливою, АЛЕ (і це дуже дуже багато, але), ти не можеш це робити на звичайному процесорі. Я також робив багато апаратних розробок, і часто використовуються FPGA. Наприклад, Virtex 5 FX має на собі процесор PowerPC, і ви можете використовувати APU, щоб реалізувати власні опкоди CPU у вашому обладнання. Ви можете використовувати цей інструмент, щоб дійсно розшифрувати вставки для PowerPC, недоступного зовнішнім чи іншим програмним забезпеченням, або навіть виконати команду в апаратному забезпеченні. Оскільки FPGA вбудувала AES-шифрування для конфігурації бітового потоку, ви не змогли змінити інженер (за винятком того, що комусь вдається зламати AES, але тоді я думаю, у нас є інші проблеми ...). Таким чином постачальники апаратних засобів захисту IP також захищають свою роботу.

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

3. Зробіть вашу програму невідмінною / нездійснюваною. Спробуйте використовувати якесь виявлення налагодження та застосуйте його, наприклад, в одній формулі або додавши вміст реєстру налагодження до магічної константи. Набагато складніше, якщо ваша програма виглядає в режимі налагодження, якщо вона працює там, де вона працює нормально, але робить повне неправильне обчислення, операцію чи якусь іншу. Наприклад, я знаю деякі еко-ігри, у яких була дуже неприємна захист від копіювання (я знаю, ви не хочете захищати від копіювання, але це схоже): Викрадена версія змінила видобуті ресурси після 30 хвилин гри, і раптом у вас з'явилася лише одна ресурс. Пірат просто зламав його (тобто реверсував це) - перевірив, чи працює він, і Воля випустив його. Такі незначні зміни поведінки дуже важко виявити, особливо якщо вони не з’являються миттєво до виявлення, а лише затримуються.

Отож, нарешті, я б запропонував: оцініть, який виграш від людей, що реверсують інженерне програмне забезпечення, перекладіть це на деякий час (наприклад, використовуючи найдешевшу індійську зарплату) і зробіть зворотну інженерію, щоб витратити час, що вона буде більшою.

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

Це один із прикладів ідеально затуманеної програми програми, яка демонструє мою думку:

printf("1677741794\n");

Ніколи не можна здогадатися, що це насправді

printf("%d\n", 0xBAADF00D ^ 0xDEADBEEF);

На цю тему існує цікава робота, яка доводить певні результати неможливості. Він називається "Про (Im) можливість омертвіння програм" .

Хоча в цьому документі доводиться, що обфускування, що робить програму невідмінною від функції, яку вона реалізує, неможливо, обфускація, визначена дещо слабшим способом, все ж може бути можливою!

Безпека через незрозумілість не працює, як це продемонстрували люди набагато розумніші, ніж ми обидва. Якщо ви повинні захистити протокол зв’язку своїх клієнтів, то ви морально зобов'язані використовувати найкращий код, який є відкритим і повністю перевірений експертами.

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

Я автор реверсної інженерної асемблери для x86. Якщо ви готові до холодного сюрпризу, надішліть мені результат усіх зусиль. (Зв'яжіться зі мною через мої веб-сайти.) Мало, що я бачив у відповідях, представляло б для мене значну перешкоду. Якщо ви хочете побачити, як працює складний зворотний інженерний код, вам слід справді вивчити веб-сайти, що мають зворотні інженерні проблеми.

У вашому запитанні може бути використане уточнення. Як ви розраховуєте зберігати протокол у таємниці, якщо комп'ютерний код піддається зворотному проектуванню? Якщо мій протокол буде надсилати зашифроване повідомлення RSA (навіть відкритий ключ), що ви отримуєте, зберігаючи протокол у таємниці? З усіх практичних цілей інспектор зіткнеться з послідовністю випадкових бітів.

Groetjes Albert

Традиційні методи зворотної інженерії залежать від здатності розумного агента за допомогою розбиральника відповідати на запитання про код. Якщо ви хочете отримати сувору безпеку, ви повинні робити речі, які, очевидно, заважають агенту отримувати такі відповіді.

Ви можете зробити це, спираючись на програму зупинки ("чи зупиняється програма X?"), Яку взагалі неможливо вирішити. Додавання програм, до яких важко міркувати, ускладнює міркування. Побудувати такі програми простіше, ніж розірвати їх. Ви також можете додати код до програми, яка має різну ступінь складності для міркування; чудовим кандидатом є програма міркувань про псевдоніми ("покажчики").

Коллберг та ін. Мають документ ("Виробництво дешевих, стійких та непрозорих непрозорих конструкцій"), в якому обговорюються ці теми та визначаються різноманітні "непрозорі" предикати, які можуть ускладнити міркування про код:

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.39.1946&rep=rep1&type=pdf

Я не бачив конкретних методів Колберга, застосованих до виробничого коду, особливо не вихідного коду С або С ++.

Як видається, обфускатор DashO Java використовує подібні ідеї. http://www.cs.arizona.edu/~collberg/Teaching/620/2008/Assignments/tools/DashO/

ПЕРШЕ ДЕЙТЕ ЗАПАМНУЄТЬСЯ ПРО ВІДХОДЖЕННЯ КОДУ : Не весь код потрібно приховувати.

КІНЦЕВА ЦІЛЬ : Моя кінцева мета для більшості програм програмного забезпечення - це можливість продавати різні ліцензії, які включатимуть і вимикатимуть певні функції в моїх програмах.

НАЙКРАЩА ТЕХНІКА : Я вважаю, що побудова в системі гачків і фільтрів, як пропонує WordPress, - це абсолютно найкращий метод, коли намагаються заплутати своїх опонентів. Це дозволяє зашифрувати певні тригерні асоціації без фактичного шифрування коду.

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

ЗНАЙТЕ СВОЇ КРЕКЕРИ : Знайте це: Основна причина зламування коду полягає не в зловмисному розповсюдженні ліцензій, а насправді в тому, що НЕОБХІДНО змінити свій код, і вони насправді НЕ ПОТРІБНО розповсюджувати безкоштовні копії.

ПОЧИНАЄМО : Відкладіть невелику кількість коду, який ви збираєтесь шифрувати, решту коду слід спробувати і забити в один файл, щоб підвищити складність та розуміння.

ПІДГОТОВКА ДО ЕНГРИПТУ : Ви будете шифрувати шарами з моєю системою, це також буде дуже складною процедурою, тому створіть іншу програму, яка буде відповідати за процес шифрування.

КРОК ПЕРШИЙ : Обплутайте, використовуючи назви base64 для всього. Після завершення базуватимуть невмілий код64 та зберігайте його у тимчасовому файлі, який згодом буде використаний для розшифрування та запуску цього коду. Мати сенс?

Я повторю, оскільки ви будете робити це знову і знову. Ви збираєтеся створити рядок base64 та зберегти її в інший файл у вигляді змінної, яка буде розшифрована та надана.

КРОК ДРУГИ : Ви збираєтеся прочитати в цьому тимчасовому файлі як рядок і затемнити його, а потім646464 і зберегти його у другому тимчасовому файлі, який буде використаний для розшифрування та надання кінцевому користувачеві.

КРОК ТРИ : Повторіть крок два стільки разів, скільки хочете. Після того, як у вас це буде належним чином працювати без помилок розшифровки, тоді ви захочете розпочати будівництво на мінах для своїх опонентів.

ЗЕМЛЯ МАЙНА ОДИН : Ви хочете зберегти той факт, що вас повідомляють абсолютною таємницею. Отож, побудуйте систему електронних поштових попереджень щодо спроб злому для рівня 2. Це буде випущено, щоб ви дізналися про особливості вашого опонента, якщо щось піде не так.

ЗЕМЕЛЬНА РОЗДІЛ ДВА : Залежності. Ви не хочете, щоб ваш противник мав змогу запускати перший шар без шару 3 або 4 або 5, або навіть фактичної програми, для якої він був розроблений. Тому переконайтеся, що всередині першого шару ви включите якийсь сценарій вбивства, який активується, якщо програми немає, або інші шари.

Я впевнений, що ти можеш придумати власні міни, розважитися.

ЧОГО ЗАПАМИТИ : Ви можете фактично зашифрувати свій код, а не базувати його64. Таким чином, проста base64 не буде розшифровувати програму.

ЧИТАЙТЕ : Майте на увазі, що це насправді може бути симбіотичними відносинами між вами та вашим опонентом. Я завжди розміщую коментар всередині першого шару, коментар вітає зломщика і надає їм промо-код, який вони можуть використовувати, щоб отримати від вас грошову винагороду.

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

ЩАСТИ!

Хтось спробував CodeMorth: http://www.sourceformat.com/code-obfuscator.htm ? Або Теміда: http://www.oreans.com/themida_features.php ?

Пізніше виглядає більш перспективно.