Рассуждения на тему защиты программ
От: Flamer Кипр http://users.livejournal.com/_flamer_/
Дата: 08.09.03 15:25
Оценка:
По сабжу хочется разобраться. Сижу, думаю, как поправильней поступить (кроме покупки ASProtect ). Надумалось, после прочтения нескольких профильных статей, что один из методов, затрудняющий жизнь взломщику — это шифрование кода (например, для скрытия работы алгоритма проверки введенных данных). Собственно, надумал пока нечто вроде нижеследующего (несмотря на то, что привожу код, считаю данный форум наиболее подходящим):

Пример шифрования тела функции:


// функция, которая будет шифроваться
void __fastcall MyMessageBox(const char* Message)
{
_asm
 {
  JMP @@11
  DB '376A0AFFA00A433790EBB7BFDADD452A'
  @@11:
 }

   // куча рабочего кода...

   ::MessageBox(NULL,Message,NULL,MB_OK);

_asm
 {
  JMP @@22
  DB '562C28E05F14462392124CB378149193'
  @@22:
 }

}
//---------------------------------------------------------------------------

// а это проверка :))

void __fastcall TForm1::Button3Click(TObject *Sender)
{
try
 {
  DWORD dwOld;
  VirtualProtect(MyMessageBox,4096,PAGE_READWRITE,&dwOld);

  BYTE* bMess = (BYTE*) MyMessageBox;
  for(; ;)
   {
     if(memcmp(bMess,"376A0AFFA00A433790EBB7BFDADD452A",32) == 0)
      break;
      bMess++;
   }

  bMess += 32; // обходим первую метку

   for(; ;)
    {
      // расшифровываем все до начала второй метки...
      if(memcmp(bMess,"562C28E05F14462392124CB378149193",32) == 0)
        break;

       *bMess ^= 0x12;
       bMess++;
    }


   MyMessageBox("Hello!");
 }
 catch(...) {}
}
//---------------------------------------------------------------------------


Собственно, все хорошо. Достаточно в получившемся exe проксорить (ну или другой алгоритм, для эксперимента не суть) кусок кода с 0х12 и все будет работать.

Хотелось бы большего: шифровать не тело функции, но саму функцию, т.е. включая ее пролог/эпилог. Для того, хотя бы, чтобы скопировать нужный кусок в память, расшифровать->выполнить->затереть другим куском.

Вот только, естественно, если я вынесу АСМовые меточки за пределы функции, то опаньки, не срастется... Как бы это решить?
Re: Рассуждения на тему защиты программ
От: CyberDemon Россия  
Дата: 08.09.03 16:20
Оценка:
Здравствуйте, Flamer, Вы писали:

F>По сабжу хочется разобраться. Сижу, думаю, как поправильней поступить (кроме покупки ASProtect ). Надумалось, после прочтения нескольких профильных статей, что один из методов, затрудняющий жизнь взломщику — это шифрование кода (например, для скрытия работы алгоритма проверки введенных данных). Собственно, надумал пока нечто вроде нижеследующего (несмотря на то, что привожу код, считаю данный форум наиболее подходящим):


Из достоверных источников известно, что наиболее всего затрудняет жизнь взломщику обилие левых даных и кода + шифровка (это как разновидность "обилия"). По-другому (пример) — создаем класс, на его основе (виртуальные методы) создается штук 10 _практически_ идентичных классов, отличающихся практически незаметной мелочью (константа), из-за которой этот класс не будет работать корректно (желательно, не сразу). Код, который получает нужный экземпляр, шифруется каким-нить симметричным методом. Плюс, в самом коде логика должна быть настолько разбросана по всему коду, что связи между кусками должны быть минимальны. Например, вычисление определенной констаны в алгоритме сжатия jpeg Плюс, не должно быть никаких явных проверок. Один из вариантов, сильно затрудняющих реверс кода (для начинающих — точно), это заключение шифрованного кода в exception handler "скобки" То есть, явной проверки нет, если код выполняется некорректно, происходит exception на уровне системы — гемора хацкер наберет неплохое количество

Ну и в добавок... Хакеру по барабану (в простейшем случае), как работает защита — ему надо найти точку, где она _уже_ отработала. Соотвественно, 2 вывода — защита обязательно должна быть очень сильно завязана с логикой софтины и эта точка (точки) должны быть очень сложно получаемы.

вот-с...
Re: Рассуждения на тему защиты программ
От: OlegSv2 Россия  
Дата: 09.09.03 07:10
Оценка:
Здравствуйте, Flamer, Вы писали:

F>Вот только, естественно, если я вынесу АСМовые меточки за пределы функции, то опаньки, не срастется... Как бы это решить?


Вообще тема интересная, жаль что совсем нет времени с этим поэкспериментировать.
А что если вкратце не срастается ?
Вообще для дешифрации, кажется, метки искать не обязательно, адреса вычислимы.

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

PSS: Вот кстати не знаю, скажем VC6, может менять порядок функций относительно того как они определены в CPP ? Если не меняет, тогда пожалуй дело решаемо, только перенос функции по другому адресу пожалуй нетривиален.
... << RSDN@Home 1.0 beta 6a >>
Re[2]: Re: 10х.
От: Flamer Кипр http://users.livejournal.com/_flamer_/
Дата: 09.09.03 08:09
Оценка:
Здравствуйте, OlegSv2, Вы писали:

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


F>>Вот только, естественно, если я вынесу АСМовые меточки за пределы функции, то опаньки, не срастется... Как бы это решить?


OS>Вообще тема интересная, жаль что совсем нет времени с этим поэкспериментировать.

OS>А что если вкратце не срастается ?

Да умный компилер вынесет все мои асмовые меточки в сегмент данных, вот и все Я смотрел на BCB 5.0 — такая там фигня... А если в теле функции — то все ок. Единственное, что пока вижу — это применять __declspec(naked) и ручками писать пролог/эпилог).

OS>Вообще для дешифрации, кажется, метки искать не обязательно, адреса вычислимы.


Если функция будет зашифрована полностью и "снаружи" — какие такие адреса? Не будет таких. На месте функции будет кусок мусора, грубо говоря. Вот этот-то кусок мусора надо сперва расшифровать, а уж потом выполнить... Так что меточки, по моему разумению, все-таки нужны...
Re[3]: Re: 10х.
От: OlegSv2 Россия  
Дата: 09.09.03 08:57
Оценка:
Здравствуйте, Flamer, Вы писали:

F>Да умный компилер вынесет все мои асмовые меточки в сегмент данных, вот и все Я смотрел на BCB 5.0 — такая там фигня... А если в теле функции — то все ок. Единственное, что пока вижу — это применять __declspec(naked) и ручками писать пролог/эпилог).


Я подразумевал небольшие функции с асмовыми вставками(метками) до и после шифруемой функции (но я не уверен, что функции в exe будут точно в том порядке, что в CPP). Вероятно также потребуется сделать их ложные вызовы, чтоб оптимизатор их не снес. Но не пробовал.

OS>>Вообще для дешифрации, кажется, метки искать не обязательно, адреса вычислимы.


F>Если функция будет зашифрована полностью и "снаружи" — какие такие адреса? Не будет таких. На месте функции будет кусок мусора, грубо говоря. Вот этот-то кусок мусора надо сперва расшифровать, а уж потом выполнить... Так что меточки, по моему разумению, все-таки нужны...


Меточки определенно пригодятся для поиска по exe. ИМХО если если шифровать не полностью, как в твоем примере, то можно сделать самодешифрируемую функцию, внутри нее адреса меток 11 и 22 известны (или вызов функции дешифратора с этими адресами как параметры).
Если полностью зашифрована, то адрес самой функции известен. Длину участка можно считать при обработке exe (и скорректировать где-то в exe). Однако если будут некие функции "ограничители" с метками до и после шифруемой функции, то адрес фунцкции после шифруемой известен и это есть ограничитель.

Скажем:
void BeginGuard()
{
//asm
}
void Func()
{
}
void EndGuard()
{
// asm
}

void Decode()
{
// decode from Func to EndGuard
}


PS:
Также может стоит попробовать без Guarda что-то подобное ( если оптимизатор не снесет ):

void Func()
{
// body
return;
// asm lebel after last return
}
... << RSDN@Home 1.0 beta 6a >>
Re[4]: Re: 10х.
От: OlegSv2 Россия  
Дата: 09.09.03 17:31
Оценка:
Мда, сегодня чуть повозился с этим. Не все так просто, как хотелось бы
На MSVC даже твой пример может и не работать, т.к. взятие адреса для нестатической функции:
BYTE* bMess = (BYTE*) MyMessageBox;
не дает адрес кода, а адрес другого места с jmp-ом.
Порядок функций на MSVC может меняться в зависимости от static или нет функция.

Вообщем как сделать всю функцию шифруемой целиком не знаю

Удачи. Олег.
... << RSDN@Home 1.0 beta 6a >>
Re: Рассуждения на тему защиты программ
От: TK Лес кывт.рф
Дата: 10.09.03 05:38
Оценка:
Hello, "Flamer"
> По сабжу хочется разобраться. Сижу, думаю, как поправильней поступить (кроме покупки ASProtect ). Надумалось, после прочтения нескольких профильных статей, что один из методов, затрудняющий жизнь взломщику — это шифрование кода (например, для скрытия работы алгоритма проверки введенных данных). Собственно, надумал пока нечто вроде нижеследующего (несмотря на то, что привожу код, считаю данный форум наиболее подходящим):
>

Можно еще сделать две (n) одинаковые функций которые будут отличаться небольшими нюансами (+ на — поменять, == на != и т.п.) а итоговую функцию собирать на их основе — найти точки различий и используя ключ выбрать правильные. Как плюс — код готов после компиляции.
Posted via RSDN NNTP Server 1.6
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re: Рассуждения на тему защиты программ
От: peterbes Россия  
Дата: 10.09.03 06:35
Оценка:
Здравствуйте, Flamer, Вы писали:

F>По сабжу хочется разобраться. Сижу, думаю, как поправильней поступить (кроме покупки ASProtect ). Надумалось, после прочтения нескольких профильных статей, что один из методов, затрудняющий жизнь



Посмотри в http://www.rsdn.ru/Forum/Message.aspx?mid=184388&amp;only=1
Автор: peterbes
Дата: 29.01.03
, можеть быть там что полезное для себя найдешь.
Re[2]: Рассуждения на тему защиты программ
От: CyberDemon Россия  
Дата: 10.09.03 07:12
Оценка:
Здравствуйте, TK, Вы писали:

TK>Можно еще сделать две (n) одинаковые функций которые будут отличаться небольшими нюансами (+ на — поменять, == на != и т.п.) а итоговую функцию собирать на их основе — найти точки различий и используя ключ выбрать правильные. Как плюс — код готов после компиляции.


Это изложение по-русски моего ответа ?
Re[3]: Рассуждения на тему защиты программ
От: TK Лес кывт.рф
Дата: 10.09.03 07:52
Оценка:
Hello, "CyberDemon"
>
> TK>Можно еще сделать две (n) одинаковые функций которые будут отличаться небольшими нюансами (+ на — поменять, == на != и т.п.) а итоговую функцию собирать на их основе — найти точки различий и используя ключ выбрать правильные. Как плюс — код готов после компиляции.
>
> Это изложение по-русски моего ответа ?

Наверное не совсем
Например, зачем создавать кучу классов? Можно создать один с кучей "лишних" методов и в процессе проверки подправить vtable так, что-бы она указывала на восстановленные методы. Да и в данном случае нет шифрования всего метода — запутываются лишь отдельные фрагменты
Posted via RSDN NNTP Server 1.6
Если у Вас нет паранойи, то это еще не значит, что они за Вами не следят.
Re: Рассуждения на тему защиты программ
От: Слава Израиль  
Дата: 10.09.03 07:55
Оценка: 9 (1)
Здравствуйте, Flamer, Вы писали:

F>По сабжу хочется разобраться. Сижу, думаю, как поправильней поступить (кроме покупки ASProtect ). Надумалось, после прочтения нескольких профильных статей, что один из методов, затрудняющий жизнь взломщику — это шифрование кода (например, для скрытия работы алгоритма проверки введенных данных). Собственно, надумал пока нечто вроде нижеследующего (несмотря на то, что привожу код, считаю данный форум наиболее подходящим):


Значит так. Чтобы такие вопросы не возникали нужно внимательно и вдумчиво прочитать книгу Касперского "Технологии и механизмы хакерских атак" там подробно описываются методы защиты, а потом методы снятия этой защиты, а потом способы борьбы с этими методами, а потом способы нейтрализации этих способов , а потом..., .... А где-то в середине вскольз упоминается, что шифровать код — это в настоящее время отстой. Могу выслать на мыло в формате doc и с хреновым качеством
Спасибо за внимание
Re[2]: Рассуждения на тему защиты программ
От: Flamer Кипр http://users.livejournal.com/_flamer_/
Дата: 10.09.03 08:07
Оценка:
Здравствуйте, Слава, Вы писали:

[]

С>Значит так. Чтобы такие вопросы не возникали нужно внимательно и вдумчиво прочитать книгу Касперского "Технологии и механизмы хакерских атак" там подробно описываются методы защиты, а потом методы снятия этой защиты, а потом способы борьбы с этими методами, а потом способы нейтрализации этих способов , а потом..., .... А где-то в середине вскольз упоминается, что шифровать код — это в настоящее время отстой. Могу выслать на мыло в формате doc и с хреновым качеством


Буду признателен: flame@rsdn.ru
Re[4]: Рассуждения на тему защиты программ
От: CyberDemon Россия  
Дата: 10.09.03 08:14
Оценка:
Здравствуйте, TK, Вы писали:

TK>Hello, "CyberDemon"

>>
>> TK>Можно еще сделать две (n) одинаковые функций которые будут отличаться небольшими нюансами (+ на — поменять, == на != и т.п.) а итоговую функцию собирать на их основе — найти точки различий и используя ключ выбрать правильные. Как плюс — код готов после компиляции.
>>
>> Это изложение по-русски моего ответа ?

TK>Наверное не совсем

TK>Например, зачем создавать кучу классов? Можно создать один с кучей "лишних" методов и в процессе проверки подправить vtable так, что-бы она указывала на восстановленные методы. Да и в данном случае нет шифрования всего метода — запутываются лишь отдельные фрагменты

Да, в принципе тоже вариант. Или, по-другому, те же яйца, но в профиль Главное только самому не запутаться
Re[2]: Рассуждения на тему защиты программ
От: CyberDemon Россия  
Дата: 10.09.03 08:15
Оценка:
Здравствуйте, Слава, Вы писали:

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


Если можно, мне — интересно почитать

supered[собака]mail.ru
Re[2]: Рассуждения на тему защиты программ
От: UGN  
Дата: 10.09.03 08:33
Оценка:
Здравствуйте, Слава, Вы писали:

С>Значит так. Чтобы такие вопросы не возникали нужно внимательно и вдумчиво прочитать книгу Касперского "Технологии и механизмы хакерских атак" там подробно описываются методы защиты, а потом методы снятия этой защиты, а потом способы борьбы с этими методами, а потом способы нейтрализации этих способов , а потом..., .... А где-то в середине вскольз упоминается, что шифровать код — это в настоящее время отстой.


Почему же отстой? Для недорогого продукта вполне приемлемая защита, особенно нестандартно реализованная.

Многие достойные программы имеют очень слабую защиту, практически никакую.

Ставишь бряк на вызов MessageBox( hWnd, "Не угадал!", "Ввод кода", MB_OK );

Потом смотришь что было выше.

Иногда прямо в отладчике видно сравнение открытым текстом "Фигня, которую я ввел вместо кода" c "Единственно верный код от разработчика".

Бывает, конечно, что сравнение замороченное (я забиваю на все, что сложнее XOR ) но при этом результат top_secret_validate_fn() тупо сравнивается с нулем...

Можно подумать, что подправить сравнение очень сложно (или лучше саму функцию, чтобы всегда определенное значение возвращала)...

На фоне таких шедевров, шифрование кода, имхо, очень неплохой ход.

По крайней мере отсеет массу любопытных личностей с зудящим отладчиком.

А серьезные товарищи, имхо, этим заниматься не будут. У них интерес материальный.

Зачем им недорогая программа, на которой потеряешь время, а много не заработаешь?

У них есть более выгодные проекты.

Так что, считаю, что шифрование кода рано списывать со счета.


ЗЫ: Я ни в чем не виноват, никого не трогал, ничего не ломал.

А если что и делал, то только в общеобразовательных целях.
Re: Рассуждения на тему защиты программ
От: Евгений Коробко  
Дата: 10.09.03 09:18
Оценка:
Замуровать проверку подлинности — это вопрос техники. А мне вот интереснее другой вопрос.
Допустим, я позволяю скачать прогу, которая работает в демо-режиме, а за деньги — файлик-ключик. Проверка
подлинности ключика зашифрована — не подковаешься. Но вот кто-то прогу купил. Дал переписать знакомому, тот — своему, и
в конце концов ключик оказыватеся на astalavista. Как этому можно помешать?
Первое, что приходит в голову — привязка к железу пользователя. Но это очеень нехорошо. Большинство пользователей очень не любит
подобные вещи (я тоже не люблю), да и проблем очень много.
Делать много версий программы с разными алгоритмами проверки ключа (и разными ключами) — неэффективно, хватит и одной копии
Научить прогу лезть в интернет — тоже не вариант
Ограничивать срок действия дистрибутива/ключа нельзя, т.к. нарушает права пользователя, да и не будет он с таким геморроем возиться.
А что же делать?
Евгений Коробко
Re[2]: Рассуждения на тему защиты программ
От: CyberDemon Россия  
Дата: 10.09.03 09:36
Оценка:
Здравствуйте, Евгений Коробко, Вы писали:

ЕК>Замуровать проверку подлинности — это вопрос техники. А мне вот интереснее другой вопрос.

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

Black-list, который резко будет обновляться в случае проявления ключа. Но это только защита от работы в новых версиях.
Соответственно, версии надо обновлять почаще, чтобы была заинтересованность в закачке новья. А спец, который "поделился" в след. раз подумает хорошо
Re[3]: Рассуждения на тему защиты программ
От: Слава Израиль  
Дата: 11.09.03 05:23
Оценка:
Здравствуйте, CyberDemon, Вы писали:

CD>Если можно, мне — интересно почитать


CD>supered[собака]mail.ru


Отправил
Спасибо за внимание
Re[3]: Рассуждения на тему защиты программ
От: Слава Израиль  
Дата: 11.09.03 05:48
Оценка: 18 (1)
Здравствуйте, CyberDemon, Вы писали:

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


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


CD>Если можно, мне — интересно почитать


CD>supered[собака]mail.ru


Отправлял, но вернулось обратно
Спасибо за внимание
Re[3]: Рассуждения на тему защиты программ
От: Слава Израиль  
Дата: 11.09.03 06:17
Оценка: 9 (1)
Здравствуйте, UGN, Вы писали:

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


UGN>Почему же отстой? Для недорогого продукта вполне приемлемая защита, особенно нестандартно реализованная.


Во-первых это мнение Касперского, во-вторых его мнение можно понять, из того-же SoftIce можно сделать дамп расшифрованной проги ( она же сама себя расшифровывает) да и дизасемблером IDA можно легко расшифровать , в третьих это уже стандартная реализация.

UGN>Многие достойные программы имеют очень слабую защиту, практически никакую.


И это очень плохо

UGN>Ставишь бряк на вызов MessageBox( hWnd, "Не угадал!", "Ввод кода", MB_OK );


UGN>Потом смотришь что было выше.


UGN>Иногда прямо в отладчике видно сравнение открытым текстом "Фигня, которую я ввел вместо кода" c "Единственно верный код от разработчика".


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

UGN>Бывает, конечно, что сравнение замороченное (я забиваю на все, что сложнее XOR ) но при этом результат top_secret_validate_fn() тупо сравнивается с нулем...


UGN>Можно подумать, что подправить сравнение очень сложно (или лучше саму функцию, чтобы всегда определенное значение возвращала)...


UGN>На фоне таких шедевров, шифрование кода, имхо, очень неплохой ход.


UGN>По крайней мере отсеет массу любопытных личностей с зудящим отладчиком.


Нет , если личность действительно любопытная.

UGN>А серьезные товарищи, имхо, этим заниматься не будут. У них интерес материальный.


UGN>Зачем им недорогая программа, на которой потеряешь время, а много не заработаешь?



UGN>У них есть более выгодные проекты.


UGN>Так что, считаю, что шифрование кода рано списывать со счета.



UGN>ЗЫ: Я ни в чем не виноват, никого не трогал, ничего не ломал.


UGN>А если что и делал, то только в общеобразовательных целях.


Да ладно чё уж там. Цитирую из упомянутой книги:

Мелким кракингом занимаются все.


ИМХО Это даже полезно, потому что налицо видны чужие ошибки.

Я после взлома ( если он удался ) удаляю прогу со своего компа.
И SofICE и IDAPro у меня установлены

А теперь хочу посоветовать один не очень честный метод тестирования своей защиты:

Зарегистрироваться на хакерском форуме, написать CrackMe и дать его на растерзание, об ошибках узнавать из форума. Согласен, что это подло, но они, обесценивая наш труд поступат ещё подлее.

ИМХО на отрытом форуме, как этот не стоит обсуждать защитние механизмы своих прог.

ЗЫ я не взломщик, и до почётного звания хакер мне ещё очень далеко, просто как и все я озабочен защитой от компьютерных вандалов, называющих себя хакерами.
Спасибо за внимание
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.