I'd like to sign my iOS apps on a Linux box (Debian 5 if it matters). Does anyone know if this is possible? (Let's not get into why I'd want to do this since it's specific to my environment.)
I see source code to codesign on Apple's site but before I get into the weeds pulling it over and trying to build it myself, I wondered if anyone knows of an existing port.
I'd heard that codesign is not really OSX-specific and may exist on other OS's but there's always a chance Apple has tweaked it to their own needs. I wonder if an app signed by something other than Apple's codesign will run on an iOS device.
If it matters, the signed apps are meant for enterprise users and will not go in the iTunes App Store.
Saurik wrote a codesigning utility called ldid, I think for OS X and iOS. It also might be available for Linux though.
Check out JTool.
Code signing is considered to be the second most useful feature of JTool. With iOS security revolving around code signatures and entitlements, it's important to have a way to quickly determine what given entitlements a binary possesses and how it is signed. OS X has codesign(1), but I find it crude (at best) - and what more there's no port to iOS, where it's really necessary.
Related
This question is not really technical in nature but it is clearly answerable with yes/no and so I hope its fine if I ask it here on StackOverflow.
My scenario is as follows: In order to share code between iOS and Android I'm using C++ for much of the app's logic. I'm about to start writing network code for both platforms and I plan to utilize OpenSSL or one of its derivates (LibreSSL / BoringSSL) to be able to do HTTPS calls.
OpenSSL/LibreSSL/BoringSSL would be statically linked into my app and periodically be updated by releasing a new app version.
However, I'm unsure about whether Apple would accept such an app in its app store or not. As far as I know they take a closer look at what is inside the app and I want to prevent a situation where all code is written but eventually rejected when attempting to publish the app to the app store.
I'm looking for a clear yes/no answer whether Apple accepts such apps nowadays (2019). Preferably this answer is coming from someone who actually knows the answer i.e. from someone having done the same recently (2018/2019).
Did anyone recently succeed in publishing such an app into Apple's app store?
Not only does Apple allow this, that's exactly how one is supposed to use OpenSSL in an iOS app. The operating system doesn't provide OpenSSL for the apps, so the apps need to bring their own one.
You'll probably need to declare the use of encryption to comply with encryption export regulations. It is, however, required even when using the system encryption like TLS.
I hash my iOS executable at launch to verify its integrity, and have had no problems doing so until TestFlight -- which appears to modify the executable as well as install it in some funky (undocumented?) way.
Even more concerning is I get multiple hash values, which appear to vary by device or iOS version or carrier or something. I don't own enough devices to be certain. But none of the hashes match the one I compute prior to uploading to TestFlight.
So I have two questions: (1) What is TestFlight doing to my executable, and is the process documented somewhere? And (2) Does the final app store release pull the same shennanigan, or something similar, or does it leave my executable unmodified from when I uploaded it?
That's what code signing is for.
Code signing your app assures users that it is from a known source and
the app hasn’t been modified since it was last signed.
Source: https://developer.apple.com/support/code-signing/
It seems like Apple encrypts your app. While this post is about App Store submission, could be the same for Test Flight (not sure about this).
See: https://stackoverflow.com/a/5784332/2019384
Also it's not recommended to verify your apps integrity by yourself, as you'll run in such issues. Besides iOS already does this for you:
Apple does not provide any supported way for you to check your app’s
integrity. iOS already does that by default.
Source: https://forums.developer.apple.com/thread/52801
In addition to d4rk's answer, if you're using Swift, Apple compiles in appropriate bits to optimize your app for each device.
Is there a way to run any app in iOS 10+ from command line/Mac without jailbreaking?
Re-signing and none of the existing tools seem to work (ios-deploy, Instruments) nor have I been able to find a way via iTunes or other programs.
Yes it is possible for any App you have the source code for.
No it is not possible for any App you acquired from the App store or direct download.
Not quite sure I fully understand your emphasis on any app, but here is what I understand:
1) If you mean you want to run any app from the app store that can currently be downloaded, and you have a .ipa file, you can definitely install it manually to another device using this method (iTunes drag and drop)
2) If, however, you're trying to run an .ipa on a Simulator, that's not possible, as described by this answer.
3) Lastly, if you have source, which I'm confused about since you mention re-signing, then you can easily build that source into an executable for either Simulator or device using either Xcode, or since you asked about command line, you could also use xcodebuild, info found here
I hope one of these 3 options is what you're looking for, as it's hard to tell from the wording of the question. If it's not, expanding on exactly what use case you're trying to resolve would be very helpful.
From the comments in #BHendricks answer, it seems you want to use the command line on your computer to start apps that are installed on an iOS 10+ device.
This is not possible without jailbreaking the phone!
On a jailbroken phone it might be possible to write something that connects over ssh and starts apps, but on vanilla iOS this is disabled for security. You could search for an app that you can send commands, but I highly doubt iOS apps have access to system features like starting other apps, as this is also a large security risk.
If you have the ipa, you can install the app via iTunes. This is what we used to ask QAs to test apps on devices and it works fine. Please refer to this [SO] for detail Install IPA with iTunes 12.
Use Cydia Impactor (cydiaimpactor.com) to sign the app. 99% chance it will work
This one is probably a lost cause, but I'll ask cause I'm honestly just curious...
We have a client that wants to create a replacement Messaging app for OS X. They basically want to use the same accounts, chat history, and everything, but provide a completely different UI (for people with certain disabilities) to the built-in Messages.app. Creating their very own messaging app would not fly given that the primary service in Messages.app, iMessage, is completely undocumented and so supporting that with 3rd party code would be nearly impossible.
Upon initial research, it became obvious that the well-documented AppleScript approach would provide a workable but crude solution, missing many features from the original app (such as an indication while typing, etc.), not to mention that it requires keeping the original Messages app running which is distracting to the user.
At that point we started digging a little deeper and found the IMCore.framework. IMCore is basically what Messages.app uses to communicate with the various services, and its engine is imagent, which is what appears to manage the data, and actually communicate with the various IM servers. IMCore is a private framework which obviously is somewhat risky to use (and automatically excludes their app from the App Store), but our assumption was that with OS X we should still be able to implement this and distribute the application outside of the App Store with not much difficulty.
We started experimenting with IMCore (while reverse-engineering Messages.app to see how it's used), and made some headway. We were able to successfully connect to the imagent process and perform several configuration operations, but then discovered that the data model is basically empty -- we're not able to see any of the user's data or communicate with any IM services even though we're running in the user's security context.
Then we noticed that the Messages.app has some very curious undocumented entitlements such as com.apple.private.imcore.imdpersistence.database-access and com.apple.imagent. At this point we're assuming that these entitlements are what we're missing in order to successfully communicate with imagent. We've tried adding those entitlements to our own app and were able to successfully build and codesign it, but when the program is launched it crashes on startup with the system message EXC_CRASH (Code Signature Invalid) (Xcode says Terminated due to code signing error).
Our fearful assumption is that Apple locked their private entitlements so that the system won't accept a binary that uses them unless it is signed directly by Apple, but this is obviously a theory. The other question is, how does imagent know whether our binary has these entitlements or not? Couldn't we somehow spoof these entitlements?
As I said, feels like a lost cause but who knows. I'm guessing people who have done hardcore jailbreak work on iOS might have an idea or two -- anyone?
I'm going to answer my own question to provide a bit more information in case anyone cares about this. At the end of the day we were able to cross this barrier by injecting into the imagent process and trapping the entitlement verification functions, adding functionality so that imagent will allow the XPC connection for our client.
This opened the door to full, unlimited communications with imagent through IMCore.framework, and I can confirm that full iMessage functionality was achieved. We we were able to see the user's iTunes account, send and receive messages, load messages from the user's database (to show the history for each chat), and pretty much everything else. The implementation included a tiny system daemon that injected imagent whenever it was restarted (or when the system booted up), so it was very easy for an end-user to install using a standard OS X installer program.
IMCore.framework is fairly easy to use and includes every tiny bit of metadata for iMessage, including notifications that the user on the other end is typing, the APIs for the sending and receiving of attachments, you name it! It seems to change a bit between OS X releases, but we were able to make it work across OS X versions (we tested 10.8 through 10.10).
The challenge came when El Capitan showed up. The new rootless feature (System Integrity Protection) in El Capitan prevents from injecting our little hack into imagent, which put an end to this solution. :-( The failure happens when we call task_for_pid on the imagent process. That fails and basically blocks us from injecting our code into that process.
So overall not a happy ending, but at least we got a taste of the promised land.
I have an open source iOS project with public sources on github. I have published the app on the App Store using my developer account.
Is there a way for me to prove to the user that the published app in fact has been compiled from the sources on github?
EDIT
To clarify: I am in search for a mathematical (or cryptographic, if you like) proof that the app binary originates in a publicly available source code, rather than a sort of disclaimer. A disclaimer can claim anything but does not prove anything.
E.g. by code signing the app package I prove to apple that the creator of the app and the developer registered with apple are one and the same person. My question is whether there exists a similar mechanism to prove to the user that the origin of the binary and the public source are identical.
I think I've stumbled upon a hard problem. It is much more general than iOS. It is hard to prove that the origin of a certain binary is a given source code at least because the binary you'll get depends on so many details:
compiler version
os patches
compiler flags
exact library versions and their compiler settings
values of environment variables at compile time etc.
The proof would need to take all that into account somehow.
Maybe the developer could make a video of how he pulls the repo, then compiles, then calculates a hash sum of the binary. then he could publish that video. But again, the video could have been tampered with. Or the compiler could be compromised.
So apparently we have to trust the developer. This "trust in the developer" attitude seems to be the norm. With security critical open source projects the developer would sign the binary. After downloading the binary I would verify the signature before running the code. In the case of an iOS App, the App Store takes care of all that. As a developer I have to code sign the binary. Apple would verify that signature before putting the app into the app store.
As a result, if you put an App in the App Store, I know that Apple knows who you are. So it is easier for me to trust in you.
TL;DR : A proof would be hard, but you can make it easier to trust.
For iOS there are additional complications. Part of submitting your app is codesigning it, and the codesigning process involves changing the Mach-O header, the load commands, and the LINKEDIT segment.
You could probably increase trust (but still not prove) by submitting the code-hashes in the code-signed code-directory structure; BUT the app in AppStore is re-signed by Apple and thus some of the code-hashes will have changed no matter what you do.
One way to do that is by showing the information in iOS settings bundle. I've seen couple of application implementing iOS settings bundle and showing acknowledgements/attributions over there. Other way would be showing that info inside your itself but I wouldn't recommend that.