Re: "Защита" *.DLL
 

Cyan
я кстати имперу в асе предлагал такой вариант
для ООП языков ето самое оно :)
либа с одной функцией ... и что юзер с ней делать то будет ? :)

impersonalis
что мешает закапать ето все в exe с нормальным названием
а потом при открытии банально распоковать в левую папку и запустить ?

Ответ: "Защита" *.DLL
 

Хотелось бы узнать мнение Knightmare по этому вопросу.

Ответ: Re: "Защита" *.DLL
 

Конечные ключи (надо было только для одного проекта) встраивал не в явном виде, а в виде кода, генерируемого другой программой. На выходе получался синтетический набор массивы/функции, результатом взаимодействия которых был создаваемый в памяти ключ. Для паранойи можно ключ в памяти не держать, а создавать ровно на время работы с ним.
Конечно, можно было разобрать и этот код и восстановить ключ, но это совсем не то же, что прогнать фильтр chr()>31.
Ну и, "уязвимости" подвластны не только блитцевые exe.
То есть в роли интерфейса оставить только одну функцию, рассказывающую о внутренностях? Возвращающую по команде указатели на остальные методы? Ну это больше кодирование, чем шифрование (в плане - много возни, но если делать хорошо, то и пользователь быстро разберётся; не ясно как здесь обфусцировать код). Подобным приходилось маяться при изготовлении MATLAB-овских mex-файлов (DLL с фиксированным интерфейсом в одну функцию): функция получала на вход команду что_делать (инициализация, очистка ресурсов, рассчёт, прочее) и необходимый (для данной операции) набор данных. Ситуация упрощалась тем, что при написании используются matlab-овские контейнеры, что придаёт интерфейсу довольно масштабируемый характер.

Ответ: "Защита" *.DLL
 

Ответ: "Защита" *.DLL
 

Ну для начала немного кэпства: все можно поломать (ну исключая разве что какие-нибудь веб-сервисы, но и то возможности некоторые есть), скорость поломания зависит от популярности.
Если ты делаешь что-то не особо популярное (или очень узконаправленное) и врядли над этим будет пыхтеть куча людей чтобы изломать и выкинуть на торренты, то можно особо не заморачиваться с защитой изощренной, потому как лишняя работа (ну разве что для лулзов, для лулзов как я уже писал можно хоть что делать без каких-либо обоснований). Если кого-то приспичит очень сильно, то все равно сломают, а большинство юзеров и с весьма простой защитой соснут.
В целом обфусцированный кусок кода для проверки ключей, который в целях отдельного извращения можно размазать по функционалу либы, и частично на результат проверки завязать функционал (ну там из правильного куска ключа получается правильная константа и все работает верно), у нас был код который крашил не до конца поломанную (если остановится на проверке ключа и не втыкать что дальше в движке происходит) либу, например. Антидебаггерная защита тож полезной будет, потому как одно дело с дебаггером ковырять ассемблерную мешанину, а другое дело медитировать на этот самый ассемблер без возможности запуска. Плюс всегда можно написать свой упаковшик с самопальным шифрованием (но тут я не уверен насколько возможно в современных вендах с наглой мордой запихать в память код и сказать что его надо выполнять), тогда соответственно при инициализации DLL с верным ключом в память развернется уже непосредственно код с функционалом либы, но даже при возможности загрузки левого кода задача не самая тривиальная.
А вообще по возможности можно все вынести на сервер, а в либе будет только связь с ним, типа отправить запрос, распарсить ответ. Тогда хоть заломайся в либе нихера толкового не будет, надо ломать уже сервер, что несколько сложнее, а если он правильно анально огорожен, то и практически невозможно (ну всякие там Heartbleedы всегда могут нарисоваться). Хотя этот вариант не везде подойдет (интернет сейчас есть в любом зажопинске, но для чего-то реалтаймового не подойдет очевидно). Алсо при этом подходе легко выпиливаются скомпрометированные ключи. Ну а если функционал либы уникальный и нужный кому-то, то этот кто-то согласится и на такие условия. И плюсом сюда крайне просто под разные платформы все это растиражировать, а если под какую-то и нет официальной либы, то кому надо сами запилят по документации к API.

Ответ: "Защита" *.DLL
 

Это, к сожалению, не сработает. Любой ламер "обходит" такую защиту поставив пару плагинов на отладчик (порог вхождения слишком низок).
Так делает ASProtect. Он шифрует часть кода, а в часть рег. кода запихивает ключ для расшифровки.
Еще больше проблем взломщику принесет виртуальная машина.
То есть она ничего отлаживать не запрещает (присутствует пара методов, но они легко обходятся), однако вместо ассемблера у вас в отладчике непонятная каша, вследствие чего отладка становится попаболью (нет авт. анализа (IDA идет лесом), нет брейкпоинтов, никаких "констант" в коде и т.д.). Единственное решение для таких ВМ - заниматься распаковкой, но это задачка совсем не тривиальная и в принципе ВМ это лучшее из решений "на стороне клиента".

Ответ: "Защита" *.DLL
 

Нет, в той статье на которую я давал ссыль, есть приёмы которые не отлавливаются и плагинами. Зависит от количества применяемых тобой приёмов -- чем больше их сделаешь -- тем больше работы придется сделать ламеру, а значит не все ламеры захотят делать столько действий.

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

Ответ: "Защита" *.DLL
 

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

Ответ: "Защита" *.DLL
 

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

Там есть демка в разделе Downloads.
Каким это образом ?

Ответ: "Защита" *.DLL
 

Даже если идти по ссылке на не_SecureEngine методы, когда начинаешь тыкать на объяснение как это работает, они всё равно переходят на SecureEngine.

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

Демку посмотрю.

Ну как, получаешь контекст процесса, значения регистров, дамп памяти виртуальной машины в случае падения кода прямо с удалённого компьютера пользователя, без каких либо привелегий и отвлекания пользователя предоставить какой-то доступ. Да и пользователю спокойнее что программа изолировано работает в обычном приоритете. Удобно когда всё внутри.

Ответ: "Защита" *.DLL
 

Виртуальные машины бывают разные.
У jvm, например, команд мало и они вполне очевидные (положить в стек, достать из стека, сложить два верхних и положить результат на стек)- такой код с чётким разделением на методы разбирать действительно проще.

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

насколько я понимаю, разобраться в том, что делает такая виртуальная машина, станет очень трудно - придётся понять, как работают её команды, а потом написать нечто вроде анализатора кода для такой машины, чтобы он наконец-то разобрался, какие переменные важны, а какие - не влияют на результат. И только потом можно будет докопаться до алгоритма.

P.S. где-то читал, что в лаборатории Касперского есть софт, который умеет анализировать работу таких виртуальных машин без помощи человека.

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

Ответ: "Защита" *.DLL
 

Ага всё попробовал демку.
Ну вроде работает но нагромождений дофига.
Из ограничений: платная и только для Windows.

Вот ещё кстати статейка, но правда старая, её смысл в том что нужно макросами указывать внутри своего кода что и как защитнику делать, т. к. полностью автоматический режим не очень хорошо справляется с задачей.

Да там так и сделано -- есть несколько шаблонов выдуманных машин, какие то быстрее но проще, какие то медленнее но сложнее. И я так понял что из шаблона можно генерировать более конкретную машину для данного случая.

Нет имеется ввиду что запущенные процессы с одинаковым приоритетом не могут внедрятся друг в друга по своему желанию. В то время как запущенный из под админа дебагер может потрошить приложение с привилегиями обычного пользователя. Это не относится к виртуальной машине, просто кроме такого подхода там ещё и машина и много чего ещё.

Ответ: "Защита" *.DLL
 

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

Ответ: "Защита" *.DLL
 

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

Кстати демка которую я запускал не требовала инсталляции и не требовала прав администратора на запуск защищаемого софта, так что похоже действительно есть вариант, который работает в режиме пользователя. Единственное что меня смутило у Themid'ы нет цифровой подписи и Windows даёт соответствующее предупреждение при её запуске.

Ответ: "Защита" *.DLL
 

Это можно сделать и без виртуальной машины.

Ты все время говоришь про какие-то там привелегии. Что ты имеешь в виду под "привелегиями" ? Отсутствие каких конкретно привелегий является проблемой для пакеров вроде темиды (исключая вариант с ring0 защитой) ?