Если я не ошибаюсь, для взлома софта очень часто эти программы запускают из под отладчика. Не имея никакого практического опыта с этим делом и желая построить как можно более надежную защиту для своих продуктов, хотелось бы узнать следующее. Программа А запущена в отладчике, в свою очередь она запускает процесс В. Будет ли этот процесс В также запущен в отладчике, или же он не будет находиться по контролем отладчика в данной ситуации?

Заранее спасибо
(Сорри, если не совсем по теме этой ветки форума)

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

А>Если я не ошибаюсь, для взлома софта очень часто эти программы запускают из под отладчика. Не имея никакого практического опыта с этим делом и желая построить как можно более надежную защиту для своих продуктов, хотелось бы узнать следующее. Программа А запущена в отладчике, в свою очередь она запускает процесс В. Будет ли этот процесс В также запущен в отладчике, или же он не будет находиться по контролем отладчика в данной ситуации?

А>Заранее спасибо
А>(Сорри, если не совсем по теме этой ветки форума)

1) Обычно отладчики "используемые для взлома" "контроллируют" все процессы системы и могут влезть в любое адресное пространство — например SoftIce
2) И в любом случае, если пользователь имеет привелегию на отладку, он может отлаживать любой процесс, к которому имеет доступ. Этого можно избежать подправив список доступа, но это не спасает от п.1

Стратегий защиты может быть две:
1) Усложнение дизассемблирования и патча кода ( это всякие сжимальщики, путальщики, шифровальщики — вариантов много )
2) Обнаружение присутствия отладчиков типа SoftIce и борьба с ними. Это несколько задержит взломщиков.

Общие советы:
Защититься от взлома невозможно. Если цель — защититься от нелегального распротстранения, это мало реально . Если целью стоит защита алгоритма — смотрите в сторону средств, затрудняющих реверс кода. Расковырять весь алгоритм гораздо сложнее, чем взломать "проверялку ключа" и трудоемкость этого процесса отпугнет потенциальных злодеев .

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


TC>1) Обычно отладчики "используемые для взлома" "контроллируют" все процессы системы и могут влезть в любое адресное пространство — например SoftIce
TC>2) И в любом случае, если пользователь имеет привелегию на отладку, он может отлаживать любой процесс, к которому имеет доступ. Этого можно избежать подправив список доступа, но это не спасает от п.1

TC>Стратегий защиты может быть две:
TC>1) Усложнение дизассемблирования и патча кода ( это всякие сжимальщики, путальщики, шифровальщики — вариантов много )
TC>2) Обнаружение присутствия отладчиков типа SoftIce и борьба с ними. Это несколько задержит взломщиков.

TC>Общие советы:
TC>Защититься от взлома невозможно. Если цель — защититься от нелегального распротстранения, это мало реально . Если целью стоит защита алгоритма — смотрите в сторону средств, затрудняющих реверс кода. Расковырять весь алгоритм гораздо сложнее, чем взломать "проверялку ключа" и трудоемкость этого процесса отпугнет потенциальных злодеев .

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

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

если нет опыта ассемблера и мало С, то нет никакого смысла самим писать такое!

Ничего это не даст — просто запатчат места проверки в основной программе. Копи деньги на Asprotect\HardKey\Armadillo. Грубо говоря — если хочешь нормальной защиты — забудь о простой проверке ключа. Только шифрование части рабочего кода ключом, передаваемым пользователю как часть рег. информации.

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

G>Ничего это не даст — просто запатчат места проверки в основной программе.

Да тут даже искать проверки не нужно. Просто засунуть в ресурсы "правильный" Checker .

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

TC>Стратегий защиты может быть две:
TC>1) Усложнение дизассемблирования и патча кода ( это всякие сжимальщики, путальщики, шифровальщики — вариантов много )
TC>2) Обнаружение присутствия отладчиков типа SoftIce и борьба с ними. Это несколько задержит взломщиков.

Последний способ имеет бооольшие подводные камни: ложное срабатывание защиты.
Или такой сценарий: специалист запускает программу (которую он собирается купить!) на рабочей машине и видит, что она работать не хочет. И не будет, даже если он заплатит деньги автору! Получается challenge, который интересно решить. Да ещё и кряк потом опубликовать можно со злости на кривую схему заshitы.
В общем, про легальных пользователей тоже не нужно забывать.

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

TC>2) Обнаружение присутствия отладчиков типа SoftIce и борьба с ними. Это несколько задержит взломщиков.

Если бандиты ломают вашу дверь — начните ломать ее изнутри. Это озадачит злоумышленников.

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


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

P.S IMHO лучшая защита — вменяемая лицензия и ценовая политика.

P.P.S Это ссобщение также является тестом.

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

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

Интересно, а можно ли в отладчике следить за разделяемой памятью, ведь Checker можно стартануть в любое время, а потом он должен периодически проверять разделяемую память, пока там не окажется ожидаемая информация. Ведь крекеру еще до этого дойти надо, что валидацией другого ключа занимается другой процесс

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

А>Интересно, а можно ли в отладчике следить за разделяемой памятью, ведь Checker можно стартануть в любое время, а потом он должен периодически проверять разделяемую память, пока там не окажется ожидаемая информация. Ведь крекеру еще до этого дойти надо, что валидацией другого ключа занимается другой процесс

за крекеров не волнуйтесь. Съём такой доморощенной защиты занимает на порядок меншье времени, чем её написание и отладка.

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

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

А>>Интересно, а можно ли в отладчике следить за разделяемой памятью, ведь Checker можно стартануть в любое время, а потом он должен периодически проверять разделяемую память, пока там не окажется ожидаемая информация. Ведь крекеру еще до этого дойти надо, что валидацией другого ключа занимается другой процесс

А>за крекеров не волнуйтесь. Съём такой доморощенной защиты занимает на порядок меншье времени, чем её написание и отладка.

Как я понимаю, после того как серийник будет записан в переменную (возьмем для примера этот элементарный случай), крекер будет отлавливать все места обращения к этой переменной, именно в этих местах и есть слабое звено в защите. Если это и в самом деле так, как я себе представляю, то хотелось бы услышать мнение по следующему вопросу:
Предположим, в коде программы я объявляю две переменные именно в следующем порядке

long SmartVar;
long MySerialNumber;

После записи во вторую переменную серийника, я не буду напрямую к ней обращаться, возьму адрес переменной SmartVar и вычислю на его основе адрес переменной MySerialNumber, тогда для крекера будет обращение к серийнику не так очевидно. Или же из-за своей неопытности я заблуждаюсь?

>

>long SmartVar;
>long MySerialNumber;

>

>После записи во вторую переменную серийника, я не буду напрямую к ней обращаться, возьму адрес переменной SmartVar и вычислю на его основе адрес переменной MySerialNumber, тогда для крекера будет обращение к серийнику не так очевидно. Или же из-за своей неопытности я заблуждаюсь?

как можно вычислить &SmartVar по &MySerialNumber ? разве есть гарантия ( от оптимизатора ), что они располагаются именно в указанном порядке и без дырок на выравнивание?

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

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

А>Как я понимаю, после того как серийник будет записан в переменную (возьмем для примера этот элементарный случай), крекер будет отлавливать все места обращения к этой переменной

Зачем? Для начала он поставит break point на чтение памяти серийника.

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

TC>Стратегий защиты может быть две:
TC>1) Усложнение дизассемблирования и патча кода
TC>2) Обнаружение присутствия отладчиков типа SoftIce и борьба с ними. Это несколько задержит взломщиков.

№2 — Это геморрой на задницу в первую очередь легального пользователя, и только во вторую или третью — взломщика. Вспомни FineReader, который отказывался работать у пользователей, проапгредившихся до XP. Сильно это задержало пиратов? Короче,