Bab*_*aba 5 c api obfuscation hide
我编写了一个C库,其中包含几个.h文件和.c文件.我将其编译为.a静态库.
我想仅向用户公开某些功能,并使其余功能尽可能"模糊",以使逆向工程变得相当困难.
理想情况下,我的图书馆将包括:
1-一个.h文件,只显示向用户公开的功能
2- myLibrary.a:尽可能不可逆转
有什么最好的做法？我应该在哪里看,是否有一个很好的教程/书？
进一步来说:
为 - 1
我已经拥有了所有的.h和.c工作,我想避免更改它们,将函数声明从.h移动到.c并进入循环引用潜在的pbs.那可能吗？
例如,创建一个新的.h文件是一个好主意,我只会用我的.a文件进行分发？.h将包含我想要公开的函数的副本以及我使用的类型的转发声明.这是一个好主意吗？
为 - 2
a)我应该注意哪些gcc标志(或xcode)(用于剥离,没有调试符号等)b)一个很好的指针来学习如何进行代码混淆？
任何想法都会有帮助,
谢谢,巴巴
通常的做法是确保static在该模块中声明仅在某个模块内部使用的每个函数和全局变量.这限制了单个模块的内部实现细节的暴露.
如果您需要跨模块交叉但不供公共使用的内部实现细节,则声明一个或多个.h保密的文件,而不是交付给最终用户.以这种方式定义的对象的名称仍然可以被链接器(以及诸如objdump和之类的工具nm)看到,但它们的详细签名将不会出现.
如果您有交付给最终用户但不透明的数据结构,那么请考虑让API将它们作为指向struct公共API .h文件中未定义的声明的指针.这将保留类型安全性,同时隐藏实现细节.当然,完整的struct定义是在私有.h文件中.
With care, you can keep a partially documented publicly known struct that is a type-pun for the real definition but which only exposes the public members. This is more difficult to keep up to date, and if you do it, I would make certain that there are some strong test cases to validate that the public version is in fact equivalent to the private version in all ways that matter.
Naturally, use strip to remove the debug segments so that the internal details are not leaked that way.
There are tools out there that can obfuscate all the names that are intended to be only internal use. If run as part of the build process, you can work with an internal debug build that has sensible names for everything, and ship a build that has named all the internal functions and global variables with names that only a linker can love.
Finally, get used to the fact that anyone that can use your library will be able to reverse engineer your library to some extent. There are anti-debugger measures that can be taken, but IMHO that way lies madness and frustration.