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

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

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

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

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

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

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

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

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

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

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

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

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

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

Marik Decide пишет:

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

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

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

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

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

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

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

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

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

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

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

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

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

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