0xe8008024 / 0xe8008018: not certificate revocation, and enforced locally on the device

[eliabal]

Short version: on one free Apple ID I regenerated everything a signer controls
(private key, development certificate, App ID, bundle identifier, provisioning
profile) and the device rejected all of it, while a second free Apple ID installed
fine on the same iPhone minutes of work later. Apple's OCSP responder says the
rejected certificate is good. And with the phone in airplane mode, a profile Apple
had issued seconds earlier was still rejected as banned, so whatever the device is
checking, it already has it locally.

Setup: iloader 2.3.1 on Windows 11, iPhone 16 Pro on iOS 26.6.1 over USB, SideStore
(.io) anisette. Two free accounts, neither on the Developer Program. Account A is EU
and has been sideloading for years, account B is US and never had.

I changed one variable at a time on account A:

what changed	result
nothing, reused existing certificate	0xe8008024 profile is banned
new certificate, same key	0xe8008018 identity no longer valid
new certificate after revoking all	0xe8008018
new private key and new certificate	0xe8008018
new bundle ID, new App ID, new profile	0xe8008018
account B, everything else identical	installed
account A, phone in airplane mode	0xe8008024

For the bundle ID row I took a minimal app with no extensions, rewrote
CFBundleIdentifier to something that has never existed anywhere, and imported it.
iloader registered a new App ID and Apple issued a matching profile a second before
signing, correct UDID provisioned. Rejected like the rest, so the block does not
follow the app or its App ID.

The certificate in that last rejected signature was issued by WWDR G3, valid for a
year, and the CMS blob carries the full chain (leaf, WWDR G3, Apple Root CA). Its
OCSP status is good, checked minutes after the device refused it. As a control,
two certificates I had deliberately revoked earlier come back revoked with times
matching when I revoked them, so the responder is accurate and current. You can
check this on any affected install by pulling the profile out of the app iloader
staged (it survives a failed install, on success it gets cleaned up):

openssl smime -inform DER -verify -noverify \
  -in embedded.mobileprovision -out profile.plist
python3 -c "import plistlib;open('leaf.der','wb').write(
  plistlib.load(open('profile.plist','rb'))['DeveloperCertificates'][0])"
openssl x509 -inform DER -in leaf.der -out leaf.pem
curl -s https://www.apple.com/certificateauthority/AppleWWDRCAG3.cer -o g3.cer
openssl x509 -inform DER -in g3.cer -out g3.pem
openssl ocsp -issuer g3.pem -cert leaf.pem \
  -url http://ocsp.apple.com/ocsp03-wwdrg303 \
  -header "Host=ocsp.apple.com" -noverify

I also ran it with the phone in airplane mode, PC online, same minimal app on
account A. Apple issued the profile, the app was signed a second later, the device
rejected it about five seconds after that. The profile was seconds old and the
device had never seen it, the phone had no network so it could not look anything up,
and the profile is structurally identical to one issued to the same App ID hours
earlier (same key set, no extra fields, only the DER blob differs because it embeds
the UUID and dates). So the device is holding state keyed on the team and refusing
anything carrying it, offline. Installing offline is not a workaround, and if that
state was pushed to devices then lifting the block probably needs another push
rather than a server-side flag, which makes "this shouldn't be permanent" slower
than it sounds.

The same App ID gave 0xe8008018 on one run and 0xe8008024 on another. I read
those as two surfaces of the same team-level state rather than two separate lists,
surfacing at whichever check gets evaluated first.

Requesting fresh provisioning profiles instead of reusing existing ones is necessary
but not sufficient. A fresh profile does clear 0xe8008024, but installation then
fails at the next check and stays there through every regeneration I tried. There is
nothing left on the client side to fix.

Unrelated to the above, three different failures are getting reported as the same
thing. Anisette and auth problems (HTTP 503 from gsa.apple.com, Failed to get anisette data, error sending request ... listTeams.action, ADIOTPRequest failed (-45061)) all cleared on retry within minutes for me. The signing block is
persistent and account-scoped. LocalDevVPN and device reachability is separate
again. The first two look identical to users and need opposite advice, and asking
for OCSP status in the template would split them automatically.

What I cannot answer is which account attribute triggers it. My two accounts differ
in identity, region and sideloading history, so this separates account from device
but not those three from each other. I would not say Apple bans accounts for
sideloading on this evidence, it is one reading of several, though the region split
is worth noting since at least one report in #583 describes the same EU-blocked,
US-working pattern. I also only have one device, so I cannot test whether a phone
that never received the state would still accept a blocked account. For what it is
worth, the iOS 26+ theory from Discord on Sept 1 does not hold here, since the same
26.6.1 device accepts B and rejects A.

Happy to run more tests, I have a blocked account and a working one on the same
hardware so A/B testing is easy. Related: #583 #571 #580 #589 #605 #611 #633 #638
#641 #644, altstoreio/AltStore#1775, Apollo-Reborn/Apollo-Reborn#1014 (Sideloadly,
same code).

[nythepegasus]

Howdy! I wanted to add some insight somewhere of my current (limited) findings along with your investigations here. It appears iOS 18+ have added a new mechanism for querying ppq.apple.com which is Apple's profile validation server. Generally on versions below iOS 26 all communication was handled via a single daemon, misagent, and it used to seemingly only operate on individual profiles and app cdhashes.

iOS 18+ has changed this to a new shared library called libmis which handles a lot of the mis.db operations, as well as online-auth-agent. iOS 26+ specifically moved banned profile UUIDs as well as banned cdhashes into the mis.db file along with more team information and "online auth" data. This has already been exploited and may even help users facing error 0xe8008024 but more testing is required there.

To note, older devices stored banned cdhashes and profile UUIDs in separate plist files on disk rather than in the mis.db as newer versions do. Their paths can be found at:

/private/var/db/MobileIdentityData/AuthListBannedCdHashes.plist
/private/var/db/MobileIdentityData/AuthListBannedUpps.plist

Here is a compiled together list of queries ran per schema version migration online-auth-agent performs on mis.db

schema:

-- NOTE: the "withBind" stuff is from the queries Apple's code adds while querying the db
-- this is every visible sqlite statement within online-auth-agent's reversed pseudocode
-- schema version 1
CREATE TABLE profiles(uuid TEXT NOT NULL PRIMARY KEY withBind:team_id TEXT NOT NULL withResults:{install_time TEXT DEFAULT CURRENT_TIMESTAMP, name TEXT NOT NULL, expires INTEGER, is_for_all_devices INTEGER, is_apple_internal INTEGER, is_local INTEGER, is_beta INTEGER, cms_blob BLOB NOT NULL);
CREATE TABLE certificates(pk INTEGER PRIMARY KEY AUTOINCREMENT withBind:leaf BLOB UNIQUE NOT NULL);
CREATE UNIQUE INDEX certificate_leaf_index ON certificates (leaf);
CREATE TABLE certificate_provisioning_cache(pk INTEGER PRIMARY KEY AUTOINCREMENT withBind:uuid TEXT NOT NULL withResults:{leaf_pk INTEGER NOT NULL, UNIQUE(uuid, leaf_pk), CONSTRAINT fk_certificate_leaf  FOREIGN KEY (leaf_pk)  REFERENCES certificates(pk)  ON DELETE CASCADE, CONSTRAINT fk_cert_profile_uuid  FOREIGN KEY (uuid)  REFERENCES profiles(uuid)   ON DELETE CASCADE);
CREATE TABLE entitlements_provisioning_cache(pk INTEGER PRIMARY KEY AUTOINCREMENT withBind:uuid TEXT NOT NULL withResults:{predicate TEXT NOT NULL, wildcard INTEGER NOT NULL, UNIQUE(uuid, predicate), CONSTRAINT fk_predicate_profile_uuid  FOREIGN KEY (uuid)  REFERENCES profiles(uuid)   ON DELETE CASCADE);
CREATE UNIQUE INDEX entitlements_cache_index ON entitlements_provisioning_cache (uuid withBind:predicate);
-- schema version 2
ALTER TABLE profiles ADD COLUMN is_der INTEGER DEFAULT (0);
CREATE TABLE xml_profiles_cache(uuid TEXT NOT NULL PRIMARY KEY withBind:cms_blob BLOB NOT NULL withResults:{CONSTRAINT fk_xml_profile_cache_uuid  FOREIGN KEY (uuid)  REFERENCES profiles(uuid)   ON DELETE CASCADE);
-- schema version 3
-- pseudocode (seemingly) searches for profile UUIDs that match "AppleInternal"
UPDATE profiles SET is_beta = 1 WHERE uuid = @uuid;
-- schema version 4
CREATE TABLE IF NOT EXISTS trusted_team_ids(team_id TEXT PRIMARY KEY withBind:signature BLOB);
-- schema version 5
SELECT team_id withBind:signature FROM trusted_team_ids;
UPDATE trusted_team_ids SET signature = NULL WHERE team_id = ?1;
-- schema version 6
CREATE TABLE IF NOT EXISTS team_id_info(team_id TEXT NOT NULL withBind:team_name TEXT NOT NULL withResults:{PRIMARY KEY (team_id));
SELECT profiles.team_id withBind:profiles.cms_blob withResults:{profiles.uuid FROM profiles;
INSERT INTO team_id_info VALUES (@team_id withBind:@team_name);
-- schema version 7
CREATE TABLE IF NOT EXISTS signing_identities(pk INTEGER PRIMARY KEY AUTOINCREMENT withBind:uuid TEXT NOT NULL withResults:{signing_identity TEXT NOT NULL, UNIQUE(uuid, signing_identity), CONSTRAINT fk_signing_identity_profile_uuid  FOREIGN KEY (uuid)  REFERENCES profiles(uuid)   ON DELETE CASCADE);
SELECT uuid withBind:cms_blob FROM profiles WHERE is_der = 0 AND (is_for_all_devices = 1 OR is_local = 1);
SELECT xml_profiles_cache.uuid withBind:xml_profiles_cache.cms_blob FROM xml_profiles_cache LEFT JOIN profiles ON profiles.uuid = xml_profiles_cache.uuid WHERE profiles.is_for_all_devices = 1 OR profiles.is_local = 1;
INSERT OR IGNORE INTO signing_identities VALUES (NULL withBind:@uuid withResults:{@signing_identity);
-- schema version 8
-- these are new in 26+
CREATE TABLE IF NOT EXISTS online_auth( uuid TEXT NOT NULL withBind:cdhash BLOB NOT NULL withResults:{grace_period INT NOT NULL, last_success_monotonic_time INT NOT NULL, last_success_reset_count INT NOT NULL, is_rejected INT NOT NULL DEFAULT (0), is_rejected_by_whole_profile INT NOT NULL DEFAULT (0), PRIMARY KEY (uuid, cdhash), CONSTRAINT fk_online_auth_profile_uuid    FOREIGN KEY (uuid)    REFERENCES profiles(uuid)    ON DELETE CASCADE);
CREATE TABLE IF NOT EXISTS banned_profile_uuids( uuid TEXT NOT NULL);
CREATE TABLE IF NOT EXISTS banned_cdhashes( cdhash BLOB NOT NULL);
-- schema version 9
SELECT uuid withBind:predicate FROM entitlements_provisioning_cache WHERE predicate LIKE 'string%' || x'1f' || '*' AND wildcard = 1;
INSERT OR IGNORE INTO entitlements_provisioning_cache (uuid withBind:predicate withResults:{wildcard) VALUES (?1, ?2, 1);

That leads to the other new daemon on newer versions, online-auth-agent which seems to now speak to ppq. It sends a request that contains deviceID + profileID + appID + teamID, and ppq then responds in 1 of 4 ways, AUTHORIZED, REJECT_APP_FOR_PROFILE, REJECT_APP_AND_PROFILE, and REJECT_PROFILE.

When a device throws error 0xe8008024 then all devices (even those on lower versions than 26!!) seem to throw error 0xe8008018 with the team that caused it. Users have reported creating a separate account with a new team has worked for said devices like you reported above.

I'll also add using the above repo, it appears 0xe8008024 existed to be handled in their code for a long time, but it wasn't actually set anywhere until 26+ and is only set two times in libmis_02.

We have not been able to determine what causes ppq to ban profiles and only some teams and only on newer versions. Stranger still, as you observed as well, the developer API happily provisions new certificates and profiles that appear perfectly valid but are immediately banned via ppq. We're definitely still looking into this, but hopefully this provides at least a little bit more information as to the nature of the issue.

[MorteADio]

as a user of both sidestore and altserver as already mentioned by op and nythepegasus it seems to be on apples end trying to affect the users of free developer accounts.

[Hny-B-King]

For what it’s worth. 2 of my iPhones running latest iOS 27 beta’s didn’t get the profile bans yet. But 3 of my friends after updating to 26.6.1 got banned. And even after a successful refresh every day, all apps got unverified.

Hope to see a fix soon