在OS X 10.13上对旧的Director投影机进行代码签名-也许操纵__LINKEDIT段值 [英] codesign an old Director projector on OS X 10.13 - perhaps manipulate __LINKEDIT segment value

问题描述

(请参阅本文末尾的更新)

(See Updates at end of this post)

出于理由，我需要对一台旧的Director投影机进行代码签名，而该投影机无法再发布(无法访问原始源代码或Director).

For $reasons, I need to codesign an old Director projector that we can no longer re-publish (no access to original source code or to Director).

之所以这样做，是因为在未经签名的情况下运行时，该应用程序现在会打开一个Finder窗口，并提示"Where is ..." ，要求文件是嵌入式投影仪之一资源.

I'm doing this because when run without being signed, the app now opens a Finder window with a prompt saying "Where is..." asking for a file that's one of the embedded projector resources.

但是...如果我将cd放入Projector.app内容中(这不是真的，但是您明白了)，然后在Contents/MacOS/中找到了放映机二进制文件并从终端运行此二进制文件，则该应用程序将启动并在二进制文件的末尾解压缩了(大概)附加的存档后，运行良好.

But... If I cd into the Projector.app contents (it's not really called that, but you get the idea) and find the projector binary inside Contents/MacOS/ and run this binary from terminal, the app launches and runs fine, once it's decompressed the (presumably) attached archive at the end of the binary...

/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

我不能要求我们的用户这样做(他们是非技术性的)，所以我猜测"Where is ..." 提示是操作系统的某些方面X Gatekeeper，因此我希望对二进制文件进行签名将使其再次可点击运行.

I can't ask our users to do this (they're very non-technical) so I'm guessing that the "Where is..." prompt is some aspect of the OS X Gatekeeper, and hence I'm hoping that signing the binary will make it click-runnable again.

当我尝试对二进制文件App.app/Contents/MacOS/projector进行代码签名时，我得到:

When I try and codesign the binary App.app/Contents/MacOS/projector I get:

main executable failed strict validation

设置--no-strict代码签名选项会提供更多细节:

Setting the --no-strict codesign option gives a bit more detail:

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

我认为这是因为Director投影仪是二进制文件，带有捆绑的归档文件，其中包含应用程序的其余资源，并附加在可执行文件的末尾.一些搜索表明其他项目的嵌入式资源也有类似的问题.

Which I think is because the Director projector is a binary with a bundled archive containing the rest of the application's resources, appended to the end of the executable. Some googling shows that other projects have similar problems with their embedded resources.

我尝试使用 macho_edit 来查看我是否可以修改二进制文件，但并不高兴.我也尝试过使用 jtool 进行签名，但是同样，这没有用.

I've tried using macho_edit to see if I could modify the binary, but with no joy. I've also tried signing using jtool, but again, this didn't work.

现在，在 MachOView 中打开二进制文件:

So now, opening the binary in MachOView:

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

I'm hoping that I can hexedit the binary and change the value of the __LINKEDIT segment so it covers the end of the file, and hence so the codesigning will work, but I have no idea what the modified value should be, or what else if anything I need to change. Any tips appreciated.

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

我尝试调整__LINKEDIT段中的File Size值，因此，此+ File Offset与实际二进制文件相同(我尝试了几次；实际上，您需要将VM Size更改为与File Size相同的值，或者由操作系统获得Killed: 9.如果将File Size设置为二进制文件的总大小，也会发生同样的情况，但是没有运气.使用新的File Size和VM Size值，我仍然可以运行二进制文件，但无法对其进行代码签名；但是，我确实这样做，得到的错误消息稍有不同:

I've tried adjusting the File Size value in __LINKEDIT segment, so this + the File Offset is the same as the actual binary (I tried a few times; you actually need to change the VM Size to be the same value as the File Size or you get Killed: 9 by the OS. Same happens if you set File Size to be the total size of the binary), but with no luck. With the new File Size and VM Size values, I can still run the binary, but I can't codesign it; I do however, get a slightly different error message:

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

更新2 -

Update 2 - https://github.com/pyinstaller/pyinstaller/wiki/Recipe-OSX-Code-Signing#pyinstaller-fix-implementation has a bit more detail on the same problem:

PyInstaller破坏了OSX代码签名，因为它在以下位置附加了python代码 二进制文件的末尾.在可执行文件中断的末尾追加数据 Mach-o格式结构. codesign实用程序抱怨 以下消息.

PyInstaller breaks OSX code signing because it appends python code at the end of the binary. Appending data at the end of executable breaks the Mach-o format structure. codesign utility complains with the following messages.

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大小-与文件大小"相同

  • Fix __LINKEDIT - File Size (offset + File size == exe size), VM Size- same as 'File Size'

    修复LC_SYMTAB-字符串表大小-mach-o文件中的最后一个数据(偏移量+大小=文件系统上的exe大小)-附加到可执行文件的数据将是字符串表"的一部分(最后一个数据)在部分 Mach-O文件).

    Fix LC_SYMTAB - String Table Size - last data in mach-o file (offset + size = exe size on the filesystem) - The data appended to the executable will be part of the 'String Table' (Last data section in Mach-O file).

    我将看看如何修复LC_SYMTAB是否有帮助.

    I'll take a look at fixing LC_SYMTAB to see if that helps.

    推荐答案

    __LINKEDIT的File Offset + File Size应该等于物理可执行文件的大小.您可以在MachOView中的File Size中进行修改，方法是双击该值，然后对其进行编辑并保存-可执行文件应该没问题.只是不要触摸File Offset，因为这肯定会破坏它.

    __LINKEDIT's File Offset + File Size should be equal to physical executable size. You can tinker with File Size in MachOView by double clicking the value, editing it and saving - the executable should be fine. Just don't touch File Offset because this will definitely break it.

    这篇关于在OS X 10.13上对旧的Director投影机进行代码签名-也许操纵__LINKEDIT段值的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！