Controlling application Separation

From: http://mylifewithandroid.blogspot.com/2009/06/controlling-application-separation.html

 

I thought I knew how application separation in Android works. Then I had
Little project and I realized that there is more than meets the eye. Here are my
Experiences.

The basic-and very efficient-Separation Method in
Android is the Multiprocess capability of the Dalvik VM. Dalvik is able to fork
Many instances of itself and can run applications in different Linux processes.
By default, each application (Application

Tag in androidmanifest. XML) has its own process. There is however another, often
Overlooked separation mechanic inside

Each VM process that provides further separation. The good old classloader
Separation-originally designed to separate applets, used heavily in
Multi-module frameworks like osgi-is also at work. inside each VM process,
Each task-acitivity or service-uses in its own classloader. This means that
Object instances created in different tasks are not visible to each other.
Standard Setup for Android applications is such that the classes. Dex in
Application's APK package is on the path of the application's own classloader.
The application's own classloader delegates the loading of system classes to
Boot classloader instance which is common for all the tasks in one particle VM
Process.

Class loading implementation in Dalvik is tied heavily to Dex
Files. This has visible side effects. Classes loaded by different class loaders
That don't delegate to each other shoshould be completely separated.
Implementation differentiates the "initiating" and "defining" classloader (
Latter is the one that managed to call defineclass () for a participant class from
A participant Dex file in a participant VM process). This differentiation does not
Work very well and results in a glitch: Once a class from a participant Dex File
Is defined, its static fields are visible and shared from all the class loaders
That access the DEX file, even if they don't delegate to each other. This means
That tasks of the same application (usually packed into the same Dex file) See
Each other's static fields.

As if this was not enough, Android provides
Control of task-VM process mapping. As said previusly, usually each application
Goes into its own VM process. It is possible to declare, however, that
Applications share a process. This works like the following:

• First we declare that applications wishing to share the same VM Process
  Belong to the same user ID. This is done by addingShareduserid
  

  Attribute toManifest
  
  Tag
  In androidmanifest. xml file like the following:Android: shareduserid = "AEXP. Share. sharedapp"
  
  .
  The value of the attribute must be a unique string shared among the applications
  Wishing to use the same VM process. This is a powerful mechanic, hence android
  Enforces strong check of the apks containing the Declaration. Only the first APK
  For a special shareduserid can be installed without limitation. The issuer
  The digital signature of that APK is saved and further apks with the same
  Shareduserid must have digital signature from the same issuer, else their
  Installation is rejected.

• We have to declare the alias of the process a certain task or the entire
  Application goes into withProcess
  

  Attribute. This attribute can be addedApplication
  
  ,
  Activity
  
  Or
  Service
  
  Tags
  In the androidmanifest. xml file. For example:Android: Process = "AEXP. Share. sharedappprocess"
  
  .
  VM processes are proper Linux processes identified by PIDS but Android does
  Additional Transformation: Whenever a process is started which is tagged by
  Process
  
  Alias,
  The android framework saves the Linux PID and the process alias. If some other
  Application refers to that process alias and the VM process is still running,
  That process will be used.

How can we exploit this mechanic? We can
Create ordinary, well-behaving Android applications and place them into the same
Process. Android IPC is such that the usual binder-based
Communication
Is much faster in this case. The other approach is that we
Exploit our knowledge about class loaders. If we place two applications into
Same process, they not only have different class loaders but also come from
Different Dex files. This means that the android class loading glitch about
Static fields cannot be exploited (I don't recommend it anyway as it is a clear
Bug and I believe, it will be corrected soon). We know, however, that each class
Loader in the same VM process delegates the resolution of the System Classes
The boot Class Loader. If we find a system class that allows us to store and
Retrieve data, we win.

 

Click here to download
The example Program
.

 

Our two example programs demonstrate the techniques described below. sharedapp1
Allows the user to enter a string and it shares that string in different ways.
With its own popup, it shares the string by means of a static field
Sharedapp1 activity class. sharedapp2 is another application, having its own APK
File but is placed into the same process as sharedapp1. sharedapp1 and
Sharedapp2 communicate through the good old system. getproperty/setproperty
Mechanic. Observe, that this works only if the shareduserid/process mechanic
Is properly used, if you remove e.g. The process attribute from the manifest
File of any of the apps, the property set by sharedapp1 is not visible anymore
To sharedapp2 because they run in different VM processes. Also note that I
Compiled these applications with the debug option which means that they are both
Signed with the debug key. That key is common for both applications therefore
They can have the same shareduserids. If you use a proper Signing Key, take care
Of using the same key when you sign applications that depend on the shareduserid
Mechanisms.