macOS не может загрузиться из-за обновления Google Chrome

macOS не может загрузиться из-за обновления Google Chrome

macOS не может загрузиться из-за обновления Google Chrome

Последнее обновление Google Chrome приводит к проблемам с компьютерами, работающими на операционной системе macOS. В частности, различные «маки» не могут корректно загрузиться, о чём сообщили пострадавшие пользователи.

Проблема заключается в том, что вышедший патч портит важную системную директорию. Изначально столкнувшиеся с этой проблемой пользователи приняли такое поведение системы за работу вредоносной программы.

Google уже признал наличие бага, посвятив ему в блоге отдельный пост. Оказалось, что ошибка содержится в новой версии софта, отвечающего за обновление Chrome — Google Keystone.

Известно, что баг угрожает пользователя систем macOS версий 10.9 – 10.14 Mojave, в которых отключена функция Software Integrity Protection (SIP).

Разработчики Google также опубликовали инструкцию, которая должна помочь устранить проблему. Все сводится к удалению текущего Google Keystone и пересозданию символической ссылки к /var.

Также для устранения последствий бага можно ввести в терминале macOS следующие команды, загрузившись предварительно в режиме восстановления:

chroot /Volumes/Macintosh\ HD   # "Macintosh HD" is the default
rm -rf /Library/Google/GoogleSoftwareUpdate/GoogleSoftwareUpdate.bundle
mv var var_back  # var may not exist, but this is fine
ln -sh private/var var
chflags -h restricted /var
chflags -h hidden /var
xattr -sw com.apple.rootless "" /var

После этого потребуется перезагрузить компьютер.

MAX Desktop проверили на слежку за VPN, сенсация не состоялась

Пользователь Хабра Slava_B протестировал поведение десктопного клиента MAX в Windows и не обнаружил признаков того, что мессенджер распознаёт VPN при маршрутизации трафика через роутер. Зато приложение читает ряд системных параметров и идентификаторов компьютера.

Эксперимент провели 8 сентября 2026 года. Windows-компьютер подключили к роутеру Keenetic, который самостоятельно распределял трафик: российские ресурсы открывались напрямую, а часть остальных соединений уходила через OpenConnect-туннель на европейский VPS.

В самой Windows не было ни VPN-клиента, ни виртуального адаптера, ни соответствующих маршрутов.

За клиентом MAX следили с помощью Process Monitor, Wireshark и TCPView, а трафик на удалённом сервере записывали через tcpdump. Исследователь выяснил, что приложение запускает процессы MAX.exe и MAX-service.exe, связывающиеся между собой через локальный порт. Клиент подключался к инфраструктуре MAX/ONEME, сервису AppTracer и системам для звонков.


MAX и его служебный процесс многократно читали MachineGuid — стабильный идентификатор установки Windows. Программа также получала имя компьютера, настройки proxy/PAC, собственные device ID и сведения о микрофонах и камере. Впрочем, подобные данные могут использоваться для диагностики, антифрода, подключения через корпоративный прокси и работы звонков.


Главный результат успокаивает: соединения MAX не появились на VPN-интерфейсе VPS, а обращений к сервисам определения внешнего IP, Telegram, WhatsApp (принадлежит корпорации Meta, признанной экстремисткой и запрещённой в России) или другим ресурсам для проверки маршрута исследователь не выявил. Браузеры клиент тоже не запускал.

При этом автор подчёркивает: содержимое TLS-трафика не расшифровывалось, поэтому доказательств передачи MachineGuid или других идентификаторов на сервер нет. Результат относится только к конкретной конфигурации и не показывает, как MAX поведёт себя с VPN-клиентом непосредственно в Windows.

RSS: Новости на портале Anti-Malware.ru