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

Question

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

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

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

См. ответ perlfaq3 на "Как я могу скрыть источник моих программ на Perl? для получения более подробной информации.

Answer 4

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

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

Answer 5

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

Однако, если вы действительно хотите, вы можете посмотреть на PAR и / или Filter :: Crypto CPAN. Вы также можете использовать их вместе.

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

Answer 6

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

Answer 7

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

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

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

Answer 8

Это не серьезное предложение, однако взгляните на Acme :: Buffy .

Это как минимум скрасит ваш день!

Answer 9

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

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

Answer 10

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

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