# Contrefaçon « Samsung Galaxy S22 Ultra » — Rapport de rétro-ingénierie

**Date d'analyse :** 2026-08-05
**Méthode :** ADB (débogage USB), décompilation jadx, inspection firmware
**Origine appareil :** colis retour Amazon non identifié
**Verdict :** clone MediaTek bas de gamme déguisé en Samsung S22 Ultra

---

## 1. Identité réelle vs annoncée

| Caractéristique | Annoncé (S22 Ultra) | Réel (mesuré) |
|---|---|---|
| SoC | Snapdragon 8 Gen 1 / Exynos 2200 | **MediaTek MT6580** (4× Cortex-A7, ARMv7 32-bit, ~2015) |
| RAM | 8–12 Go | **2 Go** (`MemTotal: 2023024 kB`) |
| Stockage | 128–1024 Go | **~15 Go eMMC** (`mmcblk0`, 15 392 768 blocs) |
| Écran | 3088×1440, 6.8″ AMOLED | **540×1200, 240 dpi** (qHD) |
| Android | 13 (One UI 5) | **8.1.0 Oreo** (API 27) |
| Marque interne | samsung | **`alps`** (build MediaTek générique) |

### Preuves d'usurpation (props falsifiées)

```
ro.product.model        = S22 Ultra        <- falsifié
ro.product.manufacturer = alps             <- réel (générique MTK)
ro.product.brand        = alps             <- réel
ro.board.platform       = mt6580           <- réel
ro.hardware             = mt6580           <- réel
ro.build.fingerprint    = alps/full_k80hd_bsp_fwv_512m/...:8.1.0/O11019/...:user/test-keys
```

Le nom de carte `k80hd_bsp_fwv_512m` est une carte de référence MT6580 chinoise. `fwv_512m` = variante conçue à l'origine pour 512 Mo de RAM.

---

## 2. Posture de sécurité

| Élément | État | Risque |
|---|---|---|
| Build keys | `test-keys` | Firmware non signé par clé de release |
| Date build | 2022-07-11 | — |
| Patch sécurité | **2021-10-15** | ~5 ans de CVE non corrigées |
| SELinux | Enforcing | (seul point positif) |
| Root/su | Absent par défaut | — |
| BROM MT6580 | Non authentifié | Dump/flash complet trivial via `mtkclient` |
| Clé signature OTA | **testkey AOSP publique** | N'importe qui peut forger un OTA accepté |

### Certificat OTA — faille critique

`/system/etc/security/otacerts.zip` contient un unique certificat :

```
subject = C=US, ST=California, L=Mountain View, O=Android, CN=Android
sha256  = A4:0D:A8:0A:59:D1:70:CA:A9:50:CF:15:C1:8C:45:4D:47:A3:9B:26:98:9D:8B:64:0E:CD:74:5B:A7:1B:F5:DC
```

C'est le `testkey.x509.pem` **public d'AOSP** — la clé privée correspondante est publiée dans l'arbre source Android (`build/target/product/security/testkey.pk8`). Toute personne sachant la trouver peut signer une mise à jour OTA que cet appareil validera comme légitime.

---

## 3. Applications préinstallées suspectes

| Package | APK | Rôle | Évaluation |
|---|---|---|---|
| `com.abfota.systemUpdate` | `/system/app/Rsota/Rsota.apk` | Client OTA Redstone (tiers chinois) | **Élevé** — voir §4 |
| `com.baidu.map.location` | `/system/priv-app/Baidu_Location/` | Géolocalisation Baidu | **Élevé** — voir §5 |
| `com.elephanttek.faceunlock` | `/system/priv-app/FaceUnlock/` | Déverrouillage facial (27 Mo) | Moyen |
| `com.example` | `/vendor/app/AutoDialer/` | Test usine (composition auto) | Faible (bénin) |
| `com.example.versioninfo` | `/vendor/app/VersionInfo/` | Affichage version usine | Faible |
| `com.kingsentime.*`, `com.kst.*` | `/vendor/app/KST*`, `SwitchApp` | Outils usine « Kingsentime » | Faible |
| `com.samsung.weather.mega` | `/system/app/KSTMegaWeather_Samsung/` | Fausse app météo « Samsung » | Cosmétique (usurpation marque) |
| `com.mtk.telephony` | `/vendor/app/SimRecoveryTestTool/` | Test SIM MediaTek | Faible |

> Note : `com.samsung.weather.mega` est signée par « KST », pas Samsung — usurpation de marque pure.

---

## 4. Analyse du client OTA (`Rsota` / Redstone)

### Serveurs de mise à jour (`assets/config.xml`)

```
Production : http://fota.redstone.net.cn:6100/service/request
             http://fota.redstone.net.cn:6100/service/report
HTTPS      : https://fota.redstone.net.cn:7100/service/request
Test       : http://fota.mwhtml5.com:6100/service/request
```

Toutes les mises à jour transitent par une infra tierce chinoise (Redstone), **pas** par les serveurs Samsung. C'est la source du message « Échec de la vérification » : l'appareil interroge `redstone.net.cn`, qui ne reconnaît pas ce build ou renvoie une erreur.

### Configuration dangereuse

```xml
<string name="verify_package_sha1">false</string>   <!-- pas de contrôle intégrité -->
<string name="key_force_update">true</string>        <!-- mise à jour forcée -->
<string name="is_test">false</string>
```

### Vérification de signature = code mort

`RsFirmwareVerify.verifyPackageLegal()` appelle `RecoverySystem.verifyPackage()` — mais **grep confirme zéro appelant** dans tout le code décompilé. La seule vérification optionnelle (`verifyPackageSha1`) est désactivée par config (`verify_package_sha1=false`).

### Permissions détenues

`REBOOT`, `RECOVERY`, `MOUNT_UNMOUNT_FILESYSTEMS`, `INSTALL_LOCATION_PROVIDER`, `SYSTEM_ALERT_WINDOW`, `RECEIVE_BOOT_COMPLETED`, `READ_LOGS`, `WRITE_MEDIA_STORAGE`.

**Chaîne d'attaque :** serveur OTA tiers (HTTP en clair aussi) + zéro vérification de signature effective + permissions d'installation complètes + clé de signature publique = **exécution de code arbitraire à distance persistante** via une fausse mise à jour. Vecteur classique de ces clones.

---

## 5. Traceur Baidu (`com.baidu.map.location`)

Application **privilégiée** (`priv-app`) avec permissions élevées :

```
WRITE_SECURE_SETTINGS   INTERACT_ACROSS_USERS_FULL
INSTALL_LOCATION_PROVIDER   PEERS_MAC_ADDRESS
ACCESS_FINE_LOCATION    READ_PHONE_STATE   INTERNET
```

`INSTALL_LOCATION_PROVIDER` + `WRITE_SECURE_SETTINGS` = capacité de s'imposer comme fournisseur de position système et de modifier les réglages sécurisés. Remonte la géolocalisation vers l'infrastructure Baidu. `PEERS_MAC_ADDRESS` = collecte des adresses MAC WiFi environnantes (trilatération).

---

## 6. Table des partitions (MT6580 eMMC)

| Partition | Bloc | Taille | Note |
|---|---|---|---|
| preloader_a/b | boot0/boot1 | 4 Mo | BROM/preloader MTK |
| lk / lk2 | p6/p7 | 384 Ko | Little Kernel (bootloader) |
| boot | p8 | 16 Mo | kernel + ramdisk |
| recovery | p9 | 16 Mo | |
| logo | p11 | 8 Mo | logo de boot (Samsung falsifié) |
| system | p21 | ~2 Go | ext4 ro |
| vendor | p14 | ~416 Mo | ext4 ro |
| userdata | p23 | ~12 Go | f2fs |
| nvram / nvdata | p2/p16 | | IMEI, calibration RF |
| frp | p15 | 1 Mo | Factory Reset Protection |

Mapping complet : `recon/partitions.txt`, `recon/getprop.txt` (724 props).

---

## 7. Conclusions

1. **Matériel** valant ~15–25 € présenté comme un appareil à 1000+ €.
2. **Trois vecteurs de compromission** : OTA non signé (Redstone), traceur Baidu privilégié, clé de signature publique.
3. **Firmware inauditalbe en profondeur** sans dump complet — des portes dérobées peuvent résider dans `preloader`, `lk`, `boot` (hors de portée d'ADB).

### Recommandations d'usage

- ❌ **Jamais** de SIM, compte Google, e-mail, banque, mot de passe.
- ❌ **Jamais** connecté au WiFi (désactive le vecteur OTA et le traceur Baidu).
- ⚠️ Apps déjà désactivées via ADB : `com.abfota.systemUpdate`, `com.baidu.map.location`, `com.samsung.weather.mega` (réversible, ne touche pas les partitions basses).
- ✅ Usage acceptable hors-ligne uniquement : réveil, lecteur média local, appareil de test/jouet.
- ✅ Meilleure option : recyclage DEEE. Revente interdite (contrefaçon).

---

## 8. Dump firmware complet (mtkclient / BROM)

Réalisé le 2026-08-05. Appareil entré en **mode preloader** (branché éteint, sans bouton) → mtkclient capture le preloader résident, récupère la config EMI/DRAM, charge un Download Agent patché.

### Résultat handshake BROM

```
Preloader - BROM mode detected.
ME_ID: D555FD4EDD2E8073CA2F3E3873F72388
DaHandler - Device is unprotected.
DaHandler - Device is in BROM-Mode. Bypassing security.
eMMC CID: 90014a4841473265...  (fabricant 0x90 = SK Hynix)
```

**Sécurité matérielle nulle :** BROM non authentifié, `seccfg` entièrement à zéro (bootloader déverrouillé), aucun fusible eFuse de protection. Dump et reflash intégral possibles sans contournement.

### Partitions extraites (`dump/`)

| Fichier | Taille | Contenu |
|---|---|---|
| `preloader.bin` | 4 Mo | boot0, header `EMMC_BOOT` |
| `lk.bin` / `lk2.bin` | 384 Ko | Little Kernel (bootloader) |
| `boot.bin` | 16 Mo | kernel 5.6 Mo + ramdisk |
| `recovery.bin` | 16 Mo | image recovery |
| `logo.bin` | 8 Mo | logos de boot (marque Samsung falsifiée) |
| `nvram.bin` / `proinfo.bin` | 5 / 3 Mo | calibration RF, IMEI |
| `protect1/2.bin` | 10 Mo ×2 | données protégées vendor |
| `frp.bin` | 1 Mo | Factory Reset Protection |
| `seccfg.bin` | 256 Ko | config sécurité (tout zéro) |
| `system.img` / `vendor.img` | ~2 Go / 416 Mo | rootfs (diff vs AOSP en cours) |

### Analyse boot.img

- Image Android standard (`ANDROID!`), pagesize 2048, cmdline `bootopt=64S3,32S1,32S1 buildvariant=user` (typique MT6580).
- Ramdisk (gzip+cpio) extrait dans `recon/ramdisk/` : `init.rc` = AOSP standard, `sbin/` propre (aucun binaire injecté, seulement `charger` + symlinks).
- **Aucun dm-verity ni AVB** dans le fstab → toutes les partitions sont modifiables à chaud. Combiné à la clé OTA publique (§2), la chaîne de compromission par fausse mise à jour est intégralement ouverte.

## 9. Analyse rootfs (system.img / vendor.img montés)

Images montées en loop lecture seule. `system` = 925 Mo utilisés, `vendor` = 236 Mo. Build **Android Go 8.1** (édition basse RAM) MediaTek de référence, re-brandé.

### Source de l'usurpation (`system/build.prop`)

```
ro.product.model        = S22 Ultra          <- FAUX
ro.product.brand        = alps                <- réel
ro.product.manufacturer = alps                <- réel
ro.product.device       = S22_Ultra
ro.build.fingerprint    = alps/full_k80hd_bsp_fwv_512m/...:8.1.0/O11019/...:user/test-keys

# start redstone OTA properties
ro.redstone.brand    = alps
ro.redstone.model    = S22 Ultra
ro.redstone.version  = O1655361084581V200F_RF4F0C13_S22ULTRA_20220711-1723
ro.redstone.platform = MTK6580_8.1            <- l'OTA sait que c'est un MT6580
ro.fota.device       = O1655361084581V200F_RF4F0C13_S22ULTRA
```

Seul `ro.product.model` est falsifié en « S22 Ultra ». Marque, fabricant et plateforme réels (`alps` / `MTK6580_8.1`) sont conservés en clair. **Preuve intentionnelle** : la propriété `ro.redstone.platform=MTK6580_8.1` montre que le fournisseur OTA sait qu'il s'agit d'un MT6580 tout en le vendant comme S22 Ultra.

Profil bas de gamme confirmé : `dalvik.vm.heapsize=256m`, édition Android Go (`GmsCoreGo`, `MapsGo`, `Launcher3Go`, `GoogleSearchGo`).

### Inventaire des ajouts non-AOSP

| Composant | Emplacement | Nature |
|---|---|---|
| `Rsota` | system/app | Client OTA Redstone détourné (§4) |
| `Baidu_Location` | system/priv-app | Traceur géoloc Baidu (§5) |
| `CallRecorderService` | system/priv-app | **Enregistrement d'appels** — à surveiller |
| `FaceUnlock` (elephanttek) | system/priv-app | Déverrouillage facial tiers |
| `KSTDeviceInfo`, `KSTMegaWeather_Samsung` | system/app | Outils/marque « Kingsentime » |
| `KSTFactoryTest`, `KSTFactoryTest_Aging`, `SwitchApp`, `SwitchApp_tab`, `AutoDialer`, `VersionInfo`, `SimRecoveryTestTool` | vendor/app | Suite de test usine Kingsentime (bénins) |
| `fake-libs/libart.so` | system | Shim ART 14.7 Ko (voir ci-dessous) |

### `fake-libs/libart.so`

ELF ARM 32-bit strippé exportant des symboles ART internes (`art::Dbg`, `art::FaultManager`) + routines unwind EABI. **Aucune** chaîne réseau, aucune référence par `init`/`vendor`. Verdict : hack de compatibilité pour une app repackagée attendant ces symboles, pas un implant réseau. Menace faible.

### Absence de root / implant système

- Pas de `su`, pas de Magisk, pas de `supolicy` dans `system/bin` ni `system/xbin` (seul `tcpdump` présent, usage usine).
- `sbin` du ramdisk propre.
- Les menaces restent au niveau applicatif (OTA Redstone + Baidu + CallRecorder), pas dans des démons natifs injectés — dans la limite de ce qui est analysable statiquement.

---

## 10. Synthèse des vecteurs (confirmés)

1. **OTA Redstone détourné** — serveur tiers `redstone.net.cn`, signature vérifiée par clé **testkey AOSP publique**, contrôle de signature = code mort, SHA1 désactivé, pas de dm-verity/AVB. Chaîne d'exécution de code distant complète et ouverte.
2. **Traceur Baidu privilégié** — remonte géoloc + MAC WiFi environnantes.
3. **Enregistreur d'appels** préinstallé (`CallRecorderService`).
4. **Sécurité matérielle nulle** — BROM non authentifié, bootloader déverrouillé (`seccfg`=0), dump/reflash intégral sans contournement.

Rien de tout cela n'existe sur un vrai Samsung. Recommandations §7 inchangées et renforcées : **appareil hors-ligne uniquement, ou recyclage**.

---

## Fichiers du dossier

```
apk/        12 APK extraits (Rsota, Baidu, KST*, AutoDialer, etc.)
dump/       14 partitions BROM : preloader, lk, boot, recovery, logo,
            nvram, proinfo, protect1/2, frp, seccfg, system.img, vendor.img
recon/      getprop.txt, partitions.txt, otacerts.zip + certs,
            system_build.prop, vendor_build.prop, ramdisk/ (rootfs boot)
recon/src/  sources décompilées jadx (AutoDialer, Baidu, Rsota, SwitchApp, VersionInfo)
docs/       RAPPORT.md (ce document)
```

## 11. Interception réseau live (mitmproxy transparent)

Réalisée le 2026-08-05. Cette machine transformée en **point d'accès WiFi isolé** (`hostapd` sur `wlp4s0`, SSID `CloneLab`, sous-réseau 10.42.0.0/24) : le clone y est seul, tout son trafic NATé vers Internet via l'ethernet, ports 80/443/6100/6200/7100 redirigés vers `mitmproxy` transparent (`connection_strategy=lazy`). Le clone n'a jamais touché le LAN principal.

### Requête d'enregistrement OTA capturée (déchiffrée)

À chaque démarrage, `RsOtaReceiver` (BOOT_COMPLETED) → `dealRegisterDevice()` envoie :

```
POST https://fota.redstone.net.cn:7100/service/request
User-Agent: rsotaua 1.0

{"version":"A1.0","session":"FUMO-REQ",
 "devid":"IMEI:358220XXXXXXXXX",
 "utdid":"[REDACTED-UTDID]",
 "man":"alps","mod":"S22 Ultra","osv":"8.1.0",
 "swv":"O1655361084581V200F_RF4F0C13_S22ULTRA_20220711-1723",
 "lang":"fr-FR","operator":"","loc":"-1,-1,00,0,0",
 "buildtime":"1657529728",
 "carrier":{"appid":"3oe15zmxv7eq3elnzaamzjre",
            "pkgname":"com.abfota.systemUpdate",
            "channel":"kingsentime","version":"V7.4.1","rollback":0}}
```

### Ce que la capture prouve (comportement réel, pas seulement statique)

1. **Fuite d'IMEI** — `358220XXXXXXXXX` (structure Luhn valide) envoyé à un serveur tiers chinois à chaque boot, sans SIM, sans consentement.
2. **Tracking Alibaba** — `utdid` = Universal Tracking Device ID (SDK UMENG/Alibaba). Le clone est instrumenté pour l'analytics Alibaba.
3. **TLS trust-all** — mitmproxy a présenté un certificat signé par une CA que le téléphone n'a jamais installée ; **aucune erreur de handshake** côté Rsota (à comparer : les apps Google ont, elles, rejeté le certificat — `tls alert certificate unknown`). Rsota accepte donc n'importe quel certificat. Un attaquant MITM peut se faire passer pour le serveur OTA **sans même** la clé de signature publique (§2).
4. **Serveur** `47.254.132.202:7100` = **Alibaba Cloud**, actuellement injoignable (`Errno 110`). Le canal OTA est fonctionnel côté client mais l'infra serveur dort — une reprise (ou un détournement DNS) réactiverait le vecteur.
5. **Identité usurpée transmise** — `man:alps` + `mod:S22 Ultra` : le serveur reçoit à la fois la marque réelle et le faux modèle. `channel:kingsentime` identifie l'intégrateur.

### Comparaison statique ↔ live

| Vecteur | Preuve statique (§4) | Preuve live (§11) |
|---|---|---|
| OTA tiers chinois | URLs `redstone.net.cn` dans config | POST réel capturé vers 7100 |
| Pas de validation | code de vérif = mort, SHA1 off | **TLS trust-all confirmé** |
| Fuite de données | permissions `READ_PHONE_STATE` | **IMEI + utdid réels exfiltrés** |

Fichiers : `capture/clone-traffic.mitm` (flow mitmproxy), `capture/mitm.log`.

---

Infra live laissée en place (AP `CloneLab`, mitmproxy). Pour tout arrêter : `pkill hostapd dnsmasq mitmdump` + retrait des règles iptables.

### Non réalisé

- Déclenchement du traceur **Baidu** — nécessite qu'une app demande la localisation (GPS) ; non provoqué durant la session.
- PoC serveur OTA simulé (répondre « mise à jour dispo » pour démontrer l'installation) — non fait, volontairement (éviter tout écrit sur l'appareil).