Есть ли хороший обфускатор для кода Perl?

Question

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

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

Answer 1

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

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

В данном случае похоже, что это действительно проблема лицензирования или контракта.Пусть у них будет открытый исходный код, но сделайте это частью лицензии, согласно которой любые отправленные ими изменения должны возвращаться к вам и утверждаться.Когда вы выпускаете патчи, проверяйте суммы md5 всего кода, и если они не соответствуют ожидаемым, это нарушает лицензию и с них будет взиматься соответствующая плата (и эта ставка должна быть намного, намного выше).(Я помню одну компанию, которая разрешила нам открыть исходный код, но дала понять, что если мы что-то изменим, мы «купят» код за 25 000 долларов, и они больше не несут ответственности за исправления ошибок или обновления, если мы не купим код. новая лицензия).

Answer 2

Не.Просто не надо.

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

Answer 3

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

Видеть Ответ perlfaq3 на вопрос «Как я могу скрыть исходный код моих программ на Perl? Больше подробностей.

Answer 4

Казалось бы, ваша главная проблема заключается в том, что клиенты изменяют код, что затрудняет его поддержку.Я бы посоветовал вам запрашивать контрольные суммы (md5,sha и т. д.) их файлов, когда они обращаются к вам за поддержкой, и аналогичным образом проверять контрольные суммы файлов при исправлении.Например, вы можете попросить клиента предоставить выходные данные предоставленной программы, которая проходит процедуру установки и проверяет контрольные суммы всех файлов.

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

Answer 5

В этом случае запутывание — неправильный подход.

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

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

Answer 6

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

Answer 7

Я согласен с предыдущими предложениями.

Однако, если вы действительно хотите, вы можете изучить номинальная стоимость и/или Фильтр::Крипто CPAN-модули.Вы также можете использовать их вместе.

Я использовал последний (Filter::Crypto) как очень легкую форму «защиты», когда мы поставляли наш продукт на оптических носителях.Он не «защитит» вас, но остановит 90% людей, которые захотят изменить ваши исходные файлы.

Answer 8

Это несерьезное предложение, однако взгляните на Акме::Баффи.

По крайней мере, это украсит ваш день!

Answer 9

Альтернативой обфускации является преобразование вашего скрипта в двоичный файл, используя что-то вроде Комплект разработчика Perl от ActiveState.

Answer 10

Я использую операционную систему Windows и использую perl2exe от IndigoSTAR.Полученный файл .EXE вряд ли будет изменен на месте.

Как говорили другие, «как мне это запутать» — неправильный вопрос.«Как мне запретить клиенту менять код» — правильный вариант.

Answer 11

Идеи контрольной суммы и контракта хороши для предотвращения «проблем», которые вы описываете, но если цена для вас — это трудности с развертыванием обновлений и исправлением ошибок, как ваши клиенты вносят изменения, которые не проходят проверку? комплексный набор тестов?Если они способны внести эти изменения (или, по крайней мере, внести изменения, которые отражают то, что они хотят от кода), почему бы просто не упростить/автоматизировать для них открытие заявки в службу поддержки и загрузку исправления?Клиент всегда прав о том, чего хочет клиент (они могут не иметь ни малейшего представления, как это сделать «правильно», но именно поэтому они вам платят.)

Лучшая причина для использования обфускатора — это развертывание настольных компьютеров на массовом рынке, где не у каждого клиента есть постоянный контракт.В таком случае что-то нравиться PAR - все, что упаковывает логику шифрования/обфускации в скомпилированный двоичный файл, является подходящим вариантом.

Answer 12

Как уже сказали несколько человек:не.

Учитывая природу интерпретатора Perl, в значительной степени подразумевается, что все, что вы делаете для запутывания Perl, должно быть отменено до того, как Perl получит это в свои руки, а это означает, что вам нужно оставить сценарий/двоичный файл деобфускации там, где находится интерпретатор. (и, следовательно, ваш клиент) может его найти :)

Устраните реальную проблему:контрольные суммы и/или соответствующим образом сформулированную лицензию.А сотрудники службы поддержки обучены говорить: «Вы это изменили?»мы применяем пункт 34b нашей лицензии, и это составит X 000 долларов, прежде чем мы его коснемся»....

Также читайте почему я должен использовать обфускацию для более общего ответа.

Answer 13

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

Не боритесь с этим, примите это.

Answer 14

Как говорит Овидий, это договорная, социальная проблема.Если они изменят код, они аннулируют гарантию.Берите с них высокую плату за исправление этой проблемы, но в то же время дайте им канал, по которому они смогут предлагать изменения.Кроме того, посмотрите, что они хотят изменить, и, если можете, внесите эту часть конфигурации.У них есть что-то, чем они хотят заняться, и пока вы не удовлетворите это желание, они будут продолжать пытаться вас обойти.

В Освоение Perl, Я немного говорю о победе над обфукаторами.Даже если вы делаете такие вещи, как создание бессмысленных имен переменных и тому подобное, такие модули, как Б::Депарс и B::Деобфускация, а также такие инструменты Perl, как Перл::Тиди, сделайте так, чтобы знающий и мотивированный человек мог легко получить ваш источник.Вам не придется так сильно беспокоиться о незнающих и немотивированных людях, потому что они все равно не знают, что делать с кодом.

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

Удачи,

Answer 15

Еще одно несерьезное предложение — использовать Акме::Блич, это сделает ваш код очень чистым ;-)