Некорректно работает из-за вирусов, а не из-за того, что сама программа начинает портить данные. Насчет всего остального, в крупных компаниях юристы основательно изучают лицензионные соглашения, а суммы договоров могут быть значительными и альтернативы тоже. Поэтому, программы отвечают за то, что делают сами.
Серьезные программы не дистрибутируются «As Is» потому как программа без ответственности о результатах своей работы многим коммерческим компаниям не подходит. Так вот, если она что-то запортит или рассчитает неправильно, это может стоить компании серьезных убытков. С автора вируса они очевидно не смогут из взыскать, а вот с авторов программы — запросто. Особенно если учитывать то, что повреждение нанесла программа, а не вирус. Вот в чем делема.
Тут, говорят после заражения вирусом (даже если она была вылечена антивирусом) контрольные суммы и у легальных пользователей могут не совпадать. Поэтому, эта медаль о двух сторонах…
Отследить можно что угодно. И появление и уничтожение. Весь вопрос насколько просто. Если при использовании стандартных функций, которые хорошо описаны в других примерах вскрыть программу сможет первый встречный, но использование нестандартных функций может кое кого остановить. Насчет того что писать, а чего не писать — решать мне, в общем, спорить не собираюсь.
Хорошая система защиты стоит не дешево. И разработка собственной хорошей защиты порой может по стоимости превышать затраты на разработку самого программного продукта. Поэтому, воспользоваться готовыми решениями для некоторых — выход. Ведь, можно не продать ни одной копии программы, притом все будут пользоваться ей «на халяву».
Вообще, по мне так — я против всякого деструктива. Программа должна стоить реально исходя из возможностей потенциальных покупателей плюс основной должна быть служба поддержки и налаженная целевая аудитория сбыта. Т.е. решать вопрос легальности копий не только программными, но и маркетинговыми методами.
Конечно не мешает. Так и происходит на самом деле. Ведь если программу кто-то захотел взломать кто разбирается в процессе — то все равно взломает. А вот, допустим, школьник, прочитавший в интернете и действующий по инструкции — может на этом споткнуться. Я уже писал тут, что для программирования терпимой программной защиты перед навесной нужно не 4 совета, а в 40 бы уложиться…
Хочу еще раз подчеркнуть, что советы не претендуют на полноту и достаточность. Они лишь описывают конкретные ошибки в данной изучаемой программе. Диалоговые окна — не бред: поставив на функцию прерывание INT3, можно легко отследить их работу в отладчике. Найти собственное написанное окно сообщений также возможно, но на это потребуется два «клика» вместо одного.
>> все строки в программе хранились в зашифрованном виде, и расшифровывались на лету ( то есть зная какое сообщение выводит программа в коде найти его было нельзя не взломав наш ключ и алгоритм шифрации)
Заблуждение. Часто сами строки ничего не решают. Это затрудняет изучение, но очень слабо. Некоторые их даже не ищут.
>> Если фукнция возвращала true — мы знали что программу взломали.
Саботаж — он конечно интересен, но по ошибкам легко догадаться откуда ноги растут и пропатчить :)
>> в ключевых местах программ — проверка CRC
Которую также можно сфальсифицировать при желании…
>> Ключи вшивались в бинарник после компиляции программы.
Можно изменить ход программы таким образом, чтобы она любые ключи принимала за правильные.
>> сами взломщики рекомендуют использовать таймауты чтобы проверять не отлаживается ли программа
Подходит только для некоторых отладчиков. Самые сложные останавливают на время отладки всю систему. Так что, поймать таймерами их невозможно.
Ломают все — так уж повелось )) Как говорится, замки создаются для честных людей :) Сможет ли рядовой программист написать защиту, которую не сломают? Навряд-ли… Сможет ли рядовой программист написать защиту, которую не сможет взломать школьник? Хм, возможно! Именно это я и хотело донести до читателей.
Тема как раз «основные ошибки..». Мало купить протектор, надо еще уметь правильно воспользоваться его API. А это несколько другое. Как я уже писал в комментах, многие пронадеявшись на внешний протектор, допускают страшные ошибки в блоках проверки. Возможно, в других статьях я освещу тему с протекторами. И для того, чтобы написать действительно хорошую защиту, конечно, вышеприведенных советов будет явно недостаточно.
Перечня софта-документации и так достаточно в интернете. А показывать как менять условные переходы — не цель данного материала. Внешние протекторы не решают проблему полностью. Естественно, качественную защиту надо продумывать основательно и не останавливаться на приведенных советах. Статья называется «Основные ошибки», а не «программирование защит». Поэтому, все логично :)
Часто программисты, понадеявшись на внешний протектор допускают страшные ляпы в теле программы и в самом использовании протектора. Так что, такой код можно читать как открытую книгу несмотря на навесную защиту.
2, 3 — согласен.
з.ы. Познакомился лет 15 назад :) Пример, согласен — очень простой. На это и рассчитывал.
Заблуждение. Часто сами строки ничего не решают. Это затрудняет изучение, но очень слабо. Некоторые их даже не ищут.
>> Если фукнция возвращала true — мы знали что программу взломали.
Саботаж — он конечно интересен, но по ошибкам легко догадаться откуда ноги растут и пропатчить :)
>> в ключевых местах программ — проверка CRC
Которую также можно сфальсифицировать при желании…
>> Ключи вшивались в бинарник после компиляции программы.
Можно изменить ход программы таким образом, чтобы она любые ключи принимала за правильные.
>> сами взломщики рекомендуют использовать таймауты чтобы проверять не отлаживается ли программа
Подходит только для некоторых отладчиков. Самые сложные останавливают на время отладки всю систему. Так что, поймать таймерами их невозможно.