Кодирует старый проектор Director на OS X 10.13 - возможно, манипулирует значением сегмента __LINKEDIT

Question

(См. Обновления в конце этого поста)

По причинам, связанным с $, мне нужно присвоить код старому проектору Director, который мы больше не можем повторно публиковать (нет доступа к исходному исходному коду или Director).

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

Но... если я cd в Projector.app содержимое (на самом деле это не называется, но вы поняли идею) и найдите двоичный проектор внутри Contents/MacOS/ и запустить этот двоичный файл из терминала, приложение запускается и работает нормально, как только он распаковывает (предположительно) прикрепленный архив в конце двоичного файла...

/BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Common/ChunkCompression.cpp:50: Error: unsupported compressor 8
/BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Libraries/CompressData/CompressData.c:353: Error: Unknown compression scheme encountered for file '/System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/Exceptions.plist'
/BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Common/ChunkCompression.cpp:50: Error: unsupported compressor 8
/BuildRoot/Library/Caches/com.apple.xbs/Sources/AppleFSCompression/AppleFSCompression-96.30.2/Libraries/CompressData/CompressData.c:353: Error: Unknown compression scheme encountered for file '/System/Library/CoreServices/CoreTypes.bundle/Contents/Library/AppExceptions.bundle/Exceptions.plist'
271 blocks
1120 blocks
274 blocks
136 blocks
255 blocks
120 blocks
1487 blocks
575 blocks
1128 blocks
570 blocks
104 blocks
2042 blocks
4889 blocks
677 blocks
388 blocks
363 blocks
700 blocks
23010 blocks

...app opens and runs correctly at this point

Я не могу просить наших пользователей сделать это (они очень нетехнические), поэтому я предполагаю, что приглашение "Где находится..." является некоторым аспектом OS X Gatekeeper, и, следовательно, я надеюсь, что Подписание двоичного файла сделает его снова запускаемым по клику.

Когда я пытаюсь и подписать двоичный код App.app/Contents/MacOS/projector Я получил:

main executable failed strict validation

Настройка --no-strict Опция CoSignign дает немного больше деталей:

the __LINKEDIT segment does not cover the end of the file (can't be processed)

Я думаю, это потому, что проектор Director - это двоичный файл со связанным архивом, который содержит остальные ресурсы приложения, добавленные в конец исполняемого файла. Некоторые поиски в Google показывают, что другие проекты имеют похожие проблемы со своими встроенными ресурсами.

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

Итак, теперь, открыв двоичный файл в MachOView:

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

Обновление 1 - в ответ на ответ Kamil.S

Я пытался настроить File Size значение в сегменте __LINKEDIT, так что это + File Offset совпадает с реальным двоичным файлом (я пробовал несколько раз; вам действительно нужно изменить VM Size быть таким же значением, как File Size или вы получаете Killed: 9 ОС. То же самое происходит, если вы установите File Size быть общим размером двоичного файла), но без удачи. С новым File Size а также VM Size значения, я все еще могу запустить двоичный файл, но я не могу кодировать его; Однако я получаю немного другое сообщение об ошибке:

file not in an order that can be processed (link edit information does not fill the __LINKEDIT segment)

Обновление 2 - https://github.com/pyinstaller/pyinstaller/wiki/Recipe-OSX-Code-Signing содержит более подробную информацию по той же проблеме:

PyInstaller нарушает подпись кода OSX, потому что он добавляет код Python в конце двоичного файла. Добавление данных в конце исполняемого файла нарушает структуру формата Mach-o. codesign Утилита жалуется со следующими сообщениями.

the __LINKEDIT segment does not cover the end of the file (can't be processed)

file not in an order that can be processed (link edit information does not fill the __LINKEDIT segment)

• Исправлено __LINKEDIT - размер файла (смещение + размер файла == exe-размер), размер виртуальной машины - такой же, как "размер файла"

• Fix LC_SYMTAB - Размер таблицы строк - последние данные в файле mach-o (смещение + размер = размер exe в файловой системе) - Данные, добавленные к исполняемому файлу, будут частью таблицы строк (последний раздел данных в файле Mach-O).).

Я посмотрю на исправление LC_SYMTAB чтобы увидеть, поможет ли это.

Answer 1

__LINKEDIT"s File Offset + File Size должен быть равен физическому размеру исполняемого файла. Вы можете повозиться с File Size в MachOView дважды щелкнув значение, отредактировав его и сохранив - исполняемый файл должен быть в порядке. Просто не трогай File Offset потому что это определенно будет тормозить.

Answer 2

DIrector использует схему, широко используемую в Windows, которая называется "Перегрузка". Я прилагаю некоторые данные в конце физического файла, но за пределами размера исполняемого образа. Этот подход не поддерживается с файлами Mach-O. Физическое изображение должно заканчиваться последним байтом, покрываемым сегментом LINKEDIT, и даже порядок элементов внутри сегмента LINKEDIT четко определен. Причиной для этого была предварительная привязка в прошлом, теперь это кодирование.

Добавленные данные - это начальный каталог DIR/DXR, который требуется загрузить первым. Я думаю, это было исправлено позже, добавив DIR/DXR в комплект приложений. Но я больше не в директоре, поэтому я не уверен в этом.

Answer 3

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

Я не думаю, что подписание двоичного файла приложения само по себе решит эту проблему и предотвратит рандомизацию пути ОС. Пользователь должен либо переместить приложение в другой каталог после его извлечения, либо вам нужно распространить приложение в образе диска, который был подписан вашим сертификатом ID разработчика. DropDMG (ссылка из поста выше) может создавать подписанные образы дисков, которые, возможно, стоит попробовать.