我编写了一个 C 库，其中包含一些 .h 文件和 .c 文件。我将其编译为 .a 静态库。
我想只向用户公开某些功能，并使其余功能尽可能“模糊”，以使逆向工程变得相当困难。
理想情况下，我的图书馆应包括：
1- 一个 .h 文件，仅包含向用户公开的功能
2- myLibrary.a：尽可能不可逆工程
对此的最佳实践是什么？我应该在哪里看，有什么好的教程/书籍吗？
进一步来说：
for - 1
我已经让所有 .h 和 .c 都可以工作，我想避免改变它们，将函数声明从 .h 移动到 .c 并进入潜在的 pbs 循环引用。那可能吗？
例如，创建一个新的 .h 文件是否是一个好主意，我只将其用于与我的 .a 一起分发？该 .h 将包含我想要公开的函数的副本以及我使用的类型的转发声明。这是一个好主意吗？
for - 2
a) 我应该注意哪些 gcc 标志（或 xcode）（用于剥离、没有调试符号等）
b) 一个了解如何进行代码混淆的好指南？
任何想法都会有所帮助，
谢谢，爸爸
通常的做法是确保声明仅在某个模块内部使用的每个函数和全局变量static在该模块中。这限制了单个模块内部实现细节的暴露。
如果您需要跨模块但不供公共使用的内部实现细节，请声明一个或多个.h保密且不交付给最终用户的文件。以这种方式定义的对象的名称对于链接器（以及诸如objdump and nm）但他们的详细签名不会。
如果您有交付给最终用户的数据结构，但这些数据结构是不透明的，那么请考虑让 API 将它们作为指向struct未在公共 API 中定义的声明.h文件。这将保持类型安全，同时隐藏实现细节。自然，完整的struct定义是私有的.h file.
只要小心，您就可以将部分记录的信息公开struct这是真正定义的类型双关语，但仅公开公共成员。这更难保持最新状态，如果你这样做，我会确保有一些强大的测试用例来验证公共版本实际上在所有重要方面与私有版本相同。
自然地，使用strip删除调试段，以便内部细节不会以这种方式泄露。
有一些工具可以混淆所有仅供内部使用的名称。如果作为构建过程的一部分运行，您可以使用内部调试构建，该构建对所有内容都具有合理的名称，并发布一个构建，该构建已使用只有链接器可以喜欢的名称命名所有内部函数和全局变量。
最后，要习惯这样一个事实：任何有能力的人use您的图书馆将能够在某种程度上对您的图书馆进行逆向工程。可以采取反调试器措施，但恕我直言，这种方式会带来疯狂和挫败感。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
