App应用双开技术，Android沙盒

> App应用双开（多开）技术
微信分身，微信多开，微信双开- http://blog.csdn.net/yunajie/article/details/50894488
Android应用分身功能介绍- http://blog.csdn.net/maetelibom/article/details/52084085

-- LBE平行空间和市面上的其他应用双开app有本质区别，其他方案是通过改包名、改Framework等非常粗糙的方式达到目的，而 LBE是让应用在自己开的虚拟机里面运行，单独的进程单独的环境来实现双开；而机友精灵是把应用通过复制改代码重新生成APK文件来实现的；MIUI8。LBE平行空间的底层是一个完整的虚拟化引擎：MultiDroid更准确的说，MultiDroid并不是硬件虚拟化或OS虚拟化 (譬如VMware, Xen, KVM)，它也不是应用层虚拟化（譬如XenApp, Wine)，MultiDroid更类似容器(Container).LBE出品的平行空间（Parallel Space）。
  现阶段，已有许多安全公司研发出了较早时期的App双开技术：LBE平行空间、卓盟双开助手、金山开小号，但是它们的原理无一例外的是插件化。

 - LBE MultiDroid的关键技术有：
  1. Framework层的虚拟实现在Android环境中，每个应用在运行时都需要和Android framework打交道。Android系统的System-Server进程提供了大部分的系统API。 应用程序通过Binder IPC调用系统API。LBE之前在安全大师产品中，也就是通过对System-Server的hook来实现主动防御和权限管理，但MultiDroid在设计之初的一个最重要的目标就是不需要root权限，从而不能通过hook的方式来实现虚拟化。为此，我们需要自行实现一套完整的System-Server API，这就是MultiDroid的核心，工作量非常大，更麻烦的是，我们的设计目标是支持所有Android 4.0以上版本，而每个版本的Framework实现又千差万别……
  2. 文件系统虚拟化程序在运行的时候，会加载文件系统上的程序指令和程序数据。要建立虚拟的应用程序运行环境，需要模拟一个独立的文件系统，在这个独立的文件系统中，再针对不同的虚拟应用的主目录进行区分和权限控制；
  3. Android系统组件管理一个Android应用基本上是由Android四大组件（Activity， Service， Broadcast Receiver，Content Provider）构成。在Android环境中，System-Server和应用通过进程间通信交互，Android系统负责了四大组件的管理，包括创建，激活，销毁等。MultiDroid引擎实现了一套Android组件管理系统，用来模拟系统对Android组件的管理。每个运行在虚拟环境中的应用，会把自己的组件注册给MultiDroid引擎，由MultiDroid引擎负责各个组件的生命周期维护；
  4. 应用进程管理Android本身在应用和进程之间做了隔离，应用几乎不需要感知进程的存在，只需要关注应用自身的四大组件。但是应用本身还是需要在Dalvik进程中运行。虚拟环境中的进程仍然是一个Dalvik进程， MultiDroid引擎负责了虚拟应用进程的创建，进程ID的分配，进程的销毁等；
  
 - MultiDroid的未来发展：
 目前的MultiDroid引擎已经相当完善，可以很好的运行市面上的绝大部分App，而且在耗电和内存使用上都做了非常多的优化，但这只是起步，我们期望下一版的MultiDroid引擎将会从某种程度上改变Android本身的生态环境和使用体验，譬如支持整个虚拟环境的快照和恢复，发烧友就不用为了尝试各种新鲜玩法而反复刷机了，当然，还有虚拟环境内应用数据的云备份，类似iCloud，虽然有Android厂商也支持类似功能，但跨厂商的设备同步目前还没有；再譬如代码动态优化，虽然目前的MultiDroid引擎并没有性能问题，但我们希望可以借鉴ART的做法，通过在虚拟环境中的代码预优化和动态转换，来提升应用加载速度；同时，我们已经找到了一个办法把具有某些特征的dex字节码片段在虚拟环境中转为native指令来运行，性能的提升非常夸张。总之，MultiDroid打开了一个盒子，里面有无穷可能。

-- 实现双开（多开）的几种方案：
 1.静态修改APK包名，然后重打包
作为厂商肯定不推荐这个方式拉，可能存在法律风险
 2.动态修改APK包名
对原生代码修改量小，兼容性差，部分APP需单独适配
 3.动态修改进程的实例
对原生代码修改量大，兼容性一般，可能会导致系统一些乱七八糟的BUG
 4.通过多用户机制实现
MIUI的实现机制，更多的是修改多用户在相关的代码
 5.通过动态加载（运行）的机制来实现（LBE的平行空间）
作为第三方开发者，不能ROOT，不能修改系统源码，逼的LBE用这种方式，也是难为他们了

-- 不管是平行空间还是双开助手还是其他的类似实现，都离不开Hook技术。几种Hook技术：
1.Binder Hook，DroidPlugin；
2.Handler Hook，去看看ActivityThread.mH是干啥的就知道了；
3.Native Hook。就是文件系统Hook，比如：
 open("/data/data/${pkg}/", flag) ==>open("/data/data/http://com.lbe.xxx/yy/${pkg}/", flag); LBE用的是inline hook

-- 企业空间和原本用户空间
  使用Android原生接口，实现“应用双开”，源代码可以从 https://github.com/bobohuang1985/android-utils-api 下载，具体代码位置在utils.bobo.com.boboutils.MultiApp包内，

-- APK多开原理- https://segmentfault.com/a/1190000005139577
 packageName 在代码中使用，通常在 AndroidManifest.xml中指定，applicationId 则只是用于程序的标识，通常在 build.gradle 中指定。这样有一个好处，假如你想发布一个免费版，一个收费版，你只需要在 build.gradle 中把applicationId 后面加上免费版的后缀包名（如".free"），收费版加上收费版的后缀即可，而不需要修改你的其他代码。 
　　你可以通过使用以下的 Gradle DSL 方法，为不同的flavors和构建类型修改你的应用程序的 ApplicationId：
 productFlavors {
        pro {
            applicationId = "com.example.my.pkg.pro"
        }
        free {
            applicationId = "com.example.my.pkg.free"
        }
    }
    buildTypes {
        debug {
            applicationIdSuffix ".debug"
        }
    }
 改掉主配置文件中的包名和smali文件相关的包名后，虽然可以安装，但是并不能运行，最直接的一点就是改掉了主配置文件的包名，那些像百度地图，极光推送，环信聊天等第三方SDK就都不能用了，因为这些都是在开发者中心注册ID的，和包名是绑定的，所以用ApkTool工具反编译的APK并不是双开实现的工具。

-- 三星MY KNOX不仅仅是一个软件这么简单，它具有两大特性。首先就是安全沙盒机制，My Knox功能可以为需要安全保护的APP应用（如：微信、支付宝等）和信息（如：通讯录、相册等）提供一个独立的、与外界隔离的空间，从使用场景来看就是应用双开；其次是Root操作熔断机制，如果有人企图非法获取系统管理权，一旦触发Root操作，手机主板上的Knox“保险丝”会物理熔断，且不可逆转。

> DroidBox安卓沙盒
Android 双开沙箱 VirtualApp 源码分析（三）App 启动- http://blog.csdn.net/ganyao939543405/article/details/76177392
针对Android沙盒的“中间APP攻击”- http://blog.csdn.net/qq_27446553/article/details/56674931

  App沙盒/双开技术是现在仍处于发育时期的未成熟技术，它的目标是使一个未安装的APK直接运行在一个容器当中，与外部环境部分隔离（或完全隔离），处于沙盒之中的App无法觉察到自己的环境与普通运行时的环境有所不同，并能够与沙盒之中的其它App进行交互。概念上来讲，它类似Docker。
  
-- App沙盒的难点主要有：
 1.欺骗 App，让其认为自己运行在正常的环境中。
 2.完整得驱动四大组件。
 3.让组件的进程分布与实际完全一致。
 4.随时与处在沙盒外部的容器和宿主(Host)进行同步的远程通信。
 5.兼容不同系统API版本的设备。
 6.SD卡隔离(Native IO Redirect)。