"Защита" *.DLL
 

Хотелось бы обсудить вопрос защиты от несанкционированного использования *.DLL-файлов.
А именно:
например есть самодельная длл-ка, вроде и с народом хочется поделиться, но и враг не дремлет - хаъапает мою дээльэль и будет втихаря юзать без всяих копирайтов. Можно конечно наг-скрин генерить при загрузке приложения - но что-то я не совсем чётко себе представляю реализацию.

Поделитесь мыслями - не хочу велик изобретать.:stop:

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

imho, наг скрин или водяной знак в окошке :)
а еще ключики ^_^ :-)

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

Если делать всплывающие окна (например, в модуле инициализации), то, скорее всего, ей пользоваться никто не будет. Вариант - сделать строку в самой DLL (и, если очень хочется, сделать в модуле инициализации проверку на контрольную сумму, чтоб не затерли) - кто захочет - просмотрит файл и найдет имя автора.

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

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

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

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

наг-скрины нерулят однозначно.
собсно, скажу что и все ,, ИМХо - ключ. и просто и эффективно (враг нескомуниздит либу незная ключа).
вариант два, враг таки заполучил ключ и нагло стер копирайты (или чо еще хуже, вписал свои), вот что делать в етом случае?
а что если так:
есть кейген у владельца, который генерит ключ на основе имени "ексешки". т.е. на каждый проект - новый ключ (иначе - наг-скрин) ?
а потом из длл-ки можно как нить узнать имя процесса который ее потревожил?
еще идея - найти смещение в длл, где начинаются копирайты, и проверять, если автор != Impersonalis то *** им, а не инициализация?

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

А можно наглую онлайн проверку делать :) Дать юзеру ключ ( или какой нибуть оригинальный файл) И когда ключ введен, прога проверит не забанен ли ключ.

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

HolyDel
тогда уж md5 file checksum юзать для dllки :)

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

Досаточно CRC32 имени ехе.
Типо : в качестве теста (на период написания) выдаётся код 12345, который будет запускаться, только если ехе, попродивший процесс, будет носить имя ВЕЛИКИЙ_ИМПЕР

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

Делай как все, пароЛЪ при инециализации библы...

ЗЫ\Нече тебе всеравно непоможет защитить её, даже Виндоус- одна из самых великих программ, на которой работают почти все и вся крякнута!!! что говорить о ДДЛ,!, кому нада тот узнает парол, а ктонибуть купиТ=)

ЗЫ\_02_ что за длл такая???

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

Согласен
Например МЕГАПУПЕРГИПЕРБИПСИ_МоКа! ;)
Что за библиотека и вправду такая?
Ненавижу Наг скрины. А ключик это временное.

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

impersonalis
1) Достаточно чтобы сама либа имела подпись
2) надо проверять checksum файла либы
иначе будет гемор ... в твоем способе достаточно переименовать файл чтобы все запахало :) думаеш ето сложно обойти ?

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

И ты бы согласился выпускать свою шаровару, если её имя будет "Йа ТУПОЙ РАЗРАБ, НЕ КУПИВшИЙ БИБЛУ"?

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

Vlad в чем-то прав, 100% защитить ты ее все равно не сможешь. Поэтому если либа любительская и не предполагает баснословных прибылей, любая защита сойдет, ибо ломать никому интереса не будет. А если либа коммерческая и мощная, то все равно сломают. С онлайн проверкой та же история, эмулятор напишут и все.
А привязывать к наименованию - я это проходил, когда базы данных пытался защитить - копируют вместе со всеми чужими копирайтами и наименованиями, и особо совестью не мучаются.

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

А я еще раз напомню: Онлайн проверки ключа хватит.

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

*Ключ отпадает однозначно если либа используется Блицем, ибо ключ как строку можно посмотреть HEX или блокнотом в exe или просто выдрав машинный код из exe и так-же посмотрев его HEX или блокнотом.
*Наг-скрин грохнут за раз плюнуть - тоже отпадает
*Проверка контрольной суммы уже лучше но и ее тоже можно отключить

Имхо, лучший вариант для любой либы пока остается навесная защита в виде какого-нить протектора, лучше не популярного - всякие там аспротекты и молебоксы лучше забыть или юзать их последнии версии.
ЗЫ
Если либа не в блице используется, то можно попросту использовать интерфейсы - либа передает интерфейс одной функцией (как Блицевский runtime.dll), а через него уже используются все необходимые функции. Юзеру изрядно попотеть прийдется чтобы узнать структуру такого интерфейса.

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 защитой) ?

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

нет. Я имел в виду виртуализацию. Вся их возня с привиделегиями не спасёт их от того, что я поставлю virtual box, запущу там их приложение, а читать-модифицировать память буду из основной ОС.

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

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

UPD: Вообще вот эта штука должна работать в режиме пользователя.

Но именно ring0 их основная фишка. Да демка работает в обычном режиме и не требуется ничего ставить и никаких экранов UAC не появляется. Но я так понял что с таким подходом защита существенно ниже.

А понятно. Ну есть методики которые применяются вирусописателями которые могут обнаружить что программа запущена на виртуальной машине и она откажется выполняться корректным образом. Разработчики Themida могли прибегнуть и к этому, имхо. Опять же можно и это обойти но это будет существенно сложнее.