DPHMS · comparison · 6 November 2026

Root versus uid 2000

Root does more than we do. That is the first true sentence in this comparison and it will not change later. What changes is the price you pay for it, and whether you can undo it on a Tuesday afternoon.

1. What root actually is

Root is uid 0: the kernel's owner. Getting there on a locked Android phone means modifying the boot chain - patching the boot image with Magisk, flashing KernelSU or APatch, unlocking the bootloader somewhere in the middle of that. Once the kernel hands you 0, SELinux is the only thing left between you and everything, and most root solutions set it permissive or punch a hole through it.

Our whole suite runs at uid 2000, the shell user, which already exists on every Android device and already has a meaningful set of powers on purpose. No boot image is touched, no bootloader is unlocked, verified boot stays intact.

2. What root can do that we cannot

Straight list. If any of these is your actual requirement, root is the correct answer and we are not it.

• Write to system partitions. Replace system apps, push files into /system, modify the framework. We cannot: verified boot rejects it and the shell has no write access.
• Kernel-level work. Load modules, change governors, alter I/O schedulers, add netfilter rules that block by process. We can set policy through cmd, settings and svc, not through the kernel.
• Read any app's private data. Another app's /data/data and its storage belong to it. The shell is blocked by SELinux just like a normal app is.
• Hook other processes. LD_PRELOAD, Xposed, Frida, in-process instrumentation. None of that is available to the shell user.
• Full block-level backup. Reading raw partitions, cloning /data, restoring a system image. Our apps cannot and will not.
• SELinux permissive mode. Turning the policy off, which is exactly the door we refuse to open.
• Survive a reboot silently. A root daemon starts itself. Ours does not: after a reboot the shell server needs re-arming, which is a deliberate cost of not owning the boot chain.

3. What the shell user can do, which is most of what people actually want

This is the part root guides never say plainly: uid 2000 is not a weak account. It is the account adb shell uses, and Android hands it the real controls.

• Radio and network control. cmd phone for preferred network type and band masks, svc data and svc wifi, airplane cycling, private DNS through settings - with an ordered candidate list per vendor, printing which one answered.
• Permissions and appops. pm grant, appops set and a read-back that proves what took effect. Taking permissions away from an app is a shell power, not a root power.
• Installing apps. pm install-create and install-write stream an APK into the session installer. No popup, no account, no root.
• Device policy, force-stop, doze. dpm, am force-stop, dumpsys deviceidle.
• System settings. settings put across global, secure and system namespaces - the same knobs most root tweak apps flip.
• Input, capture and inspection. input keyevent, screencap, dumpsys, logcat.
• Running a server at 2000. That is how Tunnel holds the shell: a small server process started once, listening on a keyed socket, doing the work at the same privilege adb shell would have.

4. The comparison, in the terms that matter

5. The security argument, stated honestly

Root's problem is not that it is dangerous in the hands of someone careful. It is that it removes the boundary between one app and the entire device, and it does so permanently and invisibly. An app that asks for root gets everything: every other app's data, every account, every key. There is no narrower grant, and the grant does not expire.

The shell user is still powerful, but it is confined: SELinux still applies, the app's own sandbox still applies, and the things it cannot touch are the things that would destroy the device if mishandled. On top of that standing limit we add house rules - one door, a server that checks the caller's certificate against the house key, a key per house app, a printed rung for every command, and a stop switch that persists.

Root is a master key for the whole building. The shell is a set of keys to the rooms you actually use. We sell the second one, and we say so.

6. When we tell people to go root instead

If you need system partition writes, kernel modules, per-process kernel firewalls, in-process hooks, or a block-level backup, root is the only answer and no amount of clever shell work will replace it. We would rather lose the sale than sell a shell app to someone who needed a kernel module.

If what you want is to make your phone obey you - control the radio, take back permissions, install without a popup, force-stop what misbehaves, audit what an app can do - that is shell work, and it does not require breaking your device's boot chain to get it.

7. What we are not claiming

• Not that shell is as powerful as root. It is not, and section 2 is the list.
• Not that a shell app cannot be abused. It can; it is one door, but it is a door.
• Not that our builds are hardware-confirmed. Every claim here comes from signed APK bytes, live endpoints and a documented ladder, which is a real limit and printed on purpose.
• Not that root is bad. Root is honest about what it is. So are we.

GET TUNNEL - NO ROOT READ THE TRANSPORT PAPER RSS

Delivery links expire after 30 days by design. An expired link is not a lost purchase: send the receipt and the house issues a new one.