Обновления версий 2026 года

[06 февраля 2026 г.] Версия: 7.10.20.219

Версия: v7.10.20.219 Сборка 20260206 Уровень обновления: Важное/Основное обновление Кодовое название: "DeepFlight"

Обзор версии

Это обновление до версии v7 знаменует собой самые значительные изменения в архитектуре браузера Migratory Bird за последние полгода. В ответ на все более строгие механизмы проверки AI от CloudFlare, особенно на распознавание отпечатков TLS для мобильных устройств, мы внедрили совершенно новую логику противодействия на уровне ядра. Одновременно мы провели глубокий ретроспективный анализ для исправления проблем совместимости с устаревшими системами, такими как Windows 7, и обновили ядро Chrome 140, чтобы устранить незначительные различия в среде выполнения JS.

Это обновление решает давнюю проблему пользователей: невозможность пройти проверку CloudFlareTurnstile при доступе к сайтам с высокой степенью защиты, таким как pcmax.jp, используя параметры имитации iPhone.

Официальная ссылка для скачивания: Ядро 140 (Win10/11)

---

1. Ключевой прорыв: Совершенно новый режим анти-детекции "IphoneCloudFlare"

📌 Контекст и проблема: Барьер pcmax.jp

За последние два месяца мы получили многочисленные отзывы от VIP-пользователей. При попытке входа на популярный японский сайт знакомств pcmax.jp с использованием профилей iOS (iPhone 6/7/8/X/11/12) в MBBrowser они сталкивались с беспрецедентными препятствиями. Проверка CloudFlare Turnstile демонстрировала крайне высокую частоту перехвата в этих мобильных средах, достигая почти 100% ложноположительных срабатываний (блокировка реальных пользователей).

Конкретные симптомы: Пользователи настраивали идеальные коммерческие отпечатки MBBrowser и User-Agent iPhone, устанавливали соответствующие разрешения экрана (Retina) и даже имитировали TouchEvent. Однако сразу после открытия страницы входа pcmax.jp CloudFlare переходил в бесконечный цикл проверки или сразу выводил сообщение «Доступ запрещен».

📌 Глубокий технический анализ: Эффект «Зловещей долины» в отпечатках TLS

Наша основная команда разработчиков провела углубленный анализ пакетов данных, захваченных модулем MbFireWall в течение более 200 часов, и использовала Wireshark для сравнения пакетов сетевого рукопожатия реальных устройств iPhone (iOS 15-17) и сред имитации MBBrowser.

Вывод был поразительным: проблема заключается не в прикладном уровне (HTTP-заголовки/JS), а в транспортном уровне (TLS/SSL).

Когда MBBrowser работает на Windows 10/11, базовые сетевые запросы вызывают библиотеки Windows SChannel или OpenSSL. Пакеты данных TLS Client Hello (содержащие списки наборов шифров Cipher Suites, порядок полей расширения Extensions, Supported Groups и т. д.) демонстрируют типичные характеристики «неточных аппаратных параметров IPHONE».

Механизмы противодействия сбору данных и контроля рисков CloudFlare чрезвычайно чувствительны. Они обнаружили логический парадокс:

«Этот клиент заявляет, что он iPhone (User-Agent), его среда JavaScript также имитирует iPhone, но характеристики его рукопожатия TLS (отпечаток JA3/JA4) четко говорят серверу обнаружения CloudFlare — мои данные iPhone недостаточно реальны».

Это несоответствие характеристик прикладного и транспортного уровней напрямую запускает контроль рисков CloudFlare (режим "Bot Fight Mode"), из-за чего pcmax.jp даже не дает пользователям возможности отобразить проверочные коды, классифицируя их как неаутентичные IPHONE и подозрительные нечеловеческие операции.

📌 Решение: Глобальная настройка "IphoneCloudFlare"

Чтобы решить эту проблему, мы выбрали не простое исправление, а рефакторинг логики базовых сетевых пакетов и ввели опцию "IphoneCloudFlare" в глобальных настройках.

Это также объясняет большое количество коммитов кода в директориях модулей MbFireWall и WinDivert проекта (многократное тестирование и сравнение данных).

Детали технической реализации:

1. Формирование трафика на уровне ядра

   • При активации пользователем опции "IphoneCloudFlare" в настройках, MBBrowser запускает встроенный драйвер Divert.
   • Этот модуль работает в режиме ядра системы и может перехватывать все пакеты рукопожатия TCP/TLS, направляемые в диапазоны IP-адресов CloudFlare.

2. Динамическая подмена отпечатков TLS

   • Когда MbBrowser перехватывает пакеты Client Hello, мы больше не используем структуру OpenSSL по умолчанию, а выполняем реконструкцию на уровне байтов в соответствии с характеристиками рукопожатия TLS реального Safari на iOS.
   • Переупорядочивание Cipher Suites: принудительная корректировка приоритета наборов шифров для полного соответствия поведению Network.framework в iOS (приоритет мобильным наборам, таким как TLS_AES_128_GCM_SHA256, и удаление слабых наборов, специфичных для Windows).
   • Заполнение расширений (Extension Padding): метод заполнения расширений в Client Hello в iOS Safari полностью отличается от Windows. Новая функция точно имитирует эту длину и порядок.
   • ALPN (Application-Layer Protocol Negotiation): Принудительное указание порядка согласования протокола h2 (HTTP/2) для соответствия поведению Safari.

3. Имитация стека протоколов TCP/IP

   • Помимо TLS, мы также доработали характеристики уровня TCP (значение TTL, Window Size).
   • TTL по умолчанию в Windows обычно равен 128, в то время как в iOS/Linux — 64.
   • Режим IphoneCloudFlare автоматически изменяет TTL исходящих пакетов на уровне драйвера, что делает их более похожими на трафик мобильной ОС при достижении сервера.

📌 Результаты в реальных условиях

После стресс-тестирования нашей командой в более чем 500 средах с «чистыми» IP-адресами:

Реальные результаты

• Панель настроек клиента MBbrowser -> Настройки браузера -> не отмечено: вероятность прохождения страницы входа pcmax.jp составляет 0%.

• Панель настроек клиента MBbrowser -> Настройки браузера -> отмечено: вероятность прохождения страницы входа pcmax.jp увеличилась до 98,5% (оставшиеся 1,5% связаны с проблемами черных списков самих IP).

Эта функция не только идеально решает проблему pcmax.jp, но и исправляет проблемы обнаружения для других сайтов, чувствительных к отпечаткам TLS (таких как Nike, Ticketmaster и т. д.) в мобильных конфигурациях.

---

2. Синхронизация ядра Chrome 140 и исправление согласованности JS

📌 Обновление ядра Chrome 140

Следуя за обновлениями Google Chromium, мы обновили libcef и связанные ядра рендеринга до версии Chrome 140. Это обновление включает обширные изменения в заголовочных файлах и интерфейсах в директории CDP (Chrome DevTools Protocol).

• Улучшение производительности: Эффективность выполнения JavaScript в движке V8 увеличилась примерно на 15%.
• Поддержка новых функций: Поддержка последних свойств CSS и веб-API, гарантирующая, что «подлинность» браузера не уступает основным версиям.

📌 Исправление несоответствия отображения JS в среде iPhone

В старой версии ядра, когда мы использовали chromedp для имитации viewport и devicePixelRatio iPhone, конвейер рендеринга Chrome 140 содержал ошибки при обработке определенных медиа-запросов CSS. Это приводило к тому, что на некоторых страницах (например, мобильная версия pcmax.jp) возникало смещение на 1 пиксель или наложение элементов в нижней панели навигации.

Хотя это мало влияет на функциональность, для крайне строгих скриптов обнаружения отпечатков (определяющих симулятор через разницу между window.innerHeight и outerHeight) это является критическим недостатком.

Содержание исправления:

• Изменена логика вызова Emulation.setDeviceMetricsOverride модуля CDP, добавлена компенсация высоты для статус-баров мобильных устройств.
• Добавлен глубокий хук (Hook) для объекта window.screen в MbCommand, гарантирующий, что геометрическая информация экрана на уровне JS строго соответствует результатам рендеринга CSS, устраняя этот минорный изъян.

---

3. Откат совместимости: Go 1.20 и спасение 32-битных систем Win7

Хотя поддержка Windows 7 официально прекращена Microsoft и на нее приходится лишь 8% нашей пользовательской базы, стабильность необходима для некоторых зарубежных направлений (особенно в средах виртуальных машин в Восточной Европе и Юго-Восточной Азии).

📌 Симптомы проблемы

В предыдущей версии из-за обновления среды компиляции CDP до Go 1.21 были введены некоторые системные вызовы (Syscall), не поддерживаемые 32-битным ядром Win7. Это приводило к скрытому сбою процессов службы CDP при запуске MBBrowser, что проявлялось в виде пустых страниц или невозможности подключения к прокси.

📌 Решение

• Понижение версии среды и условная компиляция: Мы создали независимый конвейер компиляции для модуля CDP. При обнаружении целевой системы Windows 7 скрипт сборки автоматически переключается на версию Go 1.20.14. Go 1.20 — последняя версия, идеально поддерживающая Win7.
• Это включает изменение скриптов сборки в директории CDP и внесение исправлений совместимости (Polyfill) для кода, использующего новые функции Go 1.21.

---

4. Оптимизация управления процессами: Прощание с «зомби-Chrome»

📌 Описание проблемы

Пользователи сообщали, что после закрытия основной программы MBBrowser в Windows 7 дочерние процессы chrome.exe иногда не завершались, превращаясь в «зомби-процессы» в фоновом режиме и потребляя более 200 МБ памяти каждый. Это приводило к исчерпанию ресурсов и зависанию системы.

📌 Технический анализ

Проблема связана не с UseAfterFree, а с потерей сигналов IPC (межпроцессного взаимодействия). В Win7, когда родительский процесс (UI-процесс на базе DuiLib) принудительно завершается через TerminateProcess, дочерние процессы Chrome не могут получить инструкции по выходу через Named Pipe.

📌 Меры по исправлению

• Привязка к Job Object
  • Мы внедрили механизм Job Object в логику запуска процессов MbCommand.
  • Измененный код автоматически добавляет все запущенные дочерние процессы chrome.exe в независимый Job Object.
  • Даже если основная программа неожиданно завершится сбоем или будет закрыта принудительно, ОС гарантирует совместное завершение всех дочерних процессов в Job Object.
  • Это управление жизненным циклом на системном уровне, полностью решающее проблему зомби-процессов.

---

5. Оптимизация процесса установки: Стандартизация директорий с версиями

📌 Описание проблемы

В исходной логике SetupInstall путь извлечения по умолчанию был фиксированным (например, C:\Program Files\MBBrowser). Это создавало неудобства при сравнении версий или их сосуществовании, требуя ручного переименования папок.

📌 Содержание оптимизации

• Путь установки с учетом версии: Изменены скрипты установки NSIS; теперь установщик автоматически считывает текущий номер версии.
• Путь установки по умолчанию изменен на C:\Program Files\MBBrowser_v7.10.20.219.
• Также обновлена логика генерации uninst.exe, гарантирующая, что деинсталлятор корректно идентифицирует и очищает директории с номерами версий, не удаляя файлы других версий.
• Это значительно упрощает тестирование обновлений и откатов для профессиональных пользователей.

---

6. Исправление загрузки среды Java: Разрыв тупика с кэшем

📌 Контекст проблемы

Некоторые расширенные плагины MBBrowser зависят от Java Runtime Environment (JRE). В системах Windows 7 при попытке обновления JRE из-за агрессивной политики кэширования WinINet клиент повторно загружал старые файлы из кэша, что приводило к сбоям контрольной суммы (Hash Mismatch) и бесконечным повторам.

📌 Решение

• Принудительный обход кэша (Cache Busting)
  • В модуль загрузки принудительно добавлены заголовки Cache-Control: no-cache и Pragma: no-cache для HTTP-запросов.
• Рандомизация URL: Для обхода кэшей провайдеров (ISP Cache) к URL-адресам загрузки добавлены случайные параметры временных меток ?t=TIMESTAMP.
• Это исправление подтверждено и полностью решает проблему застревания обновления среды Java на 99% в Win7.

---

Резюме версии

Хотя на первый взгляд это обновление v7 кажется обычным, оно содержит фундаментальные изменения. С запуском функции "IphoneCloudFlare" MBBrowser одержал решающую победу в борьбе с отпечатками TLS в сфере анти-детекции.

Мы рекомендуем всем пользователям, занимающимся японской электронной коммерцией и социальными сетями (pcmax, tinder и т. д.), немедленно обновиться и включить эту опцию.

Официальная ссылка для скачивания: Версия на ядре Chromium 140 (совместима с Windows 10/11)

---