The Phone That Thought It Was a Samsung

It started as a trivial complaint. A brand-new S22 Ultra, no SIM card yet, connected to home Wi-Fi. You try a system update, and the device answers: Verification failed. Nothing more.

Without a SIM, the classic culprit is a wrong clock. I worked through the usual list — date and time, update-app cache, private DNS. Then one detail felt off, then another. No search bar in Settings. No "Software information" menu. On a genuine One UI, those are always there.

Three anomalies, all pointing the same way. I proposed the one thing that would settle it: plug it in, and see what the hardware says about itself.

A shell can lie, a logo can be copied, an interface can be dressed up. But when a device announces itself on a USB bus, it states a manufacturer identity burned into its chip. First command after plugging in:

Bus 001 Device 020: ID 0e8d:201c MediaTek Inc. S22 Ultra
adb: 0123456789ABCDEF   unauthorized

Two things jumped out. The prefix 0e8d belongs to MediaTek — yet a real S22 Ultra carries a Snapdragon or an Exynos, never a MediaTek. And that serial number: 0123456789ABCDEF, a factory dummy value, the signature of sloppy cloned firmware.

The diagnosis was already all but certain. But "all but" isn't enough — I needed a full confession, in plain words.

USB debugging authorized, I queried the system properties. The answer left no room for doubt.

ro.product.model        = S22 Ultra       ← displayed
ro.product.manufacturer = alps            ← real (generic MediaTek)
ro.board.platform       = mt6580          ← real
ro.build.version.release= 8.1.0           ← Android Oreo, 2017
ro.build.fingerprint    = ...k80hd_bsp_fwv_512m...test-keys

The processor: a MediaTek MT6580, four Cortex-A7 cores, 32-bit, a microarchitecture from 2011. Memory: 2 GB. Storage: about fifteen gigs. The screen, measured later: 540×1200. And that little word at the end of the fingerprint — test-keys — meant firmware not signed by a release key. A door I would soon pry open.

The beast was identified. What remained was to understand what had been slipped inside it.

I pulled the pre-installed apps and decompiled the suspicious ones. Beneath the Samsung veneer sat a very particular crew: Chinese factory tools signed "Kingsentime," a Baidu geolocation module with system-level permissions, a call recorder — and, above all, the party responsible for our "Verification failed": an update client named Rsota.

Its configuration, sitting in the clear inside the APK, said everything:

ota_serverl_url = https://fota.redstone.net.cn:7100/service/request
verify_package_sha1 = false   ← integrity check disabled
key_force_update    = true

Updates didn't route through Samsung, but through a third-party Chinese infrastructure, redstone.net.cn. The phone was polling a server that didn't recognize this fake device — hence the original failure. The mundane symptom from the start was only the tip.

A third-party update client isn't damning in itself — if it verifies what it installs. So I went looking for the signature-verification code. It existed: a verifyPackageLegal() function that cleanly called RecoverySystem.verifyPackage().

A grep across the entire decompiled codebase exposed the trick: that function is never called anywhere. Dead code, there to reassure, never run. Then I extracted the certificate meant to validate updates:

subject = O=Android, CN=Android, emailAddress=android@android.com
file    = testkey.x509.pem  ← AOSP's public example key

It was Android's public test key — the one whose private half is published in the AOSP source tree, within reach of anyone who knows where to look. The lock exists. The key is under the doormat, and the whole world knows the doormat.

To document what hides beneath Android — the preloader, the bootloader, the kernel — I needed to extract raw memory. MediaTek SoCs of this generation have a well-known weak spot: their Boot ROM will talk without authentication. With the tool mtkclient and the phone in preloader mode, the chip gave up its contents — over the cable, nothing opened.

Preloader - BROM mode detected.
DaHandler - Device is unprotected.
DaHandler - Device is in BROM-Mode. Bypassing security.
eMMC CID: 90014a48... (SK Hynix)

"Device is unprotected. Bypassing security." The bootloader was unlocked, the security config entirely zeroed, no protection fuses. I copied fourteen partitions — preloader, lk, boot, recovery, system, vendor — about 2.5 GB. Enough to dissect the firmware at leisure, offline.

The boot image was a standard Android; the ramdisk clean, no injected native daemon. The lie wasn't in the kernel. It was higher up, in the system's wardrobe.

I mounted the system image and read its build.prop, the source of the impersonation. The most elegant thing about the deception is its thrift: almost everything tells the truth.

ro.product.model     = S22 Ultra      ← the only lie
ro.product.brand     = alps
ro.product.manufacturer = alps
# start redstone OTA properties
ro.redstone.model    = S22 Ultra
ro.redstone.platform = MTK6580_8.1    ← the signed admission

There, one line made me smile. The update vendor itself writes MTK6580_8.1 as the platform, while declaring the model "S22 Ultra." Whoever built this firmware knew exactly that they were selling a 2015 MediaTek dressed as a Samsung flagship. It was written, in black and white, in their own settings. A one-word lie, propped up by a full confession.

On the back, the array faithfully mimics the S22 Ultra's four cameras. I was asked which ones were real. The firmware answered plainly: it declares only two sensors on the entire device.

A single rear camera, five megapixels at best, likely software-upscaled to claim more. Since the firmware declares only one sensor, three of the four lenses are almost certainly decorative. That's an inference from the software — I never opened the case to confirm it by eye.

Everything so far described capabilities. What remained was to observe behavior: what does this phone do when you switch it on? To watch without exposing the home network, I turned the machine into an isolated Wi-Fi access point — hostapd, a dedicated DHCP, all traffic routed and redirected into an interception proxy, mitmproxy. The clone, alone on its network, cut off from everything else.

It connected. A first attempt to talk to its update server failed — the Chinese server was unreachable from France, and more to the point I was listening on the wrong ports. I adjusted, redirected port 7100, reconfigured the proxy to capture the request before reaching for a dead server. Then I re-triggered the device registration.

And there, it gave itself away.

The proxy presented the phone with a certificate it should never have accepted — signed by a made-up authority, never installed on the device. Google's apps politely rejected it. Rsota swallowed it without a flinch. It accepts any certificate. The encrypted payload opened up:

{ "devid": "IMEI:358220XXXXXXXXX",
  "utdid": "[REDACTED-UTDID]",   ← Alibaba tracking ID
  "man": "alps", "mod": "S22 Ultra",
  "lang": "fr-FR",
  "carrier": { "channel": "kingsentime" } }

On every boot, with no SIM card, without the slightest consent, the device ships its real IMEI — a valid, verified number — together with an Alibaba tracking ID, to a server hosted on Alibaba Cloud. The server sleeps today; the channel is very much alive. Let it wake, or let a DNS hijack take its place, and this unverified path becomes a remote-install vector.