Тема от Marik Decide

  • Marik Decide
  • Посетитель
  • Неактивен

Применение Grdarmor поверх защиты через guardant api

Заметил такой пункт в информации к grdarmor в разделе "Использование утилиты":
"Нельзя выполнять защиту файлов, которые ранее уже были защищены другими протекторами, в том числе утилитами автозащиты Guardant."
У нас используется защита .exe-файла, написанного на delphi, с помощью guardant api. Также непосредственно в работе программой используется несколько .net (c#)-dll. Нужно защитить .exe-файл, одну .net-dll и внешнюю c++-dll (не использующаяся внутри программы, используется provider'ом базы данных), так как между ними происходит обмен определенного буфера. Вопрос: Получится ли к такой конструкции применить grdarmor?

Ответ от Тимофей Ершов (2018-12-19 17:00:04 отредактировано Тимофей Ершов)

  • Тимофей Ершов
  • Техническая поддержка
  • Неактивен

Re: Применение Grdarmor поверх защиты через guardant api

Добрый день. Guardant Armor предназначен для защиты native приложений 32-х и 64-х разрядных. Приложение или библиотеку, написанную на DotNet, не получится защитить с помощью GrdArmor. Можно попробовать следующий вариант.
Защитить нативный ехе файл GrdArmor, .net-dll защитить DotNet автозащитой, а C++ dll защитить опять же GrdArmor. Если при этом используются публичные интерфейсы или reflection, при взаимодействии защищенных объектов могут возникать проблемы. Что бы их избежать, необходимо исключить из защиты публичные интерфейсы, reflection.

Ответ от Marik Decide (2018-12-20 06:59:14 отредактировано Marik Decide)

  • Marik Decide
  • Посетитель
  • Неактивен

Re: Применение Grdarmor поверх защиты через guardant api

Тимофей Ершов пишет:

Добрый день. Guardant Armor предназначен для защиты native приложений 32-х и 64-х разрядных. Приложение или библиотеку, написанную на DotNet, не получится защитить с помощью GrdArmor. Можно попробовать следующий вариант.
Защитить нативный ехе файл GrdArmor, .net-dll защитить DotNet автозащитой, а C++ dll защитить опять же GrdArmor. Если при этом используются публичные интерфейсы или reflection, при взаимодействии защищенных объектов могут возникать проблемы. Что бы их избежать, необходимо исключить из защиты публичные интерфейсы, reflection.

Спасибо за отклик. Хотел бы уточнить насчет

Тимофей Ершов пишет:

Защитить нативный ехе файл GrdArmor

, у нас же есть уже защита на нем с помощью guardant api. Нам в таком случае придется отказаться от неё, чтобы использовать grdarmor? Просто в Вашем ответе я уточнения по этому моменту не увидел...

Тимофей Ершов пишет:

Если при этом используются публичные интерфейсы или reflection, при взаимодействии защищенных объектов могут возникать проблемы.

А это Вы говорили обо всем сразу (.net dll, c++ dll,exe-файл) или только о том, что защищается armor'ом? У нас есть использование (вызов) функций exe-шника (delphi) в .net-dll-ках..

Ответ от Тимофей Ершов

  • Тимофей Ершов
  • Техническая поддержка
  • Неактивен

Re: Применение Grdarmor поверх защиты через guardant api

, у нас же есть уже защита на нем с помощью guardant api. Нам в таком случае придется отказаться от неё, чтобы использовать grdarmor? Просто в Вашем ответе я уточнения по этому моменту не увидел...

Отказываться от API не придется. Автоматические утилиты корректно работают с встроенными функциями.

А это Вы говорили обо всем сразу (.net dll, c++ dll,exe-файл) или только о том, что защищается armor'ом? У нас есть использование (вызов) функций exe-шника (delphi) в .net-dll-ках..

В процессе защиты автоматическими утилитами код функций и методов приложения может быть "запутан" (видоизменен), или зашифрован. В этом случае вызов такой функции именно из внешнего модуля будет невозможен. Такие функции лучше исключить.  Исключения и включения содержатся в *.ini файле. Подробнее о GrdArmor можно узнать на нашем портале документации.

Ответ от Marik Decide

  • Marik Decide
  • Посетитель
  • Неактивен

Re: Применение Grdarmor поверх защиты через guardant api

Тимофей Ершов пишет:

.net-dll защитить DotNet автозащитой

Если у нас стартовое приложение native (delphi) получится ли поработать .net профайлером  c .net dll?

Ответ от Антон Тихиенко

  • Антон Тихиенко
  • Администратор
  • Неактивен

Re: Применение Grdarmor поверх защиты через guardant api

Здравствуйте.

Marik Decide пишет:

Если у нас стартовое приложение native (delphi) получится ли поработать .net профайлером  c .net dll?

Да. Попробуйте так поработать.

Ответ от Marik Decide

  • Marik Decide
  • Посетитель
  • Неактивен

Re: Применение Grdarmor поверх защиты через guardant api

Антон Тихиенко пишет:

Здравствуйте.

Marik Decide пишет:

Если у нас стартовое приложение native (delphi) получится ли поработать .net профайлером  c .net dll?

Да. Попробуйте так поработать.

Я бы хотел у Вас уточнить, применение .net-автозащиты должно обеспечивать антиотладку? Просто я реализовал данный пример, но в защищенный метод в .net-dll (защищен он кодобфускатором и протектором) можно попасть через отладчик в dotPeek. А там уже можно снять дамп и..

И еще хотел бы, чтобы Вы прокомментировали момент один. Я хотел в добавок защитить .net-dll, которая является провайдером для подключения к базе. Добавив к имеющейся конструкции защиты .net-dll-ек нашей программы я получил выходные файлы codestorage32.dll и codestorage64.dll, но заменив обратно на незащищенную версию этой dll ничего не поменялось. Т.е. получается, если это внешняя dll по отношению к программе, которую можно скачать, её достаточно подменить и получить доступ к данным подключения к базе. Спасет ли подписание этой dll и не упустил ли я в документации чего-то?

Ответ от Антон Тихиенко

  • Антон Тихиенко
  • Администратор
  • Неактивен

Re: Применение Grdarmor поверх защиты через guardant api

Marik Decide пишет:

Я бы хотел у Вас уточнить, применение .net-автозащиты должно обеспечивать антиотладку? Просто я реализовал данный пример, но в защищенный метод в .net-dll (защищен он кодобфускатором и протектором) можно попасть через отладчик в dotPeek. А там уже можно снять дамп и..

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

Marik Decide пишет:

И еще хотел бы, чтобы Вы прокомментировали момент один. Я хотел в добавок защитить .net-dll, которая является провайдером для подключения к базе. Добавив к имеющейся конструкции защиты .net-dll-ек нашей программы я получил выходные файлы codestorage32.dll и codestorage64.dll, но заменив обратно на незащищенную версию этой dll ничего не поменялось. Т.е. получается, если это внешняя dll по отношению к программе, которую можно скачать, её достаточно подменить и получить доступ к данным подключения к базе. Спасет ли подписание этой dll и не упустил ли я в документации чего-то?

Тут стоит разобраться поподробнее:

Эта dll (провайдер для подключения к БД) не ваша разработка, а сторонний компонент, доступный для свободного скачиваня?
Пришлите нам на e-mail ( hotline@guardant.ru ) bat-файлы со всеми параметрами защиты кода и обфускации. Если для защиты использовали GUI-мастер автозащиты, то эти файлы (все файлы с расширениями *.obf и *.prt) будут в папке с проектом защиты, в подпапке "CommandLines".

Ответ от Marik Decide

  • Marik Decide
  • Посетитель
  • Неактивен

Re: Применение Grdarmor поверх защиты через guardant api

Антон Тихиенко пишет:

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

А у армора тоже нет антиотладки?

Ответ от Антон Тихиенко

  • Антон Тихиенко
  • Администратор
  • Неактивен

Re: Применение Grdarmor поверх защиты через guardant api

Все инструменты защиты (native-автозащита, Guardant Armor и .Net-автозащита), по сути, и предназначены для затруднения изучения кода приложения и препятствию его несанкционированной отладки.

Что касается .Net, то выше я уже писал о шифровании строк и переносе MSIL-кода в защищенные native-контейнеры (codestorage).
В Guardant Armor, например, есть случайная проверка целостности и если использовать отладчик, то рано или поздно приложение отреагирует.

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

Ответ от Marik Decide

  • Marik Decide
  • Посетитель
  • Неактивен

Re: Применение Grdarmor поверх защиты через guardant api

Антон Тихиенко пишет:

Тут стоит разобраться поподробнее:

Эта dll (провайдер для подключения к БД) не ваша разработка, а сторонний компонент, доступный для свободного скачиваня?

Да, это сторонний компонент и доступный для скачивания. Нужно ли в таком случае отправлять Вам bat-файлы на почту?

Ответ от Антон Тихиенко

  • Антон Тихиенко
  • Администратор
  • Неактивен

Re: Применение Grdarmor поверх защиты через guardant api

Marik Decide пишет:

Нужно ли в таком случае отправлять Вам bat-файлы на почту?

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