Но отвечу только в понедельник...

Хорошо, мне не к спеху:-)

Но что делать, если документ кодировать не приемлемо

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

для начала по мылу будет проще: rouse@grandsmeta.ru
Но отвечу только в понедельник...

>В принципе, в свободное время, я могу провести для вас консультацию по использованию ключей Guardant Code и дать некий набор рекомендаций, после которых Вы и сами поймете как его "правильно готовить".

Буду Вам очень признателен. Как это лучше организовать? e-mail? ICQ? Или прям здесь?

Для начала необходимо разработать сам алгоритм защиты.
Ключ это просто железка - не ждите от него "магии".
Как один из вариантов подхода к построению защиты можно рассмотреть рекомендованную выше Антоном Тихиенко статью, вот прямой линк на нее: http://alexander-bagel.blogspot.ru/2012 … -post.html

А теперь по поводу Guardant Code:
Вопрос: "Небольшой объем памяти ключа"
Ответ: всю программу туда переносить не стоит, только общую логику защиты, правда RAM узковат (мне не хватило, пришлось ужиматься) впрочем...
Это ж вам не PIC12F675-I/P, где с памятью вообще плохо (практически не память - а склероз).
Почитайте кстати: http://www.javaportal.ru/humour/history … _byte.html

Вопрос: "Программы пишутся на объектных языках программирования с использованием сторонних библиотек, в то время как в ключ можно загрузить код только на языке С и без использования сторонних библиотек."
Ответ: Да, это проблема, но с учетом того что код пишется на "Ansi C", затруднений с его реализации не должно возникнуть даже у первокурсников.

Вопрос: "Быстродействие алгоритма, перенесенного в ключ будет заметно ниже."
Ответ: нет, это не так - проверенно практикой :)

Вообще идея работы с ключом Guardant Code должна сразу абстрагироваться от того что в нем "просто выполняется код".
Т.к. это достаточно надежный "BlackBox" есть варианты переноса в него даже известной взломщику логики из старых версий ПО таким образом, что даже имея на руках полностью отреверсенный алгоритм от старой версии программы, он не сможет ничего сделать с этими знаниями, т.к. сам ключ будет мешать (конечно при правильной реализации).
Я уж не говорю о реализации новых алгоритмов, доступных только ключу.

В принципе, в свободное время, я могу провести для вас консультацию по использованию ключей Guardant Code и дать некий набор рекомендаций, после которых Вы и сами поймете как его "правильно готовить".

У меня как раз такой ключ, но как его использовать на практике мне сложно представить, поскольку, насколько я понял, преимущество такого ключа в том, что часть полезных функций программы можно перенести из exe файла в ключ. Однако для применения на практике такого принципа вижу ряд препятствий:
1. Небольшой объем памяти ключа.
2. Программы пишутся на объектных языках программирования с использованием сторонних библиотек, в то время как в ключ можно загрузить код только на языке С и без использования сторонних библиотек.
3. Быстродействие алгоритма, перенесенного в ключ будет заметно ниже.

В целом Ваше суждение скорее ошибочно, а что касается наших примеров, то они как раз предназначены для дополнительной (помимо документации) иллюстрации применения функций Guardant API и намерено представлены в таком "открытом" виде, чтобы лишний раз не путать разработчика, начинающего осваивать их. Естественно, что использование в коде приложения таких функций должно быть не столь очевидным и выбор вариантов их применения и построения своей собственной, уникальной схемы защиты приложения, лежат только на плечах разработчиков, внедряющих эту самую защиту в свое ПО.

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

Здесь точно можно сказать то, что такая, комбинированная (Guardant API + автозащита), защита гораздо предпочтительней чем использование только одного метода (либо Guardant API, либо автозащита) и нами рекомендуется к применению.

Механизм виртуальной машины для Native-приложений можно не применять (опция "/RIP_CODE"), но в таком случае степень защищенности от дизасемблирования будет меньше. Правильнее будет использовать наши утилиты профилирования, позволяющие провести анализ скорости выполнения различных участков кода и в автоматическом или ручном режимах исключить (не будут защищаться) некоторые, особо медленные.

Также тут можно рассмотреть вариант использования электронных ключей с загружаемым кодом Guardant Code.

«6.  Усложните  логику  обработки  кодов  возврата  функций API. Если вы будете проверять код возврата функции API простым сравнением, хакеру не составит труда уничтожить это сравнение прямо в теле приложения – и таким образом снять защиту.»

Однако в уроке 3.3 приводите код:

// Проверяем подлинность подписи
    nRet = GrdVerifySignSource( GrdECC160_PUBLIC_KEY_SIZE, abyPublicKey , 
      sizeof(szMessage), szMessage, 
      sizeof(szDigitalSign), szDigitalSign, NULL );
   if(nRet)
     cout << "G rdVerifySign() failed!" << endl;
   else
  {
     // Алгоритм принятия решения о выборе напитка
     random_shuffle(ans.begin(),ans.end(),p_random);
     cout << "T oday your drink is ";
     if (q=="t")
    cout<<ans [0];
     else
    cout<<ans [1];
     cout << "  !!!" << endl;
  }
   cout << "= =========================================="<< endl; 

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

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

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