Mises à jour des versions 2026

【06 février 2026】Version : 7.10.20.219

Version : v7.10.20.219 Build 20260206 Niveau de mise à jour : Mise à jour importante / Noyau Nom de code : "DeepFlight"

Aperçu de la version

Cette mise à jour v7 marque le changement structurel le plus important de Migratory Bird Browser depuis près de six mois. En réponse aux mécanismes de vérification adverse IA de plus en plus stricts de CloudFlare, particulièrement la reconnaissance d'empreintes TLS ciblant les environnements mobiles, nous avons introduit une toute nouvelle logique adverse au niveau du noyau. Simultanément, nous avons effectué une profonde rétrospective pour corriger les problèmes de compatibilité avec les systèmes obsolètes comme Windows 7, et mis à jour le noyau vers Chrome 140 pour lisser les différences mineures dans l'environnement d'exécution JS.

Cette mise à jour répond à un point de douleur de longue date pour les utilisateurs : l'incapacité de passer la vérification humaine CloudFlare lors de l'accès à des sites de haute sécurité comme pcmax.jp en utilisant des environnements de simulation iPhone.

Téléchargement officiel : Noyau 140 (Win10/11)

---

1. Percée majeure : Tout nouveau mode anti-détection "IphoneCloudFlare"

📌 Contexte et défi : Le mur de pcmax.jp

Au cours des deux derniers mois, nous avons reçu de nnombreux retours d'utilisateurs VIP. En tentant de se connecter au site de rencontre japonais populaire pcmax.jp en utilisant les profils iOS iPhone 6/7/8/X/11/12 de MBBrowser, ils ont rencontré des obstacles sans précédent. La vérification Turnstile de CloudFlare présentait des taux d'interception extrêmement élevés dans ces environnements mobiles, atteignant presque 100% de faux positifs (interception erronée).

Symptômes spécifiques : Les utilisateurs configuraient parfaitement les empreintes commerciales MBBrowser et l'User-Agent iPhone, réglaient les résolutions d'écran correspondantes (Retina), et simulaient même les TouchEvents. Pourtant, dès l'ouverture de la page de connexion de pcmax.jp, CloudFlare entrait dans une boucle de vérification infinie ou affichait directement "Accès refusé".

📌 Attribution technique approfondie : L'effet "Vallée de l'étrange" de l'empreinte TLS

Notre équipe R&D a mené une analyse approfondie des paquets de données capturés par le module MbFireWall pendant plus de 200 heures, et utilisé Wireshark pour comparer les paquets de poignée de main réseau entre de vrais appareils iPhone (iOS 15-17) et les environnements de simulation MBBrowser.

La conclusion est étonnante : le problème ne réside pas dans la couche application (Headers HTTP/JS), mais dans la couche transport (TLS/SSL).

Lorsque MBBrowser s'exécute sur Windows 10/11, les requêtes réseau sous-jacentes font appel aux bibliothèques SChannel ou OpenSSL de Windows. Les paquets de données TLS Client Hello qui en résultent (contenant les listes de suites de chiffrement, l'ordre des champs d'extension, les groupes supportés, etc.) présentent les caractéristiques typiques de "valeurs de paramètres matériels IPHONE imprécises".

Les moteurs de contrôle des risques et d'anti-scraping de CloudFlare sont extrêmement sensibles. Ils ont détecté un paradoxe logique :

"Ce client prétend être un iPhone (User-Agent), son environnement JavaScript simule également un iPhone, mais ses caractéristiques de poignée de main TLS (empreinte JA3/JA4) indiquent clairement au serveur de détection CloudFlare que les données iPhone ne sont pas assez réelles."

Ce décalage entre les caractéristiques de la couche application et de la couche transport déclenche directement le contrôle des risques CloudFlare, c'est-à-dire le "Bot Fight Mode", empêchant pcmax.jp d'afficher même les codes de vérification aux utilisateurs, déterminant directement un IPHONE suspecté non authentique et une opération humaine suspectée non réelle.

📌 Solution : Réglage global "IphoneCloudFlare"

Pour résoudre ce problème, nous n'avons pas choisi de simples correctifs, mais avons refactorisé la logique des paquets réseau sous-jacents et introduit l'option "IphoneCloudFlare" dans les paramètres globaux.

Cela explique également pourquoi notre département technique a effectué de nombreux commits de code dans les répertoires des modules MbFireWall et WinDivert du projet (tests répétés et comparaison de données).

Détails de l'implémentation technique :

1. Façonnage du trafic au niveau du noyau

   • Lorsque les utilisateurs cochent "IphoneCloudFlare" dans les paramètres globaux, MBBrowser active le module de pilote Divert intégré.
   • Ce module s'exécute en mode noyau du système et peut intercepter tous les paquets de poignée de main TCP/TLS destinés aux plages d'IP de CloudFlare.

2. Usurpation dynamique de l'empreinte TLS

   • Lorsque MbBrowser intercepte les paquets Client Hello, nous n'utilisons plus la structure générée par défaut par OpenSSL, mais nous effectuons une reconstruction au niveau de l'octet selon les caractéristiques de poignée de main TLS du vrai Safari iOS.
   • Réorganisation des suites de chiffrement : Ajustement forcé de l'ordre de priorité des suites de chiffrement pour qu'il soit totalement cohérent avec le comportement de Network.framework d'iOS, en privilégiant les suites spécifiques au mobile telles que TLS_AES_128_GCM_SHA256 et en supprimant les suites de chiffrement faibles spécifiques à Windows.
   • Remplissage d'extension (Padding) : La méthode de remplissage de Safari iOS pour les extensions dans le Client Hello est complètement différente de celle de Windows. La nouvelle fonctionnalité simule précisément cette longueur et cet ordre de remplissage.
   • ALPN (Application-Layer Protocol Negotiation) : Spécification forcée de l'ordre de négociation du protocole h2 (HTTP/2) pour correspondre au comportement de Safari.

3. Simulation des caractéristiques de la pile de protocoles TCP/IP

   • En plus du TLS, nous avons également affiné les caractéristiques de la couche TCP (valeur TTL, taille de la fenêtre).
   • Le TTL par défaut de Windows est généralement de 128, tandis que celui d'iOS/Linux est généralement de 64.
   • Le mode IphoneCloudFlare modifie automatiquement le TTL des paquets sortants au niveau de la couche pilote, les faisant apparaître comme s'ils provenaient d'un système d'exploitation mobile lorsqu'ils atteignent le serveur.

📌 Résultats en conditions réelles

Après des tests de stress effectués par notre équipe de test interne dans plus de 500 environnements d'IP propres :

Résultats en conditions réelles

• Panneau de configuration du client MBbrowser -> Paramètres du navigateur -> n'est pas coché : Le taux de réussite de la page de connexion de pcmax.jp est de 0%.

• Panneau de configuration du client MBbrowser -> Paramètres du navigateur -> est coché : Le taux de réussite de la page de connexion de pcmax.jp est passé à 98,5% (les 1,5% restants étant dus à des problèmes de liste noire de l'IP elle-même).

Cette fonctionnalité résout non seulement parfaitement le problème pcmax.jp, mais corrige également les problèmes de détection pour d'autres sites sensibles à l'empreinte TLS (tels que Nike, Ticketmaster, etc.) dans les environnements de configuration mobile.

---

2. Synchronisation du noyau Chrome 140 et correction de la cohérence de l'affichage JS

📌 Mise à niveau du noyau Chrome 140

Suite aux mises à jour amont de Google Chromium, nous avons mis à jour libcef et les noyaux de rendu associés vers la version Chrome 140. Cette mise à jour implique de nombreux changements de fichiers d'en-tête et d'interfaces dans le répertoire CDP (Chrome DevTools Protocol).

• Amélioration des performances : Efficacité d'exécution du moteur JavaScript V8 améliorée d'environ 15%.
• Support de nouvelles fonctionnalités : Support des dernières propriétés CSS et API Web, garantissant que l'"authenticité" du navigateur reste au niveau des versions de navigateurs grand public.

📌 Correction de l'incohérence de l'affichage JS dans l'environnement iPhone

Dans l'ancienne version du noyau, lors de l'utilisation de chromedp pour simuler le viewport et le devicePixelRatio de l'iPhone, le nouveau pipeline de rendu de Chrome 140 présentait des bogues lors du traitement de certaines Media Queries CSS spécifiques, provoquant des déplacements de 1px ou des chevauchements dans la barre de navigation inférieure sur certaines pages Web (comme la version mobile de pcmax.jp).

Bien que cela ait peu d'impact sur la fonctionnalité, pour les scripts de détection d'empreintes extrêmement stricts (déterminant s'il s'agit d'un simulateur par la différence entre window.innerHeight et outerHeight), c'est un défaut fatal.

Contenu de la correction :

• Modification de la logique d'appel de Emulation.setDeviceMetricsOverride du module CDP, en ajoutant une compensation de hauteur pour les barres d'état mobiles.
• Ajout d'un Hook profond pour l'objet window.screen dans MbCommand, garantissant que les informations de géométrie d'écran obtenues à la couche JS sont strictement cohérentes avec les résultats du rendu CSS, éliminant ce défaut d'empreinte au niveau du pixel.

---

3. Retour de compatibilité : Go 1.20 et sauvetage du système Win7 32 bits

Bien que Windows 7 ait été officiellement abandonné par Microsoft et ne représente que 8% de notre base d'utilisateurs, car certaines entreprises à l'étranger (particulièrement en Europe de l'Est et en Asie du Sud-Est dans des environnements de machines virtuelles) dépendent encore fortement des systèmes Win7 32 bits légers, nous devons assurer leur stabilité.

📌 Symptômes du problème

Dans la version précédente, en raison de la mise à niveau de l'environnement de compilation CDP vers Go 1.21, certains appels système (Syscall) non supportés par le noyau Win7 32 bits ont été introduits, provoquant le plantage silencieux des processus de service CDP lors du démarrage de MBBrowser sur ce système, se manifestant par des pages blanches ou l'incapacité de se connecter aux proxys.

📌 Solution de correction

• Rétrogradation de l'environnement et compilation conditionnelle : Nous avons spécifiquement construit un pipeline de compilation indépendant pour le module CDP. Lors de la détection du système cible comme Windows 7, le script de construction passe automatiquement à la version Go 1.20.14 pour la compilation. Go 1.20 est la dernière version qui supporte parfaitement Win7.
• Cela implique de modifier les scripts de construction dans le répertoire CDP et d'effectuer des réécritures de compatibilité (Polyfill) pour le code utilisant les nouvelles fonctionnalités de Go 1.21.

---

4. Optimisation de la gestion des processus : Adieu au "Chrome Zombie"

📌 Description du problème

Les utilisateurs ont signalé qu'après la fermeture du programme principal MBBrowser sur Windows 7, les processus enfants chrome.exe sous-jacents ne se ferment parfois pas en conséquence, mais deviennent des "processus zombies" résidant en arrière-plan, occupant plus de 200 Mo de mémoire. Si les utilisateurs ouvrent et ferment fréquemment des navigateurs, cela peut conduire à l'épuisement de la mémoire système et à des gels.

📌 Analyse technique

Ce n'est pas lié à un UseAfterFree, mais plutôt à un problème de perte de signal IPC (Inter-Process Communication). Sur Win7, lorsque le processus parent (processus UI, basé sur DuiLib) s'arrête de force via TerminateProcess, les processus enfants Chrome ne peuvent pas recevoir d'instructions de sortie via le Named Pipe.

📌 Mesures de correction

• Liaison d'objet de travail (Job Object)
  • Nous avons introduit le mécanisme de Job Object de Windows dans la logique de démarrage de processus de MbCommand.
  • Le code modifié ajoute automatiquement tous les processus enfants chrome.exe lancés à un Job Object indépendant.
  • Même si le programme principal plante de manière inattendue ou est terminé de force, le système d'exploitation garantit que tous les processus enfants du Job Object sont terminés ensemble.
  • Il s'agit d'une gestion du cycle de vie au niveau du système, résolvant complètement le problème des processus zombies.

---

5. Optimisation de l'expérience du pack d'installation : Normalisation du répertoire par numéro de version

📌 Description du problème

Dans la logique originelle de SetupInstall, le chemin d'extraction par défaut du pack d'installation était généralement fixe (ex: C:\Program Files\MBBrowser). Cela causait de grands désagréments aux utilisateurs lors de tests de comparaison de versions ou de coexistence de plusieurs versions, nécessitant de renommer manuellement les dossiers.

📌 Contenu de l'optimisation

• Chemin d'installation tenant compte de la version : Modification des scripts d'installation NSIS ; désormais, l'installeur lit automatiquement le numéro de version de la construction actuelle (Version Info).
• Le chemin d'installation par défaut devient C:\Program Files\MBBrowser_v7.10.20.219.
• Mise à jour également de la logique de génération de uninst.exe, garantissant que le désinstalleur identifie et nettoie correctement les répertoires numérotés par version sans supprimer par erreur des fichiers coexistant d'autres versions.
• Cela facilite grandement le travail des utilisateurs en studio pour les tests de déploiement progressif (gray release) et de retour en arrière.

---

6. Correction du téléchargement de l'environnement Java : Briser le verrouillage du cache

📌 Contexte du problème

Certains plugins avancés de MBBrowser dépendent de l'environnement d'exécution Java (JRE). Sur les systèmes Windows 7, lorsque le téléchargeur tente de mettre à jour le JRE, en raison de la politique de mise en cache agressive de WinINet sur Win7, même si le serveur publie un nouveau pack JRE, le client téléchargeait à plusieurs reprises les anciens fichiers mis en cache localement, provoquant des échecs de somme de contrôle (Hash Mismatch) et des tentatives infinies.

📌 Solution de correction

• Passage forcé (Cache Busting)
  • Ajout forcé de Cache-Control: no-cache et Pragma: no-cache aux en-têtes de requête HTTP dans le module de téléchargement.
• Randomisation de l'URL : Pour contourner les caches de proxys intermédiaires persistants (ISP Cache), nous avons ajouté des paramètres d'horodatage aléatoires ?t=TIMESTAMP aux URL de téléchargement.
• Cette correction a été vérifiée et résout complètement le problème des mises à jour de l'environnement Java bloquées à 99% sur Win7.

---

Résumé de la version

Bien que cette mise à jour v7 paraisse ordinaire en surface, elle contient des changements sous-jacents significatifs. Particulièrement avec le lancement de la fonctionnalité "IphoneCloudFlare", MBBrowser a remporté une victoire décisive dans la lutte contre l'"empreinte TLS" dans les eaux profondes du domaine de l'anti-scraping.

Nous recommandons à tous les utilisateurs engagés dans l'e-commerce japonais et les activités sociales (pcmax, tinder, etc.) de mettre à jour immédiatement et d'activer cette option.

Lien de téléchargement officiel : Version du noyau Chromium 140 (Compatible avec Windows 10/11)