Pretty much what the title says.
I would like to install a 3rd party app on my iOS 11 device, but the only way to do so is by self-signing the .ipa and installing it via Cydia Impactor.
What are the possible security concerns in doing so?
How much control and access would said app have over my device once trusted?
There's no way of saying for certain.
Private APIs
iOS 11 fixed a number of vulnerabilities that allowed access to personal info such as SMS messages without user knowing. There might be other vulnerabilities but it looks like iOS 11 is pretty good in regards to private API access. Pretty much every known personal info leak was fixed.
The problem here is you can't do anything about it. Only way is to disassemble the application and see for yourself.
Permissions
Of course, there're many ways third-party app can steal your personal info if you give it the access. For example, contacts, calendar, call history (without phone number but still), microphone, photo library - once given permission to access, can be accessed at any point even when running in the background without you knowing it. Application can run in the background indefinitely, it's still not fixed by Apple.
Accessing location will always display an icon in the status bar so that's fine. But there're ways you can fool iOS to access location once and not display the icon. It's not reliable but it works.
If application is running in the foreground then it can access camera, microphone, location and iOS will not tell you anything about it. Recently there was an article about camera specifically. You can't tell when it's recording and that's a real problem.
Solution here is simple - don't give the permission.
Jailbreak
Jailbreaking relies on a number of vulnerabilities to modify kernel to disable security measures. No one is stopping you from using these exploits to be executed from a third-party app not meant for jailbreaking. In fact, all recent jailbreaks are done by installing an application using Cydia Impactor. And there's an actual example of that - Filza. It's a file manager that can access root file system. It does that by executing exploits used in jailbreak.
Solution here is to make sure your iOS is up to date and has no jailbreak for it. Of course there's a possibility of unknown exploits. Serious vulnerabilities found regularly in iOS. You can disassemble the application to see what it's actually doing but I don't think you would asking this question if you knew how do that.
Related
After I attended a programming class, one of my friends showed me an app that would not allow him get past the first screen due to his jailbroken iPhone.
Since then I have been intrigued as to how the app was able to detect the jailbreak without being blocked by apple and, being the anti-jailbreak advocate that I am, I kept fruitlessly trying to find a reliable way to detect a jailbroken iOS device to prevent people from cheating if I ever decided to release a game on the App Store.
Does anyone know of a reliable method(s) to detect a device's jailbreak status that cannot be easily bypassed by said jailbroken device?
EDIT: based on recent comments, I would just like to clarify that the intention of this post is to share the knowledge I gained from finding that article, and to provide a place where other users can contribute their methods of jailbreak detection.
The other day I stumbled across an article containing the exact answer I was looking for.
From https://www.theiphonewiki.com/wiki/Bypassing_Jailbreak_Detection
While there are countless ways apps can implement checks for jailbroken devices, they typically boil down to the following:
Existence of directories - Check your file system for paths like /Applications/Cydia.app/ and /private/var/stash, amongst a handful of others. Most often, these are checked using the -(BOOL)fileExistsAtPath:(NSString*)path method in NSFileManager, but more sneaky apps like to use lower-level C functions like fopen(), stat(), or access().
Directory permissions - Check the Unix file permissions of specific files and directories using NSFileManager methods as well as C functions like statfs(). Far more directories have write access on a jailbroken device than on one still in jail.
Process forking - sandboxd does not deny App Store applications the ability to use fork(), popen(), or any other C functions to create child processes on non-jailbroken devices. sandboxd explicitly denies process forking on devices in jail. if you check the returned pid on fork(), your app can tell if it has successfully forked or not, at which point it can determine a device's jailbreak status.
SSH loopback connections* - Due to the large portion of jailbroken devices that have OpenSSH installed, some apps will attempt to connect to 127.0.0.1 on port 22. If the connection succeeds, it means OpenSSH is installed and running on the device, therefore it is jailbroken.
system() - Calling the system() function with a NULL argument on a device in jail will return 0; doing the same on a jailbroken device will return 1. This is since the function will check whether /bin/sh exists, and this is only the case on jailbroken devices.[1]
dyld functions - By far the hardest to get around. Calling functions like _dyld_image_count() and _dyld_get_image_name() to see which dylibs are currently loaded. Very difficult to patch, as patches are themselves part of dylibs.
*Only a very small number of applications implement this (as it is not nearly as effective as the others)
the above passage was edited for brevity
I figured I'd post this here as a knowledge-share for those app developers wondering how that one app was able to successfully implement jailbreak detection when all other attempts at detecting jailbreak get rejected by Apple.
Blocking all jailbroken users probably wouldn't help you fight app piracy if you released a game on the App Store because it would force them to get a pirated version of the game to be able to play (instead of giving them the possibility to pay to play the game).
What you'd want is to check if the game is a legit version off the App Store. But even that could be potentially patched by the guys who crack games to release them...
You can check if the currently running executable is encrypted, which is a good way to know if the app has been pirated by looking at this answer.
Otherwise if it's a free game with in-app purchase, doing receipt validation helps block out most tweaks that get around paying for in-app purchases.
But there's definitely no way to absolutely block out app piracy.
You could always mention how had you worked on that game within the game... That could convince a few persons to pay for the legit version of the game.
I'm trying to log users individual app usage on iOS9.
I'd rather prefer that it wouldn't use jailbreak limited solutions, self explanatory. Doing the variation of this app on a jailbroken phone shouldn't be hard.
This will certainly not be released on the App Store as Apple wouldn't allow it.
I'm looking for any private API that can do this, any hidden iOS API's that can be used to do this. ANYTHING.
What I've already looked through:
how to determine which apps are background and which app is foreground on iOS by application id
How to know about app launched and details jailbreak iOS 7
Is there a private API to be able to detect what is current foreground app on iOS?
How to monitoring App running in the foreground in iOS8？use the PrivateFrameworks SpringBoardServices
which proved to be relatively helpful - we now can assume that there is some sort of additional access requirement, probably an entitlement, but we don't really know how it should look like
Can you find individual app usage duration using SpringBoard services framework or other private framework?
Find out active application or if on Springboard
Programmatically detect which iOS application is visible to user
However all of these proved to be unhelpful because Apple fixed this security flaw with iOS8 and the method to copy/access the currently front most app bundle identifier no longer works.
Question is: Is there someone who knows a workaround using different tools/exploits that do not require jailbreak?
Ideas:
inspecting the processes running on the device and devising an algorithm that would be able to recognize spikes that mean an app has been launched, which potentially could work, but it probably would be a major pain in the ass. Questions mentioning this solution:
Detect which app is currently running on iOS using sysctl,
Return a list of running background apps/processes in iOS
How to get Names of Background Running Apps
Find Background running apps in iphone
inspecting the phones traffic somehow?
not sure if there is some kernel stuff that I could do
Here is my Reddit version of this question if anyone wants to check it out. Also if it's of any value, here are the runtime headers for iOS9 and list of Apple's private API's.
Unfortunately, I was looking for a similar solution and have come to the conclusion that, at least at this point in time, there are no known methods that will allow you to determine app usage on iOS. Even the MDM providers such as Good, Airwatch, MobileIron, etc. don't seem to be able to do this. If anyone is able to come up with a solution, I'd love to see it.
For now, however, I think we would have seen a solution if someone had one that worked on the latest iOS.
sysctl is still open but they block certain combinations of selectors. I did this on iOS 7 and gave Apple Product Security the code. They won't patch iOS 7 but rely on App Review. iPhone 4 is wide open.
I went though lot of questions about tracking sms and call logs in non-jailbroken ios device. I came to conclusion that it is not possible.
But then I came across this
So I wonder how mspy does this. I am looking to built this functionality for enterprise app, so no problem of itunes rejection.
Can some one please help.
Thanks.
Please check these features description notes:
mSpy runs on jailbroken/non-jailbroken iOS devices. In the former
case, you need physical access for installation. In the latter case,
you need no access if you have iCloud credentials, but you get fewer
monitoring features. Still, the access may become necessary if iCloud
backup isn’t activated on the device.
I guess they are getting info from iCloud account but not the device itself. Moreover they have said fewer monitoring features , i dont know what they exactly mean by fewer and what info do they actually gets in that case. But they are sure getting info from already synced data over iCloud.
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.
Can I get the information about which apps are on foreground, so that controlling the screen and get interaction from user.
I can do it on Android and I want to do it also in iOS.
This is for making an app that monitoring the usages of apps, not for the CPU usage.
Please tell me how could I manage this ?
On jailbroken devices, a quite straighforward solution is to use Ryan Petrich's AppList library.
I'm not sure if this is easy on a stock device, but you might get somewhere using the Mach/XNU API for retrieving process info and searching for a suspected app executable path/name.