В августе 2026 года часть пользователей iMazing и других сторонних инструментов для работы с App Store столкнулась с ошибкой HTTP 403 при загрузке приложений. Новые технические данные указывают на то, что проблема может быть значительно серьезнее обычного изменения адреса сервера или формата запроса.
По данным разработчиков и участников проекта ipatool, Apple начала отклонять как современный, так и устаревший варианты авторизации CommerceKit. Реверс-инжиниринг системных компонентов Apple указывает на возможный переход к аппаратной проверке через Secure Enclave.
Важно: Apple и разработчик iMazing, компания DigiDNA, пока публично не подтвердили это техническое объяснение. Выводы о Secure Enclave основаны на исследовании компонентов AppleMediaServices и CommerceKit участником проекта ipatool.
Что случилось с iMazing в августе 2026 года
Проблема проявляется при операциях iMazing, которым требуется взаимодействие с серверами App Store: авторизация Apple Account, получение приложения, проверка прав на загрузку или другие операции CommerceKit.
Серверы Apple в таких случаях могут возвращать ошибку HTTP 403 Forbidden. Аналогичная проблема зафиксирована в открытом проекте ipatool.
В issue 522 были проверены сразу несколько вариантов авторизации:
- современный механизм
auth/v1/native/fast; - старый механизм
MZFinance.woa/wa/authenticate; - сервер Store pod, назначенный через Apple Configurator.
Во всех случаях Apple могла отклонять запрос еще до того, как стандартная авторизация Apple Account давала приложению возможность продолжить работу.
Почему смена сервера или User-Agent больше может не помочь
Ранее подобные сбои сторонних клиентов App Store иногда удавалось исправить переходом на другой endpoint, изменением заголовков запроса или обновлением логики авторизации.
Однако исследование issue 522 указывает на другое изменение. В актуальной конфигурации Apple Store несколько операций авторизации отмечены как требующие SAP signing.
В частности, это касается:
MZFinance: authenticate;auth/v1: native;auth/v1/native: fast.
Это означает, что проблема может заключаться не в неправильном адресе сервера и не в отсутствии обычного HTTP-заголовка.
При чем здесь Secure Enclave
Автор issue 522 исследовал системные компоненты AppleMediaServices и CommerceKit и проследил процесс формирования Store credential, который используется при обращении к сервисам App Store.
По результатам этого исследования, Store credential, известный как X-Token или passwordToken, теперь может получаться через AMSMediaTokenService в виде Private Access Token.
Главное отличие заключается в том, что для формирования такого токена используется ключ, связанный с Secure Enclave.
В исследованных компонентах обнаружены механизмы, связанные с:
SecKeyCreateAttestation;kSecAttrTokenIDSecureEnclave;CryptoKit.SecureEnclave.P384.Signing.PrivateKey;- FairPlay Device Identity;
- аппаратной аттестацией устройства.
Если эта схема действительно используется Apple для новых запросов App Store, обычной авторизации Apple ID и паролем становится недостаточно.
Apple Account может авторизоваться, но App Store все равно отказывает
Еще одна важная деталь исследования заключается в том, что стандартная система GrandSlam SRP продолжает работать.
Она может успешно возвращать данные авторизации учетной записи, включая DsPrsId, GsIdmsToken и com.apple.gs.idms.pet.
Но попытка использовать полученный PET в качестве Store-токена приводит к ошибкам CommerceKit.
В тестах автора исследования:
buyProductвозвращалfailureType 2002иMZCommerce.BadPasswordToken;volumeStoreDownloadProductвозвращалfailureType 2042иMZCommerce.AuthTokenResumeFreeBuy.
Таким образом, пользователь может успешно пройти обычную проверку Apple Account, но стороннее приложение все равно не получит необходимое разрешение на последующую операцию App Store.
Почему iMazing перестал работать не у всех одновременно
Автор технического исследования предполагает, что Apple включает новую систему постепенно: для разных storefront, серверных pod и групп учетных записей.
Это может объяснять, почему проблема распространялась волнами. Учетные записи со старым сохраненным passwordToken потенциально способны продолжать работу до истечения срока действия токена, тогда как новая авторизация уже сталкивается с новым механизмом проверки.
Однако Apple официально не подтверждала поэтапное развертывание этого изменения, поэтому эту версию пока следует рассматривать именно как техническое объяснение участников проекта ipatool.
Почему Secure Enclave создает проблему для iMazing и других программ
Secure Enclave устроен таким образом, что закрытый криптографический ключ не должен покидать защищенную аппаратную среду устройства.
По данным реверс-инжиниринга, Apple дополнительно проверяет цепочку аттестации, а доступ к необходимым операциям связан с системным процессом appstoreagent и специальными разрешениями Apple.
Среди обнаруженных разрешений:
com.apple.security.attestation.access;com.apple.keystore.absinthe;com.apple.keystore.sik.access.
Если сервер действительно требует подпись, созданную аппаратным ключом доверенного Apple-устройства, сторонней программе недостаточно просто воспроизвести HTTP-запрос.
Нельзя взять такой закрытый ключ из Secure Enclave, скопировать его на другой компьютер и использовать в iMazing или ipatool обычным способом.
Означает ли это, что Apple окончательно заблокировала iMazing
Пока такого вывода сделать нельзя.
Apple не объявляла о блокировке iMazing, а DigiDNA не сообщала о прекращении функции Manage Apps.
Более того, официальная документация iMazing по-прежнему описывает возможность:
- скачивать приложения из App Store;
- хранить IPA-файлы в локальной библиотеке;
- устанавливать приложения на подключенный iPhone или iPad;
- работать с ранее загруженными версиями приложений.
На момент публикации новости актуальной публичной версией iMazing остается 3.6.2, выпущенная 30 июля 2026 года.
При этом новые ошибки авторизации появились уже после выпуска этой версии.
Можно ли исправить проблему обычным обновлением iMazing
Если причина ограничивается очередным изменением протокола Apple, разработчики iMazing теоретически могут адаптировать программу, как это происходило ранее.
Но если выводы реверс-инжиниринга issue 522 верны и сервер App Store действительно требует аппаратную аттестацию Secure Enclave, задача становится намного сложнее.
В этом случае недостаточно:
- сменить User-Agent;
- переключиться на старый endpoint;
- добавить недостающий HTTP-заголовок;
- получить новый PET обычной авторизацией Apple Account.
Стороннему приложению потребуется механизм, который способен получить признанное серверами Apple подтверждение от настоящего доверенного устройства или от разрешенного системного компонента Apple.
Будет ли iMazing снова устанавливать приложения
На 25 августа 2026 года точного ответа нет.
Известно, что сторонние инструменты столкнулись с реальными изменениями в работе серверной авторизации App Store. Также есть технические признаки использования Apple более строгой аппаратной аттестации.
Но пока нет официального заявления Apple о новых требованиях CommerceKit и нет публичного объяснения DigiDNA о том, каким способом разработчики iMazing планируют восстановить полноценную работу Manage Apps.
Поэтому говорить об окончательном закрытии установки приложений через iMazing преждевременно. В то же время нынешняя проблема выглядит серьезнее предыдущих сбоев авторизации, которые можно было устранить обычным обновлением клиента.
Коротко: что известно сейчас
- iMazing и ipatool столкнулись с отказами серверов App Store и HTTP 403.
- Проблема затрагивает как старую, так и новую схему CommerceKit-аутентификации.
- Обычная авторизация Apple Account сама по себе может продолжать работать.
- По данным реверс-инжиниринга, Apple может требовать Private Access Token и аппаратную аттестацию Secure Enclave.
- Такую подпись нельзя просто воспроизвести заменой HTTP-заголовков или User-Agent.
- Apple официально не объявляла о блокировке iMazing.
- iMazing официально продолжает заявлять функцию установки и загрузки приложений.
- Публичного исправления проблемы на момент публикации новости пока нет.
Выбираете новый iPhone? Посмотрите актуальные модели, цены и наличие в VIPMarket iPhone24.
Источники
При подготовке материала использованы открытое обсуждение issue #522 проекта ipatool на GitHub и актуальная документация iMazing по функции Manage Apps. Технические выводы о Private Access Token, Secure Enclave и аппаратной аттестации относятся к результатам реверс-инжиниринга участника проекта ipatool и не являются официальным заявлением Apple.