I am a developer working on a robotics application for iOS. I do not intend to submit this app to the app store, nor do I have any wish for suggested methods to be apple approved....
I am trying to get bluetooth working, and I think a good place to start is to try modifying the existing apple frameworks. Is it possible for me to modify the frameworks so that when they are built to my iOS device the frameworks will be modified for the app (but not other apps on the same device)?
As a matter of fact, you can!
Objective-C allows you to "swizzle" methods to override their default behavior, and yet still call the original implementation if you want to. You can do this for any number of Objective-C methods, as many times as you want.
If you wish to override behavior that is present in C functions, you will need a little bit more control over the platform. Jailbreaking allows you to use the full power of Jay Freeman's CydiaSubstrate to hook or swizzle both Objective-C methods and C/C++ functions.
While I don't recommend the use of MethodSwizzle per se, the following URL has a good discussion of swizzling http://cocoadev.com/wiki/MethodSwizzling.
But you should really use CydiaSubstrate's MSHookMessageEx and MSHookFunction instead. Especially since you're not submitting anything to the App Store.
Now regarding Bluetooth, I've done extensive work in this field (I developed Celeste, which is a systemwide tweak providing vanilla Bluetooth OBEX support to system apps on iOS). I suggest you look into using something like BTstack, which provides you with access to the bluetooth module from the HCI to RFCOMM levels, and supports things such as SDP and pairing, which you will probably need. It also has the added benefit of not requiring method swizzling, which some people seem to think is some sort of satanic ritual that should be avoided at all costs.
Aside from categories (which extend the functionality of base classes delivered in those frameworks), I don't believe you can "modify" the existing Apple frameworks per se. A better course of action might be to simply create your own framework (or find somebody else's open source, commercial or simply third party framework) and then build that framework into the app that you install onto the iOS devices you want to work with.
Related
I've been struggling to find how I could potentially implement a simple (iOS) app that would be able to block all connections to a specific domain (to prevent the user from accessing a specific social media platform for example, even from another app).
The information that I have found so far is that I should probably create a Packet Tunnel Provider within a Network Extension and ask the user to add VPN configurations, but I haven't found any example code that would show exactly how to implement this.
Do you have any idea how I could do that in a simple way (block all connections to a specific domain)? Is there a framework/library that I could use to do it easily?
Thank you!
Well, it would not be easy, but you can do it.
Sample code from Apple could be found here and here. This project is for iOS, but it may be on deprecated Swift version, so you will need to do some work to launch it now.
The part you are interested in the SimpleTunnel sample is FilterDataProvider and FilterControlProvider, other things you can omit, because the purpose of this sample is to demonstrate a lot of abilities.
There is also a sample for macOS that is more focused on your needs, and macOS SDK is alike to iOS, but less powerful.
You may want to see this video to sort things up in mind.
There are a lot of firewalls solutions for ios and mac, and some of them are opensource
The part you are interested in the SimpleTunnel sample is FilterDataProvider and FilterControlProvider, other things you can omit, because the purpose of this sample is to demonstrate a lot of abilities.
You will need a developer account, a network extension capability assigned to an application identity, and proper network extension entitlement file a to run things up.
There is a way to sign it manually for development without account&capability, but to distribute you will need it anyway.
For some restrictions you may be needed to install MDM profile on the device.
Does Apple allow the usage of sysctl.h within iOS applications?
PS: App Scanner, a third party tool that checks code for possible private-API usage seems to think it's okay.
Note:
There is one more question like this : How can I know if I'm using private frameworks?
With the usual disclaimer that nobody can tell you what a reviewer will do, I can say for sure that there are apps in the store that use sysctl functions.
(Minor point: Simply including a header isn't a problem since symbols there shouldn't be visible in your app unless they're used...it's the things you use that might get flagged rather than what's included.)
So I know it's possible on a jailbroken iOS device to inject a dylib into a running process and interpose/hook system functions. I'm wondering if it's possible on a non-jailbroken device to interpose system functions at either link or run time, assuming I'm the one building the app? Maybe the equivalent on linux of using dlfcn and LD_PRELOAD?
An example: I want to take an app I've built that uses various Cocoa/Core Foundation abstractions for filesystem access and wrap the underlying open/read/write/close calls. I know about swizzling in Objective-C, but I'm looking for something at the libc level so I capture everything. This is for something test/debug related so it doesn't need to be App Store friendly. Thanks!
No, it's not possible (to my knowledge) on non-jailbroken iOS device. All traditional forms of dynamic loading (interposing, dlopen/dlsym, etc.) have been removed.
Since you mention that your needs are related to test/debug, you might want to try to make use of DTrace if your problem exists on simulator. You can use DTrace on simulator, but not on real iOS device.
I am pretty new to development for iOS devices with jailbreak. From what I am reading I understand that to be able to do all the cool things which you can't do on non-jailbroken phones you have to hook up to a given class and override some of its behaviour. Since there is no documentation how a developer tracks to which class exactly he should hook?
I imagine that for instance if I wanted to have my app respond to a given event such as phone boot, call hang up or user clicking on an icon I would manually generate the given event and see what invocations have been made. Is this the proper way to track where you should hook your code and if yes how is it done.
Note I am not interested in exactly those events mentioned above I am more interested the approach in general.
There are several approaches:
Disassemble binaries
You can disassemble a binary or just dump classes with something like class-dump.
So, you can see the whole hierarhy of classes.
Find dumped classes
Most of major iOS subsystems were dissasembled by somebody already. You can find quite a lot of useful stuff.
As example. Google search "Springboard headers" got this
Dump classes in a runtime.
Look at this question for explanation: List selectors for Objective-C object
While I understand that in order for an iPhone application to be accepted on the App Store, one requirement is that only documented libraries are to be used.
If this is the case, how are certain applications such as "Night Camera" and "Camera Plus" using a camera control that seems to be something other than the one contained within UIImagePickerController?
I have heard of certain cases where a developer has been given "special" access to certain headers that allow for features that would otherwise be impossible if constrained to only using documented libraries. However, given how opaque the application selection process is for the App Store, I would prefer to stick to what is recommended rather than take my chances.
Anyone care to shed some more light on this?
Have you seen this dicussion?
http://blog.airsource.co.uk/index.php/2008/11/11/views-of-uiimagepickercontroller/
and this sample code for a custom picker?
http://www.codza.com/custom-uiimagepickercontroller-camera-view
hope it helps.
You might want to check out a classdump of apple's private framework headers. Run this perl script:
http://arstechnica.com/apple/news/2008/11/dumping-the-iphone-2-2-frameworks.ars
and navigate to the PhotoLibrary directory under PrivateFrameworks. Some of the classes in here look pretty promising for direct camera access.
Using the undocumented API could hurt your chances of passing through the app store, but it's all very subjective - If your product is good, apple will probably let it slide through. I'd recommend making friends with a developer evangelist at Apple.
The UIImagePickerController is a UIViewController subclass that manages a view hierarchy. You are free to play around with the view hierarchy, as those apps are, but it is risky considering that Apple does not document it and could change it on any OS update.
I have not heard of anyone being given special access to libraries, but I have read that there is a minor distinction between undocumented classes and methods and private frameworks. Undocumented classes are a gray area, but private frameworks are definitely not allowed.
The simple explanation is that apps in the store are not supposed to use unsupported APIs, but this is not checked consistently. The apps you mentioned are either using unsupported functions/classes/methods or else are playing with the view hierarchy-- which is itself undocumented even though it can be done with standard APIs.
You could do what they do, and take your chances with it. Just be aware of the risks. Your app might (a) be rejected from the store, (b) be accepted but later booted (this has happened for unsupported API use), (c) be accepted and not booted but break the next time Apple has a new iPhone software update (since unsupported APIs or view hierarchies can change without warning). Or you could get lucky and have none of this happen.