get rid of the ads and the bloat, no mistakes

A few minutes later they're posting screenshots of a clean home screen. TechCrunch called it making smart TVs "dumb again," and Decrypt went with "vibe coding your TV." The idea sounds simple: point the thing at your TV, let it tidy up, nothing you can't undo, no root needed.

I have a cheap MagCubic projector that runs WhaleOS, a locked-down Android that ships on a lot of budget TV hardware. It's slow in a way that feels deliberate, and I mostly use it as a dumb HDMI screen anyway. So one evening I tried the trick from the posts: put it on the network, get a shell, clean it up.

It did not go the way those posts go. Twenty minutes of tidying turned into a couple days, because every door the demos walk through was bolted shut on this one. I don't regret the time I spent on this. It was a good puzzle.

No easy way in

The plan was ADB: turn on developer options, enable USB debugging, sideload from there.

This box runs a vendor Settings app, not Android's, and the developer path through it is half gone. There's no build number to tap seven times. A separate "Developer Tools" app from the app store opens, but clicking anything the vendor stripped out just doesn't work or even crashes it. Wireless debugging is the clearest tell: the toggle is there and selectable, and the moment you touch it the switch turns on, thinks for a second, and slides back to off.

Trying to install an APK off a USB stick did nothing. No install, no error, not even a dialog. Flashing a signed recovery image got me the one straight answer the device ever gave:

Download is not allowed on locked devices

The bootloader is locked with no unlock in any menu, secure boot is fused on in HW, verified boot is enforcing. Every published way in was a wall, and most of them were walls someone built on purpose. Nobody ships a settings app with its developer menu unreachable by accident.

(For anyone with the same box: a MagCubic sold as HOTACK SMART2KPJT, Amlogic T5D, Android 13, WhaleOS build from mid-2025, seventy euros in July 2025. If that's roughly your projector, the rest might apply to you as well.)

I'd owned it over a year. The reasonable move was to live with a slow screen or get a new one. I did neither.

Borrowing a shell

If the OS won't give me a shell, I can build one out of software I'm allowed to run. None of this is a vulnerability, just ordinary features used off-label:

• The casting app speaks DLNA. Started and paired from the couch, it will inject a key press or launch one of the manufacturer-approved apps on request.
• Cx File Explorer has a FTP server. Switch it on, you get read/write to shared storage, but nothing privileged.
• Kodi has a JSON-RPC remote and runs add-ons, and add-ons are Python. This was my way in.

An add-on runs inside Kodi's process, next to Kodi's Java VM, and Python plus that VM is enough to call Android's system services from a program built to play video. That got me a shell on a device that wouldn't hand me one.

I did most of this with AI coding assistants, same as the TV posts. One thing worth passing on: Claude would now and then decide my work looked like attacking someone else's device and stop. Fair enough, it can't tell my projector from anyone's. Each time it balked I handed the task to one of the Chinese open-weight models, which don't hesitate here. This seems to be a universal experience.

Three wrong turns

The shell wasn't root. The app it ran as couldn't touch admin commands or other apps' data. What it could do was start any exported activity on the device, including several the vendor apparently forgot to remove before shipping, so I pulled every preinstalled APK off the box and started reading.

One was a factory test app: the spinning teapot I remember from my computer graphics lectures, a wall of diagnostics, all in Chinese. I translated it, clicked everything, got nothing.

The vendor's settings app looked more interesting. It had a real ADB toggle I could flip. ADB was enabled now, but still wouldn't let me connect, because the approval screens live in SystemUI and aren't in this build. Another thing I flipped on, factory mode, as far as I could tell, did nothing: the box rebooted and looked identical.

There was also a longer detour trying to push a modified app through the device's own store. Its update channel is more trusting than it should be, which I'll write up once the vendor has fixed it. It didn't get me in.

At some point, a few more dead ends later, getenforce in the shell said permissive. SELinux had stopped denying anything, and I assumed that factory switch had done it. Not directly. Factory mode is a byte in the bootloader environment, and the init binary is patched to force permissive whenever it sees that byte; the menu only writes the byte and triggers a reboot. An ordinary app can only run my commands while SELinux is permissive, so when the box later came back enforcing I briefly lost my mind.

Getting root

The service that mattered is system_control, a vendor daemon Android builds from Amlogic ship: it starts as root, exposes ISystemControl over binder, and exists so the manufacturer's own apps can do what a normal app can't. One of its calls copies any file to any path as root. A pair read and write root-owned files, text only, four kilobytes at a time, and the write side only takes sysfs paths. Another sets a byte in the bootloader environment. Nothing gated any of it but SELinux, and mine was already permissive.

Each call stopped a step short. The copier can't set a mode, which is why the key I planted for adb landed 0600 root and adbd, running as a normal user, couldn't read it. The readers are text and four kilobytes, so a whole log is out; the writer only follows sysfs, so a binary is out too.

Up to this point I only knew transaction numbers for methods some vendor app already called. The file copy let me pull the device's own copy of the library that talks to the service, and disassembling it gave the whole list: 364 methods in 1.0, 25 more in 1.1. One of those 25 is systemCmd. I handed it a string:

id → uid=0(root) gid=1000(system) context=u:r:system_control:s0

Root. No adb, no patched boot image, just a vendor service doing exactly what it was built to do, from a Python add-on inside a media player.

Root first buys you the ability to see. The APK install failures that had been invisible for two days were one command away:

INSTALL_PARSE_FAILED_INCONSISTENT_CERTIFICATES ("mismatched zeasn certificates")

There was the real gate: a second signature. The package manager wants a vendor APK Signing Block, an RSA signature over the APK made with Zeasn's key, and a self-signed app doesn't have one. The vendor signs every app in the store again, and even with root I couldn't touch the key it verifies against, or the code that runs the verification. I almost decided this was the end of the road.

It wasn't. With the verifier code decompiled, I read how the check runs, and it only runs when two system properties say so. One is a general partner-build escape hatch. The other skips the signature check and lifts the package manager's refusal to pm install on a user build at all. Two guards, one flag, and the flag has a wonderfully non-descriptive corporate name:

setprop persist.sys.concert.tinsel 1
pm install my-self-signed-app.apk
  → by this brand, open function
  → Success

Any self-signed app, no vendor block, no signing key, no reflash, installed on a locked device. All I had to do was flip one property the manufacturer left in the build, probably for partners shipping a less locked-down variant of the device.

Making it survive a reboot

All of this lived in processes. The root channel ran inside Kodi, Kodi doesn't restart after a power cut, and a cold boot cleared factory mode, taking permissive with it. Something I have to walk over and restart by hand isn't much of a jailbreak.

Reflashing is out: a patched boot image won't boot against a locked, verifying bootloader. But the bootloader environment is just name=value pairs, and one value is a script it runs every boot. On a cold boot that script clears factory mode, which is why permissive kept vanishing. I edited it to set factory mode instead, one 0 into one 1, and swapped the Kodi dependency for a small app that reopens the root channel when Android starts.

Writing that script wrong is how you make a box that won't boot, so I read it back very carefully.

Then the test. Pull the plug, wait, plug it back in. It came up permissive, root listening on SSH, no laptop, no remote, nothing from me. I did it again to be sure.

After that, the cleanup I'd wanted on day one took ten minutes. Lighter launcher, preinstalled junk gone, about a gigabyte back. The panel shipped with a yellow cast, so I dropped the colour temperature until white was white. Then I pointed a game-streaming client at my desktop: it mirrors now at around eight milliseconds, a pretty nice place for a seventy-euro box to land, and the first time it has felt fast.

Isn't this a security nightmare?

Someone always asks, so: nobody can turn this chain against your projector from outside. It needs a shell and code execution on the device, which don't exist on a stock box; they're on mine because I put them there. It needs permissive mode, which comes from factory mode, which you can only switch on standing in front of the projector with the menu open. There is no network path to that. An attacker would need to be on your network, you'd need to have already rooted the thing yourself, and they'd need to physically flip factory mode. At that point, this chain is the least of your problems.

The one piece that does touch a stock projector is that store update channel. It's reachable by anyone on your network, no cooperation from you, and it's the part I reported to the vendor before publishing and am holding back until they fix it. Everything else here needs you, your consent, and your hands on your own device.

Why bother

It's a seventy-euro projector and I could have bought a Chromecast. True. But what stayed with me wasn't the root shell. It was the service underneath it: running as root, callable by any app on the box, undocumented, and nobody had mentioned it. A path I'm not allowed to use is one thing; a privileged one I'm not allowed to know about is a different one.

This is my device, on my network, built with a locked-down path nobody told me about and an override switch left in the off position. Right-to-repair usually gets argued over tractors and phones, but it's the same idea for any device in your home: you should be allowed to understand and change the thing you own.

There's an unhappy version of this where the manufacturer reads it, patches the switch, and everyone with one of these projectors is locked into the slow stock UI for good, fixing nothing real since none of it is a remote threat. I'd rather the other version: a few more people with the same box flip the same switch and get a fast projector out of a slow one.

If that's you, the tools are on GitHub.