Group of Software Security In Progress

GoSSIP @ LoCCS.Shanghai Jiao Tong University

Repackage-proofing Android Apps

论文下载

Android重打包问题严重,之前的工作都是从相似性检测方面来预防重打包,文章从自动化重打包校验的角度来防止重打包。基本思路是在源码基础上,自动化插入大量重打包检测的代码,使得APK被重打包后无法正常运行。

整个架构可以分为三部分:repackaging detection, repackaging response and the communication channel。

  • 重打包检测:主要思路是对比在APK运行时获得的public key与作者提供的public key比较。APK运行时获得的public key的方法是PackageManager。获取的代码有很多模版,利用反射调用相关API,API名字在不同模版中会由不同的片段拼凑而成,在不同模版中,需要比较的public key的片段也不一样。这其中还会加很多混淆技术:instruction reordering, variable renaming,dummy code injection, and opaque predicate insertion。

关键是插入方法。首先,会利用monkey动态跑APP,将运行一次APP被执行超过50000次的method排除掉。之后的插入会随机选method,分析其CFG,随机选一个block,找到要运行这个block就一定会运行到的其他block,即dominators。之后将检测代码随机分为N个片段,随机插入到这个block及其dominator block中。(不同模版变量名都不一样,所以一个method可能被插入多个检测代码,但不影响)如下图:

Fig

  • 响应代码:延迟响应,检测到重打包后会随机一段时间后才触发响应,响应的方式是随机修改一些整型或字符串变量。这可能会导致某些界面bug,逻辑bug,当然也会引起崩溃。但这次修改不会马上生效,会在下一次调用这个变量时生效。同时并不是每次执行到相应代码时都会响应,这也是随机的。响应代码也会被随机插入到很多调用不是很频繁的方法中。
  • 通信:采用反射来修改R Class中一些变量值。由于该实现用较多反射,因此还会故意将源码中的普通系统调用替换为反射,防止攻击者直接去掉所有反射代码。

这个保护工具效果比较好,可以有效抵抗静态分析和动态分析。由于插入的代码较多,且随机元素多,几乎不能自动化去掉所有检测,人工分析存在破解可能,但耗费成本极大。