Как защитить значения глобальных констант?

VMProtect
1

Подскажите пожалуйста, как защитить с помощью VMProtect константы в следующем модуле (маркерами в данном случае воспользоваться не представляется возможным):

unit GlobalConsts;
interface
uses
    Dialogs;
const

    // Вот эти константы необходимо защитить
    //*************************************************************
    CONST_ProgID        = '{43F8F289-7A20-11D0-8F06-00C04FC295E1}';
    CONST_TotalRunCount = 100;
    CONST_Author        = 'Vasily Pupkin';
    //*************************************************************

implentation
end;
2

В данном случае вам нужно защищать не сами контсанты, а код который с ними работает. Для строковых констант можно предложить использовать VMProtectDecryptStringA/W:

procedure TForm1.FormCreate(Sender: TObject);
begin
  Caption:=VMProtectDecryptStringA(CONST_Author);
end;

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

3

Тогда следующий вопрос, если

то константы нужно сначала как-то зашифровать (Ecrypt)?

4

то константы нужно сначала как-то зашифровать (Ecrypt)?

Строковые константы будут автоматически зашифрованы после включения их в проект (в общем списке объектов они будут видны как string “{43F8F289-7A20-11D0-8F06-00C04FC295E1}” и string “Vasily Pupkin”).

5

У меня в списке только процедуры, подскажите пожалуйста, как добавить константу в список защищаемых объектов?

6

У меня в списке только процедуры, подскажите пожалуйста, как добавить константу в список защищаемых объектов?

Для этого константу нужно предварительно обернуть в VMProtectDecryptStringA/W:

procedure TForm1.FormCreate(Sender: TObject);
begin
  Caption:=VMProtectDecryptStringA(CONST_Author);
end;
7

Всё получилось, большое спасибо. Последний вопрос - какой тип компиляции предпочтительнее для констант (по умолчанию стоит виртуализация)? Или это по большому счету не существенно?

8

Последний вопрос - какой тип компиляции предпочтительнее для констант (по умолчанию стоит виртуализация)? Или это по большому счету не существенно?

Если вы защищаете константу не только от нахождения её в ЕХЕ, но и от патча, то лучше использовать виртуализацию или ультру.

9

Не могли бы вы в будуших версия для функций:

VMProtectDecryptStringA,VMProtectDecryptStringW добавить еще указание типа защиты, чтобы не использовать скрипт и GUI?

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

10

Не могли бы вы в будуших версия для функций:

VMProtectDecryptStringA,VMProtectDecryptStringW добавить еще указание типа защиты, чтобы не использовать скрипт и GUI?

Такого в планах нет.

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

Мы планируем добавить возможность уничтожения строки, указатель на которую получен через VMProtectDecryptStringA/W - скорее всего будет отдельная API типа VMProtectFreeString. В какой именно версии это будет сделано - не могу точно сказать.

11

Такого в планах нет.

В общем то мне кажется что это было бы полезной фичей, тем более что все равно он может менятся вручную.

Мы планируем добавить возможность уничтожения строки, указатель на которую получен через VMProtectDecryptStringA/W - скорее всего будет отдельная API типа VMProtectFreeString. В какой именно версии это будет сделано - не могу точно сказать.

Тогда меня сейчас интерисует такой вопрос… считается ли что указатель который вернула VMProtectDecryptStringX уходит в утечку памяти?

12

Тогда меня сейчас интерисует такой вопрос… считается ли что указатель который вернула VMProtectDecryptStringX уходит в утечку памяти?

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

13

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

Я имел в виду следующий случай:

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

14

Тоесть на момент завершения приложения (или на момент выхода из функции) я имею указатель на выделенную область памяти - что и подразумеваю под утечкой.

Если рассматривать случай с завершения приложения (актуально для DLL/SYS файлов), то действительно будем иметь утечку памяти в пределах процесса (для SYS - в системной памяти). Мы планируем в версии 2.06 (через одну версию) устранить все эти недостатки и предоставить пользователю возможность самому уничтожать декриптованные строки.

15

то действительно будем иметь утечку памяти в пределах процесса (для SYS - в системной памяти).

Плохо… Verifier будет ругатся BSOD-ом!!!

Да и еще было бы хорошо, если в будущем функция VMProtectDecryptStringX будет еще и возвращать длину раскриптованой строки.

16

Да и еще было бы хорошо, если в будущем функция VMProtectDecryptStringX будет еще и возвращать длину раскриптованой строки.

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

17

Не вижу никаких проблем с реализацией этого на стороне пользователя

Так оно сейчас и работает, но вдруг декриптованная строчка будет без завершающего нуля??? что тогда - exception ?

18

Так оно сейчас и работает, но вдруг декриптованная строчка будет без завершающего нуля???

VMProtectDecryptStringX на входе “ждет” строчку с завершающим нулем, соответственно после декрипта он там тоже будет.

19

VMProtectDecryptStringX на входе “ждет” строчку с завершающим нулем, соответственно после декрипта он там тоже будет.

Функция ожидает константную строчку в момен компиляции и завершающий ноль будет в любом случае, а вот во время дикриптации - я за ноль уже не уверен!

  • если я буду “ДОСТОВЕРНО” знать длину строки которую вернула эта функция - я смог бы заполнить ее рандомным мусором. Делать предположение на то, что там будет ноль крайне не желательно.
20

Функция ожидает константную строчку в момен компиляции и завершающий ноль будет в любом случае, а вот во время дикриптации - я за ноль уже не уверен!

В момент декриптации происходит декриптация ВСЕЙ строки, включая завершающий ноль - иначе ваша программа перестанет нормально работать.

  • если я буду “ДОСТОВЕРНО” знать длину строки которую вернула эта функция - я смог бы заполнить ее рандомным мусором. Делать предположение на то, что там будет ноль крайне не желательно.

Зачем вы собрались заполнять строку рандомным мусором? Если только для того чтобы после использования убрать из памяти её декриптованный вариант, то вы столкнетесь сразу с несколькими проблемами:

  1. При заполении памяти мусором при последующем вызове VMProtectDecryptStringX с той же самой строкой вы получите свой мусор, т.к. декрипт строки происходит только при первом вызове VMProtectDecryptStringX и указатель на память пишется в “глобальную” переменную, которая будет выступать результатом при повторном VMProtectDecryptStringX.
  2. В режиме отладки (до компиляции в VMProtect) вы гарантировано получите Access Violation при записи по указателю, т.к. VMProtectDecryptStringX вернет вам тотже самый указатель, который вы передали в качестве параметра (строки). А все константные вещи компилер складывает в секцию без флага WRITABLE.