Запись в экзешник защитить прогу вряд ли сможет (имхо). Фактически ты сам создаёшь патчер, так какая защита из этого. Ещё зависит от того, что именно писать надо. Если прыг изменить, так это фигня, тогда уж надо кусок кода вырезать и патчером вставлять, тогда будет засада, а если этот код ещё криптом RC4 зашифровать, да ключик сиволов эдак 20, тогда токо брутфорс. Но кто похакает 100% в инет всё сольёт чтоб насолить , а то и просто купит и в сообщит всем пасс или патчером поделится. По-моему есть гораздо более хорошие способы защиты (отношение сложность создания/сложность взлома), так что париться с этим я бы не стал.
Это не запись проги саму в себя, но очень сильный способ обломать кракера. Хотя не знаю, почему тебе так охота изменять код программы, ну вобщем без паса 200% прогу не взломать...
Пока Ra$cal пишет может кто ещё выскажет соображения по поводу патчей. Я когда писал честного говоря не подумал о взломах патчами.
Нужно учитывать все варианты. Раз уж тема патчей затронута (цель не важна - благородна она или злодейская), то давайте уже доведём её до конца.
Дык тебе для защиты... Спешу обламать: защитить твою программу от изменений достаточно просто: либо поместить на read-only устройстве, либо каждый раз возвращать прежнее состояние. Батник я привел в качестве proof-of-concept. Как вариант можно предложить DLL, которая сама себя в памяти меняет, а потом шифрует, упаковывает и пишет из памяти в другой файл. А ехешник, вызывающий эту DLL, проверяет, какое из этих двух названий есть, ту и загружает... Но это тоже скорее proof-of-concept...
Обламать сложно, но можно. Это я тебе как крякер заявляю. После поломки нескольких десятков прог можно понять как их стоит защищать. Вот кратенький список:
1) НИКОГДА нельзя выдавать сообщения о правильности или неправильности пароля.
String Reference взлом. Самый простой способ. Патч за 2 минуты (если не использованы другие
способы защиты(например №14 и №6)).
************************************************************************************************
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
2) НИКОГДА не хранить пароль открытым текстом (хотя бы в HEX форме).
Подглядеть в памяти правильный более чем элементарно.
************************************************************************************************
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3) НИКОГДА не проверять пароль сразу после ввода.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4) ВСЕГДА стирать правильный пароль после сравнения.
Порывшись в памяти рядом с ввёднным пасом можно найти правильный.
************************************************************************************************
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
5) ЖЕЛАТЕЛЬНО периодически во время работы программы проверять пароль.
На тот случай, если было изменено значение флага.
************************************************************************************************
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
6) ВСЕГДА делать несколько подпрограмм проверки пароля.
Если процедура одна её можно пропатчить и программа
будет уверена, что она зарегестрирована.
************************************************************************************************
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
7) ВСЕГДА сравнивать пароль посимвольно.
См. пункт 2
************************************************************************************************
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
8) ВСЕГДА разбивать процесс генерации пароля на несколько подпрограмм. Можно сравнивать
результаты отделных подпрограмм и если что не продолжать проверку. Но сравнивать надо
какие-нибудь незначительные параметры (то есть нельзя помещать ВСЮ проверку в эти процедуры,
они служат только для генерации, процедуры проверки должны быть отдельно).
См. пункт 3
************************************************************************************************
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
9) Проверять пароль из разных мест разные куски (часть из реестра, часть из файла, имя файла
и ключ реестра обязательно должны быть зашифрованы хоть каким-нибудь способом).
См. пункт 3.
************************************************************************************************
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
10) ВСЕГДА проверять длину пароля, контрольную сумму пароля, определённые симолы, причём все
эти процедуры должны быть ОЧЕНЬ глубоко зарыты.
См. пункт 3. Причём чем глубже зарыты - тем сильнее чувства у кракера
************************************************************************************************
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
11) Не помешает сделать на сайте чёрный и белый лист с именами пользователей, и при не
обнаружении в белом списке портить код программы (только опять же с задержкой) (адрес листов
есесно должен быть зашифрован).
Если кто-то купил программу - добавляем имя в белый лист, а потом даём ему пароль. Действенный
метод, жаль, что при использовании фаервола не работает.
************************************************************************************************
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
12) Неплохо привязать программу к компьютеру (использовать при генерации имя компьютера, имя
пользователся, серийный номер диска). Можно эту инфу брать пошифрованной, чтоб человек не
догадался, как генерится пароль, но если уж человек очень подозрительный отправлять открытым
текстом.
Эффективный способ защиты от распространения ключиков от купленных программ.
************************************************************************************************
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
13) Очень желательно введённый пароль и правильный пароль шифровать перед проверкой.
Даже если кракер увидит сравнение строк ему придётся разбираться с алгоритмом шифровки.
************************************************************************************************
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
14) ОБЯЗАТЕЛЬНО делать несколько переменных(порядка 10 штук) и хранить там информацию,
зарегестирована ли программа. Хранить разными способами: True или False, набор определённых
символов, кусок пароля... Периодически проверять, и если вдруг хотя бы одна переменная не
подтвержает регистрацию вызывать ошибку в программе. Если ВСЕ пишут, что регистрации нет, валить
прогу не стоит
Это хорошая защита от патча.
************************************************************************************************
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
15) НИКОГДА не используйте любые пакеры/протекторы. Защищать они может и умеют(протекторы - да,
пакеры - полный отстой, никаких шансов), но программы работают гораздо медленне и снижается
производительность системы в целом.
Они усложняют взлом, но не настолько, насколько хотелось бы.
Обломать - невозможгно... можно-лишь максимально приблизить затраты на взлом цене программы...
Даже тем способом что придлагает Rascal, 100% никто дать не может, т.к. патчь можно всегда выложить на всеобщее обозрение...
да, вот еще один вариант, снять образ файла до и после регистрации, создать свой собственный патч и выложить его в сеть... все проще некуда...
В итоге на одной лицензии, как обычно, будет по одной тысяче человек