Android虚拟化沙箱方案技术评测

发布时间: 2023-07-12

Android虚拟化方案技术评测 VirtualApp/LBE/SpaceCore/360分身大师

虚拟化沙箱是一个基于Android系统的应用程序虚拟化引擎,一个Android系统的沙盒环境,提供在Android上克隆和运行虚拟应用程序,亦可看作是轻量级的Android虚拟机。并且已支持设备模拟、模拟定位以及用于APP多开、数据隔离、脚本自动化、插件化开发、谷歌商店上架等。支持BlackBox重新打包,支持马甲包以A/B包的形式上架Google Play

刚刚群里看到讨论,SpaceCore直接免费开放了,且允许商用,这是要搅乱市场的节奏?!
虽然还不是完全开源,只是SDK免费使用。

SpaceCore最晚出来最年轻,给我的感觉也是最求变的一家,免费开放使用虽然看起来是减少了盈利,
但是口碑打出去,何尝不是可以引来更多有定制需求的客户?
对于手头资金不宽裕的个人开发者来说,无疑是多了一个极好的选择。

前言

在目前Android大环境下,虚拟化技术已经很普及。对于虚拟化的运行原理,网上文章已经有一大堆。本篇文章就从实测角度来对比一下各家虚拟化产品技术的差异。

本文涉及到Android的相关知识点,我尽量用自己理解的大白话去讲,如有不对请前辈们不吝赐教。

一些术语

简称 全称 解释
宿主 宿主 原应用,即应用本身
子应用 子应用 被运行的应用
PMS PackageManagerService Android中的安装包管理服务
AMS ActivityManagerService Android中的应用活动的管理服务
NMS NotificationManagerService Android中的应用通知管理服务

虚拟化是如何运作?

关于这个问题网上已经有N + 1的类似文章,这里有几篇可以参考一下

通过原理分析,我们可以看出,完成虚拟化一个应用,要做的核心事情只有一件:在运行子应用时,欺骗系统让系统误以为正在运行的是宿主,否则系统会毫不犹豫的将你杀死!!

测试的切入点

首先此文章技术细节请教了这方面的大佬,再根据我自己对这方面的研究。现针对以下几个虚拟化“重灾区”进行检验一下,为什么会这样说呢,因为根据虚拟化的技术原理或多或少不可避免的需要对环境进行修改,这里就挑一些比较典型的点来对比各个框架之间对这些细节的处理。

 

参与对比的产品有(如有补充可以底下留言,我继续完善)

名称 官网
VirtualApp(收费,不建议) github.com/asLody/Virtu
LBE平行空间(楼上子公司) parallelspace-app.com/i
SpaceCore(一般) spacecore.dev/
360分身大师(360) fenshen.360.cn
双开助手 multiopen.cn/
MultiApp(SDK有广告) https://github.com/WaxMoon/MultiApp
AndroBox(VA阉割版,忽略) https://github.com/yongyecc/AndroBox
BlackBox(推荐)有能力可以改成自己的品牌 https://github.com/hadis898/BlackBox-M

 

分别对比一下以下的点:

方法 正常值
Context#mBasePackageName 自身包名
Context#mOpPackageName 自身包名
ActivityThread.H#mCallback null
ActivityThread#mInstrumentation android.app.Instrumentation
PMS检测 android.os.BinderProxy@xxxx

测试所用的Demo是随便写的,目的就是读一下里面的对象其实很简单。
子应用包名:com.virtualchecker

检测


读取应用:Context#mBasePackageName中的值

产品 期望值 实际值
Android系统 com.virtualchecker ✅ com.virtualchecker
VirtualApp com.virtualchecker ❌ io.busniess.va
LBE com.virtualchecker ❌ com.lbe.parallel.intl.arm64
SpaceCore com.virtualchecker ✅ com.virtualchecker
360分身大师 com.virtualchecker ✅ com.virtualchecker
双开助手 com.virtualchecker ❌ com.exceliance.dualaid


读取应用:Context#mOpPackageName中的值

产品 期望值 实际值
Android系统 com.virtualchecker ✅ com.virtualchecker
VirtualApp com.virtualchecker ❌ io.busniess.va
LBE com.virtualchecker ❌ com.lbe.parallel.intl.arm64
SpaceCore com.virtualchecker ✅ com.virtualchecker
360分身大师 com.virtualchecker ✅ com.virtualchecker
双开助手 com.virtualchecker ❌ com.exceliance.dualaid


读取应用:ActivityThread#mInstrumentation

产品 期望值 实际值
Android系统 android.app.Instrumentation@ ✅ android.app.Instrumentation@bfcc1e8
VirtualApp android.app.Instrumentation@ ❌ com.lody.virtual.client.h.a.c@fd146bf
LBE android.app.Instrumentation@ ❌ com.doubleagent.client.e@a0aac44
SpaceCore android.app.Instrumentation@ ✅ android.app.Instrumentation@153bfc9
360分身大师 android.app.Instrumentation@ ❌ com.morgoo.droidplugin.hook.handle.PluginInstrumentation@8e8d100
双开助手 android.app.Instrumentation@ ❌ com.exceliance.kxqp.platform.c.b.e.wy@38e16ce


读取应用:ActivityThread.H#mCallback

产品 期望值 实际值
Android系统 null null
VirtualApp null ❌ com.lody.virtual.client.h.d.d.b@800e4de
LBE null ❌ com.lbe.doubleagent.client.LocalActivityService$ActivityThreadCallback@3f40957
SpaceCore null ❌ com.fvbox.lib.client.hook.HCallbackHook@aa9ba7e
360分身大师 null ❌ com.morgoo.droidplugin.hook.handle.e@91b7b06
双开助手 null ❌ com.excelliance.kxqp.platform.c.b.e.wr@153bfc9


PMS检测

产品 期望值 实际值
Android系统 android.os.BinderProxy@ ✅ android.os.BinderProxy@eff05b8
VirtualApp android.os.BinderProxy@ ❌ com.lody.virtual.client.h.a.c@993b1e1
LBE android.os.BinderProxy@ ❌ com.lbe.doubleagent.client.hook.BinderProxy@f54e1fe
SpaceCore android.os.BinderProxy@ ✅ android.os.BinderProxy@c846443
360分身大师 android.os.BinderProxy@ ❌ com.morgoo.droidplugin.hook.newsolution.BinderHook$BinderWrapper@cf8d1da
双开助手 android.os.BinderProxy@ ✅ android.os.BinderProxy@eff05b8


测试结果

产品 mBasePackageName mOpPackageName mInstrumentation PMS H#mCallback
VirtualApp
LBE
SpaceCore
360分身大师
双开助手

 

以上测试仅仅是拿出一些关键点进行检测,展示各个框架的实测情况,唯一一点全部不通过的是ActivityThread.H#mCallback,其实这个地方并不是虚拟化才会用,很多Android上的黑科技都会用到,可以避免但是没必要为了这个牺牲掉兼容性。

结论

各个框架也浅浅的分析过一遍,其实大部分框架都有比较多的技术重合点,通过上方的测试可以看出,SpaceCore对应用的入侵是比较保守的,侧面反映了内部的处理逻辑更优,但具体实现细节未知。欢迎各位前辈指正,欢迎各位交流。

  1. Birthday p
    2023-07-13 08:24:45

    用过第二个和最后一个 兼容性太差

请在下方留下您的评论.加入TG吹水群