Hе бывает чудес.
К сожалению.
Т.е. "положить компонент на форму и огрести счастья" не выйдет.
Если ты считаешь что это так и твоя программа кому-то будет нужна, то ты
только добавишь радостных минут какому-то начинающему хакеру.

Одной компонентой никакую защиту не осуществить.
Hи плоху, ни хорошую - никакую.
Это несерьезно.
И не зависит от того проверяет она что-то "нелинейным ключом" или сравнивает
ключ с заранее забитой в экзешнике строкой.
_Все_ такие проверки обходятся в перерыве на обед минут за 15-20 очередной
сменой какого-нить 75h на 74h или 90 :)

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

Поэтому, вот мое ИМХО, которое, возможно, тебе пригодится, если тебе-таки
надо что-то защитить.
Аксиомы:
  1. защита должны быть комплексной.
     Т.е., как я уже говорил, одной компонентой ничего сделать не получится.
     По большому счету чужие компоненты можно использовать только для
проверки некоторого введенного кода, если самому лень или не охота писать
подобный алгоритм.

  2. Ты должен быть готов к тому, что самому придется многое узнать. не стоит
расчитывать на готовые универсальные и "мощные" библиотеки. Чем меньше у тебя
в программе глупостей вида:
        call IsLicenseAlive
        je ShowNagMessage
     тем лучше тебе и сложнее потенциальному ломателю.

  3. Защита должны быть актуальной.
     Т.е. твою программу все равно сломают, если кому-то это понадобится.
Вопрос _только_ во времени (рассматриваем вариант когда это вообще кому-то
нужно). Чтобы от этого защитится тебе надо менять ее (бетты, добавления,
плагина, етц) настолько часто, насколько возможно, используя самые новые
версии защит, которые ты будешь использовать.

  4. Единственный способ как-то ограничить "пытливого" пользователя
функционально - _не иметь_ лишних функций в программе. Т.е. если у тебя
functional-limited, то эти функции должны не обходится по условию, а
отсутствовать вообще.

Подготовка: перед тем как защищаться, тебе надо решить как ты это будешь
делать и что тебе надо от защиты.
 Hекоторые сведения, которые тебе для себя надо решить перед тем, как браться
за защиту.
  1. Сколько будет стоить твоя программа. (Чем дороже - тем большая
вероятность что ее сломают)
  2. Какой тип регистрации ты будешь использовать, если программа, к примеру,
бесплатная и условно-бесплатная. (Чем сложнее/нуднее/етц - тем большая
вероятность что ее сломают)
  3. Какое количество пользователей будут использовать твою программу больше
определенного ознакомительного периода. Т.е. на скольких реальных
пользователей ты расчитываешь. (Чем больше - тем большая вероятность что ее
сломают)
  4. Как часто твоя программа будет обновляться (Чем реже - тем большая
вероятность что ее сломают)
  5. Какое количество аппаратных средств может использовать алгоритм защиты
для проверок (Чем меньше - тем большая вероятность что ее сломают). Здесь
идет речь е только о различных ключах, но и об аппаратной части машины, если
тебе нужна привязка "к месту".

И самое главное: сколько ты собрался с этого получить - не имеет смысла
защищать то, что не приносит дохода или не окупит усилий по защите.

Как мне кажется, наиболее простым способом сделать защиту для _любой_
программы является:
  1. Берешь алгоритм проверки того типа ключей, который тебе нужен. Алгоритм
любой, можно использовать эти самые чужие компоненты. От сложности этого
алгоритма зависит только то, с какой вероятностью на тебя напишут кейген.

  2. Покупаешь какой-нить пакер/шифровальщик.
     Выбираешь по критериям (по мере убывания):
       - наиболее часто обновляющийся;
       - наиболее часто использующийся; (в смысле неудачных поломок)
       - наименее часто использующийся; (в смысле наличия готовых анпакеров,
универсальных дешифратором, етц)
       - наименее стандартный; (в смысле предыдущего пункта)
       - самый, на твой взгляд, продвинутый;

  3. Разрабатываешь, или используешь некоторое АПИ, или готовые компоненты,
если тебе так нравится, котоорые занимаются проверкой. Как следует из аксиом
:), проверки должны быть:
       а) массовыми (чем больше, тем лучше)
       б) разнообразными (чем больше вариантов _разного_ и _независимого_
кода используется, тем лучше).
          В этом отношении идеальным может быть - новая функция/кусок кода для
_каждого_ элемента проверки.
          Т.е. _не универсализировать_ ничего, кроме того, что в принципе
нельзя сломать (например вин АПИ).
          Поясняю: никакого смысла множественных проверок нет, если везде
будет вызываться одна и та же функция, возвращающая одно и то же значение -
отломают саму проверку и вся массовость псу под хвост.
       в) кодовлияющими.
          Т.е. тебе надо что-то делать или не делать _не в зависимости_ от
результата проверок, а делать _используя_ результат. Пример: если ты знааешь,
что правильный код функции проверки будет иметь определенное математичекое
описание (или, лучше, генерить его так), то ты можешь включать его в
вычисления с целью, чтобы формулы расчитывались верно только если используемый
код верен.
       г) незаметными.
          Если после каждой проверки программа орет "ой", то найти место этой
проверки займет гораздо меньше времени, чем если программа будет работать
молча и неправильно или вообще упадет где-то/когда-то _потом_ из-за неверно
расчитанного значения.

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

  5. Заворачиваешь это все полученным пакером из пункта 2.

  6. Тратишь _деньги_ и ищешь приличного кракера с просьбой сломать
полученный результат.
     Когда он это сломает оцениваешь время, которое он потратил и дыру,
которую он использовал.
     По необходимости перерабатываешь п1, п2 или п3.

  7. Выпускаешь в массы и смотришь через какое время на тебя появится крак
или кейген.
     По идее время актуальности текущей версии твоей программы должно быть
меньше времени слома какой-то одной ее копии.

PS:? Так что смотри сам - стоит оно того или нет :)
    Чтобы сделать нормальную защиту надо потратится, а ненормальную...
просто пожми каким-нить асПротектом из последних.
    Hа некоторое время, до публикации анпакера на эту версию, твоя прога
будет защищена хотя-бы от школьников и надейся на то, что никто не
потратится на реквест на поломку :)

ПPS: Если-таки решишь что-то делать, то помни - защита сильна настолько,
насколько силен ее слабейший элемент.
     Труд потраченный на несбалансированную защиту всегда пропадает зря.
Jouri Mamaev 2:5020/1877.665
                                                 
 ---
 *Примечание сост.: толкование используемых в тексте слов:
  етц - и.т.д.; эхотаг - C++Builder; дыра - незащищёное место в программе,
  воспользовавшесь которой, злоумышленник игнорирует защиту; асПротект -
  программа AsProtect, пакует защищает exe файл от внесения изменений; пакер
  - программа архиватор, пакует EXE файл, обеспечивая при этом простейшую
  защиту; анпакер - программа распаковывающая EXE файл, предоставляя
  злоумышленнику вносить изменения в программу; заворачиваешь - упоковываешь;
  cофтина - программное приложение; кейген - генератор регистрационных ключей

Предыдущий вопрос   |    |   Следующий вопрос

источник            by jenyok