文章目录
一、插件引擎运行特点
宿主应用 中 , 首先在 AndroidManifest.xml 中 , 定义了若干占坑的 “桩” 组件 , 这些组件的作用是为了欺骗 ActivityManagerService 准备的 , 如果给 AMS 传入没有在清单文件中注册过得组件 , 直接就报错了 ;
启动 插件应用 时 , 创建 Intent 时 , 创建的是 “桩” 组件 , 将插件应用组件信息封装到 Intent 的 Extra 信息中 ;
然后将相关数据传递通过 Binder 机制 , 传递给 AMS , 在 AMS 进程中 , 会验证要启动的组件是否在 AndroidManifest.xml 清单文件中注册过 , 此时必须使用 “桩” 组件 , 否则无法启动相应组件 ;
在 AMS 进程处理完相应操作后 , 又回到 ActivityThread 主线程中 , 此时丢弃之前使用的 “桩” 组件 , 使用 Intent 中的 插件应用 中的组件 , “桩” 组件完成了欺骗 AMS 的职责 , 之后开始创建 插件应用中的组件实例 , 然后启动插件中的组件 ;
所有的插件化引擎 , 都有上述特征 , 即 “桩” 组件 Intent 中包含 插件组件信息 , AMS 处理完毕后 , 又从该 Intent 中取出信息创建插件组件 ;
反编译 Dex 文件 , 然后通过分析 Smali 代码 , 分析是否存在上述一系列的操作 , 注意按照特定顺序执行的一系列操作 ;
如果发现上述特征 , 就说明该应用中使用了插件化引擎 ;
有个问题 , 如果应用加固了 , 加了个壳 , 或者应用的 Dex 文件进行了加密 , 就无法使用上述静态检测了 ;
二、恶意软件特点
使用了插件化引擎的 恶意应用 , 一般会有 隐藏加载 的特征 ;
恶意应用 会 极力避免 恶意插件 , 或者恶意应用 的安装执行 , 被发现 , 一般都是不经过用户同意的静默操作 ; 如 将插件 加密 ( 解密后运行 ) , 或者 从网络中下载 插件 ( 下载后运行 ) ;