Захистити код .NET від зворотної інженерії?

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

Також можна конвертувати додаток C # у нативний код, а Xenocode - занадто дорогий.

C # надає безліч функцій і є ідеальною мовою для мого коду, тому писати всю базу коду знову на C ++ не можна.

Безпечні сертифікати можуть бути легко вилучені з підписаних збірок у .NET.

Ви не можете.

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

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

Пропоную кілька пропозицій щодо захисту вашої програми:

• Прикрийте свій код. Dotfuscator має безкоштовне видання та постачається разом із Visual Studio.
• Використовуйте відкритий / приватний ключ або асиметричне шифрування для створення ліцензій на ваш продукт. Це гарантує, що тільки ви можете генерувати свої ліцензійні коди. Навіть якщо ваш додаток буде зламано, ви можете бути впевнені , що вони не будуть випускати генератор ключів для вашого застосування, тому що неможливо повністю змінити ключ алгоритму генеруючого.
• Використовуйте сторонній пакувач для упаковки вашого .NET виконуваного файлу в зашифрований додаток Win32. Теміда - одна з кращих. Це заважає людям відображати вашу програму в .NET Reflector і робить біль для розпакування для реверсування.
• Напишіть власний спеціальний пакувач . Якщо сторонні пакувальники занадто дорогі, спробуйте написати свій власний. Іноді користувальницькі упаковки можуть бути дуже ефективними, оскільки недостатньо опубліковані методи, як їх розпакувати. Навчальний посібник Як написати власний пакувач дає тону корисної інформації про написання власного пакета Win32.

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

Кваліфікований інженер з зворотного зв'язку може запустити IDA-Pro і розрізати вашу програму, як масло, незалежно від того, що ви робите. Упакований додаток можна розпакувати, а обфускація лише заважає йому прогулятися по парку. Вся ваша копітка робота зі складним ліцензійним кодом може бути скасована одним байтним патчем.

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

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

Раніше в моїй заяві пірат був, і я сприйняв це як особисту боротьбу. Ось я, маленький розробник, вилив моє серце і душу в додаток, і ці люди мали жовту піратську діяльність від мене ?! Вони брали гроші прямо з моєї кишені!

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

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

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

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

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

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

Отже, це пояснює, що означає робити саме так. Але чому б не піти далі? Чому б не заткнути кожну маленьку дірочку, яку ви можете знайти? Відповідь у двох частинах. По-перше, якщо хтось переступить етичний поріг свідомо порушувати ваші ліцензійні умови - навіть простим способом - він також буде готовий зробити щось складніше чи небезпечніше, як витягнути вашу програму з торрентасайт - і існує певна небезпека, пов’язана із запуском програм, завантажених з недовірених джерел. Зробити це складніше - це лише незначне роздратування для цих користувачів і ризикує спричинити проблеми з клієнтами, які платять. Якщо це просто, може хтось не зможе зануритися у вашу програму і випустити більш всебічну тріщину. По-друге, у вас є мало очей, щоб шукати недоліки; хакерів багато, і вони мають більше практики їх пошуку. Вам потрібно пропустити лише один невеликий недолік, і ваш додаток матиме такий самий розподіл на піратських сайтах, як ніби ви нічого не зробили. Ви повинні мати рацію щоразу; їм пощастить лише один раз. Тому необхідні зусилля дуже великі, а ймовірність будь-якого показника успіху дуже низька.

Зрештою, якщо хтось захоче піратувати вашу заявку (на відміну від того, щоб просто використовувати її), і це їх головна мета. Ви нічого не можете зробити, щоб зупинити їх. Така природа програмного забезпечення; після того , як файли , які складають ваш продукт знаходяться на комп'ютері користувача, вони будуть мати можливість робити з ними , як вони хочуть. Це особливо актуально в керованих середовищах, таких як Java або .NET , але це безумовно стосується і рідного коду. Час на їхньому боці, і з урахуванням достатнього часу будь-яку цифрову безпеку можна порушити.

Оскільки ви не можете зупинити користувачів піратства вашого продукту, ваш найкращий спосіб дії - залучити цей клас користувачів таким чином, щоб він використовував їх на вашу користь. Часто можна змусити їх працювати на вас, а не проти вас. Зважаючи на це, незалежно від того, яка ваша заявка, можливо, варто зберегти безкоштовну версію, яка майже повністю функціонує і не закінчується. Різниця між ціною навіть 1 долар США і безкоштовною величезна, якщо з будь-якої іншої причини, крім того, що клієнту не доведеться довіряти вам своєю кредитною карткою. Безкоштовне видання вашого продукту не тільки ефективно знищить піратські дистрибуції (навіщо ризикувати піратською версією, коли ви можете мати законну ціну за ту ж ціну?), Це може потенційно значно розширити вашу аудиторію.

Результат полягає в тому, що вам може знадобитися збільшити ціну видання за плату, так що врешті-решт замість 2000 користувачів по 20 доларів у кожного у вас є 100 000 безкоштовних користувачів, з яких 500 готові заплатити 99 доларів за “професійне” видання . Це заробляє більше грошей, ніж якщо б ви витратили купу часу на запитання продукту. Більше того, ви можете залучати цих безкоштовних користувачів і використовувати стосунки кількома важливими способами.

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

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

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

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

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

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

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

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

Загалом, є три групи людей.

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

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

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

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

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

Ви не можете перешкодити людям зламати ваше програмне забезпечення.

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

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

Часткова перевірка ключа гарантує, що кожен незаконний генератор ключів працює лише для одного конкретного випуску вашого програмного забезпечення. В основному, ви повинні переконатися, що кожен випуск вашого програмного забезпечення посилається лише на код для перевірки ДЕЯКІХ цифр реєстраційного коду. Які цифри точно випадкові, тому кракерам доведеться повернути інженеру багато різних версій програмного забезпечення та об'єднати все це в один генератор клавіш, щоб випустити генератор клавіш, який працює для всіх версій вашого програмного забезпечення.

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

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

Здається, є .NET Framework з відкритим кодом для часткової перевірки ключів , хоча я цього не пробував.

• Використовуйте онлайн-оновлення, щоб заблокувати ці неліцензійні копії.

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

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

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

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

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

Ти можеш..

Програмний потенціал Microsoft SLP Services InishTech пропонує можливість захистити код, не впливаючи на функціональність ваших програм.

ОНОВЛЕННЯ: (Розкриття: Я працюю над Eazfuscator.NET) Що робить програмне забезпечення Microsoft SLP Services Potential різним - це можливість віртуалізації коду, так що ви, безумовно, можете . Минуло кілька років з моменту спочатку заданого питання; сьогодні є більше продуктів, які також працюють на подібній основі, таких як:

• Agile.NET
• Eazfuscator.NET

.NET Reflector може відкривати лише "керований код", який в основному означає ".NET код". Таким чином, ви не можете використовувати його для розбирання файлів COM DLL, нативного C ++, класичного коду Visual Basic 6.0 тощо. Структура складеного коду .NET робить його дуже зручним, портативним, відкритим, перевіряється тощо. це дозволить вам зазирнути до складених збірок, але декомпілятори та розбиральники аж ніяк не характерні для .NET і існують до тих пір, поки були компілятори.

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

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

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

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

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

Трохи більше ідей (жодна ідеальна, як немає ідеальної).

• AntiDuplicate
• Зміна мови, використовувати прийоми приємно , що автори Skype використовували
• Ліцензійний сервер

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

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

Оскільки процесори німі, а люди ні, це означає, що і люди можуть зрозуміти код.

Є лише один спосіб переконатися, що ваші користувачі не отримають ваш код: не вказуйте їм свій код.

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

Інший спосіб - модель пристрою: замість того, щоб давати своїм користувачам свій код, ви даєте їм комп'ютер, що містить код. Це модель, якою користуються ігрові приставки, більшість мобільних телефонів та TiVo . Зауважте, що це працює лише в тому випадку, якщо ви "володієте" усім контуром виконання: вам потрібно створити власний процесор, власний комп'ютер, написати власну операційну систему та власну реалізацію CLI . Тоді, і тільки тоді ви можете захистити свій код. (Але зауважте, що навіть найдрібніша помилка робить усі ваші захист марними. Про це можуть засвідчити Microsoft, Apple, Sony, музична індустрія та кіноіндустрія.)

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

На жаль, ви не збираєтесь тікати від цього. Ваша найкраща ставка - написати свій код на C та P / Invoke .

Є невеликий улов-22, хтось може просто декомпілювати вашу заявку до CIL і вбити будь-який код підтвердження / активації (наприклад, дзвінок до вашої бібліотеки C). Пам’ятайте, що програми, написані на мові С, також розробляються зворотним інженером більш стійкими хакерами (просто подивіться на те, як швидко розбиваються ігри в ці дні). Ніщо не захистить вашу програму.

Врешті-решт, це дуже схоже на ваш будинок, захистіть його досить добре, щоб докласти занадто великих зусиль (тут допоможе код спагетті), і щоб нападник просто перемістився до наступного сусіда (змагання :)). Подивіться на Windows Vista, має бути 10 різних способів зламати її.

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

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

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

Це ідеї:

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

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

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

Перепишіть деяку логіку в C ++ / CLI і змішайте керований код з некерованим. Це посилить демонтаж. У цьому випадку також не забудьте вказати бінарні файли x64 .

Так. Це правда. .NET код надзвичайно легко інженеру повернути, якщо код не затуманений.

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

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

Є кілька інших безкоштовних або відкритих джерел .NET обфускаторів (але я не можу коментувати якість чи різні методи, якими вони користуються):

• Обфускар
• Babel.NET

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

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

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

• Прикрийте свій вихідний код, очевидно, це зробить ваш вихідний код схожим на безлад та нечитабельний.
• Запустіть кілька випадкових процедур перевірки у вашій програмі, наприклад, кожні дві години, 24 години, один день, тиждень тощо або, можливо, після кожної дії, яку виконує користувач.
• Збережіть контрольну суму MD5 звільненої програми на вашому сервері та застосуйте процедуру, яка зможе перевірити поточну контрольну суму MD5 файлу з справжньою на стороні вашого сервера та зробити її випадковою. Якщо контрольна сума MD5 була змінена, це означає, що ця копія була піратською. Тепер ви можете просто заблокувати його або випустити оновлення, щоб заблокувати його тощо.
• Спробуйте скласти процедуру, яка може перевірити, чи деякі ваші коди (функції, класи або конкретні процедури) насправді були змінені чи змінені або навіть видалені. Я називаю це (перевірка цілісності коду).
• Використовуйте безкоштовні невідомі пакувальники для упаковки вашої програми. Або, якщо у вас є гроші, займіться комерційними рішеннями, такими як Thamida або .NET Reactor . Ці програми регулярно оновлюються, і як тільки зломщик розпакує вашу програму, ви можете просто отримати нове оновлення від цих компаній, і як тільки ви отримаєте нове оновлення, ви просто запакуйте програму та випустите нове оновлення.
• Регулярно випускайте оновлення та змушуйте клієнта завантажити останнє оновлення.
• Нарешті зробіть свою заявку дуже дешевою. Не робіть це занадто дорого. Повірте, ви отримаєте більше щасливих клієнтів, і сухарики просто залишать вашу заявку, тому що не варто витрачати їх час, щоб зламати дуже дешевий додаток.

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

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

Тепер перейдіть і реалізуйте кілька іграшок для сухарів ...

Є Salamander , який є вродженим .NET компілятором і лінкером від Remotesoft, який може розгортати програми без .NET Framework. Я не знаю, наскільки добре вона відповідає своїм вимогам.

Якщо Microsoft може придумати рішення, у нас не буде піратських версій Windows, тому нічого не дуже безпечно. Ось кілька подібних запитань від Stack Overflow, і ви можете реалізувати власний спосіб їх захисту. Якщо ви випускаєте різні версії, то ви можете використовувати різні методи для різної версії, тому до моменту, коли перша зламається, друга може взяти на себе.

• Керування функціями на ліцензійній основі для додатка C ++

• Захистіть файл DLL за допомогою файлу ліцензії

• Програмне забезпечення для ліцензування / захисту?

.NET Reactor

Оновлення

Джаред зазначив, що de4dot стверджує, що може його декомпілювати.

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

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

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

Все, що працює на клієнті, можна декомпілювати та розламати. Обтурація просто ускладнює. Я не знаю вашої заявки, але 99% часу я просто не думаю, що варто важити зусиль.

Неможливо повністю захистити програму, вибачте.

Прикрийте код! Існує приклад в обплутанні коду C # .

Майте на увазі, що 99% + ваших користувачів не будуть зацікавлені розглядати ваш виконуваний файл, щоб побачити, як він працює.

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

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

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

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

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

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

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

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

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

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

Там є пакети, які зашифрують ваш EXE і розшифрують його, коли користувачеві буде дозволено ним користуватися

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

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

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

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

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

Чесно кажучи, іноді нам потрібно придушити код (наприклад, зареєструвати ліцензійні класи тощо). У цьому випадку ваш проект не є безкоштовним. ІМО, ви повинні заплатити за хорошого обфукатора.

Dotfuscator приховує ваш код, а .NET Reflector показує помилку при спробі декомпілювати його.

Я можу порекомендувати використовувати Obfuscator .