![](bg4.png)
by the operating system. Therefore, class instantia-
tions, method invocations, or property retrievals made
by the smartphone application could create a state
from which it cannot recover itself. Thus, the con-
trol application on the desktop monitors the execution
state of the smartphone application.
To control the device, the control application uses
the open-source libimobiledevice library
5
. Before
starting the collection process, the control application
first installs the latest version of the smartphone ap-
plication on the device. Afterwards, it starts mon-
itoring the output of the system log of the attached
device. Once this setup is complete, the control ap-
plication launches the smartphone application. Using
the library, the control application can detect when the
application has been closed by the operating system.
If this happens, the control application checks which
class instantiation, retrieval of a property, or method
invocation was the cause. It extracts this informa-
tion from the monitored system log by searching for
the last instantiated class, invoked method, or queried
property. It then adds the offending class, method, or
property to a blocklist. This updated blocklist is re-
trieved by the smartphone application the next time
it is launched. Finally, the control component restarts
the smartphone application and continues its monitor-
ing of the output via the system log.
In addition to force closures, the control applica-
tion detects whether or not the smartphone applica-
tion is still reading properties and invoking methods
correctly. If this is not the case for a predefined pe-
riod of time, the control application restarts the smart-
phone application. This can happen when the smart-
phone application invokes a method which waits for
something. For example, this method could be wait-
ing for user input, network packets, or simply trying
to acquire a lock. Therefore, before the application is
restarted, the control application adds the last invoked
method to the blocklist. This prevents the offending
method from being called again and allows the smart-
phone application to proceed with the next method.
This process is repeated until all classes of the
API have been instantiated and all their properties re-
trieved and methods called. Thereafter, the results of
the invocations are collected from the monitored sys-
tem log.
3.2 Smartphone Application
The data collection is performed using an application
on the smartphone. It collects the data provided by
the operating system API, which is available with-
out requiring any user interaction or permission. In
5
https://libimobiledevice.org/
particular, the data collection application runs with-
out any special entitlements
6
or permissions. For this
purpose, methods are called and the return values are
collected. The contents of the properties of the class
are also retrieved and stored.
Initialisation. Once the application has been started
by the control application, it fetches and parses the
blocklists for classes, methods, and properties. In ad-
dition, it retrieves the name and index of the class
at which to continue recording. The first time it
runs, the blocklists are empty and it begins at the first
class. After this initialisation procedure, it starts the
actual recording process. First, it gets all the avail-
able classes. For each of the classes derived from
NSObject, an object is allocated and initialised. This
object is then used to read all the properties and then
invoke all the instance methods on it.
Property Retrieval. To retrieve the properties of
the object, a list of all properties is first retrieved. For
each property descriptor in the list, the name of the
property is fetched. To read the property by its name,
the method valueForKey is called on the class ob-
ject. The return value of this method is the value of
the property. This value is then stored for the anal-
ysis. To store it in a readable form, the type of the
property is required. This type is determined using
property_getAttributes and then converted into
the form required for the output. The value is finally
written to the system log.
Method Invocation. Once all the properties have
been retrieved, the methods of the class are called. For
this purpose, similar to the properties, the list of meth-
ods of the class is retrieved. This list contains method
descriptors. These allow to subsequently retrieve the
selector of the method which is in turn used to get
the method signature object. The method signature is
then used to create an NSInvocation object. Further-
more, if the method takes parameters, these are cre-
ated first. To create these objects, the type of the pa-
rameter must first be determined. This is done by re-
trieving the type encoding of each parameter from the
previously created method signature. For instance,
the type encoding for the primitive type integer is i,
for an integer array with three integers [3i], and for
an Objective-C class object @. While most arguments
can be created using this description, we need more
information to successfully create an object type. For
this purpose we use the information previously parsed
6
https://developer.apple.com/documentation/
bundleresources/entitlements
SECRYPT 2023 - 20th International Conference on Security and Cryptography
436