Le téléphone qui se prenait pour un Samsung

Au début, il n'y avait qu'une plainte anodine. Un S22 Ultra tout neuf, pas encore de carte SIM, connecté au Wi-Fi domestique. On tente une mise à jour du système, et l'appareil répond : Échec de la vérification. Rien de plus.

La cause classique, sans SIM, c'est une horloge déréglée. J'ai déroulé la liste habituelle : date et heure, cache de l'app de mise à jour, DNS privé. Puis un détail a cloché, puis un autre. Pas de barre de recherche dans les Paramètres. Pas de menu « Informations sur le logiciel ». Sur un vrai One UI, ces éléments sont toujours là.

Trois anomalies qui pointaient toutes dans la même direction. J'ai proposé la seule chose qui trancherait : le brancher, et regarder ce que le matériel raconte de lui-même.

Un boîtier peut mentir, un logo se copie, une interface se maquille. Mais quand un appareil se présente sur un bus USB, il décline une identité de fabricant gravée dans sa puce. Première commande après le branchement :

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

Deux choses m'ont sauté aux yeux. Le préfixe 0e8d appartient à MediaTek — or un authentique S22 Ultra embarque un Snapdragon ou un Exynos, jamais du MediaTek. Et le numéro de série : 0123456789ABCDEF, une valeur bidon d'usine, signature des firmwares clonés bâclés.

Le diagnostic était déjà quasi certain. Mais « quasi » ne suffit pas ; il fallait le lui faire avouer en toutes lettres.

Débogage USB autorisé, j'ai interrogé les propriétés système. La réponse ne laissait plus aucune place au doute.

ro.product.model        = S22 Ultra       ← affiché
ro.product.manufacturer = alps            ← réel (MediaTek générique)
ro.board.platform       = mt6580          ← réel
ro.build.version.release= 8.1.0           ← Android Oreo, 2017
ro.build.fingerprint    = ...k80hd_bsp_fwv_512m...test-keys

Le processeur : un MediaTek MT6580, quatre cœurs Cortex-A7 en 32 bits, une microarchitecture de 2011. La mémoire : 2 Go. Le stockage : une quinzaine de giga. L'écran, mesuré plus tard : 540×1200. Et ce petit mot en fin de signature — test-keys — indiquait un firmware non signé par une clé de release. Une porte que je rouvrirais bientôt.

La bête était identifiée. Restait à comprendre ce qu'on avait glissé à l'intérieur.

J'ai extrait les applications préinstallées et décompilé les plus suspectes. Sous le vernis Samsung se cachait un équipage bien particulier : des outils d'usine chinois signés « Kingsentime », un module de géolocalisation Baidu avec des permissions de niveau système, un enregistreur d'appels — et surtout, le responsable de notre « Échec de la vérification » : un client de mise à jour nommé Rsota.

Sa configuration, en clair dans l'APK, disait tout :

ota_serverl_url = https://fota.redstone.net.cn:7100/service/request
verify_package_sha1 = false   ← contrôle d'intégrité désactivé
key_force_update    = true

Les mises à jour ne transitaient pas par Samsung, mais par une infrastructure tierce, redstone.net.cn. Le téléphone interrogeait un serveur qui ne reconnaissait pas ce faux appareil — d'où l'échec initial. Le symptôme banal du début n'était que la partie émergée.

Un client de mise à jour tiers, ce n'est pas dramatique en soi — s'il vérifie ce qu'il installe. J'ai donc cherché le code de vérification de signature. Il existait : une fonction verifyPackageLegal() qui appelait proprement RecoverySystem.verifyPackage().

Un grep sur tout le code décompilé a révélé la supercherie : cette fonction n'est appelée nulle part. Du code mort, présent pour rassurer, jamais exécuté. Puis j'ai extrait le certificat censé valider les mises à jour :

subject = O=Android, CN=Android, emailAddress=android@android.com
fichier = testkey.x509.pem  ← clé publique d'exemple d'AOSP

C'était la clé de test publique d'Android, celle dont la partie privée est publiée dans le code source d'AOSP, à la portée de quiconque sait la trouver. La serrure existe. La clé est sous le paillasson, et le monde entier connaît le paillasson.

Pour documenter ce qui se cache sous Android — le préchargeur, le bootloader, le noyau — il fallait extraire la mémoire brute. Les SoC MediaTek de cette génération ont un talon d'Achille bien connu : leur Boot ROM accepte de dialoguer sans authentification. Avec l'outil mtkclient et le téléphone en mode preloader, la puce a livré son contenu — par le câble, sans rien ouvrir.

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

« Appareil non protégé. Contournement de la sécurité. » Le bootloader était déverrouillé, la configuration de sécurité entièrement à zéro, aucun fusible de protection. J'ai copié quatorze partitions — preloader, lk, boot, recovery, system, vendor — environ 2,5 Go. De quoi disséquer le firmware à loisir, hors ligne.

Le boot était un Android standard, le ramdisk propre ; pas de démon natif injecté. Le mensonge n'était pas dans le noyau. Il était plus haut, dans la garde-robe du système.

J'ai monté l'image system et lu son build.prop, la source de l'usurpation. Le plus élégant dans la tromperie, c'est sa parcimonie : presque tout dit la vérité.

ro.product.model     = S22 Ultra      ← le seul mensonge
ro.product.brand     = alps
ro.product.manufacturer = alps
# start redstone OTA properties
ro.redstone.model    = S22 Ultra
ro.redstone.platform = MTK6580_8.1    ← l'aveu signé

Là, une ligne m'a fait sourire. Le fournisseur de mise à jour lui-même inscrit MTK6580_8.1 comme plateforme, tout en déclarant le modèle « S22 Ultra ». Ceux qui ont fabriqué ce firmware savaient parfaitement vendre un MediaTek de 2015 sous les traits d'un fleuron Samsung. C'était écrit, noir sur blanc, dans leurs propres réglages. Un mensonge d'un seul mot, adossé à une confession complète.

Au dos, le bloc imite fidèlement les quatre caméras du S22 Ultra. On m'a demandé lesquelles étaient réelles. Le firmware a répondu sans détour : il ne déclare que deux capteurs sur tout l'appareil.

Une seule caméra arrière, d'au mieux cinq mégapixels, sans doute upscalée par logiciel pour prétendre davantage. Le firmware ne déclarant qu'un seul capteur, trois des quatre objectifs ne sont, très probablement, que du décor. Je le déduis du logiciel — je n'ai pas ouvert le boîtier pour le confirmer de mes yeux.

Tout ce qui précède décrivait des capacités. Restait à observer le comportement : que fait ce téléphone quand on l'allume ? Pour l'observer sans exposer le réseau de la maison, j'ai transformé la machine en point d'accès Wi-Fi isolé — hostapd, un DHCP dédié, tout le trafic routé et redirigé vers un proxy d'interception mitmproxy. Le clone, seul sur son réseau, coupé de tout le reste.

Il s'est connecté. Une première tentative de dialogue avec son serveur de mise à jour a échoué — le serveur chinois était injoignable depuis la France, et surtout j'écoutais les mauvais ports. J'ai ajusté, redirigé le port 7100, reconfiguré le proxy pour qu'il capture la requête avant de chercher à joindre un serveur mort. Puis j'ai relancé l'enregistrement de l'appareil.

Et là, il s'est trahi.

Le proxy a présenté au téléphone un certificat qu'il n'aurait jamais dû accepter — signé par une autorité inventée, jamais installée sur l'appareil. Les applications Google, elles, l'ont poliment rejeté. Rsota, lui, l'a avalé sans broncher. Il accepte n'importe quel certificat. Le contenu chiffré s'est ouvert :

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

À chaque démarrage, sans carte SIM, sans le moindre consentement, l'appareil expédie son IMEI réel — structure valide, vérifiée — accompagné d'un identifiant de tracking Alibaba, vers un serveur hébergé chez Alibaba Cloud. Le serveur dort aujourd'hui ; le canal, lui, est bien vivant. Qu'il se réveille, ou qu'un détournement DNS prenne sa place, et cette voie sans vérification devient un vecteur d'installation à distance.