Захист програм: генерування серійних ном. активаційних etc
На початковому етапі для захисту програми прийнята така технологія:
1) клієнту видається серійний номер
2) при установці програми з серійним номером і залозу генерується код запиту.
3) клієнт вбиває на сайті код запиту і отримує активаційний код
І виникає купа питань - як краще це реалізувати, за якими критеріями генерувати серійний код? Бажано чи в код запиту якимось чином включати інформацію, за якою можна зрозуміти про який серійному ключі йдеться (по базі)?
Чи можна обійтися в кодах виключно цифрами для більш простої передачі інформації в розмовному вигляді?
За якими параметрами краще прив'язуватися до залозу, є у кого досвід?
Як генерувати код запиту і активаційний код?
Які граблі зустрічаються, чого краще не робити?
P.S. рішення корпоративне, тобто число інсталяцій щодо мало. На першому етапі захист буде не дуже складна в самій програмі, але протокол обміну ключами, генерування і так далі бажано з початку зробити по розуму.
Які граблі зустрічаються, чого краще не робити?
Всього цього не робити.
Бо спочатку йде хитромудра перевірка чогось там, а після неї банальний
іф / зен / Елс
Хитромудру перевірку ламати ніхто не буде, зламають іф / зен / Елс
На мій погляд, якщо і робити подібну "захист", то треба прив'язуватися до серійного номеру гвинта (завантажувальний для системи гвинт)
Отриманий серійник обрамляється будь-якими константними символьними доважками і перетворюється оборотним способом в потрібну за складом символів рядок - отримуємо умовний ID компютера.
Користувач повідомляє його постачальнику ПО.
Постачальник, на основі відомого оборотного алгоритму генерує закодований ID (Code) і повідомляє його користувачеві.
Користувач вводить його для активації.
Клієнтський софт перевіряє еквівалентність ID і Code.
У мене так зроблено для примітивної захисту - у багатьох випадках цього достатньо.
Втім, зазначу - зроблено не для захисту ПО, а від захисту запуску на несанкціонованому (не активований) робочому місці.
> А від захисту запуску на несанкціонованому (не активований
>) Робочому місці.
для захисту від запуску на.
> Чого краще не робити?
Чи не страждати відвертою фігньою.
Якщо ПО дійсно того варто, щоб захищати його від неліценз.іспользованія, слід захищати його сучасними апаратними ключами - вони недорогі, надійні, зручні і дуже стійкі до злому.
У кр.случае, якщо купити ПО + ключі для захисту жаба давить і дуже хочеться постраждати фігньою, є резон прив'язуватися до біометрії ліцензованого користувача в якості "коду запиту"
Якщо це буде помітно дешевше, ніж купити.
не обов'язково.
чісло_хакеров_в_міре <<число_пользователей_нелегальных_копий_ПО
> Слід захищати його сучасними апаратними ключами
Я б додав - слід вчитися захищати його апаратними ключами. А то захисників багато, а дійсно добре поставлених захистів по пальчикам почитати можна :)
При цьому біометрії нехай малює мишкою в реалі
Це, до речі, думка - озброївшись 100-кратною лупою розташуватися біля дзеркала і замалювати мишею в Пейнт фактуру райдужної оболонки свого ока)
> На мій погляд, якщо і робити подібну "захист", то треба
> Прив'язуватися до серійного номеру гвинта (завантажувальний для
> Системи гвинт)
а не знаєш способу вважати цей серійний номер стовідсотково? Бажано, не маючи прав адміністратора.
Щоб працювало з усіма вінчестерами, в тому числі IDE, SCSI, SATA, RAID-масиви та інше.
Я до цього думав про ID процесора.
> Користувач повідомляє його постачальнику ПО.
> Постачальник, на основі відомого оборотного алгоритму генерує
> Закодований ID (Code) і повідомляє його користувачеві
а ось тут і саме один з найважливіших моментів. Як кодувати?
Чи включати до закодовані дані інформацію про серійне ключі?
Теоретично кодувати особливо нічого не потрібно, можна в цілому і взагалі прямим текстом відправляти наступне: серійний ключ (або його частина), ID вінчестера. А ось у відповідь сервер повинен повернути якусь закодовану інформацію. яку клієнт може розшифрувати і перевірити правильність.
Питання в тому як шифрувати? Наприклад, одна з ідей - несиметричне шифрування. Кодувати інформацію буде сервер невідомим крім нас самих ключем. А клієнт буде розшифровувати і отримувати дані.
- трошки якось геморойно приплітати алгоритми відкритих / закритих ключів, несиметричне шифрування та інше, інше.
- чи не вийде занадто великим обсяг даних після шифрування несиметричному ключем? Або обсяг залишається вихідним?
> Обмовлюся - зроблено не для захисту ПО, а від захисту запуску
> На несанкціонованому (не активований) робочому місці
а в чому різниця?
Захист ПО - це хіба не запобігання несанкціонованого запуску ?!
Для розшифровки потрібен повний (private) ключ.
> Якщо купити ПО + ключі для захисту жаба давить
та це копійки коштує. Але не підходить. Потрібно вміти змінювати умови ліцензії без перевисилке ключів.
> А не знаєш способу вважати цей серійний номер стовідсотково?
> # XA0; Бажано, не маючи прав адміністратора.
> Щоб працювало з усіма вінчестерами, в тому числі IDE, SCSI,
> # XA0; SATA, RAID-масиви та інше.
> Я до цього думав про ID процесора.
Алекс Коншин - hddsn.pas
Що є - то є, розбирайся сам, чого він не може.
HDD - це зрозуміло і справедливо. Якщо переінстальовано система на новому гвинті, то й не гріх заново запросити активацію.
> А ось тут і саме один з найважливіших моментів. Як кодувати?
>
> Чи включати до закодовані дані інформацію про серійне
> Ключі?
Навіщо серійник ще якийсь. Вести ще базу серійників?
Софтина запускається і якщо не була активована - повідомляє код ID (гвинта).
У перший раз він не відомий. Юзер його записує і повідомляє інсталятору, останній на основі повідомленого ID за допомогою утиліти активації отримує у відповідь Code і передає його Користувачеві. Усе.
> А в чому різниця?
> Захист ПО - це хіба не запобігання несанкціонованого
> Запуску ?!
Ні.
Для корпоративи цілком зійде.
А як захист продаваного ПО - фігня і геморой.
> Потрібно вміти змінювати умови ліцензії без перевисилке ключів.
Ну ось накрився у користувача гвинт. Ось він його поміняв. Ось він перевстановив програму. І що далі? А далі вона банально не працює.
> А далі вона банально не працює.
Ще раз - це варіант для корпоративної системи, не більше.
Юзер взагалі нічого робити не повинен при поломці гвинта.
Йому все зробить служба IT, в тому числі і активацію.
> Для розшифровки потрібен повний (private) ключ.
це зрозуміло. Я і хочу поміняти концепцію несиметричних ключів.
Щоб розшифрувати міг КОЖЕН (ну теоретично, просто він буде вшитий в програму і його при умінні можна буде вицепіть). А ось ключ для шифрування відомий тільки нам.
Відповідно, сервер надсилає зашифровану інформацію. Гарантія достовірності цієї інформації в тому, що її за допомогою відомого ключа вдалося правильно розшифрувати.
Наскільки це вразливе? Я знаю, що за відомим ключу шифрування неможливо (дуже довго) визначати ключ дешифрування. А ось зворотний процес захищений? За відомим ключу дешифрування можливо визначити ключ шифрування?
> Навіщо серійник ще якийсь. Вести ще базу серійників
>?
звичайно, для ідентифікації клієнта. Одна з найважливіших складових - знати хто і скільки разів активував систему. І взагалі, в цілому це для контролю за нашими дилерами.
Від кінцевого користувача в цілому захищатися сенсу особливого не має, програма прив'язана до обладнання. І дуже рідкісні випадки, коли купують обладнання без програми.
> Наскільки це вразливе? Я знаю, що за відомим ключу шифрування
> Неможливо (дуже довго) визначати ключ дешифрування. А от
> Зворотний процес захищений? За відомим ключу дешифрування
> Можливо визначити ключ шифрування?
Будь-шифр рано чи пізно буде розкритий. Важливо щоб він був розкритий після того, як інформація перестала бути актуальною.
Хлопців, я дуже прошу. Мені ці філософські баяни - ну чесне слово не потрібні, без образ.
Якщо є у кого що сказати по справі - з великим задоволенням послухав би. Якщо хто розуміє в позначеному справі захисту програм.
вилучено модератором
Примітка: Правила, батенька, поважаємо.
> Будь-який шифр рано чи пізно буде розкритий.
Лежання, я трошки поправлю тебе :) Шифр (якщо це дійсно він) сам по собі займає саму нижчу позицію на етапі зламу. Будь кріпкостойкій алгоритм не повинен представляти із себе ніякої таємниці бо ну не скриня-же він. Все будуватися на ключах - ось якщо підібрали ключ, тоді ой. Якщо ключ розбирається на Брута - тоді ой двічі, якщо на колізій - тоді два рази КУ з присіданням і в топку такий алгоритм :)
Розич, а ти розбираєшся в цій справі? Може хоч ти відповіси. А точніше порадиш - який алгоритм (бажано щоб була готова реалізація на Delphi і на PHP) заюзать, щоб шифрувати закритим ключем і розшифровувати відкритим. При цьому щоб по ключу расшіфраціі не можна було підібрати (криптостойкость на рівні) ключ шифрування?
> За якими критеріями генерувати серійний код?
Особисто я включаю в генератор серійного коду ще інформацію про власне назві продукту (бо на одній машині може працювати кілька осіб програм, і виходить що у них у всіх буде один і той же ключ активації) і про його версії (якщо не передбачається фрішное оновлення версії продукту).
Втім, схожий я на ідіота, який б'ється головою об стіну, причому вкотре. піду спитаю в ЖЖ і на ixbt - ось просто цікаво, впевнений на 99%, що відповіді там будуть набагато позитивніше і без цієї агресії, характерної для DM останні пару років.
Розбираюся.
Використовуй наприклад RSA для видачі ключа користувачеві, другу частину ключа бережи у себе на сервері і вигадуй технологію зв'язки. Наприклад використовуй цю пару для верифікації додатки або генерації сесійного ключа з наступною верифікацією. Але це все не те. Це тільки та частина яка йде на поверхні захисту, найправильніше - це інтегруванні захисту в додаток на такому рівні щоб воно працювало в парралелі з обчисленнями виробленими в самому ПО, тобто прибрати всі (як раніше говорили) If THEN і т.п. і використовувати отримані при верифікації дані при розрахунках або подальшої ініціалізації движка програми. По хорошому звичайно-ж бажано скористатися електронними ключами захисту та їх можливостями. Тим більше у тебе корпоративні клієнти, а значить контори не бідні і зайві тисяча-дві рублів для них будуть копійкою
Саш, щодо електронних ключів я вже висловився, см. Пост [16]
Я підсумую питання, які зараз в голові крутяться:
1) до чого краще прив'язуватися? Первісне вказівку - прив'язуватися до ID процесора. Наскільки це Гудове?
Особисто мені сподобалася ідея з вінчестером. Дійсно, перевстановлення вінчестера - це перевстановлення системи зазвичай, а значить нічого страшного і ще раз активувати.
З залізяччям я не займався, проблеми з вінчестерам озвучив, чи є універсальний спосіб прив'язки? Адже варіантів може бути безліч - IDE вінчестер, SCSI, може бути взагалі рейд, там якийсь нафіг ID?
Та й якщо вже на те пішло, вінчестера взагалі може не бути, а вантажиться все з якогось мережевого накопичувача. Я просто не в змозі все передбачити, бажані перевірені рішення.
2) ти пропонуєш RSA - як я розумію, це те що використовується в PGP. Таким чином, є відкритий ключ і закритий.
ЗВИЧАЙНО відкритим ключем шифрують, а закритим розшифровують. І по відкритому ключу я точно знаю нереально отримати в нормальні терміни закритий ключ.
Наскільки крипостійкість зворотна операція, тобто за відомим закритому ключу отримати відкритий ключ?
Ще раз - я хочу поміняти концепцію. Ключ дешифрування буде вбудований в розповсюджується, тобто в теорії його звідти можна витягнути. А ось ключ шифровки невідомий нікому, крім нас. Відповідно, правильність активационного коду визначається виключно тим, що коректно розшифрувати активаційна інформація ключем дешифрування.
Звідси і питання - крипостійкість чи зворотна операція - отримання ключа шифрування за відомим ключу дешифрування?
Ну і ще раз - зазвичай ключ шифрування є public, а ключ дешифрування - private. А у мене вийде навпаки, ключ дешифрування - public (відносний), а ключ шифрування - private.
Я б крім стандартної початкової перевірки збігу ключа додав би принцип 1001 китайського нещастя.
Наприклад в Pro версії після злому початкового іф / зен / елсе при виконанні деяких функцій з використанням random (якщо немає збігу ключа) псував би працездатність сеансу системи, наприклад через впровадження віддаленої нитки в процес експлорера або закрузка бібліотек через механізм хуков і якесь некоректне перенаправлення api функцій. Так щоб сеанс продовжував працювати, але глючить.
не згоден, таке дрібне пакостничеству - доля захисту персональних шароварів. Знову ж таки, деякі концепції захисту в продукті Rouse_ теж особисто я вважаю. Ну блін низьким чи що))) Так, напевно це ефективно. Як ефективно відмивати нафтові гроші через офшори)))
Ну да тема не про це. Сенс я зрозумів - при зломі замість того, щоб у відкриту відписати що це злом і працювати далі не буду, ти пропонуєш робити видимість роботи, але пакостити. Вважаю, що так не правильно.
Та й специфіка корпоративного продукту тут сильно допомагає. Продукт зовсім не масовий, напевно всього-то було продано сотня інсталяцій ну або в тому районі. Тому щоб хтось хакера наймав для злому. Сильно сумніваюся.
Гарантія достовірності цієї інформації в тому, що її за допомогою відомого ключа вдалося правильно розшифрувати.
Шифрування ніколи не вирішувало і не вирішує завдання перевірки автентичності інформації.
> Шифрування ніколи не вирішувало і не вирішує завдання перевірки
> Автентичності інформації.
ось навіщо лізти в гілку, та й взагалі хоча б з таким впевненим виглядом писати про те, в чому абсолютно не розбираєшся?
Відповідно, правильність активационного коду визначається виключно тим, що коректно розшифрувати активаційна інформація ключем дешифрування.
А хто визначає "правильність розшифровки"?
Знову код програми і знову іф / зен / елсом.
Що? Чи не програма перевіряє, а запитує у сервера правильність?
А відповідь сервера "правильно / неправильно" розшифровано в клієнті хто перевіряє?
Знову клієнтський код.
міський Шаман # XA0; (13.02.09 19:20) [33]
Зруб антивірусом, сенсу немає (я тут не тільки про троянів, але і про всі ці впровадження). Ну і, зрозуміло, тут же підуть (цілком виправдані) байки, що така-то прога - з вірусом. І навіть легальні користувачі, навіть якщо у них антівіус НЕ буде лаятися - боятимуться. А якщо їх ще й трохи потенційних - тоді і зовсім погано.
Довести комусь мовляв "це тому що піратка, нічого не знаємо" - малореально. Винда он теж піратка, проте ж антивірус на неї не лається (тут, правда, вже про сук виходить, але це ж поясниш).
> Maacheba # XA0; (13.02.09 17:03) [16]
> Не підходить. Потрібно вміти змінювати
> Умови ліцензії без перевисилке ключів.
Потрібно просто вміти використовувати можливості ключа та відповідного йому ПО таким чином, щоб не пересилаючи ключ змінювати умови ліцензії.
А ти не вмієш. Але при цьому анітрохи не вагаючись заявляєш про якусь там "пересилання".
Пам'ять: 0.85 MB
Час: 0.056 c