Сбросить код сборки i386 и перекомпилировать как PPC?

Question

Я использовал встроенную команду «otool» Apple с переключателями «-Vvtd», чтобы выгрузить двоичный файл Mach-O i386, перенаправленный в файл .s. Я безуспешно пытался использовать сборщики nasm и GAS для перекомпиляции кода на машине PPC («как» -библиотеку в каталоге i386 gcc/darwin и «as» -binary в каталоге ppc). Выход читает что-то вроде:

some_topmost_label: 
(__TEXT,__text) section 
_default_pager: 
00112000 pushl %ebp 
00112001 movl %esp,%ebp 
00112003 pushl %edi 
00112004 pushl %esi 
00112005 pushl %ebx 
00112006 subl $0x3c,%esp 
00112009 movl _default_pager_internal_count,%ebx 
0011200f addl _default_pager_external_count,%ebx 
00112015 leal 0x00000004(,%ebx,4),%ebx 

Существует раздел данных, а также, как происходит:

...

(__DATA,__data) section 
00421000 02 00 00 00 04 00 00 00 00 40 00 00 28 64 65 66 

...

00449bc0 50 00 3d 00 00 00 00 00 00 00 00 00 00 00 00 00 
00449bd0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 

.. .

Я намерен запустить двоичный в Mac на PPC, следовательно, перекомпиляция усилий; Я попытался удалить адреса в крайнем левом столбце, чтобы сделать синтаксис более «AT & T» -стилем, оставив их и т. Д. Я НЕ хочу делать какие-либо изменения в существующей структуре кода (это не совсем обратное проектирование усилие, как таковое, только некоторые настройки). Однако, если мне нужно сделать какое-либо редактирование, мне бы очень хотелось, чтобы это было строго для того, чтобы создать существующий, неподдельный код для запуска i386, как на PPC.

Я буду очень благодарен за вашу помощь.

С уважением

Answer 1

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

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

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

В случае декомпиляции: что, если он производит четверть миллиона строк кода? Вам может понадобиться команда :)

Answer 2

В языке ассемблера, каждый «заявление» является командой, которая может выполнить процессор. Инструкции представлены в текстовом формате, удобном для человека (если вы правильный человек), но все же, каждое имя инструкции (например, movl) и зарегистрировать (например, %esp) и ссылку на память (например, 0x00000004(,%ebx,4)), которая существует в сборке напрямую соответствует детализации реализации процессора.

Таким образом, каждый процессор имеет собственный язык ассемблера. Сбрасывание и повторная сборка никуда не денутся. Даже в составе связанных процессоров - если вы возьмете 32-разрядный x86-код, который был скомпилирован, оптимизация SSE3 включена и выгрузите его, у вас будет код сборки с инструкциями SSE3. Повторная сборка не принесет вам программы, которые могут работать на немного более старом процессоре x86-32.

Возможно, у вас будет шанс, если ваш исполняемый файл достаточно стар, что это "fat binary". В период, когда Mac и PPC поддерживались Apple, они собирали скомпилированный код PPC и x86 вместе в одном файле. Судя по this answer, вы можете обнаружить живые двоичные файлы командой file.

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

КПП не имеет инструкции movl (или любого другого вида mov - он обрабатывает грузы и магазины отдельно). У него нет специального регистра стека, такого как %esp, хотя r1 - это безопасная ставка. Он не имеет ничего подобного режиму адресации в 0x00000004(,%ebx,4) - это регистр, который умножается на 4, а затем добавляет константу 4 - в PPC вам придется загрузить константу в другой регистр с одной инструкцией, а затем сдвинуть (*4 = <<2) регистр в другой инструкции, затем добавьте эти промежуточные результаты вместе в третьей инструкции. Дело не в том, написаны ли инструкции в «исходной форме» или «двоичной форме».Это относится к инструкциям в исходном коде , не существующим вообще на PPC.