Tous les articles
6 min de lectureglizzykingdreko

Tirer le meilleur parti de l'abonnement iCloud+

La fonctionnalité que je préfère dans iCloud+, c'est « HideMyEmail », qui vous crée un alias lors des inscriptions sur les sites afin d'éviter de partager…

Tirer le meilleur parti de l'abonnement iCloud+

La fonctionnalité que je préfère dans iCloud+, c'est « HideMyEmail », qui vous crée un alias lors des inscriptions sur les sites afin d'éviter de partager votre véritable adresse mail.

C'est bien, mais vous savez ce qui serait encore mieux ? La possibilité d'utiliser rapidement cette fonctionnalité pour générer une liste d'alias pointant vers mon adresse iCloud, afin d'éviter d'acheter des listes d'e-mails ou des catchalls lors de raffles, de créations de comptes en masse, ou simplement d'avoir des adresses jetables fraîches quand j'en ai besoin.

Alors, faisons-le !

Autres solutions open source

Cette idée est née quand j'avais besoin de créer quelques alias rapidement et facilement. J'ai pensé à cette approche HideMyEmail, j'ai trouvé quelques projets en ligne, mais le principal problème avec tous, c'était le login.

Absolument pas pris en charge. Il fallait extraire les cookies de ma session de navigateur pour faire fonctionner le moindre script. Donc en gros, il n'existe que des modules vibe-codés qui reproduisent une requête X fois avec les cookies que vous leur fournissez.

Et en gardant à l'esprit qu'iCloud vous laisse générer environ 5 e-mails toutes les 30/40 minutes… au final, le faire manuellement serait même plus simple que de se battre avec des sessions expirées.

On peut faire bien mieux. (spoiler : consultez le dépôt github de ce projet)

Comprendre le processus

Pour construire quelque chose qui fonctionne réellement, j'avais besoin de comprendre ce qui se passe quand on se connecte à iCloud. J'ai donc lancé mon navigateur, ouvert un proxy HTTP, et enregistré toute la session, du login jusqu'à la génération d'e-mails.

Évidemment, Apple ne facilite pas la tâche. Leur authentification utilise une implémentation personnalisée du protocole Secure Remote Password (SRP) avec quelques modifications propres à Apple qui m'ont pris beaucoup trop de temps à décortiquer.

Laissez-moi vous expliquer.

Le flux d'authentification

**Étape 1 : Initialisation SRP
**D'abord, on envoie une requête à /appleauth/auth/signin/init avec le nom du compte :

{
  "a": "<base64_encoded_A_value>",
  "accountName": "[email protected]",
  "protocols": ["s2k", "s2k_fo"]
}

La valeur a est notre valeur éphémère publique SRP. Apple répond avec ses propres valeurs, dont :

  • b L'éphémère public du serveur
  • saltPour la dérivation du mot de passe
  • iterationNombre d'itérations PBKDF2
  • protocolQuelle variante utiliser (généralement s2k)

**Étape 2 : Le protocole s2k
**C'est là qu'Apple a décidé d'être Apple. Le SRP standard calcule x = H(s || H(I:p)) où I est le nom d'utilisateur et p le mot de passe.

Mais non, le protocole s2k d'Apple fait quelque chose de différent :

x = H(s || p)

Où p n'est pas le mot de passe brut, mais :

password_hash = SHA256(password)
derived_key = PBKDF2(password_hash, salt, iterations, 32, SHA256)

J'ai passé des heures à déboguer des erreurs « Invalid credentials » avant de trouver ça. Un grand merci au projet icloudpy qui m'a aidé à valider la logique, leur implémentation m'a fait gagner du temps.

Étape 3 : Finalisation de l'authentification

Une fois la preuve SRP correcte calculée, on l'envoie à /appleauth/auth/signin/complete :

{
  "accountName": "[email protected]",
  "m1": "<base64_srp_proof>",
  "m2": "<base64_server_proof>",
  "rememberMe": true
}

Étape 4 : Authentification à deux facteurs

Si la 2FA est activée (et honnêtement, elle devrait l'être sur chaque compte), Apple renvoie un statut 409 demandant une vérification. Vous recevrez un code sur vos appareils de confiance — iPhone, iPad, Mac, peu importe ce que vous avez.

On envoie ce code à /appleauth/auth/verify/trusteddevice/securitycode :

{
  "securityCode": {
    "code": "123456"
  }
}

Ensuite, on établit la confiance de la session via /appleauth/auth/2sv/trust pour ne pas avoir à repasser par la 2FA à chaque fois.

Étape 5 : Connexion au compte

Enfin, on appelle /setup/ws/1/accountLogin pour obtenir la session complète avec toutes les URL de webservices dont on a besoin, y compris l'endpoint HideMyEmail qu'on recherche.

À ce stade, on dispose d'une session entièrement authentifiée. Le plus dur est fait !

L'API HideMyEmail

Maintenant, la partie amusante. Une fois authentifié, interagir avec HideMyEmail est étonnamment simple comparé au cauchemar d'authentification qu'on vient de traverser. (c'est probablement pour ça que tous les projets open source ne faisaient que cette partie)

Générer un e-mail

POST /v1/hme/reserve
{
  "hme": "[email protected]",
  "label": "My Shopping Account",
  "note": "Used for online shopping"
}

Une fois réservé, l'e-mail est lié de façon permanente à votre compte et transférera les messages vers votre boîte de réception pour toujours (ou jusqu'à ce que vous le supprimiez).

Lister tous les e-mails

GET /v2/hme/list

Renvoie toutes vos adresses HideMyEmail avec des métadonnées comme la date de création, le label, et si elle est active. Utile pour exporter tout ce que vous avez créé.

Limites de débit

Bien sûr, Apple ne nous laisserait pas faire n'importe quoi. Voici ce que j'ai découvert au fil de… tests approfondis :

  • Toutes les 30 minutes : ~5 e-mails × membres de la famille
  • Total par compte : ~700 e-mails

Le multiplicateur « membres de la famille » est intéressant — si vous avez le Partage familial Apple avec 5 personnes, vous obtenez théoriquement environ 25 e-mails toutes les 30 minutes. Pas mal pour une fonctionnalité qu'Apple n'avait probablement pas prévu d'utiliser de cette manière.

Quand vous atteignez la limite, Apple renvoie :

{
  "success": false,
  "error": {
    "errorMessage": "You have reached the limit...",
    ...
  }
}

Construire le CLI

Avec toutes ces connaissances, j'ai construit icloud-hme — un véritable outil CLI qui gère tout :

  • Vraie authentification SRP — Fini les cauchemars de copie de cookies
  • Support 2FA — Fonctionne avec vos appareils de confiance
  • Multi-comptes — Basculez entre plusieurs comptes iCloud
  • Bel affichage — Propulsé par Rich, parce que pourquoi les CLI devraient-ils être moches ?
  • Export — CSV ou JSON avec options de filtrage

Voir ça en action

D'abord, authentifiez-vous avec votre compte iCloud :

$ icloud-hme auth

 iCloud HME ─────────────────────────────────────────────────────

  ? iCloud email: your@icloud.com
  ? Password: ********

   Two-factor authentication required
  ? Enter 6-digit code: 123456

   Authenticated as Your Name

Ensuite, générez autant d'e-mails que vous voulez :

$ icloud-hme generate -n 5

  Generating 5 email(s) • PERMANENT

  ──────────────────────────────────────────────────────────────────

  ✓ punk_51_estofamos@icloud.com
  ✓ bicep_angora.32@icloud.com
  ✓ extinct.daze_7p@icloud.com
  ✓ minimos_orzo.06@icloud.com
  ✓ flak-din-1q@icloud.com

  ──────────────────────────────────────────────────────────────────

  ✓ Generated 5/5 permanent email(s)

Besoin de tout exporter ? Facile :

$ icloud-hme export --format csvFound 29 emails to export
  ? Save to (without extension): my_emails

  ✓ Exported to my_emails.csv

Vous pouvez installer le module via

pip install icloud-hme

ou via le code source, pensez à consulter le dépôt github

Me contacter

Si cet article vous a plu, suivez-moi sur GitHub et sur Medium pour recevoir des notifications chaque fois que je publie ou que j'ouvre le code de quelque chose.

icloudapplepythonhide-my-emailgenerator

Sautez l'étape de la rétro-ingénierie.

Takion renvoie des cookies, en-têtes et tokens frais pour tous les grands murs antibot. Un seul POST, aucun navigateur, premier appel dans l'heure.