Rescuing a Scrapped Tablet for a Child

In front of me sat a General Mobile e-Tab 4 that had gone out of service. One of the school tablets from Turkey's FATİH era; written off from a corporate fleet, no longer running on anyone's inventory. A MediaTek MT8382, a micro-USB port on the side, built in 2014. The question was simple: does this thing go in the bin, or can it be put into a child's hands at home?

Let me draw a boundary up front, because this entire piece lives inside it. What follows applies to a device that has been decommissioned and is not going back to any institution. On a school or company device still on an inventory, still assigned to someone, still in active use, none of this gets done — and if it does, it isn't repair any more, it's something else. The only future my device had was an electronics waste bin; that's the whole starting point.

And this isn't a "how to break in" guide. I won't be handing out step-by-step commands, because that isn't the point. The point is: how much effort a tool is worth before you throw it away, where that effort goes, and what actually ends up working. Let me give the short answer first — what worked wasn't the cleverest method I tried. It was the plainest one, the one I left for last.

I'm writing all of this from my own notes. The work didn't finish in one sitting; it spread across several evenings. I recorded each step as it happened, and I'm adding nothing here that isn't in the record. So there's no heroism here and no unbroken run of success. There are plenty of dead ends, because that's genuinely how those evenings went.

Two locks I mistook for one problem

There were two independent obstacles on the device, and it took me a long while to tell them apart.

The first was the corporate management layer: an "institutional first registration" screen on boot, with no way past it until the device enrolled with an institution. The second was EBA's single sign-on component. Unable to reach the institution's server, it crashed continuously; close the "has stopped" dialog and it reopened immediately. The screen drowned in those dialogs.

Because I took the two for one problem, my first plan was a single piece too: wipe the device completely, install clean software, done. But one was an enrollment lock and the other a crashing system app. Different doors, different keys. The most expensive mistake I make when solving anything has always been this one: filing two separate problems under a single name and hunting for a single fix. This tablet made me repeat that lesson at the cost of several evenings.

The first door that closed

On MediaTek devices, the well-known route is to enter the chip's lowest-level boot mode and rewrite the storage from scratch. It's powerful, because it doesn't care what's currently installed; it works from a floor below.

That door never opened for me. When I tried from an Apple Silicon Mac, not even the initial handshake that establishes the connection took place — I got a handshake error. I tried other operating systems, other modes. My note reads, verbatim: it didn't connect on any operating system or in any mode. Anything beyond that meant opening the case and working with the test points on the board. That wasn't a price I was willing to pay for a device I was putting together for a child. But the tablet still powered on. It wasn't bricked. One door had closed, not all of them.

Two machines, one tablet

The second idea was smarter: if the bottom floor is shut, I'd hand the device a signed software package from the outside, through recovery mode. But first I had to get in there.

Entering recovery means powering the device fully off and holding power and volume-up together, until an Android robot with its belly open and the words "No command" appear. It sounds simple, but you don't hit it on the first go; it took a few attempts. Once I also lingered on the wrong menu line and found myself at a format confirmation screen; I backed out without confirming. One wrong tap on that screen could have ruined the only physical copy I had, irreversibly.

The real oddity was how many separate environments this took. The Mac was already out of the picture at the lowest-level mode. And to talk to the device in recovery I needed its USB driver, which was unsigned; it could only be installed through a graphical interface by clicking "install anyway" — it couldn't be done from a remote command line. So: I pressed a Windows 7 machine into service, plugged the tablet into it, and connected to that machine over SSH from my own. From a Mac, over SSH, to Windows 7, and from there over USB to a tablet made in 2014. In a later stage a Lubuntu live USB joined the chain too; I copied the Linux adb binary over from the Mac rather than downloading it, because the package manager was crawling.

Two machines and three separate environments, for a child's tablet. This is the truth of working with old hardware: what has rotted is usually not the device itself, but the chain of tools that can still speak to it. The tablet was built in 2014; the drivers, protocols and helper programs that make it talk froze in roughly that same era. A modern computer no longer knows this dialect.

The wall of signed ROMs

The room I had inside recovery mode was quite narrow. Stock recovery offered me only "send a package"; when I tried to open a shell on the device and do anything by hand, the connection closed outright. I could get in, but I couldn't touch anything. All I could do was hold out a package from the outside.

First I downloaded the official ROM; it sat openly on the state's own content server. Then I went looking for a version of it without EBA.

And here I learned the thing the internet had not taught me. Android's recovery doesn't install a package handed to it blindly; the package has to be signed with a key the device trusts. You can see the mechanism plainly in AOSP-derived recovery source: the trusted public keys are loaded from a /res/keys file, and when verification fails a signature verification failed line is logged and the install is rejected with INSTALL_CORRUPT. Android's official signing documentation says the same thing: the public keys recovery trusts live in the recovery partition's RAM disk. On this device, adding anything to that key set was not possible for me.

Let me put the outcome concretely: this device's recovery rejects any modified, unsigned, or differently-signed package. And there is no signed build without EBA, because the private key that would sign it belongs to the manufacturer. The wall was clear: I could not solve this by modifying a package from the outside.

I still tried two official variants, since both were signed and recovery accepted both. The first booted the device but left the crashing sign-on component in place; the screen drowned again. The second actually worked: the institutional enrollment lock was gone. One of the two locks had fallen. But that package didn't delete the sign-on component either, because that wasn't its job. What I had left was a tablet that no longer asked for institutional enrollment but drowned in crash dialogs the moment it booted.

There was a mistake of my own here too. This tablet charges from the side; some packages in circulation are for the bottom-charging models. The second package I tried actually belonged to the other hardware variant. The device booted, it didn't brick, but I went ahead knowing full well that the wrong variant could cause trouble later on Wi-Fi or charging. The kind of trade everyone in a hurry makes: a debt taken on now to be paid later. I'm not recommending it; I'm writing it down for the sake of honesty.

All of this may look like failure, but it was actually proof that the system works correctly. Signature verification exists precisely to keep foreign software off the device. The thing standing in my way was the same thing protecting millions of devices from real attacks. Rather than resent it, I had to accept it.

The plainest step, the one that worked

After exhausting every clever route, I went back to the plainest option that had been there from the start: a factory reset. That "erase everything" line in the recovery menu was the screen I had stumbled into by accident and backed out of. In the end I chose it deliberately.

And the crashing sign-on loop stopped. The device booted, the screen could breathe, the interface became usable. I had wrestled for days with my cleverest ideas; what opened the lock was the step I'd written at the very top of the list and skipped with an "it can't be that simple." I made myself a promise: I won't leave the cheapest, plainest fix for last again just because it doesn't look interesting.

The rest could now be handled from inside the device. On a MediaTek device of this age there's a one-tap tool that uses an old privilege-escalation flaw; with it I obtained administrator rights. Then I removed the two system apps responsible for the corporate policy layer and the school sign-on from the filesystem — the factory reset and the ROM change had silenced both, but the files were still there; the permanent fix only came from deleting them. I'd noted their names one by one, because these were not things to delete on a guess.

At this stage a detail surfaced that rubbed the device's weakness in my face. I tried calling Android's own package manager to uninstall the app "the proper way"; the command didn't fit in memory and fell over. The tools for changing system settings similarly failed, on either permissions or memory. The most primitive commands, by contrast — deleting a file, running a network test, writing a network rule — worked without a hitch. The device had too little memory to run its own management layer, but the simple tools close to the kernel were still standing. A familiar situation in repair work: while the upper floors collapse, the crude implements at the bottom keep working. In the end they were the ones that finished the job.

The invisible last obstacle: a pinned DNS

The device booted, the apps were gone, but the internet didn't work. Wi-Fi was connected, not a single site would load.

Finding the cause took time again. In the device's network properties, the DNS server that translates domain names into IP addresses was pinned to the address 49.0.0.0 — a leftover of the institutional configuration. I tried changing it from the interface; it didn't hold. I tried overriding the setting by hand; that didn't hold either, the value kept stubbornly coming back.

The fix was roundabout again. Instead of correcting the DNS setting, I wrote a network rule that redirects all name-resolution traffic leaving the device to a well-known public DNS server, and tied it to a startup script that runs on its own at every boot. Android has a ready-made hook for this: at boot, the system runs the install-recovery.sh script by way of the flash_recovery service. So what I did wasn't "fixing the broken setting"; it was "routing around the broken setting." It wasn't ideal. But when the device rebooted, domain names resolved even with the setting still broken. When you can't repair the right part of a tool, sometimes the only honest fix is to run a safe path around it.

So can this device be handed to a child?

Here's where I have to be honest, because a happy ending isn't enough on its own.

The device works now: no institutional enrollment prompt, no crashing sign-on, internet coming up reliably. But root stays on the device. The layer that grants administrator rights is still there after the job is done. That weakens app isolation; a malicious app can cross boundaries it normally couldn't. Second, this tablet is a 2014 model and hasn't received security patches in years — we're talking about an internet-connected device that gets no fixes. Third, redirecting all name-resolution traffic to a fixed public server practically eliminates your ability to run content filtering or parental controls at the network level; it also causes trouble on corporate networks and some guest networks.

All of these are serious problems if you plan to use the device as a general-purpose, internet-connected tablet. The conclusion I reached: this tablet is reasonable as an offline or narrow-use device — downloaded videos, simple drawing and colouring apps. Not as the main device where a child roams freely with a browser, creates accounts and installs apps. Removing root afterwards is possible too; but that doesn't change the fact that you're standing on an unpatched kernel.

My reason for writing this: most old-device rescue posts end with "it works!" and never discuss what comes after. Working and being safe are not the same thing.

Are several evenings worth one tablet?

If I ran the efficiency numbers, the time I spent would probably exceed the price of a cheap tablet. The "rational" move was not to do this at all. But there are things that calculation can't see.

Electronic waste is one of the fastest-growing waste streams in the world; the United Nations' global e-waste reporting has shown the same trend for years. Even recycling a device takes energy; the best option is to get one more use out of it without ever putting it in a bin. I set out with the same stubbornness once before, in the piece where I turned an idle laptop into a 24/7 home server; the difference is that there I held control of the machine, while here the device was designed not to let me in. The US Environmental Protection Agency also suggests considering upgrading an existing device, in software or hardware, before buying a new product, and puts a number on the scale: the energy saved by recycling a million laptops is equivalent to the electricity used by more than 3,500 US homes in a year. If that's what recycling alone is worth, the arithmetic of getting one more use out of a device without recycling it at all is something else entirely.

And there's this: what I learned over those evenings doesn't fit inside a tablet. Why a signed boot chain exists, how a security check was working correctly precisely while it blocked me, the cost of underestimating the plainest solution — a broken device taught me these. The best part was that something concrete worked at the end. Most days of writing code leave behind an abstraction; the end of those evenings left me holding a tool that powered on, worked, and would be of use to someone.

Ask the old device in your own drawer this question: has it really died, or is it just stuck behind the wrong door? The answer usually comes down to whether you're willing to risk a few evenings. The call is yours; but at the very least, give the device a hearing before you throw it out.

Official Sources

• AOSP-derived recovery — install.cpp (cm-12.1) — trusted public keys being loaded from /res/keys, the signature verification failed log on a failed check, and the install being rejected with INSTALL_CORRUPT.
• AOSP mirror — system_core, KitKat init.rc — the install-recovery.sh script being run at boot by the flash_recovery service; the mechanism the startup-script hook relies on.
• US EPA — Electronics Donation and Recycling — the suggestion to consider upgrading an existing device before buying new, and recycling a million laptops saving energy equivalent to the annual electricity of more than 3,500 homes.
• EBA — official e-Tab 4 ROM distribution source — the official distribution channel for the manufacturer-signed packages the device's recovery accepts.