Recently I saw a website that include lots of AppStore applications and they resigned that applications via their Enterprise account and let people to download them directly to their iPhone/iPads.
I am wondering how they do this? I had resigned .ipa files that was created for Ad-Hoc via Enterprise; but how they resign AppStore applications with enterprise account too?
I am wondering for the answer because it is important and we should consider more security challenges for the case of resigning our appstore applications with enterprise accounts.
When an IPA is downloaded from the app store (including by Xcode), the binaries in that IPA are encrypted by Apple. Simply resigning these binaries will not work. One way to remove the DRM, and this may be illegal in your country, is to extract the unencrypted binary during runtime on a jailbroken device.
Note that when resigning apps, such services need to use a different provisioning profile than you originally used, and that provisioning profile will have a different bundle identifier than the one in your Info.plist. You can use tools such as TCMobileProvision to inspect and compare the two identifiers. This is a mouse and cat game, as they could actively look for that code and remove it statically, but you will most likely reduce the possibility of your app being resigned significantly.
Adding on to Leo's answer:
There are tools available such as Clutch to help decrypt the Apple signed binary on a jailbroken device at runtime. After decrypting the binary, you will need to figure out the app's bundle id and entitlements. Some versions of Theos (such as theos-jailed) come with an info tool that dumps the application entitlements. When regenerating your patched provisioning profiles, you must be sure your patched profile match the entitlements of the original profile used by the target app.
Everything after the decryption step can be accomplished without a jailbroken device. A jailbreak is required to remove the AppleFairplay DRM by dumping/decrypting the signed app by patching into the device's runtime.
Related
We have a series of iOS Enterprise applications that were built with Telerik Cordova (discontinued in May 2018). Those apps are in the process of being converted to a new platform, but in the mean time they must continue to service client needs.
The distribution certificate the apps were built with is valid for another 14 months or so, but the provisioning profiles expire in a few days. Since these are Enterprise apps they will expire with the profiles.
Unfortunately, Telerik can no longer rebuild the apps using an updated profile for us. We have re-signed the apps using new provisioning profiles (using both iReSign and Terminal). When we try to side-load the resulting IPAs through the XCode Devices panel, we get an error stating that the entitlements do not match and the apps are not installed.
The question was raised as to whether or not we not need to re-sign the apps since the certificates are still valid. Perhaps it would be possible to just replace the .mobileprovision file on the device somehow? I gave it a try using iTunes Sync but I cannot confirm whether the file actually went to the device or not.
Question: Is it possible to just update the *.mobileprovision on the device without re-signing the app? If so, could someone please give me the steps or direct me to a link to perform the steps?
Alternate Question: Otherwise, any thoughts on how to resolve my Entitlements issue? The app only needs Push Notifications, but Game Center and In-App Purchases are also enabled. These are reflected in the App ID and provisioning profile, and the distribution certificate is of type Apple Push Services.
I should point out that I am not an admin on the Apple Developer portal for the project as I am an outside consultant, so my portal access is strictly read-only.
Thanks in advance for any direction provided!
If the applications were distributed to the devices by an MDM, then you can push a new provisioning profile to them using the MDM.
If the applications were installed over the air from a web server or directly using iTunes or Apple Configurator, then you need to replace the entire application package on the device. This requires the app to be re-signed, since the changed .mobileprovision file will change the package signature.
If you don't have the original, app ID with matching entitlements in the developer portal, then you will need to delete the existing application from the device before installing the new, re-signed application. You won't be able to do an in-place upgrade.
Apple Developer Program Information says:
A Development Provisioning Profile must be installed on each device on
which you wish to run your application code.
Each Development
Provisioning Profile will contain a set of iPhone Development
Certificates, Unique Device Identifiers and an App ID.
So where are provisioning profiles in my iPhone XS?
Can I see them?
Can I download them?
Can I beam them to any other device via bluetooth? airdrop? email?
It is not recommended for security reasons offcourse, but if you see yourself in the position that you want to distribute your file ad-hoc onair via 3rd-party software (e.g. installonair.com): their download file does not include the provisioning profile and won't let you download the app.
In my case downloading the correct provisioning profile and sharing it via airdrop it installed the provisioning profile on the ipad. You cannot see it, but is there. With the provisioning profile installed manually, it is now possible to download the app via 3rd party software.
The development provisioning profile is contained in the application bundle that is installed on the iOS device (typically using Xcode, but you can also use ad-hoc distribution methods).
You can't see them. There is no settings screen that shows the development apps installed on your phone.
You can't download them (well, you can download the app bundle using Xcode, but if you have Xcode you could just recompile your app).
You can't send a provisioning profile to another device from the device. Even if you could, it wouldn't really serve any purpose because the provisioning profile includes a list of authorised device identifiers and some arbitrary device won't be on the list.
The provisioning profile is installed when you correctly and legally install the app. You cannot see it. It is there to enforce security. It is your warrant to run this particular app on this particular device.
Can I beam them to any other device
Obviously not; if you could do that you would break through the entire security system that Apple has devised.
I’ve modified an .ipa file by unzipping contents, decrypted and modified a few scripts, and re-zipped. How can I test the new app as quickly as possible to see the new changes, without having to go through code signing (yet)? Do I require to jailbreak my phone or is there any other way I can emulate the new ipa?
Thank you!
Jailbreak
With recent jailbreaks could be not that easy as it was in the earlier days. Even the simplest things don't work like you expect.
Resign IPA with developer account
This could be problematic due to entitlements. If the application uses them extensively then you would have to create provisioning profile containing all of them possibly also modifying the application binaries as some entitlements can't be recreated as is (like app groups and iCloud containers which are globally unique across all developer accounts).
Free developer account is even worse as it doesn't have access to some entitlements. You would have to examine the application signature and see which entitlements it uses and what the probability that it might work without them. For example, re-signing an app without SiriKit entitlement might cause a crash. When an app tries to access the API iOS will kill it due to missing entitlement.
You might heard about Cydia Impactor which does exactly that. But it actually does a pretty poor job of it. It doesn't preserve entitlements, so there's high probability that the app will crash. Pretty much all remotely complex apps use many entitlements. But it's worth a try anyway.
I think this tool maybe helpful for you: https://github.com/DanTheMan827/ios-app-signer.
If you wish to run app on iOS devices, a valid code signature is required unless that device is already jailbroken.
In fact, jailbreaking does not enable you to run un-signed code on iOS devices. It just allows you to install some plugin to tweak the system. You still need something like AppSync (https://github.com/angelXwind/AppSync) to bypass the system-level code signature verification.
So you have to sign you executable if you don't want to jailbreak. Xcode provides free app provisioning file that you only need a Apple ID and you can get a 7-day app provisioning to let you run the ipa.
We are trying to supply one of our clients with an ipa to deploy on their AirWatch. There is a lot of conflicting information on what is the best way to do that, but they all seem to agree on the fact that it needs to be signed with the certificate and private keys of some account. However, the client seems to be managing their apple enterprise account through AirWatch. Does this mean that we could supply them with an unsigned ipa file and let AirWatch do its thing?
I have been scouring the internet for a while for this information and the closest ones are similar to Renew iOS Development and APNs Production for Corporate Apps [AirWatch] which is not what i was looking for
No - AirWatch does not re-sign anything IPA-wise. It can interrogate your IPA to make sure you're not trying to accidentally update App A's IPA with the IPA for App B but that's about it.
The link you provided has nothing to do with re-signing applications within AirWatch as much as it is the general practice for renewing your Enterprise Apple Developer Cert and Provisioning Profiles.
If you try to deploy an unsigned IPA to a device not in your Developer Portal you will likely run into an issue where the app will begin installation then throw an error that it cannot be installed.
Regarding what your client is doing there may be some confusion as AirWatch does not directly tie back to the Apple Developer Portal except for the MDM APNs cert which is unrelated to IPAs.
It depends on how sophisticated AirWatch's re-signing is. A good re-signer, should be able to take anything, re-sign it AND add the correct entitlements.
That said, in Xcode unsigned feels like an unsupported path - so my conservative approach is to sign a production build of the app (Ad Hoc, Enterprise or even AppStore if that makes sense) with its entitlements being as similar as possible to those of the final app's. If the app entitlements are simple (e.g. push notifications only), then this is the way to go.
But there's a problem: matching client entitlements has recently become harder, in part due to the proliferation of App Groups (which require an explicit, globally unique App ID - thanks, Apple Watch!), so your unsigned suggestion is starting to look more attractive.
Airwatch only resigns IPAs if you wrap it with their App Wrapper, because it will alter the original IPA and invalidate the Signature.
You have to provide both the Certificate and the Provisioning Profile to allow that.
If the IPA has to be signed with the Enterprise Certificate of your customer, you either require access to their Member Center or let them do it.
Apps like AppSign or iReSign can do that for you or your customer, if you provide them with the IPA.
I know how to sign an app with Appstore mobile provision, and how to re-sign an Adhoc-signed IPA with Appstore mobile provision. This is not my question.
My question is, can you submit Adhoc-signed IPA to Appstore / iTunesConnect, and have it pass Apple verification and eventually be distributed through Appstore. Why? So that I don't have to store a redundant Appstore-signed IPA along every Adhoc-signed release candidate IPA, and don't have to do the extra step of re-signing that requires a Mac machine.
When using Application Loader, it is able to find all the stupid little errors, like missing icons and launch images, but even when I upload Adhoc-signed IPA through Application Loader, it doesn't complain about non-appstore mobile provision (which is very easy to verify, just like icons).
I have also found out in my testing, that when you take an Appstore-signed IPA (which you are not supposed to be able to install on devices unless distributed through Appstore), it is possible to install it on testing devices, provided the device already has Adhoc provision profile on it (same AppID, same distribution cert).
So, this makes me think Apple just strips out mobile provision when distributing through Appstore.
There was a similar question (closed) from almost 3 years ago, but the OP never provided an answer if it had actually worked: Submitted app to appstore with adhoc profile.
I hope someone since then had actually tried with it confirmed results.
There are a few targeted inner questions within your main question, I'll call attention to each part as we go -- as always, I'll be happy to revise or clarify if I miss something. I suppose it is only a closely guarded secret because much of the reasoning for it working come back to cryptographic details as a function of the Public Key Infrastructure system that backs Apple's provisioning -- This stuff gets deep fast so it is considered by some to be [dark] magic. Hopefully this will shine some light on what is going on!
TL;DR Version
Yes you can, but it is technically an unsupported use case that may change at any time. This works because what information iTunes Connect chooses to validate does not include the single differentiating factor between an App Store and AdHoc distribution provisioning profile. Since this is technically not a permitted configuration, I'd advocate for at least having a backup plan since Apple may change iTunes Connect validation policy at any time breaking this submission edge case.
Now for the curious, the here is the rest of the story...
Can you submit Adhoc-signed IPA to Appstore / iTunesConnect, and have it pass Apple verification and eventually be distributed through Appstore[?]
As of this specific iteration of iTunesConnect and the Application Loader (4 Sept 2014 / Xcode 5.1.1), yes you can submit an AdHoc signed build and have it accepted through the pipeline. The eagle-eyed reader will note that my 'Yes' comes with a built-in escape hatch -- Because of the data encoded in AdHoc vs App Store provisioning profiles is nearly identical coupled with what parts of these files iTunesConnect is actually using for validation, an AdHoc provisioning profile presents to the delivery pipeline in the same manner as the AppStore version of the same app.
Should the provisioning format change between AdHoc and App Store files to explicitly differentiate the two types of Distribution provisioning profiles or should Apple iTunesConnect engineers change server-side validation rules, it is distinctly possible that this undocumented behavior will stop working. Of course we all know that we are supposed to use the App Store provisioning profile, as per Developer documentation in the App Distribution Guide > Submitting Your App > About Store Provisioning Profiles (https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/SubmittingYourApp/SubmittingYourApp.html#//apple_ref/doc/uid/TP40012582-CH9-SW32) [emphasis added]:
A store distribution provisioning profile contains a single App ID that matches one or more of your apps, and a distribution certificate. For iOS apps, you need a store provisioning profile to submit your app.
...but this other avenue works for now. If you do choose to use this avenue, you just need to be aware that it is not the documented behavior and thus would be subject to change at any point in time, likely without advanced notice. Since it is skirting the edges of submission requirements it would probably be good to at least have a backup plan setup for the case of Apple changing provisioning or iTC validation requirements -- Murphy's law would dictate that these validation changes would happen at the most inopportune time.
Stepping off the 'Best Practice' Soapbox and turning to the technical side of things...
Why [does this work]?
As you may or may not know, provisioning profiles are composed of exactly 1 appId, one or more signing certificates, and zero or more test devices.
Related Reading: I've got a longer answer to What are code signing identities? that speaks in more detail to the parts of the codesign process.
In this case the question is 'why do AdHoc profiles work when the documentation says you need to have an App Store profile?'
The guts of a provisioning profile contain a cryptographically signed .plist that includes the information identified above, plus some additional metadata. On an OS X machine you can open Terminal and run:
security cms -D -i path/to/AdHoc.mobileprovision
...and in a separate Terminal window run the App Store profile equivalent:
security cms -D -i path/to/AppStore.mobileprovison
These commands will dump out the plist portion of the provisioning profile to their respective Terminal windows. When you scroll through the contents of both windows you will note that the following sections are identical:
AppIDName
AppliationIdentifierPrefix
DeveloperCertificates
Entitlements
TeamIdentifier
Version
The profile's metadata are different, but those are entirely expected differences that only matter for validating profile validity, or for humans interrogating the profile:
CreationDate
ExpirationDate
Name
TimeToLive
UUID
The salient points to take away are:
The DeveloperCertificates blocks are identical between both profiles.
The AdHoc profile only adds information (ProvisionedDevices) to the structure and format of the App Store profile.
The contents of the DeveloperCertificates array is the DER encoded X.509 iPhone Distribution Certificate -- The exact same as the one in your keychain. Is is important to note that this DER data is only the public portion of your Distribution certificate public-private keypair, and it can only be used by others to authenticate the application's signature came from you -- It can not be used to resign a binary as you.
If you paste the contents of DeveloperCertificates:Array:Data element into an ASN.1 decoder (http://lapo.it/asn1js/) and compare the elements of the output to the information encoded in the Distribution certificate included in the Keychain, you'll find that it is an exact copy of the public Distribution certificate you downloaded from Apple after submitting your Certificate Signing Request though the Certificates, Identifiers, and Profiles tool.
Because both the AdHoc and App Store provisioning profiles use the same public key certificate as their signing identity, they are inherently using the same private key when generating the application's signature. This means that the signature generated when signing with an AdHoc profile is functionally identical to one generated when signing with the App Store profile
When Apple performs a signature validation on iTunes Connect during the submission process, both and AdHoc signed cryptographic signature and an App Store signed cryptographic signature will successfully validate against the Distribution Certificate Apple has on file as both provisioning profiles are backed by the same Distribution Certificate.
So the signatures match, but why doesn't the extra information in AdHoc profiles trip up the submission?
Your original question suggests that you have familiarity with iOS' app install policies. For the benefit of someone stumbling across this answer in the future I'll briefly summarize:
iOS operates on a 'deny-all unless specifically permitted' policy. That is, iOS assumes you are not allowed to install an app unless a specific 'grant' has been allowed. For devices coming from the App Store, the app's signature includes Apple's App Store identity for which iOS has a specific 'grant' privilege. AdHoc installs by default fall under the 'deny' policy and the ProvisionedDevices section of a Development or AdHoc profile are the specific 'grant' privileges. The app will install outside of the App Store if all of the following hold true:
The application's cryptographic signature is valid
The application's embedded provisioning profile's cryptographic signature is still valid (the profile hasn't been tampered with)
The application's embedded provisioning profile's ExpirationDate hasn't passed and the current time isn't before the CreationDate
The embedded profile or a profile installed to the device match the AppId being proposed for installation.
The embedded profile or a profile installed to the device contain an entry in ProvisionedDevices that exactly match the device's UDID.
As we saw above, the app identity and signing information is identical between an App Store profile and and Ad Hoc profile -- the addition of ProvisionedDevices serves only to add these 'grant' privileges for an external (outside of App Store) distribution mechanism. It turns out that iTunes Connect / Application Loader validation is currently only validating that a Distribution profile was used for the app's signature, not that the profile that was used was an App Store profile instead of an AdHoc profile.
This boils down to the fact that the as of Version 1 (ala Version block in the plist) the only differentiating factor between AdHoc and App Store distribution profiles is the presence or absence of the ProvisionedDevices block. It turns out that as of today, this is not a detail that Apple looks for when interrogating the profile that was used, thus the binary passes the automated portions of app verification. They definitely do check that the AppId in the profile matches what the App claims, that the signing identity matches what was used to sign the binary, expiration dates, and any entitlements used match what is found in the automated scan of the app, in addition to the items you highlighted in your original question (version checks between iTunes Connect and the info.plist, iconography presence, iconography sizes, etc.)
Hypothetically, in a subsequent iTunes Connect / Application Loader update, they could start checking for the absence of this key in the embedded.mobileprovision profile that exists within the submitted binary and auto-reject the submission on the grounds that an App Store profile was not used. Similarly, if the provisioning profile format was updated (ex. Version=2) they could add a new element that explicitly calls out the type of profile and auto-reject if it isn't an App Store type. It could perhaps look like this:
<key>ProfileType</key>
<integer>1</integer>
Where the integer value could be 1, 2 or, 3 depending on the type of profile in use, consistent with the formats used in things like Info.plist for identifying supported device families (iPhone-only, iPad-only, or Universal). This would clarify other questions that have been asked about identifying the type of build.
Related Reading:
How to detect that a provisioning profile is for development or distribution, programmatically
Check if app is ad-hoc|dev|app-store build at run time
So, this makes me think Apple just strips out mobile provision when distributing through Appstore.
Yes they do! If you look at archived versions of the apps you submitted you'll find that the contents of the app contain embedded.mobileprovision -- if you then go download the same version from the App Store, you'll find that file missing. Apple only uses embedded.mobileprovision to verify the contents of your app during the submission and review process. When the app is 'Processing for App Store' the final package is assembled and the embedded profile is removed.