Is there any way to distribute an unsigned app through emails or internet?
I.e. itms-services://?action=download-manifest&url=URL_TO_PLIST.
Moreover, it is a security issue if it is possible to install unsigned app on a jailbroken device?
Thank you.
I can't quite understand what you're trying to do here - if you're trying to install an app that is not on the App Store and also unsigned with the itms-services-protocol, you are out of luck, as that is strictly for iTunes and App Store-links.
The only way to distribute an app that is not on the App Store, is with the ipa-file, but that has to be signed as well (at least for unjailbroken devices).
You can do it in cydia with link like cydia://package/[package name]
However security is really a question here. Not sure if there any code review for the accepted packages.
Sorry if this is an extremely late response, but the question isn't closed yet, so I'm assuming you still need an answer. It is a security concern, but with a jailbreak, users are technically "opening" their device to such security threats, so I don't think that's much of a concern. If they jailbreak, they probably know what they're doing.
To answer the first part of your question, you can use ldid to pseudo-sign the app and then create an itms-services:// link that users tap to install. The only caveat to this option is that the iOS Device will contact oscp.apple.com & ax.init.itunes.apple.com to verify the app's signature. If you want to bypass this, you'll have to change the DNS settings of the iOS device using a mobile configuration file. Do this using Apple's iPhone Configuration Utility, which will generate a .mobileconfig with your specified settings. You won't have to generate a specific file for each device, so you can make one and you're done.
Anyways, back to the topic, jailbreaking doesn't remove the need for codesigning, it only removes the need for an app to be signed with Apple's certificate(s). itms-services:// is a bypass (for developers) of the same "need". Since Apple obviously doesn't want people who aren't developers just signing apps that aren't approved by Apple and installing them, they've implemented certificate checks. The signing-certificate is cross-checked with Apple's two servers. One of the servers (I don't know which) checks for "iPhone Developer:" in the name of the certificate. The other checks that it was signed by Apple's WWDRCA Certificate. If the iOS Device gets a response from either of the servers signifying that the app is "bad". If the iOS Device doesn't get a response, it will still install the app.
The way to go with this in order to bypass would be to clone a DNS server, and create a specific entry that will change the IP of these two servers to something (anything) else. That way, the Device will not get a response, and will install the application.
modify the file SDKSettings.plist ： make code sign required value is NO
when build, selected project (not target) -- build setting -- code signning identity: Dont code sign
build, get the .ipa file can run on the jailbreak device
Related
As part of our software development life cycle, we want to make sure that the binary we test in house before pushing to iTunes, is the same as the binary that we push to iTunes. I know that sounds really silly, but it's a matter of checks and balances in a mid size company, so that the testers can be sure the coders didn't add in anything after testing occurred.
So is there a way to run a signed/certed app on a device that's not jail broken? Or is there a way to verify that an IPW is the exact identical code in the zip that gets pushed to iTunes?
Or possibly a way to accomplish my goals with a different way?
We have a valid developer account and around 15 different devices that are not jail broken. Would prefer to test with them left stock and not jail broken.
If you compile your app for distribution using an ad-hoc profile you can later take that archive and resign it with the appstore profile and upload it.
You can't however upload an application that was compiled with an development certificate.
A binary signed to go to the App Store cannot be run on devices via the normal ways. You can test the code by having the developers create an Ad Hoc build. This will have the same functionality as the App Store version, but you can test it.
Unfortunately, when the app is recompiled for the App Store, more code can be added.
Do you not have access to the code to test? If you must, you can have them create an adhoc in front of you, test it, and then recompile for the app store all in front of you. Seems a bit overkill, however.
There is with another trick:
first test you code for functionality's, buggs in normal way.
Than push the code to AppStore, but set the release date farther with 3 weeks, while your testers are validating it is that what they tested last time or not. Somewhere here, I have read that possibility forgot where. Never tried!
Right now I'm just trying to test my app on my phone and not deploy to the store.
How are all these things related? Since I'm not trying to upload to the store, can I ignore any of them?
I'm on the University Developer program. I was able to get a certificate and install it in Xcode, but builds still fail.
Is solving this problem just a matter of changing the application identifier? How do I know what to put in?
One thing I noticed is that in the Developer Portal I see only one App ID but it's for someone with a different name. So I guess I don't have an App ID. Do I need one if I'm just trying to test on my phone? If I need one, then how do I get it?
Help! It seems the more I research these things the more confused I get. If you can't solve my problem, can you at least tell me how these things are related to each other?
Provision Profiles are a very long, unique, string that allows the device to recognize certificates (very VERY helpful for development).
You must provision your device with the specific bundle ID of your app (done through developer.apple.com), then install said profile in order to even think about building with a valid certificate. However, it is much easier to have Xcode generate a wildcard provisioning profile, which allows you to test ANY bundle ID (it shows up as *.mobileprovision).
Certificates are the other side of the coin. A certificate for anything (website, application) indicates that this service can be trusted by the user, and more importantly, the OS. Certificates are issued by Apple California, are valid for a year, and may be revoked at any time for any reason. On a closed and secure platform like the iPhone, a certificate is a must for any application.
I am trying to set an Ad Hoc distribution in order to test an iPhone app with some remote users. And I haven't found any good and clear tutorial up to now. By reading bits and pieces on Apple documentation and others I am now able to put the app on my iPod device doing as much as I can "as if I was remote user"; meaning I can put my app on the device without going through XCode. But when I send the xxx.mobileprovision an the app file to a remote user, things go wrong. The user gets a message saying that there is no proper signing authority.
As far as I know I included myself and the other users in the list of device UDIDs.
One thing unclear to me related to this issue is :
In the iOS Provisioning Portal section Certificates I can see one tab "Development" and another one "Distribution", I am not sure of what the difference is. I have one item in each tab, but I see no "Add" button to add more items and try something different. Is one of those two tabs important for my problem above?
Thanks.
The tabs are very important.
With certificates, Development is the Key Chain cert that grants you permission to build in Xcode directly to an iOS device connected by cable. Distribution is the Key Chain cert that grants you permission to build in Xcode app that may be installed onto an iOS device remotely.
Development is the mobile provisioning profile that has the list of registered an iOS devices you may directly build an app onto connected by cable.
Distribution is the mobile provisioning profile that has the list of registered an iOS devices you may send an app to someone else and have them install it on a registered iOS device remotely without using Xcode.
You want to do an Archive which will require a Distribution mobile provisioning profile. I might add that if you are sending an mobile provisioning profile in an email, you will likely want to Zip it with the .ipa since the profile can often get corrupted with in certain email clients.
Here's a link to another question that has very thorough step-by-step instructions for creating ad-hoc distribution profiles: how do you beta test an iPhone app. The instructions have changed slightly with newer Xcode versions, but this is still the best walkthrough I could find.
I'm talking with a client who is abroad and I'm wondering whether I will be able to send him versions of the iPad app for testing before it's on iTunes.
Is there a solution (e.g. Ad-Hoc?) I could rely that doesn't require jailbreak or anything?
If so, could you please provide me with a link to a guide?
Thank you !
Yes Ad-hoc is what you need, basically you will need to associate your client device identifier (UDID) to a certificate that you will use to sign application.
This is a standard procedure (no jailbreak required) that is fully documented on Apple provisioning portal in User Program Guide (you have to apply ($99) for the developer program and be logged to access this... and it is limited to 100 devices)
Another good thing is to use an "Ad-Hoc" updater such as HockeyKit to ease your client updates and installation procedure...
Yes, indeed, there is an ad-hoc distribution method:
here is its mention on the Apple Developer website. As far as details, I think you have to be in the developer program in order to get direct documentation for that, and sadly I allowed my developer account to lapse. A few key points can be found here
Essentially, you can distribute to up to 100 other iOS users who have your group's apple developer credentials installed on their phone, and the app will remain live for 90 days
Essentially, it's the same headache on the remote side with certs, keys, etc... that you have to do with XCode when developing on the device, but you can put the app on a website somewhere where the remote party can install it on their phone.
EDIT: I found this guide that is presented on a forum if you want to look through the steps.
Grepping around, I see that I'm not AT ALL alone in being... challenged... by the process of setting up an iPhone app, getting it to run, giving it my testers, and so on.
I've gotten it to work. Somehow I emailed a copy or two to testers, and eventually got my li'l app into the store, and that was fine.
But I can't say a really, deeply understand it! (And I don't do iOS dev every day. Even now my recollection of what I did is kind-of hazy.)
I'm moderately capable of understanding things, if presented, well, you know, in a way I can understand.
Can anyone point me to a crystal clear explanation of what provisioning actually is?
I feel that if I understood it, the recipes to do it would be obvious.
Thanks!
Development provisioning profiles sign your application, and allow the phone to know it's OK to run. These days, XCode automatically makes a Development Profile for you (the "Team Profile").
The other kind of profile, when you are talking about other people running you app, is a Distribution Profile. You need a Distribution profile for either giving your app to the store, or for giving to beta-testers.
The profile is what allows other people's phones to know it's OK to run your app, basically it includes a list of device ID's approved to run that application on the phone in question, along with being signed so that the phone knows the whole thing is valid.
If you read advice around the web concerning distribution, it's easy to get confused because things used to be a lot harder. You used to have to send Distribution certificates separately from your app to beta testers. These days the certificates are included in your app bundle so you don't have to worry about that.
Furthermore, sending an AdHoc build can be all kinds of unpleasant - for testers using Windows. These days, the absolute best way to do beta testing is have a link on the web that uses the Enterprise ad-hoc deployment feature, to let a user with iOS4 or higher automatically download and install your application with no iTunes or copying work at all. In fact I would at this point refuse to use beta testers running windows who were not on iOS4 or higher.
The guide link posted should have a section about the enterprise ad-hoc, but basically the way it works is there's a small plist file the phone downloads, that has a link to the IPA file containing your app. You point the phone to a specially formatted link to the plist file and the phone fetches the application directly.
All of this is predicated on using the "Build and Archive" option for building any ad-hoc distribution build. You should do that anyway because it also saves out a symbol file for you to use in debugging crash reports.
EDIT:
Here's a little more detail on enterprise deployment (which works for any registered developer, not just Enterprise registered developers):
http://jeffreysambells.com/posts/2010/06/22/ios-wireless-app-distribution/
The Developer Program User Guide should be helpful.