Обратный инженер "скомпилировал" Perl vs. C?

Question

Иметь клиента, который утверждает, что соблюдается C, сложнее для обратного инжиниринга, чем sudo "скомпилированный" байт-код Perl или тому подобное. У кого-нибудь есть способ доказать или опровергнуть это?

Answer 1

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

Самое уродливое в коде обратного проектирования c состоит в том, что компиляция удаляет всевведите информацию.Это полное отсутствие имен и типов является самой худшей частью ИМО.В динамически типизированном языке компилятор должен сохранять гораздо больше информации об этом.В частности, имена полей / методов / ..., поскольку это обычно строки, для которых невозможно найти любое применение.

Существует множество других уродливых вещей.Например, оптимизация всей программы с использованием разных регистров для передачи параметров каждый раз.Функции, которые встроены так, что одна простая функция появляется во многих местах, часто в несколько ином виде из-за оптимизации.

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

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

Answer 2

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

Answer 3

Perl действительно легко реверс-инженер .Инструментом выбора является vi, vim, emacs или notepad.

Answer 4

C сложнее декомпилировать, чем скомпилированный байтовый код Perl.Любой код Perl, который был скомпилирован байтами, может быть декомпилирован.Байт-скомпилированный код не является машинным кодом, как в скомпилированных программах на Си.Некоторые другие предложили использовать методы обфускации кода.Это всего лишь уловки, которые затрудняют чтение кода и не влияют на сложность декомпиляции исходного кода Perl.Декомпилированный источник может быть сложнее для чтения, но есть много доступных инструментов для удаления обфускации Perl и даже модуль Perl:

http://metacpan.org/pod/B::Deobfuscate

Программы упаковки Perl, такие как Par, PerlAPP или Perl2exe win 'Не предлагать защиту исходного кода либо.В какой-то момент источник должен быть извлечен, чтобы Perl мог выполнить скрипт.Даже упаковщики, такие как PerlAPP и Perl2exe, которые пытаются использовать некоторые методы шифрования в исходном коде, могут быть побеждены с помощью отладчика:

http://www.perlmonks.org/?displaytype=print;node_id=779752;replies=1

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

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

Answer 5

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

Для мотивированного реверс-инженера оба будут одинаковыми.

Если вы используете псевдо-исполняющие программы, такие как perl2exe, тогда будет легче «декомпилировать», чем скомпилированный C, поскольку perl2exe вообще не компилирует perl, он просто немного «скрыт» (см. http://www.net -security.org/vuln.php?id=2464; это действительно старая, но концепция, вероятно, все та же (я не исследовал, поэтому не знаю наверняка, но я надеюсь, что вы поняли мою точку зрения) )

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

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

Эти 4 должны усложнить (но опять же не невозможно) ...

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

[2] Цепочка нескольких (разных) обфускаторов кода в исходном коде как часть процесса сборки.

[3] Примените защитный ключ для программного обеспечения, который предотвратит выполнение кода, если ч / б отсутствует, это будет означать, что физический доступ к данным ключа требуется до того, как может произойти остальная часть обращения: http://en.wikipedia.org/wiki/Software_protection_dongle

[4] Всегда есть защитники (например, Themida http://www.oreans.com/themida.php), которые вы можете получить, которые смогут защитить .exe после его сборки (независимо от того, как он был скомпилирован).

... Это должно дать реверсеру достаточно головной боли.

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

Короче говоря: оба метода одинаково небезопасны. Если вы не используете некомпилирующее средство создания perl-to-exe, в этом случае победит нативный скомпилированный EXE-файл.

Надеюсь, это поможет.

Answer 6

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

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