In all our previous sections, we have discussed how apps are built and run in detail. Hello everyone, welcome back again. Today, in this section, we will be going to understand Android app sandboxing. This mechanism ensures the security and isolation of each application within the Android ecosystem. 

Let's delve into the intricate layers of app sandboxing to gain a comprehensive understanding.

Understanding User IDs per Application

You're probably aware that Android is based on the Linux Kernel. The way users are kept separate in Linux also applies to Android but with a slight twist. Let's break it down by understanding how User IDs (UIDs) are given to processes on regular Linux systems.

As usual, we're on a Kali Linux Virtual Machine. To examine running processes owned by a specific user, we execute the command:

This presents us with a list of currently active processes associated with the user "kali."

To filter with specific processes associated with user “kali”, run the same command with grep “specify the process name”.

As you can notice, we can see both processes under the same User ID. But, it's different for Android apps. 

Every app on your device has its own unique User ID (UID). This makes sure that each app and its stuff are kept separate from others, like being in their own little sandbox. They can't reach each other's things.

To verify this, open a new terminal and run the command:

This will show you that each app gets a distinct UID. If you look at the first part of the output, you'll see that every installed app runs as its own user with names like u0_xx. 

For instance, the dialer app goes by the user u0_a14. You'll notice similar user names for other apps.

Remember, if two apps have the same developer key, it means, they can share data with each other.

The User IDs (UIDs) assigned to users are distinct and individual. For instance, the user u0_a14 corresponds to the UID 1723. 

To verify the correlation between users and UIDs on a rooted device, you can inspect the `packages.xml` file found in the `/data/system/` directory. 

It's important to note that the internal configurations of Android can differ, and therefore, this approach may not always yield precise results.

To grasp this concept better, let's take a closer look at the UID mapping for some apps. But before that, let me run a user-installed app to observe. 

After running the app, use the ps command and check the first column of the process.

In the provided example, the application resides within the user u0_a73. 

To delve further, we can investigate the underlying User ID (UID) mapping. Open the terminal and enter the command "cat," followed by the path to the `packages.xml` file.

However, the output might be overwhelming, so I'll paste it into a text editor for clarity.

From there, search for the app by its package name. Copy and paste the package name in the search.

 If you see the field userId="10073," it means that the app with the user u0_a73 is tied to the userid 10073.

Now, let's consider a pre-installed app such as "com.android.deskclock," which comes preloaded in the Android VM under the user u0_a14. 

Upon inspecting the `packages.xml` file, you will notice that it is associated with the userId 10051.

App sandboxing

Previously, we differentiated Sandbox on Android and Linux and then understood the UID per app on the Android app. Next, move forward to app sandboxing.

App sandboxing is like giving each app its own private room in the /data/data/ directory to keep its stuff. As we saw before, each app has its own rightful ownership of this space.

This setup is like separating each app's belongings into its own little box, or sandbox, within the /data/data/ directory. To see this in action, you'd need a rooted device or emulator since the /data/data/ directory isn't available to regular users.

To take a look, first get into your device's shell using adb. Then, head over to the /data/data/ directory by typing: cd data slash data/. Once you're in, run the command ls -l.

If you check out the file permissions, you'll see that each app's directory is owned by itself. And they're not open for reading or writing by other users. It's like each app's room is locked and only they have the key.

Can we break out of this protective sandbox? 

Well, according to Google, even though the app sandbox is strong, it's not completely unbeatable. If someone really wants to break out of it on a properly set-up device, they'd need to compromise the security of the Linux kernel – which is a big deal.

Here's, where we get into Android rooting. Rooting gives someone what's like a master key for an Android system. It's similar to having the highest authority or being the ultimate boss in a game.

In the world of computers, we call this "root" level the supreme user level. It's like being the king or queen of the system with the power to do anything. Normally, only the Android system's essential parts, like the kernel, run as this "root." But when you root your device, you're kind of opening the doors for all apps to have that same power.

So, imagine if everyone in your town suddenly became the mayor. They could change everything, including the roads, the buildings, and even the rules. In the Android world, when apps get this power, they can tinker with the system's core parts – the kernel and other apps. They can even mess with an app's personal space, the sandbox, by breaking out of it.

Just like in real life, having great power means great responsibility. But with great rooting comes great risk. It's a trade-off between freedom and security in the Android universe.

This compilation of insights provides us with a profound comprehension of the internal mechanisms of Android apps. Throughout this playlist, we've focused on grasping these internal workings, which serve as a foundational step toward delving into Android security. The objective of this playlist has been to furnish you with these pivotal concepts. 

In our forthcoming playlist, we'll explore the overarching strategies for targeting Android applications.

If you have any questions related to this article, feel free to write them in the comments section.