中文版文档为基于英文版文档的翻译。因此版本上可能会落后于英文版,仅供参考

提示

  • 安全现在不是,以后也永远不会仅仅基于代码混淆. 所谓的安全公司(例如爱加密)为了卖出更多的产品可能会这么说 ,但是二进制加固并不会魔术般的修好所有的漏洞和Bug,如果没有引入更多的话
  • 设计一个二进制加固框架非常难,而将框架开源更给攻击者提供了一些混淆后二进制的特征,这些特征能帮助拥有合适技能的攻击者编写反混淆工具. 虽然Hikari在设计上就极力避免这类特征出现, 但在拥有符号执行这类大杀器的情况下,反混淆的难度依然会被大大简化,即使是对于所谓的虚拟机加固来说. DOI 10.1145/2991079.2991114 非常详细的解释了这一点。

简介

Hikari是一个对于Obfuscator-LLVM的移植和优化并包含更多自制的加固。测试流程是在我自己的开源项目WallpaperKit上运行Hikari. 你可以在这里 找到一份在2018/01/30混淆的WallpaperKit.framework作为例子.

设计哲学

  • 影响最小化. 也就是说,Hikari应当能被相对容易的移植到任何使用LLVM作为其后端的编译工具链
  • 着重于编译器. 也就是说, 我们倾向于不在LLVM层实现应当由其他外部工具实现的操作. 例如Objective-C的方法名/类名混淆, 最适合在外部基于libClang的工具中完成
  • 抽象化.也就是说,我们尽可能的在IR层而不是大多数情况下平台特定的后端来实现混淆

开始

首先按照 编译及安装 来编译并安装工具链,其次阅读每个pass单独的页面来确认是否需要额外的设置步骤。

results matching ""

    No results matching ""