Droidception
The question has popped up on Stack Overflow a few times: how the heck does
Parallel Space
do what it is doing?
Parallel Space allows the user to have N copies of your app, each with its
own portion of internal storage. The user could then register as Foo in one
copy and Bar in another, and use each copy of the app independently. This does
not require Android for Work, Samsung KNOX, or any other hardware-supplied
partitioning system ��� Parallel Space is just an ordinary Android app.
LBE Tech, the firm behind Parallel Space, has not said much about how they do
it, other than it involves ���MultiDroid, the first application virtualization
engine on Android���. And I have never used Parallel Space personally, let alone
attempted to examine it (though
others have).
My guess is that this is a commercialization of
Boxify,
or at least an implementation of the same concept.
If somebody asked us what our Android apps run on, our initial response might
be ���ummmm��� Android?���, as the answer seems obvious.
However, most apps do not really interact much with Android, the OS, directly.
When you get past all the Java, most things in Android eventually hit one of
two things:
an IPC call using Binder, which covers everything from system services to
starting activities
a native call to a JNI-style C/C++ library linked into our app, including
many such calls that come from framework code
Boxify, in effect, proxies both of those through its own app.
The details are in the Boxify paper.
In a nutshell, Boxify:
Forks a process
Loads your APK into that process
Replaces a lot of system service implementations, like ActivityManager
and PackageManager, with its own implementations that route the IPC through
Boxify
Uses ���syscall hooking��� to replace necessary system calls with others that,
again, route through Boxify
Runs your tweaked-in-memory app (notably, nothing Boxify does requires modifying
the APK itself)
So, for example, let���s think about disk I/O. Usually, we find out where to write by
calling methods on Context or Environment. Those, in turn, wind up returning
paths supplied by Boxify. When you try to open a FileInputStream or something,
the Linux syscalls triggered by that I/O also route through Boxify, as it
leverages android:isolatedProcess to carefully manage what capabilities the
APK can actually perform, and so your app would not be able to write to
disk otherwise.
Boxify, itself, was written as a proof of concept for running apps in dedicated
sandboxes, particularly for ���untrusted apps���, to use the authors��� term.
However, this sort of virtualization technique ��� Android apps running inside other
Android apps, for an Inception-style
experience ��� requires that you trust the virtualization engine. After all,
by definition, it can see all I/O between the app and Android, as it proxies
all of that I/O. It is a MITM attack on the app.
I have little doubt that such virtualization
can be put to plenty of positive uses. At the same time, I sincerely hope that Google
and independent security researchers examine any such virtualization app, to
���trust, but verify���, to use the Reagan-era maxim.
However, this illustrates yet another way ��� on top of custom ROMs, emulators,
and related tricks ��� where a user can arrange to run your app in an environment
that the user controls more than they do a standard Android environment. That,
on top of standard rooting techniques, further emphasizes that
you cannot defend yourself from the user. DRM solutions and related techniques
are difficult to secure when the user controls the entire environment around
your app. Treating the user as the enemy might work for a majority of users,
but those who might really be your enemy may well be able to work around
whatever DRM-style protections you add. These protections resemble
the Maginot Line: strong defenses
against predictable attacks that may prove useless with a nimble adversary.
IMHO, you are better served finding a business model that does not require you
to treat the user as the enemy.
