Замените статические символы в двоичном файле MacOS Mach-O внешними символами - PullRequest
Новая
       21

Замените статические символы в двоичном файле MacOS Mach-O внешними символами

1 голос
/ 04 июля 2019

У меня есть следующий сценарий:

  • Запатентованная игра для MacOS, которая статически связывает графическую среду MoltenVK в основной двоичный файл Mach-O x86-64.
  • Версия MoltenVK, связанная с, очень старая.
  • У меня есть более новая версия MoltenVK в форме .dylib (вместе с более новыми версиями компилятора SPIRV, libVulkan и т. Д., Если они необходимы, также в форме dylib).
  • Старая и более новая версия MoltenVK совместимы с ABI, то есть экспортируемый символ имена и подписи функций должны быть идентичны старой и новой версии MoltenVK.

И основная причина этого путешествия в связи с MacOS:

  • Игра не работает правильно на моей версии macOS (10.15 Catalina Beta 3). Я изолировал проблему с MoltenVK из-за обратной трассировки.
  • Я хочу проверить, решит ли обновление MoltenVK проблему, как временный обходной путь, так и для того, чтобы помочь разработчикам изолировать проблему.

Можно ли заставить двоичный файл использовать версию символов, определенных в динамически загруженном .dylib, вместо версии, определенной в самом двоичном файле? Я хочу пропатчить всех символов, доступных в каждой из .dylib s, которые у меня есть, потому что, вероятно, он сломался бы, если бы я пропатчил только некоторые символы, но не другие (предположительно, MoltenVK работает, только если код каждого символа в каркас от той же версии MoltenVK).

Примечание: я не могу перекомпилировать основной двоичный файл Mach-O игры, потому что у меня нет исходного кода. Я готов обойти меры безопасности в моей локальной системе, чтобы сделать это, если это вообще возможно; В любом случае, я принимаю на себя риск совершения опасных действий во время работы бета-версии (непроизводственной) ОС.

Я бы предпочел, чтобы ответы и комментарии были сосредоточены на техническом решении поставленного вопроса, но если потребуется дополнительное обоснование, я стараюсь как можно быстрее изолировать эту проблему, чтобы дать разработчикам игры как можно больше времени для исправить это до окончательного выпуска MacOS 10.15. Если я молчу, у проблемы есть шанс, что она не будет обнаружена; тогда люди обновятся до финальной версии macOS 10.15 и заметят, что игра не работает. Это никому не интересно, потому что тогда мы должны либо оставаться на Мохаве, и ждать, пока разработчик игры обновит их игру, либо обходиться без игры, возможно, недели или месяцы.

1 Ответ

1 голос
/ 04 июля 2019

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

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

  1. написание разговора с использованием тандема dlopen & dlsym. Вы все равно нужны символы dlopen & dlsym, уже используемые в двоичном файле (они являются частью libSystem aka C std lib, но вам все еще нужны выделенные коды операций dyld чтобы иметь возможность фактически использовать их). В конце концов вам нужно будет поместить коды операций сборки где-нибудь в двоичном формате, чтобы все работало. Это будет довольно сложно .
  2. включение lldb отладчика, подготовка адресов dlsym для вызова вручную и исправление двоичного файла на лету для каждого вызова (для этого вам, вероятно, потребуются разрешения на запись в сегменте __TEXT, но это легко часть). Если вы знаете, что делаете, возможно, это самый выполнимый подход . Основным недостатком является его нестабильность, если вы сломаете что-то, вы начнете с нуля.
  3. Добавить команду LC_LOAD_DYLIB в двоичные и dyld операционные коды, на которые ссылается LC_DYLD_INFO_ONLY, это будет super hard

В любом случае ваши лучшие друзья - Hopper дизассемблер и MachOView для проверки двоичного файла.

Элементарное знание сборки x86 (и / или x86-64) является обязательным для . Я думаю, что игра с оригинальным исходным кодом может быть более жизнеспособным вариантом.

...