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

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

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

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

А>1) Имея только .exe файл насколько успешно из него можно выделить алгоритм расчетов?
А>2) С точки зрения вопроса 1) есть ли принципиальная разница между Debug build и Release build в VS 2005?
А>3) Есть ли в настройках проекта в VS 2005 какие-то опции усложняющие процесс декомпиляции?
Нет. Это не задача компилятора.
А>4) Какие есть способы защиты программы от декомпилирования и где о них можно почитать?
Попробуй посмотреть на протекторы (средства защиты) которые используют виртуальную машину. Автор одного из них http://www.vmpsoft.com/ есть на рсдн http://www.rsdn.ru/Users/71243.aspx, думаю лучше него на такие вопросы вряд ли кто-то ответит.
Удачи!

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

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

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

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

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

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

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

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

SO>Попробуй посмотреть на протекторы (средства защиты) которые используют виртуальную машину. Автор одного из них http://www.vmpsoft.com/ есть на рсдн http://www.rsdn.ru/Users/71243.aspx, думаю лучше него на такие вопросы вряд ли кто-то ответит.
SO>Удачи!

Не подумайте что антиреклама и т.д. Проделано просто из любопытства — скачиваю демо-версию указаного "защитника", устанавливаю, запускаю. Мастер предлагает выбрать ".ехе" для защиты. Выбираю ".ехе" элементарный Дельфийский проект с пустой формой. Запаковываю. Ксати демо-версия позволяет защитить всего одну процедуру — "ЕнтриПойнт". Запускаю полученный ".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..." а просто скачает программу другого разработчика.

Debugger found это еще не так страшно, а вот какая-то из известных защит, используемых в игрушках, выдает сообщение типа "проверка диска не удалась" или что-то в этом духе, если запущен ProcessExplorer. А потом они еще удивляются, почему у всех стоит пиратский софт.

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

SC>Debugger found это еще не так страшно, а вот какая-то из известных защит, используемых в игрушках, выдает сообщение типа "проверка диска не удалась" или что-то в этом духе, если запущен ProcessExplorer. А потом они еще удивляются, почему у всех стоит пиратский софт.

За дебугер он почему-то принял "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 лет железных "шор" наверное. Или полное отсутствие защиты со стороны тех, кто должен бы нас защищать от воровста?
Наличие спроса на такие продукты (имхо).

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

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

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

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

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

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

Вот статейка http://www.codeproject.com/KB/security/AntiReverseEngineering.aspx

Здравствуйте, 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, или другом, компилируемом в С сорцы, потом посмотри, что за каша получится.

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

Из простого, я бы посоветовал размазывание кода, защиту от отладчика и проверка на целостность .exe модуля.
Особенно размазывание кода!
Полагаю, этого вполне достаточно.

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

А>Из простого, я бы посоветовал размазывание кода, защиту от отладчика и проверка на целостность .exe модуля.

Несколько раз уже проскакивало такое мнение, извините, но это некомпетентность.

Если хотите, реверс алгоритма в отладчике — это "грязная работа", и даже может быть не принята здравомыслящим заказчиком. Потому что это динамика и можно что-то пропустить. Чистый реверс "белого ящика" — когда оригинал запускается в самом конце, для сверки результата работы с уже полученным аналогом. И если кто-то тупо сдампит образ и засунет в IDA — то скорее от нецелессообразности (лени, экономии времени) писать статический распаковщик.

Кстати, поэтому, здесь

Автор:
Дата: 17.06.09

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

А>Особенно размазывание кода!

Что имеется ввиду, раскидать код алгоритма по исполняемому файлу? Болше пользы объявить все функции inline

А>Полагаю, этого вполне достаточно.