我编写了一个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)一个很好的指针,了解如何进行代码混淆?
任何想法都会有所帮助,
谢谢,巴巴
答案 0 :(得分:8)
通常的做法是确保只在某个模块内部使用的每个函数和全局变量在该模块中声明为static
。这限制了单个模块对内部实现细节的暴露。
如果您需要跨模块交叉但不供公众使用的内部实施细节,则声明一个或多个.h
文件,这些文件保密并且未交付给最终用户。以这种方式定义的对象的名称仍然可以被链接器(以及objdump
和nm
等工具)看到,但它们的详细签名不会。
如果您有传递给最终用户但不透明的数据结构,那么请考虑让API将它们作为指向公共API {{1}中未定义的struct
的指针。文件。这将保留类型安全性,同时隐藏实现细节。当然,完整的.h
定义位于私有struct
文件中。
小心谨慎,您可以保留一份部分记录的公开.h
,它是真正定义的类型双关语,但只公开公共成员。这更难以保持最新,如果你这样做,我会确保有一些强大的测试用例来验证公共版本实际上与所有重要的私有版本相同。
当然,使用struct
删除调试段,以便内部细节不会泄露。
有些工具可以混淆所有仅供内部使用的名称。如果作为构建过程的一部分运行,您可以使用具有合理名称的内部调试构建,并发布一个已命名所有内部函数和全局变量的构建,其名称只有链接器可以喜欢。
最后,请习惯这样一个事实:任何能够使用您的库的人都能够在某种程度上对您的库进行逆向工程。可以采取反调试器措施,但恕我直言,这种方式是疯狂和沮丧。
答案 1 :(得分:1)
除了探索“静态”功能的使用之外,我没有快速的答案。我建议阅读Miro Samek的作品,他称之为“C +”。基本上面向对象的ANSI C.很棒的阅读。他拥有Quantum leaps软件。
答案 2 :(得分:0)