【问题标题】:best practice for delivering a C API hiding internal functions [closed]提供隐藏内部函数的 C API 的最佳实践 [关闭]
【发布时间】:2011-04-10 23:43:57
【问题描述】:

我编写了一个 C 库,其中包含几个 .h 文件和 .c 文件。我将它编译为 .a 静态库。

我想只向用户公开某些功能,而让其余功能尽可能“模糊”,以使逆向工程相当困难。

理想情况下,我的库应包括:

1- 一个 .h 文件,仅包含向用户公开的功能

2- myLibrary.a:尽可能不可逆向工程

这方面的最佳做法是什么?我应该去哪里看,有没有好的教程/书?

更具体地说:

为 - 1

我所有的 .h 和 .c 都在工作,我想避免更改它们,将函数声明从 .h 移动到 .c 并进入循环引用潜在 pbs。这可能吗?

例如,创建一个仅用于与我的 .a 一起分发的新 .h 文件是个好主意吗?该 .h 将包含我想要公开的函数的副本以及我使用的类型的转发声明。这是个好主意吗?

为 - 2

a) 我应该注意哪些 gcc 标志(或 xcode)(用于剥离,没有调试符号等) b) 学习如何进行代码混淆的好方法?

任何想法都会有所帮助,

谢谢,爸爸

【问题讨论】:

  • 请显示您已经编写的一些代码。我们不是您的个人编码服务

标签: c api obfuscation hide


【解决方案1】:

删除此函数的标头,在导出表中进行一些混淆,并打包您的代码并应用一些反调试器算法。

http://upx.sourceforge.net/

http://www.oreans.com/

【讨论】:

    【解决方案2】:

    除了探索“静态”函数的使用之外,我没有快速的答案。我建议阅读 Miro Samek 关于他称之为“C+”的东西的作品。基本上是面向对象的ANSI C。很好读。他拥有 Quantum jumps 软件。

    【讨论】:

      【解决方案3】:

      通常的做法是确保仅在某个模块内部使用的每个函数和全局变量在该模块中声明为static。这限制了从单个模块中暴露内部实现细节。

      如果您需要跨模块但不供公众使用的内部实现细节,则声明一个或多个 .h 文件,这些文件保持私有且不交付给最终用户。以这种方式定义的对象的名称对于链接器(以及objdumpnm 等工具)仍然可见,但它们的详细签名将不可见。

      如果您有交付给最终用户但不透明的数据结构,则考虑让 API 将它们作为指向 struct 的指针交付,该 struct 未在公共 API .h 文件中定义。这将保持类型安全,同时隐藏实现细节。当然,完整的struct 定义位于私有.h 文件中。

      小心,您可以保留部分记录的公开已知struct,它是真实定义的双关语,但仅公开公共成员。这更难保持更新,如果你这样做,我会确保有一些强大的测试用例来验证公共版本实际上在所有重要的方面都等同于私人版本。

      当然,使用strip 删除调试段,这样内部细节就不会泄露。

      有一些工具可以混淆所有仅供内部使用的名称。如果作为构建过程的一部分运行,您可以使用对所有内容都具有合理名称的内部调试构建,并使用只有链接器喜欢的名称来命名所有内部函数和全局变量的构建。

      最后,要习惯这样一个事实,即任何可以使用您的库的人都可以在一定程度上对您的库进行逆向工程。可以采取反调试器措施,但恕我直言,这种方式是疯狂和沮丧的。

      【讨论】:

      • 我有一个疑问。如何将标志 __attribute__((visibility("default"))) 仅应用于他想要公开的那些函数并在整个库的编译标志中传递 -fvisibility=hidden 。我不确定这里的逆向工程过程。
      • 即使没有符号,只要代码可以运行并且物理硬件可供检查,逆向工程也是可能的。这可能不是微不足道的,但它仍然是可能的。库的情况稍差一些,因为您确实需要允许合法用户引用 一些 符号。
      猜你喜欢
      • 1970-01-01
      • 2011-01-12
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2013-09-13
      • 1970-01-01
      • 1970-01-01
      相关资源
      最近更新 更多