[Feature] Add method to sideload apps when DNS server is not reachable

[devnoname120]

Request

Currently if the DNS server is not reachable (e.g. no Wi-Fi/cellular reception) Feather fails entirely to sideload apps. The reason is that it uses backloop.dev for the local server, which cannot be resolved if the phone is offline.

Another issue are that some DNS providers have localhost rebinding protection which prevents domains from pointing to localhost IPs i.e. backloop.dev doesn’t work. AFAIK AdGuard, Quad9, and NextDNS do that by default.

In order to fix this, Feather could have an option to use localhost directly instead of backloop.dev. Compared to something like backloop.dev it would require to install a certificate on the system, but the upside is that it could work offline entirely.

Would it be possible to add such a sideloading method to Feather? Thank you!

Request Agreement

• I have read the requirements for opening an issue above

Contributor Checks

• I am willing to attempt to make a pull request with these requested features

[claration]

There's a reason why it works the way that it is right now, unfortunately this will most likely not change in the future unless we find a new way of installing apps.

How it works right now is that by default Feather uses the itms-services URL scheme with locally hosted plist data containing the file URL to the app. However, there's a caveat, that URL scheme requires an HTTPS connection, and when installing it needs to contact Apple's servers to perform additional checks for PPQ.

There's another mode thats called semi-local, it works similarly but instead of a local HTTPS server it uses a middle man external server to serve that plist data.

While I do want a way to install while fully offline, I don't think it's particularly viable when it comes to itms-services. Though, you can try to sideload with the idevice installation configuration.

[claration]

Though, keep this issue open because I do want to see if anyone has any solutions for itms-services or something thats not idevice.

[devnoname120]

How it works right now is that by default Feather uses the itms-services URL scheme with locally hosted plist data containing the file URL to the app. However, there's a caveat, that URL scheme requires an HTTPS connection, and when installing it needs to contact Apple's servers to perform additional checks for PPQ.

Would installing a system certificate not be enough to have a localhost HTTPS server that is accepted by itsm-services?

Compared to something like backloop.dev it would require to install a certificate on the system

I’m assuming that there is a default hostname on iOS that resolves to 127.0.0.1 e.g. localhost. Otherwise this will probably not work…

[devnoname120]

I’m assuming that there is a default hostname on iOS that resolves to 127.0.0.1 e.g. localhost. Otherwise this will probably not work…

According to ChatGPT the hostname localhost resolves to 127.0.0.1 by default on iOS. That means that generating an HTTPS certificate with localhost as the Common Name/subjectAltName of the certificate and trusting it from the iOS settings should work in order to host a local server on https://localhost:7803 that works with itms-services.

[devnoname120]

As a line of code is better than a thousand words I vibecoded a solution to explain what I have in mind. It’s not meant to be merged, just to illustrate how it could roughly look like:

#577

Let me know what you think!

[devnoname120]

Btw with regard to PPQ checks here is information I gathered over time: 1. PPQ check is not required on app install. While iOS attempts to perform a PPQ check on install, if the PPQ server is not reachable at the time of installation it just proceeds with the installation and does the PPQ check at the first launch of the app instead. 2. Distribution certificates from developer accounts that have an uninterrupted dev subscription since 2022 (and before) don’t have any PPQ checks in their certificates. Sideloading apps with those doesn’t trigger any PPQ check whatsoever. I have such a certificate and it’s very convenient because unlike certificates with PPQ I can block all the relevant Apple endpoints and be sure that I can use the certificate until its expiration 1 year after even if Apple revokes it (iOS will never know that it is revoked because I blocked all the relevant endpoints in my self-hosted DNS). 3. The bundle ID is absolutely never ever sent to the PPQ endpoint. Bundle ID randomization is entirely futile and doesn’t help whatsoever to prevent certificate revocation. This has been confirmed by reverse engineering the PPQ logic embedded in iOS system modules. 4. PPQ verification is required every 33 days for post-2022 dev acc distribution certificates, and every 7 days for enterprise certs. Hope it helps understand why I would like to be able to do fully offline sideloading!

[binnichtaktiv]

Bundle ID randomization is entirely futile and doesn’t help whatsoever to prevent certificate revocation.

I heard that too but what does PPQ check then?

[claration]

We can definitely improve upon things in the backend regarding the server & PPQ stuff, but I do prefer human solutions rather than speculations and having AI bash at the problem.

[devnoname120]

@binnichtaktiv Here is what @dlopen on Telegram said:

okay, so i reverse engineered PPQ a bit and can say it's actually different from what you may think

PPQCheck (Provisioning Profile Query) is Apple's security mechanism that validates sideloaded iOS applications by checking with Apple's servers during app installation or first launch. in my case, during app installation, the installd daemon initiates an xpn connection to the online-auth-agent, which sends a request to https://ppq.apple.com/v2/authorization. the request contains the following data (signed with CMS and Basic Attestation User Sub):

{
   "cdVersion": 132096,
   "nonce": "Rg2lsWxmYsgtGsLeDp2BHQ==",
   "appID": "PO/xuw0RgEpynQ5s/CPoDVid0qcMzx5L+Inz4I9A/WM=",
   "signingTime": 1757837050000,
   "action": "INSTALL_FINE_GRAINED",
   "checkType": 0,
   "profileID": "9169e2e0-8a3c-4de0-af67-9046dd1c6180",
   "universalProfile": false,
   "localProfile": false,
   "deviceID": "6pO8hz0RqADg2AkfBS6mfn6j3I+TqNdRQ9kpJG0qe1rf/LCTyWjIvw==",
   "rejectedApps": 0,
   "teamID": "tA3YgqW/Nm7/a1dOant1cNjF0tNA0z0V6juo4MrIc0s=",
   "previousRejected": false
}

the server returns:

{
   "actions": [
      "AUTHORIZED"
   ],
   "authorized": true,
   "counterNonce": "epx+BhRd/V3Z2HiaO4ICgQ==",
   "hash": "mx0ONeN5VhXLyEBoSucXyAaolKoSJNxaxGqpPJktuLk=",
   "timestamp": 1757841838838,
   "validity": 33
}

valid actions include AUTHORIZED, REJECT_APP_FOR_PROFILE, REJECT_APP_AND_PROFILE, and REJECT_PROFILE. so PPQ may reject the specific app, reject the profile temporarily, or permanently reject the profile. it stores its lists in the /Library/MobileDevice directory, including AuthListBannedUpps.plist (banned user provisioning profiles), AuthListBannedCdHashes.plist, Indeterminates.plist, Rejections.plist, and others. it has a mechanism to revalidate all profiles periodically, which, from what i found online, happens weekly

the appID in the requests represents the sha256 hash of the CDHash and the provisioning profile ID. a CDHash is a cryptographic hash that identifies a specific version of a signed main binary file, and it changes every time you sign an app since the timestamp is also part of the app signing process. It's impossible for Apple to retrieve the bundle ID of the installed app during the PPQ check, as the CDHash has absolutely nothing to do with it

as far as i can tell, the PPQ protection in Feather seems useless, and it's completely safe to use original bundle IDs. i would say it was created to prevent the distribution of malicious applications through enterprise certificates, to track signed packages, or something, but not to verify if you sideloaded an application with a bundle ID matching one on the app store. each time you sign an app, the CDHash and thus the appID become completely different, without the possibility of identifying the application

[devnoname120]

@khcrysalis Would you be open to merging a PR (not AI generated) for fully-offline sideloading if I worked on it? Asking before I spend time working on it, testing it, etc.

[claration]

A lot of the information I had on PPQ is extremely dated, right before I started making Feather. Ever since I have gotten that information from other people I knew at the time I put it on the README's and inside the app, I really never expected Feather to get as popular as it did so that information did end up spreading to a lot of people, even though in reality I never knew how PPQ worked in the first place. The feature "PPQCheck Protection" was made so I potentially didn't get my friends developer account flagged from trying to develop Feather, and during that I assumed it ended up being fine because that account was never terminated/flagged and I ended up with an expired certificate after a year of using it.

Would you be open to merging a PR (not AI generated) for fully-offline sideloading if I worked on it? Asking before I spend time working on it, testing it, etc.

Sure, but it would need to be a lot more reliable than what we have currently in Feather. Just to note, you cannot open the app without a connection to the internet if the provisioning profile has PPQCheck enabled to true.

[claration]

I do appreciate the effort into reversing what PPQCheck actually does though, information like this is what truly helps the community better understand what Apple is actually doing in the background.

[devnoname120]

Sure, but it would need to be a lot more reliable than what we have currently in Feather.

I think it would be exactly as reliable as the current method (not more and not less), except that it would work fully offline (even if the DNS is unreachable). Downside is that it would require to manually install (once) the generated certificate from the iOS settings. But it would still be a lot easier than the idevice method and wouldn’t need a provisioning profile (which requires a computer to generate) or a VPN.

My plan would be to add this as an option rather than as a replacement for the backloop.dev approach. Just like we currently have Server and idevice tabs, I could add an Offline or localhost tab (or a better name if you have a suggestion).

In my case I’m lucky because my certificate doesn’t contain PPQCheck. To be honest with all the certificate revocations I believe that using old dev accounts without PPQ will be increasingly the only reliable way to sideload on iOS… At least with these you get a full year even in case of revocation as long as you block the relevant endpoints in the DNS.

Currently I block the following endpoints:

||vpp.itunes.apple.*
||certs.apple.*
||crl.apple.*
||valid.apple.*
||ppq.apple.*
||ocsp*.apple.*