Как защитить exe файл от декомпиляции

Обновлено: 06.07.2024

Здравствуйте, Аноним, Вы писали:

А>3) Есть ли в настройках проекта в VS 2005 какие-то опции усложняющие процесс декомпиляции?
А>4) Какие есть способы защиты программы от декомпилирования и где о них можно почитать?

Если не защищать программу протекторами, то следующее влияет на последующую сложность или простоту декомпиляции:
1. Если включен RTTI — атакующий сможет найти имена классов. Лучше выключить.
2. Если включена линковка со стандартными библиотеками в виде DLL — он легко найдет имена стандартных функций. Тоже выключать, все собирать со static libraries.

А>2. Если включена линковка со стандартными библиотеками в виде DLL — он легко найдет имена стандартных функций. Тоже выключать, все собирать со static libraries.
Самообман. IDA имеет сигнатуры на функции стандартной библиотеки.

Здравствуйте, Аноним, Вы писали:

А>Самообман. IDA имеет сигнатуры на функции стандартной библиотеки.

Ещё у них (IDA) есть плагин (Hex-Rays Decompiler) позволяющий получить вполне читабельный cpp сорец. А запакованные exe легко просматриваются в распакованом виде (и сбрасываются в дамп) обычным WinHex. Так что скрыть алгоритм от "пытливого глаза" весьма не просто. Мне кажется, надо исходить из того факта что через какое то время ваш алгоритм просто устареет, появятся новые, делающие задачу лучше, да ещё и с открытым кодом и затраты больших сил на защиту просто бессмыслены. Лучше приложить силы на получение прибыли от вашего продукта (или продукта использующего этот алгоритм) сегодня, пока он актуален.

Не подумайте что антиреклама и т.д. Проделано просто из любопытства — скачиваю демо-версию указаного "защитника", устанавливаю, запускаю. Мастер предлагает выбрать ".ехе" для защиты. Выбираю ".ехе" элементарный Дельфийский проект с пустой формой. Запаковываю. Ксати демо-версия позволяет защитить всего одну процедуру — "ЕнтриПойнт". Запускаю полученный ".vmp.exe". Вижу вместо своей проги мессадж "A debbuger has been found in your system . и т.д". Ставлю себя на место пользователя, использующего мою прогу защищённую подобным "шифровальщиком". Боюсь он не будет разбираться, что там у него "found in your system. " а просто скачает программу другого разработчика. А я буду сидеть чесать репу — как бы мне ещё круче защитить свой алгоритм. Вы ни когда не узнаете, какие антивири, дебагеры, виртуальные машины типа VMWare сидять у пользователя в трее, а посему после защиты программы всегда будет вылазить вопрос совместимости с ними. Те же разработчики антивирей всегда идут впереди разработчиков защит, и корректируют реакцию антивиря на определённый протектор лишь после появления фактов несовместимости.
Так что лично я остерегусь от использования подобных "протекторов". Вообще то почемуто бизнес подобных "протекторов" сильно развит лишь в России. Какая то маниакальная боязнь чужих глаз. Последствия

70 лет железных "шор" наверное. Или полное отсутствие защиты со стороны тех, кто должен бы нас защищать от воровста?

Здравствуйте, <Аноним>, Вы писали:

А>Есть проект, написанный на C++ с использованием MFC и не содержащий managed кода. Есть желание продать одну из версий данного проекта без раскрытия исходников. Ценность исходников не в конкретной реализации на C++, а в алгоритме расчетов, который заложен в программе. Алгоритм весьма нетривиальный (нелинейное преобразование массивов). Соответственно, именно алгоритм хочется сохранить в тайне. Я не знаком с реверс-инжинирингом, дизассемблированием и декомпиляцией, поэтому слабо представляю их возможности. В связи с этим несколько вопросов:

А>1) Имея только .exe файл насколько успешно из него можно выделить алгоритм расчетов?
Вопрос в скилах и деньгах. IDA + Hex Rays в умелых руках творят чудеса.
Но думается что нетривиальный алгоритм (особенно если там много чего заинлайнится) расковырять будет достаточно трудно.
Суть любой защиты в том, чтобы взлом обошелся сильно дороже чем легальная покупка.

А>2) С точки зрения вопроса 1) есть ли принципиальная разница между Debug build и Release build в VS 2005?
Есть

А>3) Есть ли в настройках проекта в VS 2005 какие-то опции усложняющие процесс декомпиляции?
В общем то нет.

А>4) Какие есть способы защиты программы от декомпилирования и где о них можно почитать?
Протектор.
Сходи на форум Shareware — будет сильно полезно по всем пунктам.

Здравствуйте, butcha, Вы писали:

B>Не подумайте что антиреклама и т.д. Проделано просто из любопытства — скачиваю демо-версию указаного "защитника", устанавливаю, запускаю. Мастер предлагает выбрать ".ехе" для защиты. Выбираю ".ехе" элементарный Дельфийский проект с пустой формой. Запаковываю. Ксати демо-версия позволяет защитить всего одну процедуру — "ЕнтриПойнт". Запускаю полученный ".vmp.exe". Вижу вместо своей проги мессадж "A debbuger has been found in your system . и т.д". Ставлю себя на место пользователя, использующего мою прогу защищённую подобным "шифровальщиком". Боюсь он не будет разбираться, что там у него "found in your system. " а просто скачает программу другого разработчика.

. << RSDN@Home 1.2.0 alpha rev. 685>>

За дебугер он почему-то принял "VMWare Player", которым я не пользуюсь уже пол года, и забыл за него, но установленный им сервис "VMware Network Adapter VMnet1" понятное дело запускается. Но то что "VMWare Player" это "debugger" для меня, конечно, открытие.

> 1) Имея только .exe файл насколько успешно из него можно выделить
> алгоритм расчетов?

Практически невозможно.

> 2) С точки зрения вопроса 1) есть ли принципиальная разница между Debug
> build и Release build в VS 2005?

Да, есть. В Release производится оптимизация, которая делает реверс
инжиниринг ещё более невозможным.

> 3) Есть ли в настройках проекта в VS 2005 какие-то опции усложняющие
> процесс декомпиляции?

нет (кроме оптимизации, лучше глобальной).

> 4) Какие есть способы защиты программы от декомпилирования и где о них
> можно почитать?

Я думаю, что ничего особенно делать не надо.

Аноним 972 wrote:
> 2. Если включена линковка со стандартными библиотеками в виде DLL — он
> легко найдет имена стандартных функций. Тоже выключать, все собирать со
> static libraries.

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

Здравствуйте, butcha, Вы писали:

B>Не подумайте что антиреклама и т.д. Проделано просто из любопытства — скачиваю демо-версию указаного "защитника", устанавливаю, запускаю. Мастер предлагает выбрать ".ехе" для защиты. Выбираю ".ехе" элементарный Дельфийский проект с пустой формой. Запаковываю. Ксати демо-версия позволяет защитить всего одну процедуру — "ЕнтриПойнт". Запускаю полученный ".vmp.exe". Вижу вместо своей проги мессадж "A debbuger has been found in your system . и т.д".
Предполагаю (априорно), что если покрутить настройки, то можно отключить проверки на наличие отладчика. А вообще — безусловно, пакость.
Тем не менее, если такая софтина значительно усложняет реверс-инженеринг алгоритма, то ее можно рассматривать как решение проблемы.

B>Так что лично я остерегусь от использования подобных "протекторов". Вообще то почемуто бизнес подобных "протекторов" сильно развит лишь в России. Какая то маниакальная боязнь чужих глаз. Последствия

70 лет железных "шор" наверное. Или полное отсутствие защиты со стороны тех, кто должен бы нас защищать от воровста?
Наличие спроса на такие продукты (имхо).

Да ладно вам — небольшая бага в демке, о который мы уже знаем

По поводу "почему только EntryPoint" — читайте русский хелп раздел "Работа с VMProtect" — "Подготовка проекта".

Здравствуйте, Аноним, Вы писали:

А>Есть проект, написанный на C++ с использованием MFC и не содержащий managed кода. Есть желание продать одну из версий данного проекта без раскрытия исходников. Ценность исходников не в конкретной реализации на C++, а в алгоритме расчетов, который заложен в программе. Алгоритм весьма нетривиальный (нелинейное преобразование массивов). Соответственно, именно алгоритм хочется сохранить в тайне. Я не знаком с реверс-инжинирингом, дизассемблированием и декомпиляцией, поэтому слабо представляю их возможности. В связи с этим несколько вопросов:
А>1) Имея только .exe файл насколько успешно из него можно выделить алгоритм расчетов?
А>2) С точки зрения вопроса 1) есть ли принципиальная разница между Debug build и Release build в VS 2005?
А>3) Есть ли в настройках проекта в VS 2005 какие-то опции усложняющие процесс декомпиляции?
А>4) Какие есть способы защиты программы от декомпилирования и где о них можно почитать?

Здравствуйте, MasterZiv, Вы писали:

MZ>Так и пусть себе найдёт, чем это страшно-то ? что твоя программа будет
MZ>использовать стандартные функции, это и так всем понятно.

Просто становится легче отсеять громадное количество кода стандартных библиотек, от реально полезного кода. Так же, это дает некое условное понимание, что делает конкретный кусок программы, ведь человек при разработке выделяет какие-то абстракции, в соответствии с ними создает функции/модули, а там многое становится понятно.

Виртуальные машины сложно дебажить, а точнее даже реверс инженерить, т.к. нет таких интеллектуальных сред как IDA, да и сама логика программы становится зависимой от данных, которые могут быть динамическими. Распутывание этого «спагетти» может оказаться непосильной задачей.

Я бы посоветовал автору программы:
1. Незапариваться с сильной защитой. Достаточно, чтоб требовала ключик и все. Все равно если надо сломать — сломают.
2. Сконцентрироваться на качестве программы и ее развитии на будущее, чтобы когда выбирая между Вашей программой и программой конкурентов — выбор был очевиден.

Здравствуйте, MasterZiv, Вы писали:

>> 1) Имея только .exe файл насколько успешно из него можно выделить
>> алгоритм расчетов?

MZ>Практически невозможно.

>> 2) С точки зрения вопроса 1) есть ли принципиальная разница между Debug
>> build и Release build в VS 2005?

MZ>Да, есть. В Release производится оптимизация, которая делает реверс
MZ>инжиниринг ещё более невозможным.

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

Здравствуйте, <Аноним>, Вы писали:

А>3) Есть ли в настройках проекта в VS 2005 какие-то опции усложняющие процесс декомпиляции?

Оптимизация, но особого эффекта не жди.

А>4) Какие есть способы защиты программы от декомпилирования и где о них можно почитать?

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

Традиционный вариант, как уже предлагали — использовать виртуализатор кода (не путать с "просто протекторами", которые результата не дадут).

Является ли этот метод эффективным?

спросил(а) 2011-07-31T07:08:00+04:00 10 лет, 3 месяца назад

Единственный хороший способ предотвратить перепроектировку программы ( "понял" ) - это пересмотреть ее структуру, чтобы существенно заставить противника понять Тьюринговые машины. По существу, вы делаете следующее:

Теперь противник, смотрящий на ваш код, должен понять, что такое "правильное" вычисление, решая алгоритмически сложные проблемы. Там тонны NP-жестких проблем, которые никто не решал эффективно в литературе за 40 лет; это довольно хорошая ставка, если ваша программа зависит от одного из них, что J. Random Reverse-Engineer не сможет внезапно решить их.

Как правило, это происходит путем преобразования исходной программы, чтобы скрыть ее поток управления и/или поток данных. Некоторые методы скремблируют поток управления путем преобразования некоторого потока управления в поток данных ( "косвенный переход через этот массив указателей" ), а затем реализуют алгоритмы потока данных, которые требуют точного анализа точек, что является как доказуемо трудным, так и доказало свою сложность в практика.

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

Если вы настаиваете на предотвращении декомпиляции, вы можете атаковать это, рассматривая, какую цель должна выполнить декомпиляция. Декомпиляция существенно предполагает, что вы можете преобразовать каждый байт целевой программы в некоторый фрагмент кода. Один из способов сделать этот сбой - обеспечить, чтобы приложение, по-видимому, могло использовать каждый байт
как как компьютерные инструкции, так и как данные, даже если на самом деле это не так, и что решение сделать это обфускается вышеупомянутыми видами методов. Один из вариантов заключается в том, чтобы иметь множество условных ветвей в коде, которые на самом деле безусловны (с использованием методов обфускации потока управления); другая сторона ветки попадает в бессмысленный код, который выглядит действительным, но вступает в сумасшедшие места в существующем коде. Другой вариант этой идеи - реализовать вашу программу как запутанный интерпретатор и реализовать фактическую функциональность в виде набора интерпретируемых данных.
Увлекательный способ сделать это неудачным - сгенерировать код во время выполнения и выполнить его на лету; большинство обычных языков, таких как C, практически не могут представить это.

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

Эффективен ли этот метод?

3 ответа

У меня есть программа, которая подключается к SqlServer по заранее заданному имени пользователя & паролю. Экс: static void Main(string[] args) < string UserName, Password; UserName = Name; Password = Pass; SqlConnection conn = new SqlConnection(. ); >Как защитить пароль от декомпиляции?

Предполагается, что после того, как exe будет собран, никто не сможет выкопать oi-выходы исходного кода или приложения, но после просмотра Возможно ли "decompile" а Windows. exe? Или хотя бы посмотреть Assembly? мое предположение неверно. Тогда как же защитить наш проект VS, если вся.

Единственный хороший способ предотвратить обратное проектирование программы ("understood")-это пересмотреть ее структуру, чтобы по существу заставить оппонента понять машины Тьюринга. По сути, то, что вы делаете, это:

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

Теперь противник, уставившийся на ваш код, должен выяснить, что такое вычисление "correct", решая алгоритмически сложные задачи. Есть тонны NP-сложных проблем, которые никто не решал эффективно в литературе за 40 лет; это довольно хорошая ставка, если ваша программа зависит от одной из них, что случайный реверс-инженер внезапно не сможет их решить.

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

Теперь можно было бы пройти через множество проблем, чтобы предотвратить декомпиляцию программы. Но если бы декомпилированный был невозможен для понимания, вы просто могли бы не беспокоиться; именно такой подход я бы выбрал.

Если вы настаиваете на предотвращении декомпиляции, вы можете атаковать это, рассмотрев, для чего предназначена декомпиляция. Декомпиляция по существу предполагает, что вы можете преобразовать каждый байт целевой программы в некоторый фрагмент кода. Один из способов сделать это неудачным-убедиться, что приложение, по-видимому, может использовать каждый байт как в качестве компьютерных инструкций, так и в качестве данных, даже если на самом деле это не так, и что решение об этом запутывается вышеуказанными методами. Одним из вариантов этого является наличие большого количества условных ветвей в коде, которые на самом деле являются безусловными (с использованием методов запутывания потока управления); другая сторона ветви попадает в бессмысленный код, который выглядит допустимым, но ветвится в сумасшедшие места в существующем коде. Другой вариант этой идеи-реализовать вашу программу как запутанный интерпретатор и реализовать фактическую функциональность в виде набора интерпретируемых данных. Интересный способ сделать это неудачным-сгенерировать код во время выполнения и выполнить его на лету; большинство обычных языков, таких как C, практически не имеют возможности представить это.

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

Упаковка, сжатие и любые другие методы двоичной защиты будут только мешать или замедлять изменение вашего кода, они никогда не были и никогда не будут безопасными решениями 100% (хотя маркетинг некоторых из них заставил бы вас поверить в это). Вам в основном нужно оценить, с каким уровнем хакера вы сталкиваетесь, если они являются детьми-сценаристами, то любой упаковщик, требующий реальных усилий и навыков (ie:those, которым не хватает распаковки scripts/programs/tutorials), будет сдерживать их. Если вы сталкиваетесь с людьми, обладающими навыками и ресурсами, вы можете забыть о том, чтобы сохранить свой код в безопасности (как говорится во многих комментариях: если OS может прочитать его, чтобы выполнить его, то и вы можете, это займет немного больше времени). Если вас беспокоит не столько ваш IP, сколько безопасность того, что делает ваша программа, то вам, возможно, будет лучше перепроектировать ее таким образом, чтобы она не могла быть атакована даже с исходным кодом (chrome использует этот подход).

Декомпиляция всегда возможна. Заявление

Эта угроза может быть устранена для расширения путем упаковки/сжатия исполняемого файла(.exe).

на вашем связанном сайте-это явная ложь.

Как я могу защитить свое приложение delphi от декомпиляции? Я знаю, что есть некоторые программы, такие как themida, которые, как мне кажется, сделают это, но тогда защищенный exe запускает антивирус.

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

3 ответа

Единственный хороший способ предотвратить реинжиниринг ("понимание") программы - это пересмотреть ее структуру, чтобы заставить противника понять машины Тьюринга. По сути, что вы делаете:

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

Теперь оппонент, смотрящий на ваш код, должен выяснить, что такое "правильное" вычисление, решая сложные алгоритмически задачи. Существует множество непростых задач, которые никто не смог эффективно решить в литературе за 40 лет; довольно хорошая ставка, если ваша программа зависит от одного из них, что J. Random Reverse-Engineer не сможет внезапно решить их.

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

Теперь можно избежать многих проблем, чтобы предотвратить декомпиляцию программы. Но если декомпилировать было невозможно понять, вы просто не могли бы беспокоиться; такой подход я бы выбрал.

Если вы настаиваете на предотвращении декомпиляции, вы можете атаковать ее, подумав, для чего предназначена декомпиляция. Декомпиляция, по сути, предполагает, что вы можете конвертировать каждый байт целевой программы в некоторый фрагмент кода. Один из способов избежать этой ошибки - убедиться, что приложение, очевидно, может использовать каждый байт как в качестве компьютерных инструкций, так и в качестве данных, даже если на самом деле этого не происходит, и что решение сделать это запутано вышеуказанными методы. Один из вариантов этого заключается в том, чтобы в коде было много условных ветвей, которые на самом деле являются безусловными (с использованием методов обфускации потока управления); другая сторона ветки попадает в бессмысленный код, который выглядит допустимым, но ветвится в сумасшедших местах существующего кода. Другим вариантом этой идеи является реализация вашей программы в качестве запутанного интерпретатора и реализация фактической функциональности в виде набора интерпретируемых данных. Интересный способ сделать это - генерировать код во время выполнения и выполнять его на лету; большинство обычных языков, таких как C, практически не могут это представить.

Программу, созданную таким образом, было бы трудно декомпилировать, не говоря уже о том, чтобы понять это после факта

Читайте также:

Как защитить exe файл от декомпиляции

3 ответа

Похожие вопросы:

3 ответа