Comments 71
Основная ошибка — не купили протектор :)
Ну а еще нужно добавить что часть проверок должны быть отложенны по времени и быть не регулярны — например каждый четверг, или каждое 12-такое число.
Ну а еще нужно добавить что часть проверок должны быть отложенны по времени и быть не регулярны — например каждый четверг, или каждое 12-такое число.
Протекторы не спасают, даже на самые изощренные можно написать загрузчики либо просто снять дамп. Про дополнительные проверки я также написал в самом конце.
Угу, это какой цены должна быть программа чтобы оправданной было бы писать свою виртуальную машину. Снятие дампа требует чтобы прогнались все ветки кода — никто не накрывает же всю программу виртуальной машиной, а различные куски — причем в разное время выполняються разные.
Хороший протектор с онлайн активацие спасает. Хороший пример тому Дальнобойщики2 с онлайн активацией — уж насколько востребованный продукт, а протектор не сняли — ну по крайней мере в течении месяца после релиза, сейчас не вкурсе.
Хороший протектор с онлайн активацие спасает. Хороший пример тому Дальнобойщики2 с онлайн активацией — уж насколько востребованный продукт, а протектор не сняли — ну по крайней мере в течении месяца после релиза, сейчас не вкурсе.
И виртуальные машины можно взломать. Просто это уже совсем другой уровень.
Можно практически все. Но реально покупка проектора за 200 баксов это самое простое и самоей надежное что имеет смысл делать.
Ну по крайней мере пока у вас программа не сравнялась с популярностью и доходностью Дальнобойщики2.
Т.е. как бы если давать рекомендации и говорить о ошибках — то первая рекомендацию будет — если ваша программа продаеться настолько хорошо что нуждаеться в защите, то правильным будет думать не о том как свой диалог об ошибке написать, а о покупке протектора и о том как накрыть им свой код.
Т.е. нужно определиться — если тема статей защита программного обеспечения, то и советы нужно давать реальные.
Ну по крайней мере пока у вас программа не сравнялась с популярностью и доходностью Дальнобойщики2.
Т.е. как бы если давать рекомендации и говорить о ошибках — то первая рекомендацию будет — если ваша программа продаеться настолько хорошо что нуждаеться в защите, то правильным будет думать не о том как свой диалог об ошибке написать, а о покупке протектора и о том как накрыть им свой код.
Т.е. нужно определиться — если тема статей защита программного обеспечения, то и советы нужно давать реальные.
Тема как раз «основные ошибки..». Мало купить протектор, надо еще уметь правильно воспользоваться его API. А это несколько другое. Как я уже писал в комментах, многие пронадеявшись на внешний протектор, допускают страшные ошибки в блоках проверки. Возможно, в других статьях я освещу тему с протекторами. И для того, чтобы написать действительно хорошую защиту, конечно, вышеприведенных советов будет явно недостаточно.
ВМ уже обязательный аттрибут практически любой системы защиты. И ковыряться в опкодах станет не каждый и всегда оценит ради чего он это делает. Главное сделать так, чтоб ковыряться пришлось, а не нашлось какой-нибудь лазейки в стороне от ВМ и даже ее не затрагивая.
Верно!
Возьмем тот же вмпрот. Его стоимость для shareware продукта, при условии, что в последних версиях появилась система лицензирования, соизмерима с затратами и эффектом от самостоятельной проработки заглушек и ловушек.
Совсем недавно у меня в планах было запускать shareware продукт. Стоило пустить слух и на мед слетелись те же StarForce в лице своих дистрибьюторов (SoftKey & etc) — у них есть решения, которые остановят всех, кроме Faza9 :))) «всего лишь» за 5-20% от ваших продаж. Для кого-то это выбор. Достойный выбор.
Совсем недавно у меня в планах было запускать shareware продукт. Стоило пустить слух и на мед слетелись те же StarForce в лице своих дистрибьюторов (SoftKey & etc) — у них есть решения, которые остановят всех, кроме Faza9 :))) «всего лишь» за 5-20% от ваших продаж. Для кого-то это выбор. Достойный выбор.
Хорошая система защиты стоит не дешево. И разработка собственной хорошей защиты порой может по стоимости превышать затраты на разработку самого программного продукта. Поэтому, воспользоваться готовыми решениями для некоторых — выход. Ведь, можно не продать ни одной копии программы, притом все будут пользоваться ей «на халяву».
Дальнобойщиков сломали на третьей неделе после релиза
Дальнобойщики 3, а не 2.
Выход — 27.11, таблетка — 25.12. Все же появилась в течение месяца.
По теме: нужно соотносить затраты на разработку и на защиту и исходить из целевой аудитории ПО.
Выход — 27.11, таблетка — 25.12. Все же появилась в течение месяца.
По теме: нужно соотносить затраты на разработку и на защиту и исходить из целевой аудитории ПО.
Спасают, спасают. Простой дамп уже почти как лет десять снять нельзя после использования нормальных протекторов. :-) И толку от дампа, если его половина будет обфусцирована, а вторая — зашифрована и без валидного ключа ничего все равно не увидишь?
Речь идет о другом. Намного проще и разумнее довериться крупному (или наоборот очень редкому) протектору (внимательно изучив перед этим % удачных снятий и отсутствие автоматов), чем в итоге оказаться в луже из-за забывчивости. Понятное дело, что изучение SDK прота и собственные мозги обязательны.
ExeCryptor долго держался, потом пришел RSI [cracklab] и уничтожил его окончательно.
WinLicense недавно прогнулся перед FFF [начали кейгейнить], но все равно спасает многих.
VMProtect достаточно хорошо держит напор, это вообще наш родной продукт.
ExeCryptor долго держался, потом пришел RSI [cracklab] и уничтожил его окончательно.
WinLicense недавно прогнулся перед FFF [начали кейгейнить], но все равно спасает многих.
VMProtect достаточно хорошо держит напор, это вообще наш родной продукт.
Добавил бы еще использование обфускаторов. От ламо-хакеров спасет.
Это верно :) Делал как-то такую штуку, которая по таймеру меняла некоторые участки кода в памяти. т.е. программа при загрузке была не такая, как во время работы :)
Обфускаторы мало где применимы (.net платформы, java). Обфускация некоторых ресурсов возможна для BCB/Delphi/VB, но это далеко не всегда имеет смысл.
Потому единственно верный метод — делать защиту с привязкой к сертификату и выполнением важной части программы на сервере.
Правда это требует реального IP и постоянного подключения к интернету.
Правда это требует реального IP и постоянного подключения к интернету.
Как-то сумбурно… Столько однотипных картинок только чтобы показать, как условный переход менять… :-) Т.е. позыв автора топика понятен: тема реверсинга действительно не освящена на Хабре. Но с другой стороны — она достаточно специфична, чтобы обсуждать ее на таком вполне мейнстримовом ресурсе. :-) Поэтому, если обсуждать ее серьезно, то я бы лучше не вдавался в детали, а подготовил бы некий обзор — перечень софта, документации (ссылки на статьи на тематических сайтах) и некие базовые этапы взлома/реверсинга программы. Если же автор хотел показать авторам программ, что к защите следует относиться серьезно, то это получилось лишь частично: советы в конце, как уже заметили в других комментариях, особого смысла не имеют и любым маломальски опытным реверсером обходятся на раз. Лучшим советом было бы действительно не экономить, а потратить денюжку на пакер/протектор, причем с обязательным шифрованием блоков программы и проверками ключей через Инет.
А все эти предложения использовать несколько функций проверок и отказаться от стандартных диалогов — толку не дают. Это же даже не прошивка микроконтроллера, а код на высокоуровневом языке — IDA его настолько хорошо знает и комментирует, что после часа тренировки его прямо с листа можно читать — это даже отчасти по приведенным скриншотам видно.
А все эти предложения использовать несколько функций проверок и отказаться от стандартных диалогов — толку не дают. Это же даже не прошивка микроконтроллера, а код на высокоуровневом языке — IDA его настолько хорошо знает и комментирует, что после часа тренировки его прямо с листа можно читать — это даже отчасти по приведенным скриншотам видно.
Перечня софта-документации и так достаточно в интернете. А показывать как менять условные переходы — не цель данного материала. Внешние протекторы не решают проблему полностью. Естественно, качественную защиту надо продумывать основательно и не останавливаться на приведенных советах. Статья называется «Основные ошибки», а не «программирование защит». Поэтому, все логично :)
Значит у нас с вами просто разные взгляды на эти вопросы. :-) Я считаю, что основная ошибка разработчика (программа которого продается и которую в принципе стоит защищать) — безосновательные надежды, что он сможет сам хоть как-то адекватно сделать самому себе защиту. :-)
Речь идет о прикладном разработчике, конечно. Касперский или сам Ильфаком Гильфановым защиту сами себе написать смогут. Но ведь ирония в том, что и их защиты ломают… :-)
Речь идет о прикладном разработчике, конечно. Касперский или сам Ильфаком Гильфановым защиту сами себе написать смогут. Но ведь ирония в том, что и их защиты ломают… :-)
Ломают все — так уж повелось )) Как говорится, замки создаются для честных людей :) Сможет ли рядовой программист написать защиту, которую не сломают? Навряд-ли… Сможет ли рядовой программист написать защиту, которую не сможет взломать школьник? Хм, возможно! Именно это я и хотело донести до читателей.
И Касперски и автор IDA особо не заморачиваются, на само деле. У них есть куча ниточек и сладких пирожков для лицензионных владельцев.
Кто сказал, что Ильфака не задолбал кардинг и он не вшил деструктивный механизм как это в свое время сделал автор Hiew? Никогда не запущу свежий, скарденный каким-нить YAG'ом, билд IDA без песочницы, ибо я не уверен, а проверять тонну кода на наличие чего-либо неприятного не хочется.
Кто сказал, что Ильфака не задолбал кардинг и он не вшил деструктивный механизм как это в свое время сделал автор Hiew? Никогда не запущу свежий, скарденный каким-нить YAG'ом, билд IDA без песочницы, ибо я не уверен, а проверять тонну кода на наличие чего-либо неприятного не хочется.
Мммм… Про Касперского не скажу, а вот насчет IDA не согласен. Не в курсе, как сейчас, а раньше пиратские версии вообще только с тыреными ключами появлялись… Но насчет песочницы — это верно. Ильфак тот еще затейник! :-)
О чем и речь, тыренные ключи, тыренные сборки. IDA не ломают, его КРАДУТ :) Ильфаку не нужно тратиться на защиту по сути, у него достаточно грамотно проработана схема продажи и дистрибуции. Никакого триала и т.д.
А у Евгения тоже самое, по сути. У него вообще есть возможность одним хлопком поднять себе планку продаж в разы (либо провалиться) — сделать проблемы с обновлением у пиратских версий. Есть лишь небольшой сегмент пользователей, которые согласны напрячься из-за обновлений + ореол в виде знакомых и ознакомленных через Интернет.
В итоге круг пиратских пользователей у проектов, где саппорт важен и есть завязка на Интернете можно уменьшать. Спокойно.
А у Евгения тоже самое, по сути. У него вообще есть возможность одним хлопком поднять себе планку продаж в разы (либо провалиться) — сделать проблемы с обновлением у пиратских версий. Есть лишь небольшой сегмент пользователей, которые согласны напрячься из-за обновлений + ореол в виде знакомых и ознакомленных через Интернет.
В итоге круг пиратских пользователей у проектов, где саппорт важен и есть завязка на Интернете можно уменьшать. Спокойно.
А можете поподробнее написать о том, что произошло с HIEW?
Цикл статей «Введение в крэкинг с нуля, используя OllyDbg»
Для тех кому понравилось. Там всё рассказано с самых основ, и очень грамотно.
Для тех кому понравилось. Там всё рассказано с самых основ, и очень грамотно.
хм. очень интересно
Современная технология шагнула далеко вперед. А еще лет десять назад, имхо, пиком считалось шифрование адресов в таблице виртуальных методов. А лет двадцать назад, порой было достаточно вставить одну русскую букву в расширении .com или .exe :)
после того как нашу прогу поломали похожим образом предпринял следующие действия:
— все строки в программе хранились в зашифрованном виде, и расшифровывались на лету ( то есть зная какое сообщение выводит программа в коде найти его было нельзя не взломав наш ключ и алгоритм шифрации)
— функция isActivated() (именно ее изменили взломщики заставив всегда возвращать true ) была изменена следующим образом: ее код как-бы что-то вычислял, но всегда возвращал false. Если фукнция возвращала true — мы знали что программу взломали. В этом случае запускались механизмы мягкого нанесения вреда ( крэш программы рэндомно в разных местах со странными ошибками)
— в ключевых местах программ — проверка CRC разных участков ее бинарного кода. Ключи вшивались в бинарник после компиляции программы.
а можно было бы сделать гораздо больше, сами взломщики рекомендуют использовать таймауты чтобы проверять не отлаживается ли программа, кастомные формы ввода ключей, отложенную проверка валидности ключей, запутывающие метаматические преобразования… словом фантазии есть где разгуляться =)
— все строки в программе хранились в зашифрованном виде, и расшифровывались на лету ( то есть зная какое сообщение выводит программа в коде найти его было нельзя не взломав наш ключ и алгоритм шифрации)
— функция isActivated() (именно ее изменили взломщики заставив всегда возвращать true ) была изменена следующим образом: ее код как-бы что-то вычислял, но всегда возвращал false. Если фукнция возвращала true — мы знали что программу взломали. В этом случае запускались механизмы мягкого нанесения вреда ( крэш программы рэндомно в разных местах со странными ошибками)
— в ключевых местах программ — проверка CRC разных участков ее бинарного кода. Ключи вшивались в бинарник после компиляции программы.
а можно было бы сделать гораздо больше, сами взломщики рекомендуют использовать таймауты чтобы проверять не отлаживается ли программа, кастомные формы ввода ключей, отложенную проверка валидности ключей, запутывающие метаматические преобразования… словом фантазии есть где разгуляться =)
>> все строки в программе хранились в зашифрованном виде, и расшифровывались на лету ( то есть зная какое сообщение выводит программа в коде найти его было нельзя не взломав наш ключ и алгоритм шифрации)
Заблуждение. Часто сами строки ничего не решают. Это затрудняет изучение, но очень слабо. Некоторые их даже не ищут.
>> Если фукнция возвращала true — мы знали что программу взломали.
Саботаж — он конечно интересен, но по ошибкам легко догадаться откуда ноги растут и пропатчить :)
>> в ключевых местах программ — проверка CRC
Которую также можно сфальсифицировать при желании…
>> Ключи вшивались в бинарник после компиляции программы.
Можно изменить ход программы таким образом, чтобы она любые ключи принимала за правильные.
>> сами взломщики рекомендуют использовать таймауты чтобы проверять не отлаживается ли программа
Подходит только для некоторых отладчиков. Самые сложные останавливают на время отладки всю систему. Так что, поймать таймерами их невозможно.
Заблуждение. Часто сами строки ничего не решают. Это затрудняет изучение, но очень слабо. Некоторые их даже не ищут.
>> Если фукнция возвращала true — мы знали что программу взломали.
Саботаж — он конечно интересен, но по ошибкам легко догадаться откуда ноги растут и пропатчить :)
>> в ключевых местах программ — проверка CRC
Которую также можно сфальсифицировать при желании…
>> Ключи вшивались в бинарник после компиляции программы.
Можно изменить ход программы таким образом, чтобы она любые ключи принимала за правильные.
>> сами взломщики рекомендуют использовать таймауты чтобы проверять не отлаживается ли программа
Подходит только для некоторых отладчиков. Самые сложные останавливают на время отладки всю систему. Так что, поймать таймерами их невозможно.
Зачем фальсифицировать CRC, когда все подобные проверки просто патчатся обычно? Зачем заморачиваться? Конечно все зависит от ситуации, но все же. Дело — лишь выявить все места контроля.
>> >> Если фукнция возвращала true — мы знали что программу взломали.
>> Саботаж — он конечно интересен, но по ошибкам легко догадаться откуда ноги растут и пропатчить :)
а мы не выводили ошибок )) Просто запоминали что прогу взломали — это аукалось уже после, в самой работе якобы поломанной программы
>>> в ключевых местах программ — проверка CRC
>Которую также можно сфальсифицировать при желании…
хм, там был не один ключ а штук шесть где-то, причем проверяли они также друг друга = то есть взломать только один было бы бесполезно. Учитывая что проверка сама по себе не выдавала никаких окошек ( мол взломано ) а действовала чуть погодя ( опять же через рэндомные промежутки времени, да и просто крэшила прогу )
>> Саботаж — он конечно интересен, но по ошибкам легко догадаться откуда ноги растут и пропатчить :)
а мы не выводили ошибок )) Просто запоминали что прогу взломали — это аукалось уже после, в самой работе якобы поломанной программы
>>> в ключевых местах программ — проверка CRC
>Которую также можно сфальсифицировать при желании…
хм, там был не один ключ а штук шесть где-то, причем проверяли они также друг друга = то есть взломать только один было бы бесполезно. Учитывая что проверка сама по себе не выдавала никаких окошек ( мол взломано ) а действовала чуть погодя ( опять же через рэндомные промежутки времени, да и просто крэшила прогу )
1. Спасет от нубов.
2. Вы потеряете много денег, если когда-нибудь этот флаг будет измене допустим вцепившимся в ваше ПО вирем или шальной пулей. Встраивание деструктивных механизмов — гигантская ответственность.
3. Спасет от нубов.
Что в итоге? Вы не защищены + готовитесь к судебным искам за причиненный ущерб по вине вашего ПО.
Таймауты и прочие трики по детекту отладчиков и т.д. давно уже обходятся каким-нить Phantom'ом для Ольги.
2. Вы потеряете много денег, если когда-нибудь этот флаг будет измене допустим вцепившимся в ваше ПО вирем или шальной пулей. Встраивание деструктивных механизмов — гигантская ответственность.
3. Спасет от нубов.
Что в итоге? Вы не защищены + готовитесь к судебным искам за причиненный ущерб по вине вашего ПО.
Таймауты и прочие трики по детекту отладчиков и т.д. давно уже обходятся каким-нить Phantom'ом для Ольги.
возможно. на практике жалоб не было, хотя клиентов было мало, а до большого количества фирма не дожила.
Судебные иски — не верится — ведь крэшилась бы она у нелегальных пользоватлей
Судебные иски — не верится — ведь крэшилась бы она у нелегальных пользоватлей
Я как раз и говорю о возможных крэшах у легальных пользователей. Допустим в силу повреждения исполняемого файла. Именно в этом проблема.
Тут, говорят после заражения вирусом (даже если она была вылечена антивирусом) контрольные суммы и у легальных пользователей могут не совпадать. Поэтому, эта медаль о двух сторонах…
ну пусть переустановят приложение, скачают снова с сайте в конце-концов
Серьезные программы не дистрибутируются «As Is» потому как программа без ответственности о результатах своей работы многим коммерческим компаниям не подходит. Так вот, если она что-то запортит или рассчитает неправильно, это может стоить компании серьезных убытков. С автора вируса они очевидно не смогут из взыскать, а вот с авторов программы — запросто. Особенно если учитывать то, что повреждение нанесла программа, а не вирус. Вот в чем делема.
полагаю что в лицензионном соглашении должен быть оговорен момент по которому разработчик не отвечает за то что случится с программой буде ее бинарный код поврежден. Иначе и на МС подавали бы в суд за то что вирусы внедряются в ее системные файлы и ОС некорректно работает.
Некорректно работает из-за вирусов, а не из-за того, что сама программа начинает портить данные. Насчет всего остального, в крупных компаниях юристы основательно изучают лицензионные соглашения, а суммы договоров могут быть значительными и альтернативы тоже. Поэтому, программы отвечают за то, что делают сами.
Ну так и как — был от всего этого толк или все равно ломают? :-)
Хотите, устроим конкурс на Хабре и вам пиар заодно — будем публично вашу программу ломать с комментариями и написанием статей? Сам не обещаю — времени маловато, — но уверен, что желающие появятся. :-)
Хотите, устроим конкурс на Хабре и вам пиар заодно — будем публично вашу программу ломать с комментариями и написанием статей? Сам не обещаю — времени маловато, — но уверен, что желающие появятся. :-)
Топик пришел к нам из 90-х, лишь инструментарий стал «помоднее». Советы, к сожалению, пришли из той же эпохи.
2 — Что за бред? Принебречь guide'ами или потратить кучу времени на создание своего диалога (в итоге забыть про обработку Ctrl+C, допустим)? Плохой совет.
3 — Мало чем помогает.
4 — Самый разумный пункт, но его сложно достигнуть.
2 — Что за бред? Принебречь guide'ами или потратить кучу времени на создание своего диалога (в итоге забыть про обработку Ctrl+C, допустим)? Плохой совет.
3 — Мало чем помогает.
4 — Самый разумный пункт, но его сложно достигнуть.
Хочу еще раз подчеркнуть, что советы не претендуют на полноту и достаточность. Они лишь описывают конкретные ошибки в данной изучаемой программе. Диалоговые окна — не бред: поставив на функцию прерывание INT3, можно легко отследить их работу в отладчике. Найти собственное написанное окно сообщений также возможно, но на это потребуется два «клика» вместо одного.
Почему не бред?! Следование гайдлайнам ОС — разумное требование, а также одно из требований для сертификации под ОС. При условии, что речь идет о shareware продуктах — для них сертификация не пустой звук, а соответственно и соблюдение гайдов. Не пустой звук это и для пользователей той или иной ОС.
Есть диалоговые окна, которые ведут себя определенным образом. Допустим, тот же MessageDialog — вызывает окно, которое понимает Ctrl+C. Забыли сделать в своем — вы неудачник.
Речь идет о том, что это все повышение затрат, увеличение вероятности попасть в неприятность и т.д. Этот пункт спокойно можно убирать.
Еще один момент. Кто мешает раз отследить адрес метода Execute (допустим) и потом его везде пометить? Какая разница в итоге чей диалог то? Охота за диалогами то идет лишь по той причине, что по ним легко ориентироваться. Никто не мешает найти другой низкоуровневый ориентир, либо замену.
Есть диалоговые окна, которые ведут себя определенным образом. Допустим, тот же MessageDialog — вызывает окно, которое понимает Ctrl+C. Забыли сделать в своем — вы неудачник.
Речь идет о том, что это все повышение затрат, увеличение вероятности попасть в неприятность и т.д. Этот пункт спокойно можно убирать.
Еще один момент. Кто мешает раз отследить адрес метода Execute (допустим) и потом его везде пометить? Какая разница в итоге чей диалог то? Охота за диалогами то идет лишь по той причине, что по ним легко ориентироваться. Никто не мешает найти другой низкоуровневый ориентир, либо замену.
Конечно не мешает. Так и происходит на самом деле. Ведь если программу кто-то захотел взломать кто разбирается в процессе — то все равно взломает. А вот, допустим, школьник, прочитавший в интернете и действующий по инструкции — может на этом споткнуться. Я уже писал тут, что для программирования терпимой программной защиты перед навесной нужно не 4 совета, а в 40 бы уложиться…
«поставив на функцию прерывание INT3, можно легко отследить их работу в отладчике»
ну, поставьте на DestroyWindow — ваше же окно уничтожается после того, как покажется?) Ну, не уничтожается? — поставьте на ShowWindow…
Бред в общем вы пишите. Не в теме вы.
ну, поставьте на DestroyWindow — ваше же окно уничтожается после того, как покажется?) Ну, не уничтожается? — поставьте на ShowWindow…
Бред в общем вы пишите. Не в теме вы.
Отследить можно что угодно. И появление и уничтожение. Весь вопрос насколько просто. Если при использовании стандартных функций, которые хорошо описаны в других примерах вскрыть программу сможет первый встречный, но использование нестандартных функций может кое кого остановить. Насчет того что писать, а чего не писать — решать мне, в общем, спорить не собираюсь.
1 пункт: при написании кейгена это не поможет. Использование подобных процедур легко нейтрализуется поиском по сигнатуре.
2,3: на удивление, в грамотных защитах отлов сообщения об успешной регистрации не сильно помогает делу.
4: была история, когда авторы привязали контрольную сумму ехе файла к результатам и какая-то бухгалтерия от вируса чуть не повесилась. Высока вероятность ошибки в подобных алгоритмах, если софт серьезный и кто-то потеряет деньги из-за ваших защит, то вас затаскают по судам.
ЗЫ рассмотренные примеры в статье тривиальны до нельзя, такое ощущение, что автор только познакомился с исследованием защит.
[tPORt] tport.org
2,3: на удивление, в грамотных защитах отлов сообщения об успешной регистрации не сильно помогает делу.
4: была история, когда авторы привязали контрольную сумму ехе файла к результатам и какая-то бухгалтерия от вируса чуть не повесилась. Высока вероятность ошибки в подобных алгоритмах, если софт серьезный и кто-то потеряет деньги из-за ваших защит, то вас затаскают по судам.
ЗЫ рассмотренные примеры в статье тривиальны до нельзя, такое ощущение, что автор только познакомился с исследованием защит.
[tPORt] tport.org
оО. Низкий поклон )
Раньше времени отправилось. На самом деле п.4 может повлиять ровно так же как и деструктив зашитый в ПО. Целиком согласен.
>деструктив зашитый в ПО
при обнаружении подобных вещей в софте, пусть даже для защиты, обычно его шлют аверам и они добавляют его в базы, после чего речи о распространении программы даже не идёт. Был такой пример, рассматривался товарищем Ara (с cracklab.ru) в 8 выпуске СпецХакера 2005 года, он исследовал защиту SourceFormatX, она при попытке патча её портила данные на ЖД. В последствии про эту программу ни разу ничего не слышал.
при обнаружении подобных вещей в софте, пусть даже для защиты, обычно его шлют аверам и они добавляют его в базы, после чего речи о распространении программы даже не идёт. Был такой пример, рассматривался товарищем Ara (с cracklab.ru) в 8 выпуске СпецХакера 2005 года, он исследовал защиту SourceFormatX, она при попытке патча её портила данные на ЖД. В последствии про эту программу ни разу ничего не слышал.
Вообще, по мне так — я против всякого деструктива. Программа должна стоить реально исходя из возможностей потенциальных покупателей плюс основной должна быть служба поддержки и налаженная целевая аудитория сбыта. Т.е. решать вопрос легальности копий не только программными, но и маркетинговыми методами.
Деструктив может быть на высоком уровне, допустим внесение ошибок при экспорте в сторонние форматы и т.д. Тут тонкая грань на самом деле.
1. Если функции немного менять в плане математики, то можно и не отследить.
2, 3 — согласен.
з.ы. Познакомился лет 15 назад :) Пример, согласен — очень простой. На это и рассчитывал.
2, 3 — согласен.
з.ы. Познакомился лет 15 назад :) Пример, согласен — очень простой. На это и рассчитывал.
Любая защита от анализа и создания кряков и кейгенов это хорошо, но не эффективно от опытных взломщиков. Эти методы помогут от не профессиональных взломщиков.
Если программное обеспечение рассчитано на массовый рынок, то лучше на него прикрутить платный протектор и не париться.
Если же ваше программное обеспечение рассчитано на узкий сегмент рынка и подразумевает обновление, по лучше привязывать программное обеспечение к пользователю (разные ключи к протектору + продвинутая регистрация копии) и в случае появления конкретных копий в открытом доступе блокировать обновление и заносить покупателя в чёрный список (необходимо соответствующее лицензионное соглашение).
А вообще, если ваше ПО действительно полезное и качественное никакие защиты не спасут, пару месяцев и оно взломанное появится в сети. Покупателей надо заманивать хорошей технической поддержкой и дополнительными услугами!
Если программное обеспечение рассчитано на массовый рынок, то лучше на него прикрутить платный протектор и не париться.
Если же ваше программное обеспечение рассчитано на узкий сегмент рынка и подразумевает обновление, по лучше привязывать программное обеспечение к пользователю (разные ключи к протектору + продвинутая регистрация копии) и в случае появления конкретных копий в открытом доступе блокировать обновление и заносить покупателя в чёрный список (необходимо соответствующее лицензионное соглашение).
А вообще, если ваше ПО действительно полезное и качественное никакие защиты не спасут, пару месяцев и оно взломанное появится в сети. Покупателей надо заманивать хорошей технической поддержкой и дополнительными услугами!
По сути имеем два варианта: либо для защиты своей программы покупаем навесную защиту (ASP, Execryptor, адмадило и др.) либо пишем сами. Во втором случае, возможны ложные срабатывания антивирусов на вашу программу, чем кстати грешат и альфа версии навесных защит (были прецеденты с Execryptor). Я бы советовал комбинировать оба пути. В частности накладывать защиту протектором, он обеспечит генарацию и хранение ключей, и плюс доп. проверки написанные ручками. Плюс такого подхода в том, что вам не нужно глубоко разбираться в криптографии (защищенные от реверса ключи сгенерирует сам проектор), а вот «размазанные» по коду проверки с разной степенью изощренности это уже прерогатива самого программиста. А если программа по свой сути работает с инетом, то можно добавить еще массу неожиданностей для крякера.
Sign up to leave a comment.
Защита программного обеспечения: Основные ошибки при программировании блока регистрации программы (или один бит может изменить мир)