2

（请参阅本文末尾的更新）

出于 $reasons 的原因，我需要对一个旧的 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-strictcodesign 选项提供了更多细节：

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

我认为这是因为 Director 投影仪是一个二进制文件，带有一个包含应用程序其余资源的捆绑存档，附加到可执行文件的末尾。一些谷歌搜索显示其他项目的嵌入式资源也存在类似问题。

我尝试使用macho_edit来查看是否可以修改二进制文件，但没有任何乐趣。我也尝试过使用jtool进行签名，但同样，这不起作用。

所以现在，在MachOView中打开二进制文件：

二进制的 MachOView

我希望我可以对二进制文件进行十六进制编辑并更改它的值，__LINKEDIT segment以便它覆盖文件的末尾，因此代码设计将起作用，但我不知道修改后的值应该是什么，或者如果有的话还有什么我需要改变。任何提示表示赞赏。

更新 1 - 回应Kamil.S 的回答

我已经尝试调整File Size__LINKEDIT 段中的值，所以 this + theFile 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-fix-implementation对同一问题有更多详细信息：

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 大小），VM 大小 - 与“文件大小”相同

  • 修复 LC_SYMTAB - 字符串表大小 - mach-o 文件中的最后一个数据（偏移量 + 大小 = 文件系统上的 exe 大小） - 附加到可执行文件的数据将成为“字符串表”的一部分（Mach-O 文件中的最后一个数据部分）。

我会看看修复LC_SYMTAB，看看是否有帮助。

4

3 回答 3

2

__LINKEDIT的File Offset+File Size应该等于物理可执行文件大小。您可以通过双击该值，对其进行编辑并保存来修改 - 可执行文件应该没问题File Size。MachOView只是不要碰File Offset，因为这肯定会破坏它。

于 2018-01-19T08:28:44.050 回答
1

如果应用程序在从 Finder 正常运行时无法找到其外部资源，这听起来像是Gatekeeper Path Randomization的结果。操作系统在运行时将应用程序移动到隐藏的只读位置，并且找不到资源。

我认为签署应用程序二进制文件本身不会解决此问题并阻止操作系统进行路径随机化。用户需要在解压后将应用程序移动到不同的目录，或者您需要将应用程序分发到已使用您的 Developer ID 证书签名的磁盘映像中。DropDMG（从上面的帖子链接）可以创建签名的磁盘映像，这可能值得快速尝试。

于 2018-01-18T18:04:49.220 回答
1

DIrector 使用一种在 Windows 上广泛使用的方案，称为“过载”。我在物理文件的末尾附加了一些数据，但超出了可执行映像的大小。Mach-O 文件不支持这种方法。物理图像必须以 LINKEDIT 段覆盖的最后一个字节结束，甚至 LINKEDIT 段内的项目顺序也已明确定义。过去的原因是预绑定，现在是协同设计。

附加的数据是要首先加载的初始 DIR/DXR 目录。我想这已经通过将 DIR/DXR 添加到应用程序包中来解决。但我不再喜欢导演，所以我不确定这一点。

于 2018-02-28T11:00:10.423 回答