×Закрыть

Как сделать надежную защиту программы

Давайте обсудим, как можно надежно или более-менее надежно защитить свой код от взлома.

Какие тенденции и новые направления в защите кода?

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
все по старому...
все упирается в сложность (как ранее заметили):
— комплекс из нескольких, даже простых защит ломать сложнее — например, ключ активации, ежедневные онлайн апдейты\проверки (с логгированием ипов и железа) , хеши как всей программы, так и отдельных ее частей — функций и т.д. , антидебаговые вставки, когда логика меняется если прога под дебагом (вычисляется разными методами, например энумерацией запущенных процессов либо таймерами)
— вариативность по датам — одни проверки работают при каждом запуске, другие — раз в день, третьи раз в неделю\месяц
— тихие проверки, когда прога продолжает работает, но при апдейте сливает инфу по компу

— можно еще коммерческие локи прикручивать

но лучший способ это либо сайт, либо тонкий клиент ...

Вопрос слишком широкий. Под взломом может подразумеваться защита от копирования или защита от блокировки функциональности или защита от внешней авторизации при запуске

Вот более или менее свежие тенденции:

Дема: можно включать в демо только ту функциональность, которая нужна для демо а кусок котороый работает в про версии: просто не включать в программу, пропустив текс через элиминацию кода в зависимости от условий.

Привязка к чему-то: гененерировать для каждого клиента программу, где в код вшита определяющая клиента информация (и часть функциональности зависит именно от этой информации а не от той, что ввел клиент)

Естественно, использование привязки тоже надо защищать и «абсолютно надежного способа» защиты не существует, все дело в балансе стоимости программы . стоимости ввода защиты.

на протяжении последних минимум 20 лет было доказано что это тоже самое, что и вечный двигатель изобретать. назовите хотя бы одну невзломанную систему (те которые нафиг никому не нужны просьба не называть)... Пишите опенсорсный или шареварный софт и благодарные юзеры сами вышлют вам по чуточке денег. а написать прогу с суперзащитой и просить за неё много денег — просто глупо.

Замки — для «хороших» людей. Так как вор все равно взломает ваш замок. Но уходя из дома вы ведь запираете свою квартиру?

Я вам предлагаю идти на работу и не запирать дверь! И вообще не вашать замок. Это глупо! Так как кто хочет взломает.

По вашему все компании, которые вашают защиту на свои продукты просто глупы?

ты не поверишь, но напрмиер те же финны не закрывают свои дома на замок. они глупы?

так или иначе — рынок ДРМ растет и собирется расти в ближайшее время

«Global Digital Rights Management (DRM) market is projected to witness significant growth in near future»

news4geeks.net/...eefold-by-2014

глупые компании продолжают вешать зашиту на свои проги и контент :)

вопрос только в максимизации прибыли, допустим, без защиты 100 продаж, с защитой — 150, с очень сложной защитой — 50... каждый решает для себя что ему надо.

Без защиты стоит $20 продано 200, с защитой стоит $40, продано 100. Каждый действительно решает для себя что ему надо....

если защиту не писать самому, не содержать сервер, админа, а например использовать готовые сервисы, то стоимость будет не 20$—>40$, а 20$—>21$

при подажах такой проги 200-500 (в месяц) это самое оно. при продажах 5к и больше — можно без проблемно купить лицензию и держать свой сервер для активаций — на стоимость это особо не повлияет — затраты составят 4-5%

естествено на копеечные программы 1-2$ защиты вешать вообще никакой не стоит.

но тот самый Ubisoft увидел выгоды от on-line защиты игр ( пускай средняя стоимость 25$).а некоторые проги стоят 300$, 3000$, 8000$ — их купят потому что они нужны для работы (и о том какая на них защита висит кастомер даже париться не будет)

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

ссылочку на аналитику не дадите?

вот некто приводит инфо как публикация его проги на пиратском сайте повлияла на продажи
blog.stormyprods.com/...noticeable.html

Dec- mid May видно рост продаж и явное падение mid May — Jul после появления пирацкой альтернативы

ссылочку на аналитику не дадите?

Так сходу не дам. Но если говорить о музыке, то совсем недавно попадалась статья от Apple, как повлияло появление DRM-free музыки в iTunes, которую можно свободно корировать, на продажи треков и альбомов, в общих чертах никак не повлияло.

Я только соглашусь, что в игровой индустрии всё не так, т.к. продукты в основном одноразовые, прошёл-забыл. Повторное использование продукта маловероятно. Помню я купил лицензионного STALKER’а, сразу после выхода, просто чтобы поддержать. Через несколько недель решил поставить посмотреть, а starforce шумно обгадился и не установился. STALKER хочет старфорс, старфорс не ставится. Если бы покупал, чтобы поиграть, то расстроился бы :)

Dec- mid May видно рост продаж и явное падение mid May — Jul после появления пирацкой альтернативы

А может это просто насыщение?

Многие авторы мелких програм переоценивают свой успех у пользователей, говоря о недополученной прибыли, о большом количестве инсталляций и мизерных прибылях. Если забрать одну программу, переползут на другую.

Все умные компании давно перешли на обычный trial + ключ, гораздо легче преследовать неправомерное использование, чем платить за защиту продукта.

а за счет глупых рынок ДРМ растет :)

А причём тут защита контента, которая defective by design и защита программ? Рынок DRM умирает.

Отказом рекординговых и дистрибьюторских компаний от DRM.

мож ссылочку дадите на report? Я понимаю, что юзерам не очень нравится когда не на шару..

я уже одну выложил ( на обзор репорта ) “Global Digital Rights Management (DRM) market is projected to witness significant growth in near future” — это вывод не обывателей, а экспретов.

вот еще пример ( но это лишь пример, а не исследоваие )
www.kotaku.com.au/...m-is-a-success

Apparently Ubisoft has seen a “a clear reduction in piracy of our titles which required a persistent online connection,” claimed the rep. “[F]rom that point of view the requirement is a success.”

мож ссылочку дадите на report?

Смотрите iTunes, практическа вся музыка без DRM. Смотрите Amazon, Microsoft MSN Tune продают музыку без DRM. Вся большая четвёрка даёт лицензии на DRM-free, т.к. смысла покупать online контент с DRM вообще нет.

Я понимаю, что юзерам не очень нравится когда не на шару..

Бывает.

Нет, я не пользуюсь, но не считаться с самым большим пушером музыки нельзя. Я пользуюсь Amazon, потому что они отдают в mp3, а не в aac.

по поводу онлайн авторизации... есть еще один проект — DYAMAR Orion SDK, фишка вся в том что весь програмный код выполняеться на удаленном сервере, и при этом для клиента этот процесс не заметен. все просто — ассемблерный код вырезается из EXE и исполняется на удаленной машине. память и регистры шаряться между клиент и сервером. почитать можно здесь. простите если выглядит как реклама, интересует мнение людей относительно данного проекта...?

— Обыкновенный тонкий клиент будет на несколько порядков безопаснее в плане защиты приложения.

— Постоянное подключение к интернету является очень плохим требованием, и сразу сужает возможность использования продукта.

ваши два пункта противоречат один одному :-) обычно тонкий клиент и сервер находятся на не одном компе, а в сети. и в последнее время этой сетью становиться интернет а не интранет.

Читайте до просветления вопрос и ответ.

всякое может быть. но как правило работает )

в демо что-то не срабатывает.
первый запуск — application not activated — вводим ключ — результат «activated»

повторный запуск — aceess violation at address ... — нажимаем ок — application not activated

сервер отключен, нет финансирования :-)

идея интересная и неординарная — выполнить часть кода на серванте.

но нерабочая демка скорее всего не способствет продажам. чего не запустить сервер на домашнем IP?

Вот здесь есть протектор неплохой — DYAMAR Protector

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

cool. зах.клієнта не лякає укр.компанія?

не, пока вроде не замечал.

DYAMAR Protector

Жесть, инет полон кигенов для самого этого продукта :)

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

але цікаво, що made in ukraine, орiєновано на зах.клієнта — і як воно іде?
чи не лякаються зах.клієти укр.контори? і т.д. і т.п.

На ум сразу проходит 2 варианта:

1 — сделать код OpenSource. И зарабатывать деньги на поддерже и добавление нового фунционала.

2 — Часть фунционала перевести на обработку на вашем сервере. Припоминаю была какая-то тулза по дизасеблированию и еще игра Assassin’s Creed 2 там была обработка тригеров на сервере. Хакером не сложно было собрать базу тригеров и сделать эмулятор сервера игры у себя на localhost-е.

Использовать обфускатор :)

использовать систему он-лайн авторизации на запуск проги.

*кейген сделать не выйдет ( так как нет в проге кода проверки ключа),
*триал подчистить не выйдет так как прога не пишет на локальном компе никаких данных об запусках.
*никакие данные ( как ключи ) не хранятся на локальном компе.

*предать ключ другу не выйдет так как он зарегистирован в базе.

можно крекнуть и выломать сам код авторизации — но этот подход не совсем «кошеный» .

можно задосить сервер — но это скоее приведет а неработоспособности прог, а нужно наооборот.

недостаток — сервис должен быть всегда доступен и дублироваться

С локалхоста отправлять сообщение об успешном проходжении авторизации. И чё?

если расшифровать протокол то может быть. вы знаете что получать и отправлять?

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

а почему пачка пакетов должна быть одинаковой? пакеты будут всегда разные.

В таком случае выходи (исходя из Вашего высказывания), что система будет открывать свои двери «рандомным» наборам пакетов.

отнють. если для каждой сесси будет уникальный ключ — то пакеты будт уникальные. а рандомный пакет можно элементарно отсеять.

1. Перехватить ключ.
2. Перехватить ответ для этого ключа.
3. Пишем софт, пихающий программе постоянно этот ключ и ответ на него.

4. Profit.

Я что-то упустил?

обмен идет открытыми ключами ( например RSA ) прехват котрых не поможет. уязвимость — man-in-the-middle но от этого есть лекарство.

Поделитесь решением от man in the middle?

diffie hellman

Не спасает от man on the middle.

Сам по себе не спасает, но в комплексе с аутентификацией работает.

Никакая аутентификация при возможности реверсинжениринга и хакинга локальной проги полностью не поможет.

Но это уже не man-in-the-middle.

А аутентификация это уже и не деффи хелман ;-p

Но я твою мысль понял, и абсолютно с ней согласен!

А аутентификация это уже и не деффи хелман ;-p

Ну да :)

Если нету постоянного общение с сервером (выгребание данных, обработка чего либо и прочее), то реверс — наше все. Иначе даже без шифрования можно пускать в плаванье, имхо. Без сервера — клиент ничего стоить не будет.

разговор идет о подмене сервера автоизации.

Из быстро пришедших решений — через реверс обнаружить место авторизации и снести его патчем.

ну найти и выломать — как говорится «против лома ...», а если их несколько и некоторые из них используюся не регулярною можно получит глючную погу

предсавьте себе например фотошоп который будет раз в день падать потому что его не полностью пропатчили. для пофессиональной деятельности такой вариант не пойдет.

или игру, которая упадет на самом интересном месте.

Единственное решение — предустановленный открытый ключ в програмулине, но его реверсинженирингом теоретически можно заменить

Это называется PKI.

PKI imho обычно называют все это хозяйство с иерархиями issuers, цепочками, метаинформацией и revocation lists сертификатов.

Просто PKC без PKI не может гарантировать конфиденциальность.

Если абривиатурой PKC ты хитро назвал сертификат, то почему не может? В простейшем случае может — есть клиент и сервер которые заранее обменялись открытыми ключами. Какая угроза конфиденциальности?

PKC — Public Key Cryptography, PKCS — набор стандартов PKC. Сами по себе алгоритмы, описанные в PKCS не оперерируют аутентичностью, не проводят аутентификацию. А то что ты рассказываешь, это уже часть PKI, которая реализовывает аутентификацию.

Ладно, пойду скаже маме что ее плейн текст пароль от гмейла сохраненный в текстовом файле на компе — это часть PKI реализующая аутентификацию!

Можешь рассказывать. Не забудь рассказать про SSL :)

любым способом, котрый выявит чужие пакеты на этапе обмена ключами

например — генерируеш crc пакета и добавляешь в пакет, шифруешь весь пакет секретным ключем. сам секрентый ключ можеб быть не константой (чтоб не нашли в теле) а генерится на лету.

таким образом вы можете выявить модификацию или подмену пакетов

можно крекнуть и выломать сам код авторизации — но этот подход не совсем «кошеный» .

Что значит не кошерный если в большинстве случаев так и ломают?

кейген — это кошерный, так как правильный ключ гарантирует 100% работоспособность проги.
а крек не кошерный так этого гарантировать не может, вдруг где то спрятана дополнительная проверка, которая срабатывает только при определенных обстоятельсствах ( например при схранении доукмента > 20 раз, или в понедельник, или еще чего..)

Если исключить возможность создания кряка программы, то очень просто написать алгоритм под который кейген не сгенерится, типа в программе хранится SHA1024(что б мало не показалось)хеш оригинального ключа, и что бы сгенерить ключ кейгену прийдется собственно найти колизию SHA1024 что на сегодняшний день невозможно ни на каких суперркомпьютерах. По этой причине меня кстати факт существования кейгенов в принципе смущает, может я чего то недопонимаю?

Это алгоритм RAR’а, только хеш считается 256 тысяч раз, чтобы мало не показалось.

Алгоритм для чего? Шифрования файла? Зачем там нужен какой то хеш?

И шифрования внутри архива и генерация serial’а, если мне память не изменяет. Хеш — это ключ.

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

Да, именно для замедления. А лицензионный RAR стоит $35, что явно дешевле брутфорса.

А содержимое архива может быть намного дороже.

Да. Но замедление помогает очень сильно, даже с двумя GTX 580, с разогнанным core i7 до 4.5GHz я получаю около 10000 брутфорсных паролей в секунду. Даже имея ферму быстрее чем за пол года-год кошерный пароль не вынести.

С появлением облаков правила игры немного изменились: arstechnica.com/...n-ec2-cloud.ars

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

GTX 580

А твой крякер использует гпу?

С появлением облаков правила игры немного изменились: arstechnica.com/...n-ec2-cloud.ars

Что-то твоё облако аж на 451 месте :) Computational кластера рулят.

top500.org/...ist/2011/06/100

А твой крякер использует гпу?

Не мой. Да, использует GPU. В перерасчёте 6 ядер core i7 980 уступают одной GTX 580 в 5-6 раз.

Что-то твоё облако аж на 451 месте :) Computational кластера рулят.

top500.org/...ist/2011/06/100

Осталось выяснить сколько мне нужно откладывать карманные деньги с моих завтраков на комп из топ500 что бы поломать пароль соседкe по парте.

Осталось выяснить сколько мне нужно откладывать карманные деньги с моих завтраков на комп из топ500 что бы поломать пароль соседкe по парте.

%-)

я не хакер. но насколько я знаю кейгены делаются таким макаром:

—при вводе ключа хакер отлавливает момент ввода напр GetWindowText
—отследивает движение данных ключа до того момента кода происходит прверка этого ключа ( ненерация хеша или чего еще )

—выерезает эту процедуру поверки и вставляет в свой кейген

то есть никакие супер-пупер вычисления не призводятся, а copy-paste.

Спорить лень, но ты ерунду написал, как процедура проверки может сгенерировать новый ключ?

особо спорить не буду :) раз вы и впрямь reality_hacker

как вы думаете работает активация? по сути внури по серийному ключу
вычисляется ключ активации и сравнивается с тем ключем

активации что вы ввели

вот несколько мануалов, как найти вычисление ключа активации в коде и из него сделать кейген
rahulhackingarticles.wetpaint.com/...to make keygens
forum.gsmhosting.com/...e/t-288761.html

www.xakep.ru/...397/default.asp

В предложенном мной варианте вчисление происходит наоборот — серийный ключ — это хеш от вводимого кода активации и твоя схема не катит, т.к. что бы сгенерить новый код активации нужно найти колизию в SHA1024 что до появления квантовых компов вряд ли получится.

не имеет значения — хеш не хеш :)

при преходе на фунцию вычисления этого хеша априсходит jump. для того чтоб следать кейген нужно найти этот jump и сделать из того куска кода кейген. хакер даже не задумывается о алгоритме вычисления. все кейгены делаются одним и тем же образом.

вот еще пример: www.onrpg.com/...ards/50489.html

один из продуктов над которыми я работал использовал sha512 для активации. кейкен появился через 2 недели после выхода продукта. хакер для того чтобы его сделать потратил максимум пару часов.

если вы хакер в **самом деле** я не буду спорить :)

в указанных мной примерех сложность вычисления ключа никак не влияет на сложность создания кейгена. так как никаких super computations в реалньности никто не делает.

не имеет значения — хеш не хеш :)

при преходе на фунцию вычисления этого хеша априсходит jump. для того чтоб следать кейген нужно найти этот jump и сделать из того куска кода кейген. хакер даже не задумывается о алгоритме вычисления. все кейгены делаются одним и тем же образом.

вот еще пример: www.onrpg.com/...ards/50489.html

один из продуктов над которыми я работал использовал sha512 для активации. кейкен появился через 2 недели после выхода продукта. хакер для того чтобы его сделать потратил максимум пару часов.

если вы хакер в **самом деле** я не буду спорить :)

в указанных мной примерех сложность вычисления ключа никак не влияет на сложность создания кейгена. так как никаких super computations в реалньности никто не делает. все делается на вполне средних компах. :)

PS розможно вы запутались в терминах «серийный ключ» и «ключ активации» — серийный известен еще до процесса активации и по сути это идентификатор проданного образца. и не может генерироваться по ключу активации.

возможно нужно было сказать «reaquest key» ключ котрый катомер дает вендору для вычисления activation key — так или иначе activation_key = f( request_key ) присвует в теле программы — ее можно найти, вырезать и сделать на ее основе кейген встроив во врапер с парой полей.

и не может генерироваться по ключу активации.

Почему не может? ЧТо конкретно мешает? В третий раз повторяю — в этом и заключается моя схема — генерировать серийный ключ как хеш от ключа активации, и если ее заимплементировать все твои рассуждения примеры и ссылку отправляются в урну — кейген построить нельзя.

’генерировать серийный ключ как хеш от ключа активации’ - это можно назвать как угодно но не «серийный ключ»

вопрос: в проге можно найти вычисление этого хеша?

’генерировать серийный ключ как хеш от ключа активации’ - это можно назвать как угодно но не «серийный ключ»

Ну не назыавай, твое личное дело, а я буду называть строку вида ’081253bf64885b3aa3e645012f7e2857c4c5c206′ серийником и не вижу в этом никаких проблем.

вопрос: в проге можно найти вычисление этого хеша?

Вот тебе прога:
read s
if(sha1(s) == ’081253bf64885b3aa3e645012f7e2857c4c5c206′) {
print ’cool’
} else {
print ’Invalid activation code’

}

Жду кейгена

А смысл в такой защите?

так как 1 ключ на все инстансы проги.
купил, передал ключ другу, а тот своему другу, а тот выложил в инете. зачем тут кейген?

так как ключ один — вендор даже и предположить не сможет кто disclosed.

или для каждого покупателя будет билдаться отдельная инстанс?

а как с доунлоадами? так как нужно делать custom build.

если даже и custom build это не предотвращает предачу ключа и установку проги не неграниченное количество машин.

-----

согласен. кейген тут сделать нельзя. но это и не меет смысла. так как генерить нечего. проще распространить 1 ключ.

такая защита не имеет смысла вообще.

----

или для каждого покупателя будет билдаться отдельная инстанс?

Билдить не обязательно, достаточно перезаписать последовательность чисел

если даже и custom build это не предотвращает предачу ключа и установку проги не неграниченное количество машин.

И как от этого защищает «классический подход»?

«классический подход»

не совсем понятно, что вы подразумеваете под классическим.

чтоб предотвратить использование ключа на другой машине обычно генерирент request key на основе hardware lock ( который идентифицирует машину ) (кое-кто иcпользует software lock)

кастомер получает request key при запуске проги
request key = f( machine )

посылает request key вендору + оплачивает счет

вендор генерит ключ активации
activation key = F( request key )

вендор посылает activation key кастомеру

при активации прога делает проверку введенного ключа

input activation key == F(f(machine))

activation key не сработает на другой машине так как он F(f(machine))

уязвимость — можно вырезать F и сделать кейген.

Кейгены(и схемы их исключения) и хардварные сигнатуры ортогональны и могут сосуществовать или несосуществовать паралельно.

Сломали ваш супер пупер алгоритм шифрования и защиты (все там же на руборде)... вообще это вечный спор пули и брони :) ...
За «отупели» отвечать надо... каким тупым надо быть чтобы в VS код писать так коряво... а народ в унманаджет коде копается и разбирается...

Как вариант лучше рассмотреть снижение стоимости... тогда всем тыщ 5 руб. проще отдать... напрример без суппорта но унлимитед.... а если надо суппорт еще тыщ 20 руб... вот тогда ломать не зачем будет...

Ну да, в подгруженном процессе нашли паблик ключ сертификата и подменили своим. Не велико копание. Впрочем, после SP2 это уже не пройдет. Можешь проверить — накати SP2 и попробуй активировать левым ключом.

Другое дело, что по недосмотру SP2 и SP3 пошел без требования обязательной реактивации, поэтому его можно накатить поверху. Но это фигня. Больше лажи не будет. Если будет SP4 — то после апдейта фейковые активации работать не будут.

За «каким тупым надо быть» — тоже надо отвечать. Сломай SP2 или SP3 — и ты докажешь, что ты не тупой.

Как вариант лучше рассмотреть снижение стоимости...

Мы СНГ как рынок никогда не рассматривали. Ломайте на здоровье! Босс не выделяет достаточно ресурсов на защиту, но, поскольку вы таки меня лично разозлили на ру-борде — халявы больше не будет. Я в свое личное время переделаю защиту. Посмотрим, как вы будете ломать v11.

Yuriy
Читаем внимательнее: «вариант сломали», имеется ввиду вариант защиты, а не сам AES. Ранее я говорил, что ключ нашли в теле. Уж не знаю по каким признакам догадались про AES, но дважды на грабли я не люблю наступать.
gonzo

Да, можно отреверсинжинирить. Но, как я и говорил, никто этим не занимается. Можно было бы и не париться с расшифровкой, а поотлавливать все места, где проверяется лиц. инфо, но видимо и это слишком сложно/дорого для софта такого типа.

Октай, интересная идея.:)

«Улучшить» защищенность кода эквивалентно — повысить трудность/стоимость его взлома.
Как можно максимально повысить трудность взлома кода?
Например — не «сообщать» юзеру/хакеру, что софт зарегистрирован легально/нелегально.
В таком случае, хакер не будет иметь возможности знать — «вскрыл» он код удачно, или неудачно?! Он не будет иметь возможности настроить алгоритм взлома на какие-то точки типа «прошел — непрошел», т.к. этих точек в принципе нет.

Как это сделать? — это уже другой вопрос. Решений может быть множество. Например использовать данные ключа в логике работы софта. Опять же — неявно. Если ключ «верный», то число Пи равно 3.14159265, если «не верный» то оно равно 3.1414. Поверьте мне, такая разница в константе не сможет быть уловлена программно, но через минуту работы юзер визуально (но не программно) уже будет видеть, что время потрачено зря. Есть еще много математических констант, статистических формул, весовых коэффициентов, вероятностных алгоритмов...

Вот это творческий подход. Направление верное.

но через минуту работы юзер визуально (но не программно) уже будет видеть, что время потрачено зря.

Обратную связь можно не давать — просто отключить некоторые функции, если программа взломана.

Минус — хакеры начнут кричать, что прога кривая и глючная.

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

Согласен. Но допустим ключ состоит из 27(или, скажем 47) символов. Ни больше ни меньше. Получение по e-mail. Ествественно никто их не будет вводить руками. Ctrl+C >> Ctrl+V. Даже можно запретить ввод с клавиатуры. Если какой символ и не был выделен при Ctrl+C, то в таком случае, все-таки можно поставить фильтр, и напомнить юзеру/хакеру, что скорее всего произошла ошибка ввода данных, что ествественно повлечет за собой «нелицензированное» функционирование софта.

мені здається це не бізнес-підхід.

з точти зору «програмера» це звучить логічно — заплутати хакера.
з точки зору хлопця з «підтимки» це звучить кошмарно так збільшить кількіст звертань «чого воно не працює...»

з точки зору «маркетинга» звучить не зовсім добре, так як може псувати імідж гарної проги чрез не ясну авторизацію.

а якщо юзер придбав ключ і помилився при введенні?

Ну можно по некоторым параметрам отличить взломанную программу от демо.

Она перестанет работать в каких-то местах только после взлома.

можна вираховувати хеш проги при запуску і порівніювати її з хешем «цілісної» проги — якщо хеші не співпадають — можна робити висновок — прога крекнута.

Где хранить хеш так, чтобы его не смогли заменить?

на удаленном сервере. по крайней мере система над которой я работаю так делает :) через пару недель выйдет бета.

Делается свой чип (процессор), делается USB-key на основе чипа. Ключ подключается к ПК и внутри него выполняется ключевой участок кода программы или ключевые участки, или обрабатываемые данные проходят через чип и т. д.
Взломать этот метод можно только реверс-инженирингом чипа, что для обычного хакера в домашних условиях невозможно.
Но свой ASIC могут себе позволить только оч. состоятельные компании (цена начинается где-то от 300к + 1−2 года на разработку чипа и подготовку к производству) — найти подрядчика будет не сложно (были бы ресурсы). Для остальных есть готовое решение от NXP SenseLock EL, вот тут можно почитать более подробно:
senselock.ru/...elock-genii.php

Хотя, думаю, слить ROM/flash со стандартного чипа, проще чем со специфичного ASIC. В любом случае, аппаратная защита куда лучше программной — софт айсом ее не сломаешь;).

Поэтому самым надежным вариантом я посчитал свой собственный алгоритм шифрования. По крайней мере его не найдеш в Гугле.

В гугле не найдешь, но алгоритм можно отреверсить. Я когда-то давно отреверсил алгоритм шифрования до рабочего состояния, а потом, по числам из блоков оказалось, что это комбинированый Twofish + Blowfish.

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

Тем, что после того как один вариант сломали (был стандартный AES) — использовать другой общедоступный-общеизвестный алгоритм шифрования — как мнимум наивно. Гугл сёрч есть не только у меня, как ни странно. Поэтому самым надежным вариантом я посчитал свой собственный алгоритм шифрования. По крайней мере его не найдеш в Гугле.

Да, именно сделал свой алгоритм шифровки. А что, есть сомнения?

А чем не устроили 100500 уже существующих?

Вообще-то в инфо указана компания в которой я работаю. Это и есть ответ на Ваш вопрос.

Да, именно сделал свой алгоритм шифровки. А что, есть сомнения?

Archie вам задали конкретный вопрос. А созерцать ваше инфо/жжешечки и проч. интереса нет.

После того как я сделал свой алгоритм шифровки

Вот оно как, он сделал Свой алгорим шифровки.

Давайте обсудим, как можно надежно или более-менее надежно защитить свой код от взлома.

Питання дуже дивне. Це з розряду —, а яке авто купити? Можна запорожець, ланос, болід формули 1, БЕЛАЗ, танк...
Який код, мова, гранична вартість, агресивність середовища, портабельність, сумісність, супровід...

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

Strelok, от видно, что ты тоже не хакер. Или моё инфо не всем показывается?

zzhou конечно прав.

Archie хэккеры на руБорде такие хэккеры. А что за софт-то?

Демо, тут уже справедливо заметили, что ломать никто не станет, если стоимость взлома стоит дороже программы. Взлом — это ж не прогулка под пальмами. А труд квалифицированного человека в течение какого-то времени. Никто не будет тратить месяц времени чтобы сломать программу стоимостью в 100 баксов.

Назови хоть одну программу которую не возможно взломать? И ты еще хочешь свою защитить? полагайся только на совесть пользователей

2Сергей,
Да, уязвимое место. Согласен. Пиши на unmanaged C++ и обязательно используй TLS соединение — и будет тебе Щасте. Я тут наблюдаю за российскими хакерами на руборде, они обленились (или отупели?) настолько, что анменеджед код ломать даже не пробуют. В пред. версии разгадали способ шифрации файла, в котором хранилось лиц. инфо (ключ нашли в теле экзешника) и влезли туда. После того как я сделал свой алгоритм шифровки — всё, песец. Файл расшифровать не могут, пытались ломать дотнетовскую часть, но там-то как раз нету важного функционала.
zzhou,

+100500. Все именно так. А вообще лучше не заморачиваться рынком СНГ. Его нет и не будет все равно. А на западе не так уж сильно и ломают. Если только это не игруха какая-нить. И то в основном ждут пока русские сломают.

Вы много знаете «православных» проектов с открытыми исходным кодом?

Java, Spring, Hibernate Ещё?

напиши opensource приложение под Maemo/Android и заработай на «обучении/сертификации/разработке кастомных решений»

Напиши Opensorce код по генерации проектов под Maemo/Android

Я работал над проектом, который был легко взламываемый. Но этот проект соблюдал несколько простых правил:
1. Был реально востребован пользователями.
2. Часто обновлялся.
3. Стоил не космических денег.

В результате имел неплохой приток пользователей из бывших пиратов.

искать и делать — разные вещи.

Код обращения к серверу лицензий — уязвимое место.

matt_

Тебе интересно как программы защищать от взлома или ты поумничать вышел?

Последняя (улучшенная) версия моего софта до сих пор не взломана.

неуловимый джо?

Из личного опыта: привязка к серверу лицензий рулит. Последняя (улучшенная) версия моего софта до сих пор не взломана. Уже больше года. Хотя на Варезнике руборда народ активно ищет/просит кряки.

Надо сделать так чтобы стоимость (сложность) взлома была больше чем стоимость официальной покупки софта

Реализация кода в железе не есть панацея, во-первых придется с софтом распространять еще и железяку и решать связанные с ней, взявшиеся из ниоткуда, вопросы. Во-вторых никто не мешает спилить/растворить корпус микросхемы, с помощью микроскопа и тривиальной приспособы снять lock bit и прочитать прошивку по JTAG и дальше спокойно лепить клоны, как это делают наши младшие желтые братья.

Saas всем хорош, пока есть [надежный] сетевой доступ к серверу, клиенты, готовые юзать все это в данном режиме и ваши безотказные сервера. Если софт не предполагает постоянное исполнение в сетевой среде, то придется рассматривать какие-нибудь донглы или что-то похожее. Весь вопрос в оценке возможных потерь (включая потери ограничения/исполнения самого кода), затрат на реализацию защиты и потенциальной стоимости ее взлома. В общем — balance is the key to the life.

2Влом
Из оригинального текста ТС кажется, что ему сейчас интересна не столько защита ПО от пиратства, сколько именно защита кода. И в этом смысле Ваши варианты, кроме весьма неоднозначного open source, конечно, не очень-то помогают.
Если хочется защищать именно код, то тут всё зависит от объёма кода и требований к нему (типа быстродействия). Если кода действительно требующего защиты много, то, вероятно, единственный жизнеспособный вариант, это таки не давать его не кому, например, исполнять только на своих серверах. Можно пытаться зашить код в какое-нибудь железо, по слухам реверсить сложную логику из железа значительно труднее, чем из ПО (возможно спецы по embed’у меня поправят). Если «секретного» кода не очень много и его быстродействие не критично, можно попытаться сделать свою запутанную виртуальную машину и исполнять критичный код в ней. Однако это сопряжено с кучей проблем и для правильной реализации требует нетривиальных знаний (у меня таких нет). Но в общем всё это большие и сложные решения.

Ну, а из простых идей: не писать на managed (и тем более интерпретируемых) языках вообще, и пользоваться обфускаторами. Правда популярные обфускаторы хорошо изучены и, видимо, хорошо ломаются теми, кому надо.

Да, забыл добавить — правильней будет «правоверный», а не «православный»;)

2Вовка:

Попробуй-ка напиши opensource приложение под Maemo/Android и заработай на «обучении/сертификации/разработке кастомных решений» или какое-нить приложение с уникальным know-how. Если у тебя есть лишние 10 лет жизни и/или _очень_ много денег — opensource рулез вне всякого сомнения.

Вы много знаете «православных» проектов с открытыми исходным кодом?

Сделайте свой код опенсорсным и зарабатывайте на обучении/сертификации/разработке кастомных решений.Правда это путь самый сложный, зато самый православный

Тут многое зависит от специфики программы, ее distribution area, маркетинговой политики и т.д. Вариантов обычно несколько, перечислены в плане уменьшения надежности:
1. Контроль запуска через выделенный интернет сервер лицензий
2. Привязка к нестандартному оборудованию (донглы, спец-железо которое необходимо для работы ПО, и т.д.)
3. Привязка к стандартному оборудованию (TPM, PCI, SMBIOS data, HDD, GSM IMEI, и т.д.)

В любом из вышеперечисленных случаев применяют различные анти-reverse и маркетинговые приемы, дабы уменьшить потери от нелегального использования ПО.

Киньте полезными ссылками. Литературку бы почитать.

Мне известно два способа надёжных способа защитить код от взлома — никому его не давать. — сделать код, который никому на фиг не нужен

Иначе говоря, при достаточном желании/необходимости сломают всё, что угодно. И в этом смысле, защита и методика «официальной покупки» со всеми сопутствующими плюшками должны быть такими, что последний вариант оказывался проще, дешевле и удобнее.

+1000 единому здравомыслящему и опытному человеку

Подписаться на комментарии