Ya, that is quite the cold war situation there.
I have a random idea, though.
Perhaps Apple could make a dynamic method name that changes during run time. Each name might last 30 seconds and then roll over. ( kind of like a rsa dongle ) You query Apple's secure hardware for the method signature ( the hardware that stores touch id for instance with no access ) -- perhaps there is a fixed memory address on the bus in hardware somewhere to get at it. Then call it ( or use it to construct a name ) as a method in your program. If the method does not exist then you crash but you did not want to run on the broken phone anyways. Otherwise, you call this working function that attempts to do something outside your sandbox and or does something not priviledged. If you called it and it returns a failed status then you are not jailbroken. Otherwise, you are jailbroken because it worked when it should not have -- your updated app takes action. Perhaps, when there is a system update they can replace or modify what that randomly named method checks for -- maybe it has its own implementation of fork or other checks etc. Since the name is random and the Xcon folk do not have access to Apple's secure hardware in the phone, they can't patch the name. Atleast, your app might be out of the loop on the check. Fun to think about...
… perhaps there is a fixed memory address on the bus in hardware somewhere to get at it.
Except that memory addresses are translated by a VM system that’s managed by the OS that’s already been subverted.
Personally I’m of the opinion that it’s impossible to detect OS subversion from an app running inside that subverted OS. Which is one of the reasons for this post.
Share and Enjoy
Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware
let myEmail = "eskimo" + "1" + "@apple.com"
Ya, this is the ultimate issue imo. Otherwise, none of the other security really matters. You can't beat the hex editor.
It's a futile arms race because the end result is a 'non-standard' environment with a "Restrict app to sandbox" toggle switch.
So the compromised device still has the unauthorized copy of the app, and the unauthorized copy of the app thinks it's properly sandboxed.
That's to say nothing of the fact that an app trying to violate its sandbox 'just to see if it can' is just as suspicious as someone walking up to your car and checking to the doors. :-/
Any update on the xCon detection.
I have a device with xCon 41 version installed on our iPhone and its not able to detect the Jailbroken phone. Its a finance app so we want to avoid it getting executed on such phone.
Referred to one link but no success : https://github.com/masbog
Appreciate your help over this.