In the previous blog post, I wrote about remote unlocking of LUKS encrypted rootfs with tailscale on Arch Linux. To be honest, there are already a lot of blogs and wiki pages about remote unlocking of LUKS encrypted rootfs. But it seems that no one write about remote unlocking of Android phones with tailscale. There are quite a lot interests in running linux tailscale daemon on Android, for example,

• Magisk-Tailscaled
• A github issue in tailscale repo
• A fork of tailscale for Android
• An issue about tailscale in termux
• My previous attempt which runs tailscale daemon to provide a SOCKS5 server for clash

But the above solutions does not provide a full-featured tailscale experience because they all use userspace-networking instead of tun and thus does not work transparently.

By full-featured, I mean that

• Tailscale is directly integrated into system routing decisions.
• You can use another Android VPN app with it without any special configuration.
• Tailscale SSH works, so that you can get a remote shell of your phone.

Of course, there are currently some non-working features like MagicDNS. But I don’t think that is technically impossible. Personally I disable MagicDNS on all my devices and thus I won’t work on getting it work.

Why

Don’t ask me why. Who don’t want to access their devices from anywhere? And it could offer some degree of help if you accidentally lose your phone.

More importantly, if you decided to go crazy and self-host some services on an Android phone, tailscale would provide an easy way to access them since usually the phone won’t get a public IPv4 address. (You can even try more crazy stuff like reverse proxying it via an nginx server running on a VPS)

A Quick Refresher on Android FBE

This blog post will use /data/tailscale to store tailscale state. To better understand the rationale and implication, let’s have a quick refresher on Android FBE:

Current Android phones encrypt the userdata partition with file-based encryption instead of full disk encryption like LUKS. This approach provides more flexibility because different files can be encrypted with different keys. On Android, there are two classes of storage used in FBE,

• Credential Encrypted (CE) storage, which is only available after the user unlocked the device.
• Device Encrypted (DE) storage, which is available before the user unlocks the device. (But it is still encrypted!)

/data/tailscale will be in Device Encrypted storage, which means that we can have tailscale daemon running before the user unlocks the device (Great!). But this also means that the tailscale secret keys are not protected by your Android password.

Requirements

First, the only hard requirement:

• A rooted Android phone (I only tested it on Android 15, but it should work for recent Android releases)

Then, here are some soft requirements only necessary if you want to follow this blog’s approach:

• You are building the Android system you use from source.
• You are familiar with building Android system from source

If you don’t meet the soft requirements, don’t worry. There are other ways to do it like writing a magisk module.

Patching Tailscale for Android

I have created a fork of tailscale for running a full-featured daemon on Android. This section explains some of the patches in that fork. So you may just skip this section if you are not interested in the technical details.

The tailscale daemon is written in golang. It already contains support for GOOS=android with the intention to be used in tailscale’s official Android app. The code base already has lots of branches for handling Android quirks. Some of them only applies to official app without root permission, while others apply to Android platform in general.

We would need a linux like tailscaled instead of a binary to be used within the official app. There are two ways to move forward,

• Build with GOOS=linux and update the code to handle Android edge cases
• Build with GOOS=android and update the code to align the behavior of Android to Linux.

Both approaches are reasonable to some degree. I randomly chose the second approach.

Aligning the behavior to Linux

This is the boring part. Update go:build directives and if/switch branches to use linux code for android. For example:

Carefully handle IP rules

Tailscale uses quite a few IP rules where it seems that just a single rule would suffice.

They actually justified it in the comments:

So they are using a complicated approach to support old kernels and old ip rule implementations. Sounds fair.

But let’s review the complicated approach when we use it on Android. Here is what we get:

The sutle problem is that Android comes with its own set of complicated ip rules. If a packet is marked by tailscale’s bypass fwmark, by rules with pref 5210 and 5230 it would directly land in the main and default routing table, bypassing all Android system rules with pref higher than 10000.

The solution is simplifying the rules as I do not need to support old kernels or ip rule implementations:

Handle Odd iptables Implementation

go-iptables is relying on the error message from iptables to detect if the error is just complaining about the target does not exist.

Somehow Android’s iptable implementation returned another error message when the target does not exist. This made go-iptables mad and throwing a hard error instead of a recoverable non-existent target error.

I have made a pull request to fix it: https://github.com/coreos/go-iptables/pull/132/

Replacing the Defaults

Nothing interesting, we are just setting the default socket path to /data/tailscale/tailscaled.sock and state dir to /data/tailscale.

Fixing Tailscale SSH for Android

Tailscale SSH is disabled for Android. Just fiddling with go:build directives to enable it won’t work because /etc/passwd and /etc/group are shameless lies in Android. (See it for yourself by running cat /etc/passwd in adb shell)

There is no silver bullet to make it work with Android. But we do have a silver lining. For a shell in Android, most of the time we are referring to adb shell. The adb shell has a fixed user shell(Unless you count rooted adb in). And the system group ids and user ids are statically allocated.

So let’s just hardcode it into tailscale ssh code and call it a day.

Creating An Android Init Service

To make tailscale daemon start as the system boots, we need to make it a service. (Just like we use tailscaled systemd service on Linux). But there’s no systemd on Android. All we have is a simple(compared to systemd) Android init system.

Refer to its documentation if you wish to learn more.

Build and Install the Binaries

Initially I thought I could build and install tailscale binaries by writing a soong blueprint.

But it turns out to be impossible because blueprint_go_binary build rule only supports building go binaries for the host, not the target system.

So let’s just build the binaries outside AOSP’s build system and use cc_prebuilt_binary to include them into the system_ext partition of the target system:

The prebuilts are available in https://github.com/android-kxxt/external_tailscale_prebuilt

The Service

We will write an rc file called init.tailscale.rc in Android Init language.

Here is its content, assuming tailscaled is installed to system_ext partition:

It is quite self-explanatory. We are starting the tailscaled service on boot trigger (Sadly there is no equivalent to network-online.target), with logs redirecting to kmsg and running as root. (Setting the capabilities alone won’t suffice because it would need to invoke iptables).

Sepolicy

For the service to work, we also need to apply appropriate sepolicy to it. Please refer to a blog post from LineageOS project for a quick intro on SELinux on Android if you are not already familiar with it.

It is in general very hard to write a suitable sepolicy for tailscale daemon, which needs to spawn tailscale SSH shells and execute iptables with NET_ADMIN capability.

Here we will do a little cheat to run tailscale daemon in a permissive domain, which means that it will just ignore all SELinux rules.

Include It Into the Build

Now it is time to include it into the AOSP build:

Then we can build an OTA package and sideload it in recovery. (Or alternatively, if you are already on a recent build, mka systemextimage and flash it in userspace fastbootd)

Run It

After flashing the OTA package, tailscale daemon should now starts as the phone boots. But we haven’t logged in.

Tailscale Authentication

To log into tailscale, we use tailscale cli as usual.

Open an adb root shell and run

• --accept-dns=false: MagicDNS does not work so disable it.
• --ssh: Enable tailscale SSH.
• --accept-routes: Tailscale subnet router. Just my personal preference.

By default this device will be called node in the admin console. Now it is a good time to rename it.

And you may want to disable key expiry for this device as well.

Tailscale SSH ACL

Mobile devices contain highly sensitive information. Allowing any devices in your tailnet to access it is a bad idea in general.

So let’s setup strict ACL rules.

I am tagging my personal devices with personal tag and personal mobile devices with personal-mobile tag. I plan to allow personal devices ssh into personal-mobile devices. But unfortunately, the following ACL rules do not work.

Tailscale shows an error message: "check" action does not support tags in src.

So I decided to allow any device to try to ssh into personal-mobile devices but require a re-authentication for every SSH connection:

This also does not work. A tagged node isn’t part of autogroup:members, tagged nodes are not associated with a User.. So tailscale SSH ACL rules really sucks. For the purpose of this blog post, I will just use an accept rule:

But I will use a dropbear ssh server and disable tailscale SSH for mobile devices in the future.

Service Management

This section is primarily for those who are not familiar with how to manage init services on Android.

As we all know, systemctl start/stop/restart can be used to start/stop/restart a service on Linux (Well, at least on distros with systemd).

The equivalent command on Android, is setprop ctl.start/stop/restart (And the wrapper program start and stop). For example, to stop tailscale daemon, simply run stop tailscaled, to restart it, run setprop ctl.restart tailscaled.

Remote Unlocking

Remote unlocking is no longer a hard problem once we got tailscale daemon working before the user is asked to unlock the phone(to decrypt credential storage).

With tailscale, we can do remote ADB debugging. And scrcpy even enables you to interact with the device over ADB.

Enable ADB over Network

In Android settings, there are not direct way to enable adb over network. However, there is a toggle called Wireless debugging in Developer options. It could only be enabled if the device is connected to Wi-Fi (Yes, you cannot enable it even if you start a hotspot on your phone). But when it is enabled, it actually listens on other network interfaces as well.

This odd setting has become more and more annoying on recent Android releases. Recent Android releases ramdomize the port of ADB service.

But fortunately, we still have other ways to enable ADB over Network persistently with a fixed port.

Open an ADB root shell and run the following command:

Then reboot your phone. (or just run setprop ctl.restart adbd to restart adbd). ADB should now also be available on tcp port 5555.

Exposing ADB to public network seems to be a bad idea even though ADB has public key based authorization.

ADB actually supports another property called service.adb.listen_addrs that could limit the IP address to listen on. But sadly it does not check persist.adb.listen_addrs and I don’t think it would work with tailscale service because ADB daemon starts before the tailscale interface is up.

Well, at least we can still use iptables to restrict it.

Remote ADB Authorization

Now, what happens if you are away with your android device. But the adb server on your laptop is not authorized.

Well, you could cheat it by transferring the adb key from an authorized machine to your current machine.

But we already have tailscale SSH access to the phone. If you can elevate to root in tailscale SSH shell (using Magisk su or KernelSU for example), you can also append your current adb public key(~/.android/adbkey.pub) to /data/misc/adb/adb_keys.

Remote Unlocking

Now it comes to the simple part. First, reboot the phone so that CE storage is encrypted.

Let’s try to unlock and control it remotely.

We will use scrcpy, a popular tool to view and control an Android device over ADB. Of course nothing stops you from unlocking it programmatically through the input command:

First, let’s connect scrcpy to the Android phone’s TCP adb server over tailscale:

Then right click on the scrcpy UI to wake up the screen of the Android phone. Here is what we get:

Now we can unlock the phone as usual. Well, it is not entirely as usual because when you swipe up to unlock your phone, you can no longer see the UI in scrcpy because that is forbidden for the sake of security.

But still nothing stops you from unlocking it as the input still works. You can blindly click the buttons on the screen or blindly draw your unlock pattern. Just joking, if you are using PIN or password, you can just type it on your keyboard and press enter. Well, if you are using with pattern lock, good luck with that.

Now CE storage is unlocked and you can enjoy remotely using your phone over scrcpy over ADB over tailscale.

Security Concerns

We are not finished yet. Before you adopts the approach in this blog post, I still have some security concerns to state.

Concerns about Using scrcpy Remotely

It might looks cool to unlock and use your phone(or whatever Android device) remotely. But if someone sees that a phone unlocks its screen by itself they might think the phone is hacked. And they can also freely access the phone after you unlock it remotely.

You could use scrcpy --tcpip=XXX:YYY --new-display to use a virtual display after unlocking the CE storage(first screen unlock after boot). (And BTW, a new display is also very nice since we could use different display dimensions. e.g. --new-display=1920x1080)

But to unlock the CE storage, you cannot use --new-display. This means that when you are remotely unlocking the CE storage, an attacker with physical access to the device could take over the control of the phone.

So make sure that the device is put at a physically secure location if you want to use it remotely. And after unlocking the CE storage, restart scrcpy with --new-display to use a virtual display instead of the device’s physical display.

Concerns about Tailscale Daemon

Tailscale daemon is running as root and with a permissive SELinux context, this does not match the general Android security practice. But it is what we get on most Linux platforms.

It should be possible to write proper sepolicy for it(but with a bit of modification to Android system sepolicy).

Concerns about ADB Over Network

The instructions in this blog post exposes ADB service to all network interfaces of the phone.

Although adb implements authorization, you may still want to limit it to tailscale interface using iptables.

Wrap Up

Thank you for taking time to read this long blog post. Hopefully it could be helpful.

Here are some links to the repositories used in this blog post:

• Patched tailscale: https://github.com/android-kxxt/external_tailscale
• Prebuilt binaries of patched tailscale: https://github.com/android-kxxt/external_tailscale_prebuilt

If you are not familiar with building Android system from source and modifying it in source form. You can still achieve it by writing a Magisk module.