I just got done reading the press hysteria around AFNetworking exposing apps to a man in the middle attack. I was surprised that sourcedna.com claims
SourceDNA analyzes the code in thousands of iOS & Android apps.
sourcedna.com even has a search engine to report whether a vendor's apps use the AFNetworking SDK.
Considering they don't have access to paid apps, how do they claim to do this? Do SDKs like AFNetworking log SDK use in some form? If so, to who?
I am curious about this too. Here is what I gather:
SourceDNA only checks whether the library is linked into the app binary. They do not check how or whether the library is actually used by the app.
Objective-C is a dynamic language and keeps a lot of metadata in the binary. You can trivially run tools like class-dump or otool -ov on any unencrypted binary and it will list the names and inheritance of all classes, and the names and signatures of all methods and instance variables in each class, among other things.
Libraries like AFNetworking have many distinctive class names that they can check for in the list of classes in the app. Each version will have some added or removed methods and/or instance variables, so by checking the class dump from the app against the class declarations from each version of the library, they can figure out the version of the library used.
However, apps downloaded from the App Store are encrypted; and the App Store is the only way that SourceDNA could have gotten these apps. It is possible to decrypt / crack encrypted apps (that is how people pirate paid apps -- they buy them, crack them, and post the unencrypted binaries on pirate websites), but the common way to do this I believe involves buying and running the app on a jailbroken device.
I assume that the SourceDNA people must have automated this process somehow, so that they can automatically report on thousands of apps.
As I replied to #janselrx, I believe it's as I suspected and they can only analyze free apps. From their website:
SourceDNA analyzes the code in thousands of iOS & Android apps. This report lets you explore recent data about the mobile SDKs and tools found in the top 500 free apps.
Related
Goal
I'm building an iOS app using flutter for frontend, and C/C++ as backend. They must interoperate through FFI, which is a language binding scheme through C dynamic libraries. I intend to submit it to iOS App Store.
Problems
The Dart FFI sample on accessing C-struct works on macOS through dynamic liking and binding. Now dynamic linking is technically possible on iOS according to Xcode 9 - No option to create dylib project iOS, however, it's unclear to me how to ship the app to AppStore, because dynamic linking is not allowed according to Apple Guidelines Section 2.5.2.
2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they
download, install, or execute code which introduces or changes
features or functionality of the app, including other apps.
Educational apps designed to teach, develop, or allow students to test
executable code may, in limited circumstances, download code provided
that such code is not used for other purposes. Such apps must make the
source code provided by the Application completely viewable and
editable by the user.
Quite a few SO questions confirm this problem, such as:
can I use dynamic library(shared object) in my iphone app?
Will Appstore reviewers allow us to use dynamic library in iOS8?
Then official flutter documentation says
Dynamically linked libraries are automatically loaded by the dynamic
linker when the app starts. Their constituent symbols can be resolved
using DynamicLibrary.process. You can also get a handle to the library
with DynamicLibrary.open to restrict the scope of symbol resolution,
but it’s unclear how Apple’s review process handles this.
Questions
As of the date when I post this (2020), does this say that I could never ship an app using this architecture to App Store?
Is it possible that I static link my C/C++ code into a single binary of a flutter app? Take Unity as an example, their iOS plugin system recompiles the plugin into native app. If flutter has a similar mechanism, how?
The answers saying you can't use dynamic libraries on iOS date to before iOS 8, when support for user-provided dynamic libraries was added.
Nothing in 2.5.2 days you can't use dynamic libraires as long as they are shipped as part of your app. So:
As of the date when I post this (2020), does this say that I could never ship an app using this architecture to App Store?
No it doesn't, as long as "this architecture" refers to using a dynamic library that you link to at build time and bundle into your application.
Adding inputs from Reddit's FlutterDev channel
#escamoteur
As I understand it you are not allowed to load any library from
outside your installation folder. Especially not downloading something
at a later point of time. Could you make this a Stackoverflow question
and tag it with Flutter?
#airflow_matt
Since iOS 8 there can be shared libraries in the bundle, when properly
codesigned I don't see why dlopen wouldn't work. Or you can link the
library with main executable itself (just like flutter does) and
dlopen self (DynamicLibrary.process()). I think it's worth a shot.
I want to reduce the size of the app to its minimum level. So what all resources i can load from remote after installation? I know I can download images from remote. But can I download libraries or pods from remote after installation? I know we need those files to generate ipa files. Is there any way to setup app with minimum required code, and "load" rest of the code from remote, and is it even possible?
On a different note, I think there should be a framework which checks for existing libraries (like AF Networking) on device, and if it is not there, then downloads it, and all the apps which need it use it. This will help reduce the size of apps considerably.
For assets (images, movies, sounds, etc...) absolutely.
For executable code (libraries, frameworks and pods) absolutely not.
That would directly contradict one of the rules that Apple has in place on apps on the App Store.
Any executable code has to be bundled and submitted to the App Store for approval.
Apple's iOS developer guidelines state:
3.3.2 — An Application may not itself install or launch other executable code by any means, including without limitation through the use of a plug-in architecture, calling other frameworks, other APIs or otherwise. No interpreted code may be downloaded or used in an Application except for code that is interpreted and run by Apple’s Documented APIs and built-in interpreter(s).
As the title says, I am trying to create an app(personal development) and try to see what kind of system information or user data can be retrieved from phone. For now I am using the stimulator provided. So far what I am able to do is to retrieve information using the Address Book and UIKit Framework such as contact details and System Name/Version etc.
Is there any system information/user data that I missed out because I have yet to know of any more frameworks that allows retrieving of any information from the phone/Stimulator. I am not able to test EventKit Framework(the only other framework that I know) due to the fact that I am deploying the app in the stimulator which does not have the required apps. (Will be trying on jailbroken iphone in the later stages).
Also, I have yet to find any information of accessing the .sqlitedb /.db/.plist files programmatically instead of using any software tools as I would like to access the files such as messages, phone history through my app that I created. If this is possible, I would also like to know if accessing these .sqlitedb /.db files/.plist is only applicable if I deploy my app in the jailbroken phone /Applications folder which does not have sandbox or is it also applicable in the stimulator itself?
This will be definitely helpful to you to get access the call/sms/email details by reading the .sqlite database. Here is a tutorial.
i know providing links are discouraged here however these apple and wiki
links will be helpful to you.
thanks
I read that PhoneGap is approved by Apple as a framework for building native apps, but I'm not clear on how this does not constitute a "website wrapped as an app," something that Apple specifically doesn't like, as per their App Store guidelines. I'm assuming it is because the JS is contained in the application, rather than running on a remote server?
Any clarification on this issue would be most appreciated.
but I'm not clear on how this does not constitute a "website wrapped
as an app," something that Apple specifically doesn't like, as per
their App Store guidelines.
By this Apple means Apps that simply show a UIWebView that loads a remote website, so it basically just behaves like Mobile Safari, just without the controls. Also they wan't Apps to show at least a UI when the device is not connected to the internet, like in the Facebook App where you can still read already downloaded status updates, view photos etc. That's what a "I just wrap a remote website inside a UIWebView"-App can't do.
PhoneGap Apps have all the resources they need (HTML, CSS, JavaScript) on the device residing in the App's bundle, so using such an App would not depend on network availability and could at least show a UI that tells you to connect to the Internet in order to use the App, or they could display already loaded content (like Facebook, Twitter and so on).
I think that the signature of the binary tells Apple what framework built the application, and since all the supporting files (js included) are included in the project and therefore in the binary, it is a standalone application. That being said, I still think that doing things Natively is the best way to go. I am extremely comfortable with javascript and started out thinking Phonegap was the way to go for me. I did a couple of projects with it and then decided to take the plunge and learn Objective-C. That worked out so much better for me. No dependency on a third party framework and I wish that I had started that way.
Sometimes the easy way out just hurts ya in the end IMO.
Are separate apps able to share the same binary in a form like a DLL? I know its possible to compile static libraries but I wouldn't count these as the same as a DLL (i.e. a dll is one copy of a binary shared by multiple apps, whereas static libraries are separately included by any using app).
Is each app totally separate from each other, are there any IPC or file sharing mechanisms available for differing apps to communicate and share data?
Is it possible for an app to create a new process in addition to a new thread (I guess not)?
You can't share executable files between applications. Apple requires that all apps function standalone. However you can use a UIDocumentInteractionController to get another program to deal with files you don't understand, and a 'quick view' may be available. That's how Mail works, for example.
Programs from the same vendor can share the keychain and, I think, iCloud storage as of iOS 5, but can't share storage on disk. As they can declare supported file types, UIDocumentInteractionController can be used to push temporary access to a file from one app to another. A custom URL scheme can be used in a similar way to pass fragments of data if that helps.
As a general rule, only one user process may be active at once in iOS - e.g. background processing is essentially event based. So you can't create a second process for yourself.
You can do this if you are developing for a jailbroken phone. Not
otherwise.On jailbroken phones, you can create .dylibs or shared libraries that can be
loaded via the DYLD_INSERT_LIBRARIES environment var (much like on
MacOS)
Apps are sandboxed. However, there are some ways of communicating between apps. You can use
(a) customURL scheme (also mentioned by Tommy above)
(if any) associated with an app to launch an app and send some
parameters to the launching app
(b) If you control communicating
apps, then you can use Message ports (CFMessagePortCreateRemote)
(c) If you control communicating apps, you could use Darwin
NOtification center for distributed apps.
Of course the expectation for (b) and (c) is that the
communicating apps are all running. On iOS since there is only one foreground
process, you'd have to have the other as a background app and that's
restricted to certain kinds of apps on the iOS platform.
Basically, no to all of the above, unless you're targeting jailbroken phones and are bypassing Apple's App Store. If you jailbreak, I believe you have similar options to those you have in Mac OS X.