Why my locked Galaxy A10e won't take LineageOS - a full firmware teardown

[CassieFox23]

TL;DR: I wanted to put LineageOS on an old Galaxy A10e and turn it into a pet cam, but this one's locked down way too hard for that. So I had Claude Code read the firmware with REA: the real wall is a locked bootloader plus verified boot. Claude also tripped over a sneaky bug, and a blind second pass caught it - that's my favorite part.

Edit (Oct 28): a blind review flagged a few claims that were too strong. The verified boot, Knox Guard and heimdall bits got the biggest fixes.

How this started

So I had a spare Galaxy A10e sitting in a drawer. The plan was to make it a pet cam so I can check on the dogs while I'm at work. First step was putting a clean custom ROM on it. I've done that before - two of my Galaxy Tab A8 tablets run a LineageOS GSI (a generic Android system image) and that went fine. So I figured the A10e would be the same.

Nope. The bootloader's locked, and the OEM unlock toggle is off on this carrier model. I can still run a camera app on stock Android, and honestly that's the plan now. But I really wanted to know why this phone is so locked down when my tablets weren't. So I asked Claude Code to go through the firmware and show me.

Small note on who did what: I own the phone, I asked for this, and I'm writing up what it found. Claude Code did the hands-on reverse engineering through REA. That was mostly Opus, with Sonnet helpers on some side passes. It also made the mistake further down. A blind second pass in another session flagged it, and Claude confirmed it. I mostly just pointed it at the problem lol

Everything in here is static analysis, just a hobby project. I'm not affiliated with Samsung in any way, either. The phone's an SM-A102U on T-Mobile, build A102USQSDAVD1, Android 9. The firmware came straight from Samsung's servers, plus two 2023 builds from a mirror. Nothing got flashed, no lock got bypassed and no partition got written. The phone only got two read-only checks: an adb sweep and one trip into download mode. heimdall could see the phone but never got the partition table, and nothing got flashed.

Heads up, it's a long one since I put all the findings in. The deep stuff is folded up, so click a section when you want the full read.

The scripts, the full write-up and the diagram source are all in a10e-firmware too.

The whole chain from boot to apps looks like this:

the locks at boot, then a fence inside the OS

The locks at a glance

Lock	What it does	Way past it?
Verified boot (AVB)	While the bootloader's locked, rejects any image that isn't signed with Samsung's 4096-bit key	Unlocking the bootloader, but the unlock toggle is off on this phone
Knox Guard	Blocks flashing in download mode, based on carrier and financing	Only a Samsung-signed engineering token for that one chip (the check itself wasn't traced)
TEEGRIS secure world	Runs Samsung's trusted apps, apart from Android	Nothing you flash through - SELinux keeps normal apps away from it (Knox DAR, the data-at-rest encryption, aside)

The first two are about flashing and booting. TEEGRIS and the SELinux fence in front of it guard what's inside the running phone, so they don't really block a ROM.

So could it run LineageOS?

Not happening - there are two separate things in the way. This is the part my tablets got past and this phone doesn't.

Wall 1 is getting in at all. The bootloader's locked and OEM unlocking isn't available: oem_unlock_supported=1 but oem_unlock_allowed=0. One catch: that =0 only proves the toggle is off. US carrier models like this one are known for not exposing a working toggle. That's known about the model in general, these files don't prove it. Either way, while the bootloader's locked, AVB rejects an unsigned image.

Wall 2 is Treble's VINTF check, which tests that a system image fits the phone's vendor side. It only pairs them on an exact level match. This vendor is level 3, which is Android 9. The LineageOS 21 GSI is Android 14 and only ships matrices for levels 4 to 8. So there's no level-3 matrix to match, and by the rule the pair should get refused. That's what the rule says should happen, not a boot test. Two smaller details came from a later review of the GSI, and the GSI isn't on disk to re-check them. It does still ship the VNDK-28 runtime. On the kernel side it wants patch level 4.4.302, and this phone is on 4.4.111.

My Tab A8s only got past wall 1 because they allow OEM unlock, and on this carrier A10e that toggle is off.

The firmware package

Samsung ships the firmware as six .tar.md5 bundles: BL, AP, CP, CSC, HOME_CSC and USERDATA. All six MD5 trailers checked out. The partition map (PIT) lists 38 partitions, but this firmware only writes 17 of them. The other 21 get left alone. EFS, SEC_EFS and CPEFS hold your radio identity and calibration. PERSISTENT holds the lock that kicks in after a factory reset. The modem's calibration areas stay put too. So a stock reflash should leave all of that just as it was. That's going by the PIT, since nothing got flashed.
The chip is an Exynos 7885-class part, but the names are kinda all over the place. The strings say exynos7885 and exynos7904, and the device-tree overlays name Exynos 7884B. That last one is most likely the real chip. Why the other names show up isn't clear. Samsung sharing one base across sibling chips would explain it, but that's a guess.

Here's the hardware the device tree describes. The full list is in the repo's hardware appendix.

Lock #1 - verified boot (AVB), the one that matters

vbmeta is basically Android's signed table of contents for the boot chain. Here's what Claude pulled out of it:

• Algorithm: SHA256_RSA4096, so a 4096-bit RSA key.
• Key fingerprint (sha1): e553992a79ab561a4805371cce123d1ee73db21b. avbtool agrees, and so does a by-hand recompute over the 1032-byte blob.
• The same key signs the vbmeta root and every chained partition: recovery, dtb, dtbo, product.
• vbmeta carries SHA-256 hashes for bootloader, cm and boot. It also has dm-verity hashtrees for system and vendor, with FEC (error-correction data).
• The public key is baked right into the bootloader, byte-for-byte, in two spots: file 0x12b070 and 0x322410. So the key ships inside the bootloader image, and nothing showed it burned into a hardware fuse.

In the code, the gate is a call to libavb's key check, validate_vbmeta_public_key, at file 0xa7a34. A .data pointer at file 0x140b28 holds the key's address. The key gets loaded at file 0xaf334, right before the Samsung check that logs AVB pubkey is not matched with vbmeta. With the wrong key, the path ends at Public key used to sign data rejected and boot fails.

A GSI changes system or boot, so the hash stops matching vbmeta. And you can't re-sign vbmeta without Samsung's private key. That's what stops a custom ROM while the bootloader's locked. Unlocking would relax it, and the other locks are kinda extra on top.

To make sure this really is the firmware on my phone, avbtool boils the whole signed set down to one digest: 5d354bfd…a7e6. That matches the live phone's own digest. So that's strong evidence the boot chain, system and vendor images Claude read are what the phone runs.

Lock #2 - Knox Guard, and the engineering-token hatch

Download mode, the Odin flashing screen, has a second gate on top of verified boot. This one's all about the carrier and financing. Some of the strings are literally KG locked. Not allowed to flash. and blocked due to remaining installment balance.

The Odin command handler is usbd3_rdx_process at file 0xc0ecc. It collects 1024-byte command blocks and hands each one to process_packet at file 0x6cfc8, which routes the Odin commands. Class 100 is session and control, 0x65 is PIT, 0x66 is per-partition flash, 0x67 is reboot and 0x69 is device info.

The actual flash verdict happens in the writer at file 0x6f7ec, where the KG locked string sits. The lock state comes from a KG engine at file 0x74968. It reads the Knox "vaults" from RPMB, which is secure storage you can't rewind. Then it hash-checks the vaults and works out a state from them. So the flag isn't just a plaintext bit sitting out in the open. Heads up tho, Claude never read this phone's own KG state. It lives in RPMB, which isn't readable without root.

There's a hatch for a Samsung-signed engineering token - that's the This is KNOX TEST binary. Please download EM-token first! string. It's a certificate chain that sboot checks, tied to the chip ID and read from the STEADY partition. The structure's clear, but Claude didn't trace the actual RSA verify. So "can't be forged" is how it's designed, not something that got proven here.

There also looks to be a signed-image check that's separate from KG. That's going by its strings, since it wasn't traced. sboot prints a rollback check too, SW REV. CHECK FAIL, along with Custom binary blocked by CC Mode. and MDM MODE. CAN'T DOWNLOAD.

Lock #3 - the TEEGRIS secure world

There are three small ARM64 ELF programs tucked inside the bootloader. Since they're real ELF files, they decompile cleanly once you carve them out.

• teegris1 (about 60 KB) is the CSMC "BFHandler" trusted app. It uses RSA to check that a Knox kernel module is signed, and it reads the boot status fields. It prints the bl_secure_info fields as debug lines, like cc_mode, em_token, frp_lock and warranty_bit. That's just a readout tho - it was never caught setting those bits.
• teegris3 (about 78 KB) is the secure-OS loader, startup_loader. It opens startup.tzar.lz4, unpacks it and loads the trusted apps.
• teegris2 (about 9 KB) is just a small stub.

This is where Claude got stuck. startup.tzar.lz4 is the TEEGRIS OS body, and it's a separate file on the secure filesystem, outside sboot. It's not in this download, so the OS body and the trusted apps it bundles can't be pulled. The 21 trusted apps in /vendor/tee do ship, tho. There's no TZSW partition in the map either, so Claude couldn't pin down where the OS body lives. Separately, cm.bin is a signed container with several modules in it. Those include CryptoManagerV40 and srpmb_fw, tagged SignerVer02.

Inside the running OS - what SELinux enforces

The locked bootloader is what stops flashing and booting, and SELinux is the fence once the OS is up. The boot cmdline actually asks for permissive, which looks pretty alarming at first. But Android init ignores that on a user build. The kernel also has an always-enforce backstop, so the phone runs Enforcing, and the props back that up: ro.boot.selinux=enforcing.

Claude pulled the compiled policy out of vendor.img and read it with setools:

• sepolicy v30 MLS: 2,374 types, 95 classes, 39,074 allow rules.
• No domain runs in permissive mode, so every domain is enforced. But that's not the same as nothing having broad powers.
• execmem goes to 47 domains: app sandboxes, the TEE and Knox app domains, and some system daemons. So it's scoped, but broader than just apps.

The fence around the secure world holds. A normal app (untrusted_app) can't find any of the 13 secure services and has no access to the TrustZone device nodes. The only secure node it can touch is Knox DAR, /dev/dek_req. The fence matters a lot here, since most of those tz nodes are mode 0666. So SELinux is pretty much the main thing gating them.

Behind the fence it's TEEGRIS - the kernel has CONFIG_TZDEV=y and no Trustonic at all. The real services each have their own domain, and all of them are 32-bit. They're tzdaemon, the Knox proca HAL, secure_storage_daemon, keymaster, gatekeeper and Widevine. There are 21 trusted apps in /vendor/tee. Some of the policy is just leftover from a shared template too. The Trustonic, HDCP and secure_element domains are fenced off, but this firmware doesn't ship a binary for any of them.

The method, and the bug

Ok so this is the bit I'd read if you're into RE. sboot.bin is a 4 MB ARM64 image with no symbols and no obvious load address, and Ghidra stalled on it. With no valid entry, Ghidra couldn't tie the "blocked" strings to any code.

Now the bug. ARM64 code finds its own data with an ADRP + ADD pair. ADRP is page-relative, so it builds an address from the current page plus an offset. That means you need the load address mod 4 KB, which is just the low bits, not the whole base.

Claude's first pass assumed those low bits were zero, which is the natural guess, but it's wrong here. The real value is 0x800, half a page. With the wrong phase, every reference lands 2 KB off on a different string. The code still disassembles fine. The references just point at the wrong text, so nothing looks broken.

The fix is to measure the phase instead of guessing. Count how many pairs land exactly on the start of a string, once at phase 0 and once at 0x800. The right one stands way out:

Phase	References landing on a clean string start
0x800 (correct)	4,249 of 6,462
phase 0 (the wrong guess)	1,000 of 6,462

With the wrong phase, one function looked like a Knox Guard check that wanted a token magic, 0x12349876. With the right phase, it's just the partition-table parser - 0x12349876 is the magic at the top of a Samsung PIT file. The code reads a header, checks that magic and loops over the entries. So the "carrier lock" was really a partition table, and a real constant just got matched to the wrong strings.

Fixing the phase sorted out the load base too. An early guess chased 0x8f000000, but that turned out to be a jump literal in the code. The real base is 0x8ef9e800, 0x61800 lower, and it's pinned by a 13-entry table of partition-name pointers at file 0x12b488. ADRP only gets you the page, so for the base you need absolute pointers.
A blind second pass in another session flagged the mistake. Claude then re-checked it and confirmed it. Getting fooled by your own first read is pretty normal, so I'd always get a blind second look. REA itself was fine - the miss was in how Claude read the image.

If you're poking at a raw image yourself, measure the phase instead of guessing zero. A few more things that helped:

• You don't need the full base to read the logic, but pinning it down lets the disassembler's own analysis work.
• On a raw image Ghidra doesn't build these references at all, so an empty xref list proves nothing.
• If part of a blob is a real ELF, carve it out and let the tools read the headers.

The ADRP bug, drawn out:

Does it hold up? Cross-checks

Claude also checked against other builds and Samsung's own source. These compare string sets and keys, and the big 2023 rewrite wasn't disassembled. So read "same locks" as "same keys and lock strings".

• The previous build (late 2021) differs by 2,276 bytes, about 0.05%. That's just version text and checksums, plus new signatures and some header bits, so no real code change.
• A much later build (Aug 2023, Android 11) differs at 30.55% of its byte positions, and code that just moved counts in that. But the AVB root key is unchanged, and the KG, AVB and rollback strings are byte-identical. That one's an AT&T package tho, a sibling, not my T-Mobile build.
• The encrypted pre-boot stage sits behind a plaintext [SECLIB] Moonstone tag. Claude hashed that stage across four sboots. It's identical within an Android version and across carrier and unlocked, and it only changes at the A9 to A11 bump. So it's a per-version stage, not a per-device secret.
• The unlocked sibling has the same AVB keys and the same OEM-unlock code. The clearest tell is one sales string, USA:SINGLE vs USA:OPEN. So it points to the lock coming from how the phone was provisioned, instead of a crippled bootloader. The unlock getter itself is the same code in both builds. One catch: the rest of that 16% difference wasn't gone through.
• Samsung's own kernel source matches the SELinux setup Claude read, in shape if not line for line. That source is 4.4.177, the 2023 kernel, while the phone runs 4.4.111. A build-time define forces SELinux to enforcing. RKP also puts the flag under the hypervisor's guard. The permissive cmdline just gets ignored.

Oh and the modem, real quick: it's a Samsung Shannon baseband, and the A10e is sold as a 4G LTE phone. The modem code does carry some 5G (EN-DC) types from Samsung's shared codebase. So the files alone don't settle 5G. The 2022 to 2023 modem is the same family, just a refresh.

How much the bootloader changed per pair, with the AVB key the same in all three:

And sboot.bin's entropy. The encrypted pre-boot stage is the flat band at the start. The other high band is a dense data table, not encryption.

What it couldn't get to

• The encrypted parts. cm.bin's payload and sboot's [SECLIB] body are locked up, and no key ships in the firmware. So the plaintext can't be recovered from here, and the OTA fota.zip is encrypted too.
• The TEEGRIS OS body isn't in the image set, so it can't be pulled, along with any trusted apps it bundles. Claude couldn't pin down which partition holds the OS body either.
• The first boot hop goes through a function pointer in on-chip SRAM, which a static trace can't follow. The kernel hand-off and the Odin dispatch were still worked out from the static read, so those two aren't dead ends.

So, the pet cam

No Lineage then, but the pet cam's still happening. It'll just run a camera app on stock Android 9, and that was always enough for watching the dogs. And now I actually know why Lineage was never an option here when it was fine on my tablets. That's what I really wanted out of all this :3

Tools

All free and local:

• Claude used samloader to get the firmware from Samsung's own servers. The two 2023 builds came from the samfw.com mirror.
• lz4, simg2img and debugfs opened the images. avbtool checked the signatures on the images.
• The analysis ran in Ghidra, through REA.
• A capstone pass did the raw byte work and the phase check.
• checkpolicy and setools read the SELinux policy.
• heimdall could see the phone in download mode. It never got the partition table, and it flashed nothing.

All in, that was several hundred Ghidra calls through REA.

---

🤖 Written with Claude Code (Opus 4.8 and Opus 5.5, blind-reviewed by Sonnet 5.5), posted with my OK 🦊