Jak*_*sen 3 android caching dalvik
是否可以通过编程方式验证系统生成的odex文件的完整性/校验和?
我不知道该如何检测,如果扎根的Android手机上的攻击者是否为应用程序安装了自己的odex文件版本。
假设是,如果攻击者能够替换.odex文件,则他们具有足够的权限来执行许多其他操作。
构建生成的odex文件位于/ system上的受保护目录中,该目录以只读方式安装。任何能够修改这些文件的人都可以简单地入侵VM或替换系统的主要部分。
已安装生成的odex文件位于/ data / dalvik-cache中,并受文件系统权限保护。有权修改.odex文件的任何人都可以做各种事情,例如在不使用时重新安装应用程序。对于攻击者而言,这将是一种更好的方法,因为它可以在OTA更新中幸存下来(这会导致重新选择)。
在适当位置修改优化的DEX数据是可行的,但是有点麻烦。与替换应用程序相比,这样做的优势在于它更加精巧-重新安装应用程序时,您要么需要原始的签名密钥,要么希望用户不意识到自己现在正在运行的应用程序具有相同的名称,但是不同的签名者。
因此,.odex文件具有校验和,可以在您怀疑文件系统的完整性的情况下查看,但除了重新执行dexopt并在进行前后比较之外,没有其他检查篡改的措施。
有关dexopt和odex的常规信息可在android中的dalvik / docs / dexopt.html中获得;一个格式化好的版本在这里提供。
编辑:我应该提到DEX和ODEX文件确实将校验和存储在文件头中。这些通常会被忽略,因为出于性能原因,您不想在每次启动应用程序时都扫描整个文件。您可以通过将dalvik.vm.check-dex-sum属性设置为true(或-Xchecksum在命令行中传递)来启用强制校验和验证。
校验和旨在检测文件损坏,而不是有意更改。(您可以使用它dexdump -c来手动进行扫描。)篡改文件的人可能只重新计算了一个有效的校验和并将其存储,因此您需要将已知的良好副本保存在其他位置。而且,您想使用SHA1或类似的语言,而不是adler32来使二进制代码难以获得相同的校验和值。
| 归档时间: | 
 | 
| 查看次数: | 2688 次 | 
| 最近记录: |