machomachomangler 0.0.1

• 对于pynativelib库：一个使用dylib和mangling的工具 规则，并将损坏规则应用于所有导出的 符号。例如，它可以转换导出ssl new的库 将 pynativelib_openssl_u ssl_new导出到其中。它也 在库id处更改它，例如从 ssl.dylib ->； pynativelib_openssl_u ssl.dylib （类似于安装名称工具 -id ）

  另外：创建"占位符"库的工具 导入上述损坏的库，然后重新导出 原始名称下的符号。

• 对于希望使用pynativelib库的代码：一个 获取一个dylib/bundle/executable，一个"原始"dylibs的列表，以及 对于每个"原始"dylib，该dylib的新名称，以及 破坏规则。然后（a）替换原始 具有从 不存在的目录，（b）将其标记为"弱"导入，（c） 将损坏规则应用于从该dylib导入的所有符号， （d）标记这些符号，以便在平面名称空间中查找。

事实证明，事物的精确组合是唯一的方法 由MacOS链接器/加载器提供，以链接dylib/bundle 相对于dylib b，其中a和b在磁盘上的相对位置不是 在可执行文件启动之前已知，同时保留通常的 避免符号冲突的两级命名空间规则。我保证 一旦我有机会把它写好，一切都会有意义的…

mach-o损坏代码的一些已知限制：

• 不出所料，这种修补程序在代码中并不适用。 签署。代码不带签名的特殊情况； 他们可能会搞砸的。如果你想签你的 二进制文件，然后在签署之前先进行损坏。
• 我们目前只重写了新样式的dyld_info符号表 （在10.5中引入），而不是（几乎？）完全多余 符号表。（有趣的事实：所有的mach-o二进制文件 包括两种完全不同的符号表示 T易物。新的比较紧凑，节省空间，但是 保留旧的以保持兼容性，所以…无论如何。）尽可能 我知道，现代MacOS中唯一还在使用 symtab/dysymtab是dladdr，我认为没有人依赖它 关于dladdr的输出，嗯……有什么事吗？我认为最坏的情况是，你 可能会在调试器中看到原始符号名，或者 剖析器？但如果它变成一个 问题。
• 它对dyld_info弱绑定表没有任何特殊处理， 或者出口疲软。（注意，这些与 \u属性（弱的）） 或 \u属性（弱的导入）） 或任何 在手册页"i 认为它们是为了实现模糊的链接（这可能是 而不是 灾难性的选择，但我不能百分之百确定 正确–这是mach-o格式中一个令人难以置信的模糊部分，并且 mach-o一开始就很模糊。幸运的是，这个特性 只使用C++库，所以不用它就可以开始。
• 当管理导入时，我们转换任何惰性导入（需要 （挤进）急切的进口。这是必需的，因为懒人 将导入表的内存布局硬编码到 存根程序集本身中的直接常量，而我没有 感觉像是在尝试自动重写x86-64操作码。相反， 我们把lazy import表单独留下（所以所有未组合的lazy 导入可以继续使用它），并急切地绑定所有损坏的 导入，这样就不会调用未组合的存根。
• 我注意到MacOS 10.12中的一些新代码dyld强制 烦人的任意限制 dyld_信息出现在文件中。这只会影响 是以10.12作为最低要求的版本构建的，所以对于人们来说 试着为总发行量做些事情这不重要 一段时间。这也不难解决，只是意味着我们会 可能得开始做一些毫无意义的 我们 没有更改的文件位，只是第二个 拷贝可以放在我们更改的文件位之后， 太累了，我还没来得及做。
• 当管理进口时，我们不检查再出口，这也是 一种进口货。可能应该解决这个问题…