Как защитить dll от детекта
Хотелось бы обсудить вопрос защиты от несанкционированного использования *.DLL-файлов.
А именно:
например есть самодельная длл-ка, вроде и с народом хочется поделиться, но и враг не дремлет - хаъапает мою дээльэль и будет втихаря юзать без всяих копирайтов. Можно конечно наг-скрин генерить при загрузке приложения - но что-то я не совсем чётко себе представляю реализацию.
Поделитесь мыслями - не хочу велик изобретать.
А я растила сына на преданьяхо принцах, троллях, потайных свиданьях,
погонях, похищениях невест.
Да кто же знал, что сказка душу съест? imho, наг скрин или водяной знак в окошке
а еще ключики ^_^
Если делать всплывающие окна (например, в модуле инициализации), то, скорее всего, ей пользоваться никто не будет. Вариант - сделать строку в самой DLL (и, если очень хочется, сделать в модуле инициализации проверку на контрольную сумму, чтоб не затерли) - кто захочет - просмотрит файл и найдет имя автора.
А лучше, просто увидев, что где-то библиотека поставляется без описания и авторских реквизитов - написать автору, чтобы он внес в дистрибутив краткую описаловку к библиотеке.
Обычно в библиотеку добавляется функция, на вход которой поступает лицензионный код. Чтобы библиотека работала нормально, нужно в самом начали передать функции авторизации правильный код. наг-скрины нерулят однозначно.собсно, скажу что и все ,, ИМХо - ключ. и просто и эффективно (враг нескомуниздит либу незная ключа).
вариант два, враг таки заполучил ключ и нагло стер копирайты (или чо еще хуже, вписал свои), вот что делать в етом случае?
а что если так:
есть кейген у владельца, который генерит ключ на основе имени "ексешки". т.е. на каждый проект - новый ключ (иначе - наг-скрин) ?
а потом из длл-ки можно как нить узнать имя процесса который ее потревожил?
еще идея - найти смещение в длл, где начинаются копирайты, и проверять, если автор != Impersonalis то *** им, а не инициализация? А можно наглую онлайн проверку делать Дать юзеру ключ ( или какой нибуть оригинальный файл) И когда ключ введен, прога проверит не забанен ли ключ. HolyDel
тогда уж md5 file checksum юзать для dllки Досаточно CRC32 имени ехе.
Типо : в качестве теста (на период написания) выдаётся код 12345, который будет запускаться, только если ехе, попродивший процесс, будет носить имя ВЕЛИКИЙ_ИМПЕР А я растила сына на преданьях
о принцах, троллях, потайных свиданьях,
погонях, похищениях невест.
Да кто же знал, что сказка душу съест?
Делай как все, пароЛЪ при инециализации библы.
ЗЫ\Нече тебе всеравно непоможет защитить её, даже Виндоус- одна из самых великих программ, на которой работают почти все и вся крякнута. что говорить о ДДЛ. кому нада тот узнает парол, а ктонибуть купиТ=)
ЗЫ\_02_ что за длл такая.
| Досаточно CRC32 имени ехе. Типо : в качестве теста (на период написания) выдаётся код 12345, который будет запускаться, только если ехе, попродивший процесс, будет носить имя ВЕЛИКИЙ_ИМПЕР |
Например МЕГАПУПЕРГИПЕРБИПСИ_МоКа!
Что за библиотека и вправду такая?
Ненавижу Наг скрины. А ключик это временное. impersonalis
1) Достаточно чтобы сама либа имела подпись
2) надо проверять checksum файла либы
иначе будет гемор . в твоем способе достаточно переименовать файл чтобы все запахало думаеш ето сложно обойти ?
| в твоем способе достаточно переименовать файл чтобы все запахало думаеш ето сложно обойти ? |
о принцах, троллях, потайных свиданьях,
погонях, похищениях невест.
Да кто же знал, что сказка душу съест? Vlad в чем-то прав, 100% защитить ты ее все равно не сможешь. Поэтому если либа любительская и не предполагает баснословных прибылей, любая защита сойдет, ибо ломать никому интереса не будет. А если либа коммерческая и мощная, то все равно сломают. С онлайн проверкой та же история, эмулятор напишут и все.
А привязывать к наименованию - я это проходил, когда базы данных пытался защитить - копируют вместе со всеми чужими копирайтами и наименованиями, и особо совестью не мучаются.
*Ключ отпадает однозначно если либа используется Блицем, ибо ключ как строку можно посмотреть HEX или блокнотом в exe или просто выдрав машинный код из exe и так-же посмотрев его HEX или блокнотом.
*Наг-скрин грохнут за раз плюнуть - тоже отпадает
*Проверка контрольной суммы уже лучше но и ее тоже можно отключить
и он идет по трем различным методам инъекции DLL. Как я могу помешать этому процессу? Или, как минимум, как предотвратить первое?
Я думал, может быть, водитель Ring 0 может быть единственным способом остановить все три, но я хотел бы посмотреть, что думает сообщество.
лучшим техническим решением было бы сделать что-то, что заставляет код загрузчика не работать должным образом после инициализации процесса. Один из способов сделать это-взять блокировку загрузчика NT, которая эффективно предотвратит любое действие загрузчика. Другие опции включают исправление кода загрузчика непосредственно в памяти для выполнения вызовов LoadLibrary fail для злоумышленника (например, вставка точки останова int3 и самоотладка для обработки ожидаемых случаев)..
но говоря как хакер (тот, кто управляет сайтом, на который вы ссылаетесь), вы никогда не остановите людей от получения кода в ваш процесс, так или иначе. LoadLibrary просто оказывается удобным ярлыком, но есть множество различных способов загрузки кода вручную, которые вы никогда не могли бы надеяться полностью остановить, за исключением некоторого чрезвычайно вовлеченного кода ring0. И даже если вы пойдете на ring0, хакеры будут рядом с вами.
кроме того, существует множество законных применений для инъекции DLL. Тематические программы, специальные возможности и различные программы, расширяющие функциональность ОС, могут потенциально использовать DLL-инъекцию для придания дополнительной функциональности любой программе.
Как защититься от этих 3-х методов:
вы можете предотвратить первый метод (CreateRemoteThread, который вызывает LoadLibrary), подключив LoadLibrary. В вашем крючке вы проверяете список имен DLL, которые, как вы знаете, являются частью процесса и которые могут быть загружены, или вы можете проверить список известных DLL, которые вы не хотите загружать.
когда вы найдете DLL, вы не хотите загружать SetLastError (ERROR_ACCESS_DENIED) затем возвращать null. Я установил последнюю ошибку, чтобы люди, которые пишут код, ища код ошибки, получили его. Это, похоже, работает, возможно, другой код может быть более подходящим.
Это остановит загрузку DLL.
Я думаю, что тот же метод для блокировки CreateRemoteThread будет работать для SetWindowsHookEx, но только если вы можете установить свой крюк до того, как метод SetWindowsHookEx начнет загружать свой код (который обычно когда первое окно создается в приложении-так рано в его жизни).
хорошая техника. Раньше такого не видел. Вы можете защититься от этого, но вам придется подключить точку входа LoadLibrary (а не таблицу IAT), поскольку пещера кода вызывает LoadLibrary напрямую.
Как прокомментировал автор статьи - есть много способов, которыми вы можете быть атакованы, и вам, вероятно, будет трудно победить их всех. Но часто вы только хотите защитить против некоторые загрузки DLL (например, определенная сторонняя DLL, несовместимая с вашим программным обеспечением, потому что сторонняя DLL не была написана должным образом, чтобы учесть тот факт, что может также присутствовать другой крюк, поэтому вы блокируете его загрузку).
лучшим способом было бы гарантировать, что ни один ненадежный процесс не получит доступ администратора или не будет работать с той же учетной записью пользователя, что и ваше приложение. Без этого доступа инъекция кода в ваше приложение невозможна; и как только такой процесс получает этот доступ, он может вызвать всевозможные неприятности без необходимости вводить себя в другой процесс - инъекция просто облегчает скрытие.
поскольку этот плакат намекает, что он инвестирует в игру против взлома, позвольте мне пролить свет на то, что я думаю. Как бывший мошенник.
просто указатель на игру anti-hacking.
лучший способ-это пусть сервер запускает основную логику игры. например, в шутере от первого лица контролируйте движения, которые клиенты отправляют на сервер. Не позволяйте им передвигаться наугад. пусть сервер сообщит клиентам, где каждый игрок основан на своем собственном логика!--6-->. Никогда не передавайте команды. Они могут быть фальшивыми.
кого волнует, если хакер взломает своего клиента? просто откажитесь от него на других, и все будет хорошо. Для starcraft maphacks решение простое. Не выдавайте gamestate для областей, которые должны быть неизвестны. Это также экономит пропускную способность.
Я был большим мошенником в Delta Force (это старая игра). Основной трюк, который я использовал, состоял в том, чтобы деформировать в любом месте игры, напрямую изменяя память процесса. Нет DLL требуется!
вы ищете решение Ring3 тогда? Если это так, вы хотите создать дополнительную функциональность в системе, которая в настоящее время ( по крайней мере, насколько мне известно ) не предоставляется из коробки, поэтому это потребует некоторой работы. Кроме того, это возможно от драйвера, на самом деле большая часть вашего программного обеспечения AV регулярно выполняет этот вид деятельности.
Что касается остановки вышеуказанных методов из пользовательского режима, это становится немного сложнее, так как вы не можете просто зарегистрировать себя как обратный вызов для обработки создания или загрузки DLL. Однако вы можете, если вы предполагаете, что ваш процесс начался раньше их, подключить CreateRemoteThread и аналогичные функции по всему миру и выполнить этот тип проверки самостоятельно.
таким образом, вы хотели бы проверить, где CreateRemoteThread хочет создать поток и вернуть ошибку, если вы не довольны этим.
это отрицает первые два метода. Для третьего метода, если у вас есть допустимые хэши исходной программы на диске, тогда вы всегда можете проверить хэш перед загрузкой. Если у вас нет хэшей, вы можете хотя бы просто проверить некоторые из простых мест, где кто-то добавит этот тип кода и искать DLL, которые вы не ожидаете там (например, IAT или run strings).
Это не доказательство дурака, но, похоже, дает запрошенную вами функциональность.
Почему вы хотите предотвратить это? Это фактическая "бизнес" потребность, или вы просто заинтересованы в "хак", чтобы противостоять "Хак"
Если права пользователя позволяют это, это по дизайну-ОС предоставляет средство всем пользователям, которые вы, администратор системы назначил учетные записи, под которыми они работают.
Рэймонд Чен скоро будет связываться здесь.
просто краткие мысли для обсуждения :)
использование пещеры кода для ввода проверки CRC в ваш собственный код, возможно, замедлит использование других пещер кода.
Я не очень хорошо знаком с API Windows, но я могу дать вам несколько более обобщенных указателей:
Смотрите, можно ли использовать Windows Data Execution Prevention (DPE). Вероятно, это не сработает для всех (читай: большинства) ситуаций, потому что процесс, описанный в вашей ссылке, является допустимым процессом с точки зрения ОС. Защита в глубине, хотя
убедитесь, что ваши методы процесса утверждают разрешения безопасности на всем протяжении применение
фактор ваш код в драйвер устройства или какой-либо другой низкоуровневый тип процесса, который вы можете получить покрыты под зонтиком защиты файлов Windows.
только что видел ответ Ктулона (хорошее имя, кстати!) и я боюсь, что он, вероятно, прав: любой, кто хочет выполнить инъекцию кода в вашем приложении, найдет способ сделать это. Вышеприведенные шаги могут лишь усложнить задачу.
mq4 программе, так что с этим проблем нет. Осталось разобраться, как можно защитить dll файл от взлома.
Какие есть методы защиты кода в dll файле. Надо сделать так, чтобы dll работала, и при этом в нее нельзя было заглянуть постороннему лицу.
dll я пишу на C++.
А как можно заглянуть в Dll? Дизассемблером?
С потерей всех функций, переменных и логики?
Т.е. вопрос- это как защитить само бинарное выполнимое содержимое?
Или все-таки вопрос в том, как авторизовать доступ к выполнению Dll,
чтобы Dll у когото запускалась, а у кого-то- нет?
Например, есть декомпиляторы для файлов ex4. Аналогично и для dll, наверное. Должен сказать, что я начинающий C++ программист, и тему dll знаю поверхностно. Поэтому и спрашиваю: может более опытные коллеги чего-нибудь посоветуют.
Главный вопрос в том, как защитить спрятанный внутри код от копирования посторонними лицами. При этом dll должен работать в стандартном режиме, как обычный dll, т.е. из него можно вызывать ф-ии.
Совет очень простой: усердно учить матчасть, и до поры до времени не забивать себе голову надуманными проблемами.Например, есть декомпиляторы для файлов ex4. Аналогично и для dll, наверное. Должен сказать, что я начинающий C++ программист, и тему dll знаю поверхностно. Поэтому и спрашиваю: может более опытные коллеги чего-нибудь посоветуют.
Главный вопрос в том, как защитить спрятанный внутри код от копирования посторонними лицами. При этом dll должен работать в стандартном режиме, как обычный dll, т.е. из него можно вызывать ф-ии.
Всё зависит от прибыльности в месяц Вашего торгующего советника, причём в квадратичной пропорции:
1). при прибыльности -30% (минус 30 процентов в месяц) в месяц - можете ничего не делать для его защиты.
3). +0,1 % = экспортируемые функции назовите как-нибудь вычурно, вместо "correlation()" - "XCB34QRt()". Поставьте файерволл на комп, разрешите MT4 только 80 и 443 порты. Этого будет достаточно.
4). +1% = поместите весь метатрейдер на шифруемый диск-контейнер, например PGP или Jetico BestCrypt, убейте все геймы на компе, переустановите систему, поставьте приличный файерволл.
5). +2% = перепишите DLL чтобы она состояла из двух частей и части общались по протоколу TCP/IP, вторую часть поместите на отдельный шифрованный контейнер. Существуют программы-отладчики И ЛЮДИ, которые смогут понять как работает Ваша DLL - ка. Важным пунктом с этого момента является - нанять честного и опытного специалиста по безопасности, например AlexEro с форума MQL4.
6). +3% = купите отдельный сервер, на который поместите одну часть DLL-ки. Как и где его установить, и что на нём должно быть, я не могу здесь открыто писать, но при выполнении Вами п5 это не будет проблемой. Купите хардварный фаерволл.
7). +5% = застрахуйте свою жизнь, напишите завещание, наймите службу безопасности, подбирайте с лицами потупее, чтобы они не оказались хакерами. DLL-ка должна теперь состоять из 5-ти частей, две из них можете носить с собой на флешке.
Этот цикл статей посвящен VMProtect — одному из самых популярных
инструментов по защите программного обеспечения от анализа и взлома.
Введение
Идеального способа защиты программного обеспечения от несанкционированного использования и распространения не существует. Ни одна существующая система не обеспечит абсолютную защиту и не лишит потенциального взломщика самой возможности ее нейтрализации. Однако использование качественной и эффективной защиты может максимально усложнить процесс взлома программного продукта, более того, сделать взлом нецелесообразным с точки зрения потраченного на это времени и усилий. При создании защиты программного продукта могут преследоваться различные цели и решаться разнообразные задачи, однако основа любой схемы защиты — защита приложения от изучения, так как именно устойчивость к обратной инженерии определяет эффективность защиты в целом.
Изучение, взлом и защита программного обеспечения
Изучение программного продукта может осуществляться методом статического и/или динамического анализа. При статическом анализе разработка алгоритма взлома защиты производится на основе анализа результатов дизассемблирования или декомпиляции взламываемой программы. Динамический анализ чаще всего применяют при взломе программных продуктов, исполняемый код которых зашифрован или динамически изменяется, так как статический анализ подобных программ сопряжен с определенными трудностями.
Для динамического анализа взламываемую программу запускают в среде отладчика, при этом становится возможным контроль всех изменений, возникающих в процессе функционирования приложения. В процессе динамического анализа, используя режим отладки, производят пошаговое прохождение «защитных» алгоритмов программы, в частности алгоритмов проверки и генерации корректного регистрационного кода. Еще одним средством, применяемым при динамическом анализе, являются мониторы активности, отслеживающие обращение взламываемой программы к файлам, системным сервисам, портам и внешним устройствам.
Основным инструментом, применяемым для защиты приложений от взлома, являются программы-протекторы. Защита, реализуемая большинством протекторов, заключается в том, что они упаковывают и/или шифруют исходный исполняемый файл, уделяя основное внимание защите процедуры распаковки/расшифровки файла.
Подобный алгоритм работы протекторов очень часто оказывается причиной недостаточной степени защиты обеспечиваемой большинством из них. В случае если приложение защищено с использованием упаковки, по окончании работы распаковщика в распоряжении злоумышленника может оказаться исходный файл, который может быть получен при дампе определенной области памяти. Более того, для борьбы с самыми распространенными протекторами взломщики разработали множество программных инструментов, позволяющих взламывать защиту в автоматическом режиме. Аналогичный подход применяется при борьбе с шифрованием: после получения лицензионного ключа, который в том числе может быть легально приобретен, взломщик сможет расшифровать защищенные участки кода.
Ряд программ-протекторов применяют различные антиотладочные приемы. Однако применение антиотладки значительно снижает быстродействие программы. Также следует помнить, что антиотладочные приемы действенны лишь против динамического анализа и совершенно не эффективны против статического. Более того, все антиотладочные приемы, применяемые в современных протекторах, уже давно изучены, а взломщиками написано множество утилит, которые их полностью нейтрализуют. На эффективность использования мониторов активности встроенные в приложение средства защиты от отладки не влияют.
Более эффективными методами защиты приложения являются обфускация и виртуализация, усложняющие анализ кода защищаемого приложения. В общем случае эффективность данных методов достигается за счет использования особенностей человеческого фактора — чем сложнее исходный код, чем больше ресурсов использует приложение, тем человеку его анализирующему тяжелее понять логику работы программы, а следовательно, и взломать примененные средства защиты.
При обфускации производится запутывание кода приложения за счет введения дополнительных инструкций. При виртуализации исходный код преобразуется в байт-код, выполнение которого осуществляется на специальном интерпретаторе, имитирующем виртуальную машину со специфической системой команд. Следовательно, применение виртуализации приводит к высокой и неснижаемой степени запутанности результирующего кода, а при определенном подходе к реализации этого метода защищенный код не содержит методов восстановления оригинального кода в явном виде. Таким образом, важнейшим преимуществом виртуализации является то, что в момент выполнения виртуализированного участка кода не происходит его обратного преобразования в машинные коды процессора, а это исключает возможность получения взломщиком оригинального кода приложения.
Задача обратного инжиниринга виртуализированных фрагментов сводится к изучению архитектуры виртуальной машины, созданию дизассемблера, соответствующего архитектуре имитируемого виртуальной машиной процессора, и анализу дизассемблированного кода. При определенном подходе к реализации виртуальной машины задача создания дизассемблера виртуализированного кода становится достаточно трудоемкой. Единственным недостатком виртуализации является сравнительно низкая скорость работы, поэтому этот метод следует применять только для защиты участков кода, некритичных к скорости исполнения.
В подавляющем большинстве современных протекторов методы обфускации и виртуализации играют второстепенную роль, а уровень их реализации недостаточен, что позволяет взломщикам выполнять снятие подобной защиты в автоматизированном или ручном режиме. Еще одним слабым местом многих современных протекторов является использование недокументированных функций Windows, что создает ограничения для использования приложения в новых версиях операционной системы или при включенном режиме DEP.
Что такое VMProtect?
Программа VMProtect относится к новому поколению средств защиты программного обеспечения. VMProtect поддерживает компиляторы Delphi, Borland C Builder, Visual C/C++, Visual Basic (native), Virtual Pascal, при этом VMProtect содержит встроенный дизассемблер, позволяющий работать с файлами форматов EXE, DLL, BPL, OCX, SYS и подключать MAP-файл, создаваемый компилятором, для быстрого выбора участков кода, которые следует защитить. Для автоматизации операций по защите приложения в VMProtect реализован встроенный скриптовый язык. Программа VMProtect обладает полной поддержкой всех 32/64-разрядных операционных систем семейства Windows: Windows 95/98/ME, Windows NT, Windows 2000, Windows XP, Windows 2003, Windows Vista.
Базовым принципом, на основе которого построен VMProtect, является обеспечение эффективной защиты кода приложения от изучения, так как именно максимальное усложнение понимания логики работы внутренних механизмов защиты приложения создает максимальные трудности при взломе программы. Основными методами защиты программного кода, применяемыми VMProtect, являются виртуализация, мутация и смешанный метод защиты, сочетающий мутацию кода приложения с его последующей виртуализацией.
Одним из достоинств реализации метода виртуализации в программе VMProtect является то, что виртуальная машина, на которой выполняются виртуализированные фрагменты кода, встраивается в результирующий код защищаемого приложения. Следовательно, для функционирования приложения, защищенного с помощью VMProtect, нет необходимости использовать какие-либо дополнительные библиотеки или модули. VMProtect позволяет использовать несколько отличных друг от друга виртуальных машин для защиты разных участков кода одного приложения, что еще больше усложняет процесс взлома защиты, так как взломщику будет необходимо анализировать архитектуру уже нескольких виртуальных машин.
Метод мутации кода приложения, реализованный в VMProtect, основан на обфускации, в процессе которой в код приложения добавляются «мусорные» команды, «мертвый» код, случайные условные переходы, выполняется мутация оригинальных команд, а также выполнение ряда операций переносится в стек.
Ключевым отличием программы VMProtect от других протекторов является то, что с ее помощью можно защитить различные участки кода разными методами: часть кода виртуализировать, часть обфусцировать, а для самых критичных участков применить смешанный метод защиты.
Еще одной уникальной возможностью программы VMProtect является включение в код приложения водяных знаков, позволяющих однозначно идентифицировать официального владельца взломанного экземпляра программы, а следовательно, принять к нему соответствующие меры.
Всем привет, у меня есть dll мне нужно защитить данную dll от редакторов памяти таких как MegaDumper Cheat Engine и т.д Каким образом можно
это реализовать ?
Добавлено через 31 минуту
Чтобы dll не дампилась из памяти и ее не было видно к примеру в cheat engine
Помощь в написании контрольных, курсовых и дипломных работ здесь
Защита памяти процесса от редакторов памяти
Подскажите как можно написать программу которая смогла бы защитить память другого процесса от.
Профессионалы, как можно защитить созданную dll и exe?
Привет, может кто знает способы по защите dll, exe (x86,64) Например многие если не все компании.
Защитить от записи страницы памяти
Есть некая задачка где просят получить память под массив, установить некоторые значения, а потом.
Как выгрузить dll-ку из памяти?
Вопрос может не к этому форуму, но все равно спрошу. Делаю на delphi ActiveX-кую ddl-ку для ASP.
Бред, но скрыть ведь все равно можно! Вот каким образом сделать чтобы MegaDumper не мог вытащить dll из процесса? И не говорите , что нельзя или невозможно , т.к это можно реализовать и это уже реализовано, только на c++ и не мной.
Добавлено через 3 минуты
kolorotur, Либо блокировать запуск программ через dll
Был чит на раст легаси Миракле хак назывался и его не мог дампнуть программа Мега дампер и еще пару , но Cheat Engine видел dll как они это делали неизвестно.
Добавлено через 6 минут
netBool, или скачай раст легаси и скачай программу Rust Cheker и после запуска раста заспусти раст чекер открой список модулев и там не все dll видны используются к примеру dll system и ее он не видел. Каким образом?
Добавлено через 1 минуту
kolorotur, Блокировка тоже не подходит
Я вообще никогда не пользовался мега дампером. Сейчас все нормальные крякеры используют IDA PRO.
Теоретически (и практиески) можно написать софт, который будет прятаться от какой-то конкретной программы, например, той, что вы указали. Но таких программ сейчас не пересчесть.
Наиболее сложный и мощный способ, на мой взгляд, написать свой собственный dll загрузчик. Это тот самый случай, когда ты можешь сделать со своей dll все, что угодно, для защиты от посторонних глаз. (специально для тебя нашел ссылку). Так же можешь посмотреть для общего развития тыц и тыц
Читайте также: