В интернете полно советов по поводу защиты софта, но информация из разных источников не редко противоричит друг другу, и складывается порой впечатление, что автор пишет не из личного опыта, а просто цитирует разные источники. Мне, как начинающему, да, думаю, и не только мне, было бы очень интересно и полезно услышать мнение людей, которые съели пуд соли на этом поле боя и не станут цитировать чужие наброски. Вот только хотелось бы услышать мысли о собственной защите, а не инструкцию для того же "AsProtect" Думаю, тема и не нова, но всегда будет оставаться актуальной

Здравствуйте, Аноним, Вы писали:


А>В интернете полно советов по поводу защиты софта, но информация из разных источников не редко противоричит друг другу, и складывается порой впечатление, что автор пишет не из личного опыта, а просто цитирует разные источники. Мне, как начинающему, да, думаю, и не только мне, было бы очень интересно и полезно услышать мнение людей, которые съели пуд соли на этом поле боя и не станут цитировать чужие наброски. Вот только хотелось бы услышать мысли о собственной защите, а не инструкцию для того же "AsProtect" Думаю, тема и не нова, но всегда будет оставаться актуальной

Никакими asProtect-ами и EXEкрипторами не пользуюсь, по причинам:
1. ключ может быть украден через чарджбек.
2. большой соблазн кракера отломить навесную защиту — ламая одну защиту он взламывает практически все программы одним махом;

Поэтому смысла покупать эти программы не вижу, так как все это можна сделать без напряга самому:
1. Использовать алгоритм типа RSA, что бы нельзя было сделать keygen;
2. Распылять проверки ключа по всему проекту с тем чтобы сигнатуры отличались;
3. Проверять ключ не по if(key==register_key), а генерировать exception;
4. Защита от запуска под дебагером;
5. Распылять проверки CRC по всему проекту с тем чтобы сигнатуры отличались;
6. Криптовать код с некоторыми проверками;
7. Можна еще привязыватся к hardware и делать активацию в инете — если религия позволяет

Здравствуйте, Аноним, Вы писали:

А> было бы очень интересно и полезно услышать мнение людей,

главное не переусердствовать. Слишком сильная защита потребует много времени и сил. Лучше потратить их на что-нибудь другое.

Я в свое время получил очень хороший урок: три недели я сидел и внедрял асимметричные алгоритмы криптования, хеширования, паковки, серверной активации... Через два дня из Бразилии пришла мошенническая покупка, из-за которой меня отштрафовали на 240 долларов.

Лучше бы я три недели на что-нибудь полезное потратил

Здравствуйте, jit, Вы писали:

jit>Через два дня из Бразилии пришла мошенническая покупка, из-за которой меня отштрафовали на 240 долларов.

Это у какого же регистратора такие штрафы? Обычно chargeback penalty (aka chargeback investigation fee) не превышает 15-20 долларов, если вообще не бесплатен.

Здравствуйте, Аноним, Вы писали:

А>2. большой соблазн кракера отломить навесную защиту — ламая одну защиту он взламывает практически все программы одним махом;

А нефиг использовать навесную защиту. Надо защиту внедрять в код.

Здравствуйте, lozzy, Вы писали:

L>Здравствуйте, Аноним, Вы писали:

А>>2. большой соблазн кракера отломить навесную защиту — ламая одну защиту он взламывает практически все программы одним махом;

L>А нефиг использовать навесную защиту. Надо защиту внедрять в код.

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

Здравствуйте, lozzy, Вы писали:

jit>>Через два дня из Бразилии пришла мошенническая покупка, из-за которой меня отштрафовали на 240 долларов.

L>Это у какого же регистратора такие штрафы? Обычно chargeback penalty (aka chargeback investigation fee) не превышает 15-20 долларов, если вообще не бесплатен.

2CO. Штраф у них действительно 10 или 20 долларов. Но, как мне тогда объяснили — это "per item", а "не per order". А эта бразильская #ука накардила на пару килобаксов

Здравствуйте, jit, Вы писали:

jit>2CO. Штраф у них действительно 10 или 20 долларов. Но, как мне тогда объяснили — это "per item", а "не per order". А эта бразильская #ука накардила на пару килобаксов

Кстати, просветите дурака, почему кто-то там что-то ворует, потом забирают деньги обратно, а с того, кто делал прогу штраф берут?

Здравствуйте, Аноним, Вы писали:

jit>>2CO. Штраф у них действительно 10 или 20 долларов. Но, как мне тогда объяснили — это "per item", а "не per order". А эта бразильская #ука накардила на пару килобаксов

А>Кстати, просветите дурака, почему кто-то там что-то ворует, потом забирают деньги обратно, а с того, кто делал прогу штраф берут?

Спросите у Визы.

В принципе, правильно. Потому что штраф берут за черджбек. А чарджбек — это не всегда следствие мошенничества. Это в большинстве случаев возврат денег за некачественный/недобросовестный товар. Вот купили вы Страгацких на амазоне, вам привезли му-му Тургенева. Инициируйте чарджбек и амазон будет отштрафован. ИМХО.

Здравствуйте, Аноним, Вы писали:

jit>>2CO. Штраф у них действительно 10 или 20 долларов. Но, как мне тогда объяснили — это "per item", а "не per order". А эта бразильская #ука накардила на пару килобаксов

А>Кстати, просветите дурака, почему кто-то там что-то ворует, потом забирают деньги обратно, а с того, кто делал прогу штраф берут?

Потому что основной клиент Визы и Мастеркарт — покупатель.

Здравствуйте, Слава Шевцов, Вы писали:

А>>Кстати, просветите дурака, почему кто-то там что-то ворует, потом забирают деньги обратно, а с того, кто делал прогу штраф берут?

СШ>Потому что основной клиент Визы и Мастеркарт — покупатель.

А стригут купоны — банки. На кого же еще ответственность переложить, если не на вендора?

Здравствуйте, Аноним, Вы писали:

L>>А нефиг использовать навесную защиту. Надо защиту внедрять в код.
А>Да я к тому что программа должна иметь уникальную защиту от других программ, что бы к взлому был индивидуальный подход, а не по сценарию как в случае с ASPпротектом;

Вы, наверное, понимаете смысл слов "навесная защита"? И чем "навесная" отличается от "embedded" касательно ASPR или EXECryptor?

Здравствуйте, Аноним, Вы писали:


А>В интернете полно советов по поводу защиты софта, но информация из разных источников не редко противоричит друг другу, и складывается порой впечатление, что автор пишет не из личного опыта, а просто цитирует разные источники. Мне, как начинающему, да, думаю, и не только мне, было бы очень интересно и полезно услышать мнение людей, которые съели пуд соли на этом поле боя и не станут цитировать чужие наброски. Вот только хотелось бы услышать мысли о собственной защите, а не инструкцию для того же "AsProtect" Думаю, тема и не нова, но всегда будет оставаться актуальной

1. 99% того что ты сможешь найти в инете по вопросам защиты — старье которое ни в коей мере не остановит взломщика.
2. чтобы написать качественную защиту надо уметь смотреть на мир глазами реверсера
3. в большинстве случаев ресурсы затраченные на написание самопальной защиты неадекватны получаемой стойкости
4. начинающему вообще не рекомендую особо заморачиваться с защитой. тем более самопальной. вполне можно ограничиться криптостойкими серийниками для начала (чтобы кейген не выпустили) и защите кода уделить внимание после того как пойдут покупки.
5. защита не есть весчь постоянная. ее постоянно прийдется совершенствовать. и в этом процессе лучше быть на шаг впереди взломщика. а это дополнительные ресурсы

вобщем ответ вполне очевиден — сапоги должен тачать сапожник.

Здравствуйте, lozzy, Вы писали:

L>Здравствуйте, Аноним, Вы писали:

L>>>А нефиг использовать навесную защиту. Надо защиту внедрять в код.
А>>Да я к тому что программа должна иметь уникальную защиту от других программ, что бы к взлому был индивидуальный подход, а не по сценарию как в случае с ASPпротектом;

L>Вы, наверное, понимаете смысл слов "навесная защита"? И чем "навесная" отличается от "embedded" касательно ASPR или EXECryptor?

Речь не об этом.

Здравствуйте, Аноним, Вы писали:

А>Никакими asProtect-ами и EXEкрипторами не пользуюсь, по причинам:
А>1. ключ может быть украден через чарджбек.

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

А>2. большой соблазн кракера отломить навесную защиту — ламая одну защиту он взламывает практически все программы одним махом;

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

А>Поэтому смысла покупать эти программы не вижу, так как все это можна сделать без напряга самому:

ха-ха-ха

А>1. Использовать алгоритм типа RSA, что бы нельзя было сделать keygen;

этому в первом классе учат

А>2. Распылять проверки ключа по всему проекту с тем чтобы сигнатуры отличались;

можно подумать это усложнит реверсинг

А>3. Проверять ключ не по if(key==register_key), а генерировать exception;

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

А>4. Защита от запуска под дебагером;

ню-ню. думаешь не обойдут?

А>5. Распылять проверки CRC по всему проекту с тем чтобы сигнатуры отличались;

отловят и вырежут

А>6. Криптовать код с некоторыми проверками;

если криптование простое (в т.ч. и полиморфы) — расшифруют нафиг


ЗЫ советы у тебя какието ... вредные вобщем если некуда девать время — советую им следовать

Здравствуйте, Relayer, Вы писали:

R>Здравствуйте, Аноним, Вы писали:

А>>Никакими asProtect-ами и EXEкрипторами не пользуюсь, по причинам:
А>>1. ключ может быть украден через чарджбек.

R>можно подумать что его в остальных случаях не могут украсть единственный выход — система активаций. но это не совсем для начинающего

А>>2. большой соблазн кракера отломить навесную защиту — ламая одну защиту он взламывает практически все программы одним махом;

R>да ну?! а я то и не знал об этом
R>практически все защиты в той или иной мере позволяют интегрировать защиту в программу а не навешивать ее. и тогда стойкость получается гораздо выше.

Почему же, ниже вы утверждаете что это легко отловить и вырезать

А>>Поэтому смысла покупать эти программы не вижу, так как все это можна сделать без напряга самому:

R>ха-ха-ха

А что сложного?

А>>1. Использовать алгоритм типа RSA, что бы нельзя было сделать keygen;

R>этому в первом классе учат

Рад за вас

А>>2. Распылять проверки ключа по всему проекту с тем чтобы сигнатуры отличались;

R>можно подумать это усложнит реверсинг

Но прибавит геморроя патчить 1000 разных мест

А>>3. Проверять ключ не по if(key==register_key), а генерировать exception;

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

Пока стек размотается — можна получить рак мозга

А>>4. Защита от запуска под дебагером;

R>ню-ню. думаешь не обойдут?

Это правило хорошего тона

А>>5. Распылять проверки CRC по всему проекту с тем чтобы сигнатуры отличались;

R>отловят и вырежут

Протрасить все возможные варианты практически невозможно

А>>6. Криптовать код с некоторыми проверками;

R>если криптование простое (в т.ч. и полиморфы) — расшифруют нафиг

3DES не очень то поддается рассшифровке, но можна конечно дамп снять

R>ЗЫ советы у тебя какието ... вредные вобщем если некуда девать время — советую им следовать

Кому некуда девать деньги — советую им не следовать

Здравствуйте, Relayer, Вы писали:


R>можно подумать что его в остальных случаях не могут украсть единственный выход — система активаций. но это не совсем для начинающего

R> ...

R>да ну?! а я то и не знал об этом
R>практически все защиты в той или иной мере позволяют интегрировать защиту в программу а не навешивать ее. и тогда стойкость получается гораздо выше.

R> ...

R>ха-ха-ха

R> ...

R>ЗЫ советы у тебя какието ... вредные вобщем если некуда девать время — советую им следовать


Критиковать, конечно, нужно, но было бы очень неплохо вместе с критикой вносить конструктивные предложения, так что ждем продолжения

Здравствуйте, Аноним, Вы писали:

А>Критиковать, конечно, нужно, но было бы очень неплохо вместе с критикой вносить конструктивные предложения, так что ждем продолжения

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

Здравствуйте, Аноним, Вы писали:

А>>>2. большой соблазн кракера отломить навесную защиту — ламая одну защиту он взламывает практически все программы одним махом;
R>>да ну?! а я то и не знал об этом
R>>практически все защиты в той или иной мере позволяют интегрировать защиту в программу а не навешивать ее. и тогда стойкость получается гораздо выше.
А>Почему же, ниже вы утверждаете что это легко отловить и вырезать

потому что интеграция интеграции рознь.

А>>>Поэтому смысла покупать эти программы не вижу, так как все это можна сделать без напряга самому:
R>>ха-ха-ха
А>А что сложного?

да сущие пустяки. а потом чтоб это еще и работало на всех платформах и дружило с антивирусами и прочей дрянью.

А>>>2. Распылять проверки ключа по всему проекту с тем чтобы сигнатуры отличались;
R>>можно подумать это усложнит реверсинг
А>Но прибавит геморроя патчить 1000 разных мест

бряк на доступ к региону памяти и выловят все 1000 мест

А>>>3. Проверять ключ не по if(key==register_key), а генерировать exception;
R>>любой вменяемый реверсер знает про исключения больше обычного среднестатистического программиста. их это не остановит
А>Пока стек размотается — можна получить рак мозга

во первых есть скрипты, во вторых нонешние дебагеры не настолько тупы как ты думаешь.

А>>>4. Защита от запуска под дебагером;
R>>ню-ню. думаешь не обойдут?
А>Это правило хорошего тона

которое составляет максимум 10% от защиты

А>>>6. Криптовать код с некоторыми проверками;
R>>если криптование простое (в т.ч. и полиморфы) — расшифруют нафиг
А>3DES не очень то поддается рассшифровке, но можна конечно дамп снять

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

R>>ЗЫ советы у тебя какието ... вредные вобщем если некуда девать время — советую им следовать
А>Кому некуда девать деньги — советую им не следовать

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

Здравствуйте, Аноним, Вы писали:

А>2. большой соблазн кракера отломить навесную защиту — ламая одну защиту он взламывает практически все программы одним махом;

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