\Large Platform-Centric Android Monitoring---Modular and Efficient
{\rm Jan-Christoph K\"uster
abstract_andi.tex

We present an add-on for the Android platform, capable of intercepting
nearly all interactions between apps or apps with the platform,
including arguments of method invocations in a human-readable format.  A
preliminary performance evaluation shows that the performance penalty of
our solution is roughly comparable with similar tools in that area.  The
advantage of our solution, however, is that it is truly modular in the
sense that we do not actually modify the Android platform itself, and
can include it even with an already running system.  Possible uses of
such an add-on are manifold; we discuss one from the area of runtime
verification that aims at improving system security.

% The main technical contribution of this paper is the outline of an
% add-on for the Android platform, capable of intercepting nearly all
% interactions between apps or apps with the platform, including a
% human-readable representation of parametric data such as function call
% arguments.  The add-on plugs into the running system and is thus truly
% modular, not requiring changes to the platform's source code as similar
% monitoring and analysis solutions currently do.
% %
% More broadly, we also describe how this add-on can be used to monitor
% user-defined security policies concerning the undesired (or desired)
% behaviour of Android apps, combining it with emerging techniques from
% the area of runtime verification.
% %
% A preliminary evaluation with dedicated test apps shows that our
% approach is technically feasible and the performance penalty roughly
% comparable with similar tools in that area.
% %
% Naturally, our add-on is open source software and available online.





%%% Local Variables:  
%%% mode: latex
%%% TeX-master: "main"
%%% End: 

application.tex
As already pointed out in \S~\ref{sec:intro}, there is a myriad of
reasons why users may want to closely monitor their mobile devices.
Although our add-on is application-agnostic, our motivation is to bring
techniques developed in the area of runtime verification (cf.\
\cite{Chen:2009:PTS:1532891.1532921,BKV2013}) closer to Android.  In a
nutshell, runtime verification subsumes tools and techniques that aim at
checking that a system's actual behaviour agrees to a (formal)
specification of pre-defined behaviour.  For example, one could specify
that ``no installed app should ever send an SMS to a phone number, which
is not stored in the user's contacts list,'' using a dedicated temporal
logic, for example.
%
Arguably, a major focus in runtime verification research right now is to
be able to monitor not just reactive, but also data-intensive systems,
where one not only needs to know that a message was sent, but also by
who and to whom (cf.\ keynote speech ``Runtime Verification with Data''
by M.\ Leucker at the Runtime Verification conference 2013, Rennes,
France).  Temporal logics and regular expressions, traditionally used in
that domain are typically not sufficient to express such parameterised
behavioural policies, and if they are (cf.\
\cite{Chen:2009:PTS:1532891.1532921}), there is usually no tool support
for the domain that concerns us.

A recent paper \cite{BKV2013}, introduces a general purpose monitoring
algorithm for a parameterised logic, which we have implemented as a
client that directly utilises the API of the DroidTracer add-on.
% we have implemented more or
% less as a client application of our add-on.  
The above policy can be formalised in this logic and be applied to any
app installed on the phone.  To that end, our client provides a
graphical front-end that lists all the installed apps of a device and
users can choose which ones are being monitored simply by clicking on
its name in a list.

Although our approach is platform-centric, we give users the possibility
to exempt certain apps from being monitored, mainly for two reasons:
firstly, to avoid false negatives in case certain apps are more
trustworthy than others, and secondly, for performance reasons, since
our runtime verification client, internally, instantiates one runtime
verification monitor per app and policy.\footnote{In the worst-case,
  monitors are of exponential size wrt.\ a policy, depending on the
  policy as well as concretely observed system behaviour
  \cite{BKV2013}.}  Therefore, the fewer apps are being monitored, the
less overhead and disruption for the rest of the system.
%  (for a more
% detailed performance analysis, see also \S \ref{sec:exps}).


% $\ltlG \forall x:sms.\ contact(x)$

Note that, in an abstract sense, the aforementioned tools such as
AppGuard are also runtime verification tools.  However, rather than
employing tools and techniques developed in the area of runtime
verification directly, they use alternative means to define security
policies (in case of AppGuard, for example, \emph{security automata}
that have been introduced by Schneider
\cite{DBLP:journals/tissec/Schneider00}).  Also, off the shelf security
automata are not suitable as a fully declarative policy specification
language over potentially infinite data domains (e.g., set of all IPs,
email addresses, etc.).  
% The idea in AppGuard---to stick with this
% example---seems to be to offer a set of predefined policies for typical
% ``traps and pitfalls'' and not bother the user with the admittedly
% error-prone task of creating their own.

% We, on the other hand, have not yet concerned ourselves with such
% methodological considerations.

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "main"
%%% End: 

conclusion.tex
Our benchmarks suggest that we sit comfortably between the competition.
For example, Aurasium's interception of \code{getDeviceId()} has a 35\%
and \code{getLastLocation()} a 34\% performance overhead \cite{XSA2012},
whereas AppGuard's benchmarks range between 0.8 and 21.4\% overhead.
%  when
% the security automata are disabled \cite{BGH+2013}. %and Z\% when enabled
%\cite{BGH+2013}, which is close to our 26\% average overhead with the
%runtime verification client enabled.
TaintDroid, although more of a taint flow analysis rather than a pure
monitoring tool, has a performance overhead of up to 29\%, which is in
the range of our measurements of 38.6\% average overhead with the
runtime verification client enabled.
% The microbenchmarks as well as our 26\% average performance overhead
% compared to 21\% in AppGuard \cite{BGH+2013}, 35\% in Aurasium
% \cite{XSA2012} and 14\% in TaintDroid \cite{EGC+2010} suggest that we
% sit comfortably amongst the competition.
However, one should keep in mind that unlike the other solutions,
DroidTracer does not rely on app or system modifications and therefore
has limited potential for optimisation.  The fact that, in particular,
our kernel module performs well under these constraints, is somewhat
surprising but largely due to our ability to intercept all the relevant
data at a single point of entry, i.e., the Binder.
%
More so, we have shown that detailed systems monitoring on Android is
possible even without any modifications to the platform itself.


However, this is preliminary work, a proof of concept.  While we are
content with the event interception part of our work and already offer
an API, such that others can use and benefit from it as is, we have yet
to substantiate our claim that runtime verification as outlined in
particular in \S~\ref{sec:rv} really is beneficial to system security.
Works that analyse current threats and security trends in that area
(cf.\ \cite{ZJ2012, FFC+2011, EOMC2011}) seem to suggest that the total
number of Android attacks is on the rise, but that most of the threats
follow only a handful of different patterns.  Our working hypothesis is
that these patterns can and should be translated into (temporal logic)
policies, which then in turn are monitored by our tool.  The essential
ingredients for this undertaking were presented in this paper and shown
to work.

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "main"
%%% End: 

droidTracer.tex
In a nutshell, our add-on implements two different but complementary
means of event monitoring: firstly, it directly intercepts relevant
Linux system calls and secondly, it intercepts IPC calls via Android's
internal communication infrastructure called Binder (see below).

\paragraph{System Call Interception}
% To get a sufficiently detailed view of app interactions that would
% enable platform-centric monitoring, one needs hooks sufficiently
% deep in the actual platform.  To that end, our kernel module contains
% handler methods that get invoked by small bits of code (so called
% probes) that are dynamically inserted by kprobes at almost arbitrary
% kernel addresses, for example, those that are associated with relevant
% system calls.

% utilises kprobes
% \footnote{https://www.kernel.org/doc/Documentation/kprobes.txt},
% Linux' internal kernel debugging facility that which lets users
% dynamically insert probes, i.e., small bits of code, to be executed at
% almost arbitrary kernel addresses associated with corresponding
% syscalls, for example.
%
Normally, Android apps, which are executed on a Java virtual machine and
without root privileges, do not directly trigger system calls.  Instead
they request via a Java API that some service be used, or some resource
be allocated.
%
These high-level requests eventually translate into a sequence of system
calls that ultimately make the kernel open a file, send something to a
(virtual) device, etc.
%
Our kernel module contains handler methods that get invoked by small
bits of code (so called probes) that are dynamically inserted by
\code{kprobes} at almost arbitrary kernel addresses, corresponding to
the respective system calls.
%
For example, to check if an app eventually reads from (or writes to) a
file on the SD card, we break into the system call \code{sys\_open()}
and check if its argument, \code{filename}, which always holds the full
path of a file to open, contains the sub-string ``sdcard''.
%
Similarly, we can track down every internet connection established by an
app, independent of the API version in use, by checking in
\code{sys\_connect()} if the socket address family is of type
\code{AF\_INET} (resp.\ \code{AF\_INET6}), and so forth.
% Similarly, we can track down every internet connection established by an
% app, independent of the API used. All control flows starting in Java
% from either \code{HttpURLConnection}, \code{HttpClient}, or other
% interfaces, lead down to \code{sys\_connect()} in the kernel, which has
% to be used to open IP based connections.  In our corresponding handler
% routine, we first check if the socket address family is of type
% \code{AF\_INET} (resp.\ \code{AF\_INET6}) and then access its IP
% address. This way we can intercept all endpoints that an app connects
% to.

Alternatively, we could have placed hooks directly into the high-level
service handlers or the various system services of the platform, like
\cite{DBLP:journals/corr/GunadiT13, Bugiel2012, Hornyack2011, NKZ2010}
do, in order to be notified when relevant events take place.  Although
this is possible and sometimes unavoidable, as in the case of
TaintDroid, since taint flow analysis requires \emph{seamless} tracking
of control and data flows, this has the disadvantage that such hooks are
specific to particular platform releases and, generally, not portable.
Besides, the functionality provided by our kernel module can be entirely
switched on or off without rebooting or modifying the system.
%
% Although the interception of control-flows within the kernel usually
% involves its modification, kprobes \TODO{important to mention that we
%   use jprobes, a specific form to intercept functions?}, the kernel's
% internal debugging mechanism, allows us to monitor every system call
% including its function arguments in a modular and non-disruptiv
% way.
%
% Technically, it is able to dynamically add breakpoints to every kernel
% code address, and if hit invokes a handler routine specified in our
% module.
%
% For example, to check if an app eventually reads from (or writes to) a
% file on the SD card, we break into the system call \emph{sys\_connect}
% and check if its argument \emph{filename}, which always holds the full
% path of a file to open, contains the sub-string ``sdcard''. Similarly,
% for \emph{sys\_connect}, which has to be used to open IP based
% connections, we first check if the socket address family is of type
% AF\_INET (resp. AF\_INET6) and then access its IP address. This way we
% can intercept all endpoints of an app's established internet
% connections.

\paragraph{Binder Interception}
Binder is Android's main communication infrastructure between apps and
system services and it implements the popular remote method invocation
(RMI) scheme. Essentially it lets an object running in one Dalvik VM
invoke methods on an object running in another Dalvik VM.
%
\begin{figure*}[ht]
  \centering
  \includegraphics[width=0.85\textwidth]{android-crop.pdf}
  \caption{An app accessing Android's system services via Binder (left)
    and our add-on (right).}
  \label{fig:rmi}
  \vspace{-1em}
\end{figure*}
%
This communication is exemplified in Fig.~\ref{fig:rmi}. It shows an app
that attempts to send an SMS by using methods provided by the class
\code{SmsManager}. This class, however, is more of an interface rather than the
actual implementation of the service which does the sending. What is
actually happening is that the \code{SmsManager} invokes a so called proxy
which compactly encodes arguments and data types of
\code{SmsManager::sendTextMessage()}, for efficient transmission via the
Binder kernel driver. The class \code{android.os.Parcel} is the corresponding
container for this data, also providing the required encoding and
decoding methods. The parcel is then received by
\code{com.android.internal.telephony.ISms.Stub}, which is the counterpart of
the proxy and which takes care of the decoding.  The stub, in turn,
invokes \code{IccSmsInterfaceManagerProxy::sendText()} with the arguments originally
intended for \code{sendTextMessage()} to tell the GSM driver (not depicted) to
do the physical transmission of said message.
% Android uses mainly a communication paradigm known from distributed
% object-oriented programming \cite{Pitt:2001:JRM:558733}, called
% \emph{remote method invocation} (RMI).  It basically lets an object
% running in one Dalvik Virtual Machine (DVM) (e.g., some app) invoke
% methods on an object running in another DVM (e.g., some system service).
% %
% Binder is Android's key implementation of the RMI concept, and contains
% amongst others, a kernel driver to exchange a method call on low-level,
% after it was flattened into a byte-stream, between the memory of
% otherwise isolated processes.
% % rather than
% % just being an IPC kernel driver, it names a whole framework that
% % supports the RMI process on all layers of the platform. 
% % Amongst others,
% % it provides a class called \emph{android.os.Parcel} that is a data
% % container to marshall Java method arguments down into the form of a byte
% % stream (using libbinder.so); this way, they can be sent to the according
% % target process using the high-level interface
% % \emph{android.os.Binder}.\TODO{AB: Say something about Parcel or
% %   remove.}
% %
% This communication is exemplified in Fig.~\ref{fig:rmi}.  It shows an
% app that attempts to send an SMS by calling sendTextMessage() of the
% class SmsManager, and eventually invokes the SmsManagerService by way of
% the Binder kernel drive (see the control-flow arrows). SmsManager calls
% com.android.internal.telophony.ISms.Stub.Proxy, the component that
% marshalls the method call arguments (i.e., Java primitives or objects)
% into a data-container provided by android.os.Parcel. The parcel, is then
% passed to the method transact() of android.os.Binder, which uses the
% underlying Binder driver, to trigger the corresponding callback method
% onTransact() in the target process' Binder class. Then,
% com.android.internal.telephony.ISms.Stub, the counterpart of the proxy,
% unmarshalls the method arguments from the received parcel, and triggers
% a method call in SmsManagerService.
% What is not distinguishable for an app-programmer, as it happens behind
% the scenes, is that Android's API does not handle all method calls
% directly in the kernel (as seen above for internet and SD card access),
% but mainly uses so called system services to provide permission
% controlled functionality to apps. For example, assume an app (see Figure
% \ref{fig:rmi}, where classes.dex shows an app's compiled Java-code)
% wants to send an SMS and therefore calls \emph{sendText(String destAddr,
%   ... String text, ...)}  of the class SmsManager in the API. SmsManager
% then requests the corresponding SmsManagerService, which runs as a
% privileged process, to talk on the app's behalf to the radio driver and
% send the actual SMS (after checking for granted permission).

% As our approach aims to cover the interception of all security and
% privacy critical interactions, it is crucial to monitor the
% information-flow between apps and those services.
% %
% The communication concept to connect them, namely remote method
% invocation (RMI), is known from object-oriented programming and lets a
% client (app) execute methods of a remote object (service), i.e.,
% provides access to functionality across address space boundaries.
% %

The communication with Binder basically follows a stringent
communication protocol between sender and target.  By hooking into
the function \code{binder\_thread\_write()} of its kernel driver, we are
able to tell when a new communication session commences; that is, when a
sender has triggered the transmission of the \code{BC\_TRCANSACTION}
signal.  Specifically, this signal (defined inside \code{binder.h} along
with other protocol signals) indicates that the custom C structure,
\code{binder\_transaction\_data} (also defined inside \code{binder.h}),
has been initialised at a set address in memory.  It contains, amongst
others, information on the sender, method arguments, and the method
name---although compactly and not human-readable encoded (see paragraph
on data extraction below).
%
We read this information from the structure before the kernel copies it
into the address space of the target process.

% One could argue that a seemingly more efficient means of interception
% would be to analyse the entries inside \code{binder\_transaction()}, as
% this function handles \code{BC\_TRANSACTION} directly.  However, it is
% not possible to place a probe at this function's kernel address as it is
% inlined and therefore not exported to the kernel's system map.
% %
% Yet another approach was chosen by the aforementioned Aurasium that
% intercepts the \code{ioctl()} system call, which transmits the protocol
% data to the kernel driver.  The downside of this solution, however,
% is that \code{ioctl()} is not exclusively used for the Binder protocol
% (in fact, far from it), and one needs to spend many extra CPU cycles on
% filtering for and analysing relevant occurrences.

Naturally, one can also intercept system events and messages later in
the control flow; for example, when the
\code{IccSmsInterfaceManagerProxy} communicates with the kernel driver
of the radio device.  At this late stage, however, one would lose the
information about the original sender app of an SMS, since its Linux
User ID (UID), which uniquely identifies an app on the Android platform,
is not passed to the kernel.  In other words, we would see that an SMS
is being sent, but not by whom.
%
As system services check the permission of the client based on its UID,
Android uses Binder to communicate said UID directly to the service
(by writing the field \code{sender\_euid} inside
\code{binder\_transaction\_data}).  Via this indirection, it is not
possible for a rogue process to directly query a service, using a fake
UID, for example.
%
These observations suggest to us that there are no real alternatives to
intercepting system events and communication at the level of Binder, if
one is interested not only in the occurrence of certain events, but also
in the associated meta data.

\paragraph{Data Extraction}
%
Our interception of Binder lets us monitor every API method invocation,
but name, types and data of arguments as well as caller and callee are
either dropped or compactly encoded (i.e., marshalled) in terms of
abstract IDs for efficiency reasons.
%
Therefore, we also need to concern ourselves with unmarshalling the
data once intercepted; that is, determine which process/app tries to
send an SMS, what its content is, who the recipient is, etc.
%
% Although we're effectively able to intercept the information flow of
% every API method call from binder\_transaction\_data, we need to solve
% the re-assembling of their high-level meaning; that is, recalling the
% example of sending an SMS, the UID of 'App' calling the method
% 'sendText' of SmsManagerService with the String-parameters (which, in
% general, can be arbitrary Java primitives or objects) 'destAddr' and
% 'text'.  To deal with the fragmentation of the Android market, the
% re-assembling must be independently of changes in the encoding of the
% byte-stream throughout different existing and future Android versions.

To that end, we have realised \code{DroidTracerService} (see right upper
corner of Fig.~\ref{fig:rmi}), a user space app without its own GUI. It
serves mainly two purposes: On the one hand, it acts as an
interface between the kernel module and Android's ``unmarshalling
algorithms, on the other hand, it is able to pass the intercepted system
events on to a client app (cf.\ \S\ref{sec:rv} for an example).
%
As such it is similar to a classical system library, which provides an
API for third-party apps to use rather than a dedicated GUI.

Unmarshalling Binder communication, however, is not something that
is typically done by apps. In fact, there is no public API for this task
nor any complete documentation on the marshalling algorithms that
would allow users to devise their own implementations easily.  Hence, we
reverse engineered this whole process to some extent, to be able to use
the official unmarshalling methods of Android's
\code{android.os.Parcel}. This has the advantage that our
solution ends up using the same methods that are being used by the
Binder communication anyways, and is therefore not specific to
particular versions of the Android OS.
% To that end, the kernel module sends the following information taken
% from binder\_transaction\_data:
% \begin{itemize}
% \item code: a numeric ID, encoding the method to execute.
% \item sender\_euid: the sender's UID, added by the Binder driver.
% \item buffer: an uint8\_t array of variable size, that contains an encoded
%   parcel.
% \end{itemize}
%
% Under Android's RMI regime, the encoding of a method call is taken care
% of by a so called \emph{proxy class} and the decoding by a so called
% \emph{stub class}, respectively.

We discovered that \code{android.os.Parcel} provides a method to fill its internal
data structure from a byte array. Thus, we can create a
\code{Parcel} object directly from the intercepted field \code{buffer}
inside \code{binder\_transaction\_data}, to apply the Android specific
unmarshalling methods to it, namely, \code{readString()},
\code{readInt()}, \code{readFloat()}, etc.
%
However, we cannot access arguments easily, as a \code{Parcel} object
for efficiency is missing the information about the order in which they
appear; that is, we have to invoke the unmarshalling methods in the
right oder to read the encoded arguments from it correctly. In the
offical unmarshalling process, the stub knows how its proxy has encoded
the arguments using the counterpart methods \code{writeString()},
\code{writeInt()}, \code{writeFloat()}, etc. By examining several proxy
classes, we then observed they usually marshall the method arguments in
the same order they appear in the corresponding method's signature.  We
can access the signature and with it the ordering and the types of the
arguments via reflection, but only under the prerequisite of having the
called interface and method name revealed and at hand first. For our
example in Fig.~\ref{fig:rmi} this information is
\code{com.android.internal.telephony.ISms} and \code{sendText()}.
%
We found out that the interface name is always encoded first (before the
method arguments) in a \code{Parcel} object; this is, for the stub to
read and ensure that the proxy called its correct counterpart. We can
access it by applying \code{writeString()}. In terms of decoding the
called method name, \code{binder\_transaction\_data} leaves us with an
integer, called \code{code}.
%parcel object.
%  at
% first. %\TODO{actually an int in front, that decodes strict
%                   %mode}
% ; that is, both have to agree on the
% interpretation of the abstract data that is exchanged via
% binder\_transaction\_data.
% %
% They are automatically generated and mark the endpoints of a method call
% (see components coloured in grey in Fig.~\ref{fig:rmi}), i.e., abstract
% away/code the underlying technical details -- in favour of a client and
% service involved.
%
A closer look at several stub classes reveals that the mapping of
\code{code} to its according method name is, in fact, defined there.
For example, in \code{com.android.internal.telephony.ISms.Stub} the
method \code{sendText()},
  % android.app.PendingIntent sentIntent, android.app.PendingIntent
  % deliveryIntent) 
is encoded in terms of a variable
%
%static final int TRANSACTION_sendText = (android.os.IBinder.FIRST_CALL_TRANSACTION + 4);

{\centering
{\tt static final int TRANSACTION\_sendText = 5}.
}

%
\noindent
If the according proxy class sends this \code{code} through Binder, the
stub uses it to
%in a switch-case statement 
first trigger the correct unmarshalling and second, the execution of
\code{sendText()}.
%, which in our example is implemented in
%\code{IccSmsInterfaceManagerProxy}.
%
As the suffix of \code{TRANSACTION\_sendText} equals the
method name, we are able to use reflection to extract it.
%
% Importantly, our approach is robust against changes in the low-level
% encoding of method call arguments and works on all Android versions
% alike, as DroidTracerService has access to concrete android.os.Parcel
% and the specific unmarshalling methods on a device.

Marshalling methods exist only for Java primitives, and some other
types, such as Binder references, primitive arrays, etc. But more
complex objects can be sent through Binder, too; that is, if they
implement the method \code{createFromParcel()} of the interface
\code{Parcable} to define how they can be encoded using \code{Parcel}'s
standard marshalling methods. We can invoke \code{createFromParcel()}
via reflection in most cases, and are thus able to cover most argument
types appearing in method calls. This is crucial, as once we miss
unmarshalling one argument for a method call, we cannot access remaining
arguments in the rest of \code{Parcel} object's byte array.
% \TODO{What has to follow, are usual experiments, how robust our
% approach is.}


\paragraph{Kernel/User-Space Communication}

% To connect the kernel module with the high-level part of our approach
% running in Java\TODO{AB: Was ist denn ein high-level part of our
%   approach running in Java?  Meinst Du unsere GUI-lose App?}, we need an
% efficient communication mechanism across framework layer boundaries;
% %between kernel and user-space
% that is, without DroidTracer's need of polling for incoming low-level
% system-events. A further requirement to it is that it must be
% bi-directional, so that the kernel can send events upwards, and the user
% can control the module downwards, i.e, select apps, services or even
% specific API methods to monitor.\TODO{AB: Würde ich alles loeschen und
%   den Paragraph mit folgendem Abschnitt beginnen, der kuerzer und
%   weniger verwirrend ist.}

As event interception takes place solely inside the kernel space and
unmarshalling relies on Android's Java API, we need a mechanism that
allows us to pass data from inside the kernel space up to an app.
Moreover, we need some means to let the user control the kernel module
for even the most basic tasks, for example, to switch event interception
on or off from an app.
%
However, Android has no built-in way to serve as a solution, but we were
able to use
\code{netlink},\footnote{http://www.linuxfoundation.org/collaborate/workgroups/\\networking/generic\_netlink\_howto}
which is a socket based mechanism of the Linux kernel that can
bidirectionally communicate with user space. We placed the
implementation of the communication endpoints into our kernel module and
into our app, and thus, leave the Android framework as such completely
unmodified.
%
As the Android API does not offer \code{netlink} support, we had to
build a custom \code{netlink} endpoint for our app, using the
\emph{Netlink Protocol Library Suite}
(\code{libnl}\footnote{http://www.carisma.slowglass.com/~tgr/libnl/}).
It runs as a shared C++-library, \code{droidtracer.so} (see
Fig.~\ref{fig:rmi}), in the same process as our app. We had to extract
the core functionality for \code{netlink} from \code{libnl} and
recompile it for Android devices using Android's Native Developer Kit
(NDK).
%
\code{Netlink} allows to declare a callback method to receive kernel
data, so that \code{droidtracer.so} does not have to poll our kernel
module for events. As the ultimate goal is to transmit them all the way
to \code{DroidTracerService} we use reflection and Java Native Interface
(JNI) to register a method in Java that is automatically triggered if
we forward data received from \code{netlink} to it.

%Another problem is that %the high-level
%our app can be terminated anytime either by the user or the Android
%system, due to its app life-cycle management, which dynamically changes
%apps' execution priorities over time even to the point where they may be
%shut down. If during this time, relevant events are produced by an app
%or otherwise, they will pass our monitoring and interception system
%unnoticed as it is not possible with \code{netlink} to restart the
%user space endpoint from inside the kernel.
% This leads to lost events, as the app can usually not be restarted
% from kernel-space.
%
% We found a way that the kernel can trigger an Android built-in shell
% script, which is normally used by the android debug bridge (adb) to
% start apps via command-line.
%The way out for this problem is to trigger from our kernel module a
%(somewhat hidden, but available on most Android platforms) shell script,
%which is normally used to start apps in debugging mode from the command
%line.

% since there is no reason to invoke it also for our
%purposes.

% However, we found a workaround for this problem by way of an
% Android-provided, built-in shell script, which is normally used by the
% Android Debug Bridge (adb) for starting apps on the command line.

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "main"
%%% End: 

experiments.tex
\begin{table*}[ht]
  \begin{center} {\footnotesize
      \caption{%Benchmarks for 
        Execution of Android API method calls (each up to 10,000 times) with and without DroidTracer. The margin
        of error is given for the 95\% confidence interval.}
    \label{tbl:exps}
\scalebox{1.01}{%
\begin{tabular}{llrrrrr}
  \toprule
  \multicolumn{1}{l}{Interface} & \multicolumn{1}{l}{Method} & \multicolumn{1}{r}{Android} & \multicolumn{1}{r}{Kprobes} &
  \multicolumn{1}{r}{Add-on} & \multicolumn{1}{r}{Kprobes}  & \multicolumn{1}{r}{Add-on}\\
  \multicolumn{1}{c}{} & \multicolumn{1}{c}{} & \multicolumn{1}{r}{(in ms)} & \multicolumn{1}{r}{(in ms)} &
  \multicolumn{1}{r}{(in ms)} & \multicolumn{1}{r}{(Overhead in \%)}  & \multicolumn{1}{r}{(Overhead in \%)}\\\midrule
  \rowcol TelephonyManager & getDeviceId & 5309 $\pm$ 15 & 5517 $\pm$ 18 & 5811 $\pm$ 11 & 3.92 & 9.46\\[0ex]
  TelephonyManager & getSimSerialNumber & 5346 $\pm$ 16 & 5524 $\pm$ 16 & 5817 $\pm$ 7 &  & 8.81 \\[0ex]
  \rowcol LocationManager & getLastKnownLocation & 3516 $\pm$ 13 & 3562 $\pm$ 13 & 4126 $\pm$ 5 &  & 17.35\\[0ex]
  SmsManager & sendTextMessage & 9166 $\pm$ 13 & 9396 $\pm$ 13 & 10216 $\pm$ 10 & 2.51 & 11.46\\[0ex]
  \rowcol PackageManager & getInstalledApplications & 15730 $\pm$ 204 & 15514 $\pm$ 202 & 15422 $\pm$ 172 &  &  \\[0ex] 
  ConnectivityManager & getAllNetworkInfo & 5769 $\pm$ 53 & 5841 $\pm$ 60 & 5671 $\pm$ 7 &  &  \\[0ex]
  \rowcol BufferedReader & readLine & 15360 $\pm$ 72 & 15531 $\pm$ 67 & 15455 $\pm$ 38 &  &  \\[0ex]
 \bottomrule
\end{tabular} }}
\end{center}
\vspace{-1em}
\label{turns}
\end{table*}
%
When our add-on is being executed with our runtime verification client
on, the average performance overhead is 38.6\%. This was
  determined on a Nexus 7 (1st generation) tablet with a quad-core CPU
  and 1 GB RAM running Android OS 4.3. We used seven test apps,
  specifically written for our purpose, i.e., each of the apps was
  designed to generate 100 runs of up to 10,000 events of the following
  sorts: 1.\ access the device ID (IMEI), 2.\ read the SIM card serial
  number, 3.\ request location, 4.\ send SMS, 5.\ look up list of
  installed apps, 6.\ access connection status about all network types,
  and 7.\ read file from SD card.  Besides monitoring the policy
introduced in \S\ref{sec:rv}, namely that no app shall send a text
message to a number not recorded in the user's contacts list, we have
instantiated the policies used in \cite{BKV2013} to cover a somewhat
broader range of possible applications.  However, as the results of
these test runs are specific only to our implementation of runtime
verification, we also need to measure the performance overhead of our
``bare bones'' add-on when no further analysis is undertaken.
Table~\ref{tbl:exps}, shows the execution time when intercepting the API
method calls of the above eight events in three different modes of
operation: First, we ran the test apps without our add-on enabled to get
a reference execution time for the unmodified system. Second, we enabled
only the event interception part of our add-on but no further event
processing, and thirdly, we added unmarshalling and netlink
communication to it in order to determine whether or not there is a
performance penalty associated with how we process the intercepted
information back in user space.

% When our add-on is being executed with our runtime verification client
% on five test apps, the average overhead is 26\%. The test apps each
% generate 1000 events; that is, either request the location, access the
% device ID (IMEI), look up all apps installed, connect to the internet,
% or send an SMS.  In general, we observed that monitoring multiple apps
% does not result in increased overhead, as usually most apps are paused
% and only the one at the top of the screen generates system events.
% %
% Per app, we activated the policies introduced in \S\ref{sec:rv} as
% well as a selected set of policies from the well known specification
% patterns \cite{}. We chose this patterns for our experiments as they
% cover the shape of most policies appearing in practice. This is the
% reason, why we have also used them to evaluate the efficiency of our
% monitoring algorithm standalone \cite{}.

% Table 1 summarises the result of our microbenchmarks, when each test app
% repeatedly calls one specific API method. Our test device is a Nexus 7
% (1st generation), which runs Android 4.3. Note, as we use a tablet we
% are not actually sending any SMS. We ran our test apps in three
% settings: once when our add-on was completely plugged off, once when
% only our kernel module with kprobes was running, i.e., without
% DroidTracerService and netlink, and finally our whole add-on, which
% includes unmarshalling.
%

As the results show, the actual performance overhead of using just our
kernel module with \code{kprobes} is only 2.51--3.92\%, whereas
the complete performance overhead, when including netlink and
unmarshalling, is 8.81--17.35\%. During the experiments, we
  ran all four cores of the Nexus 7 on a fixed frequency rate using the
  performance governor, which allowed us to reduce the margin of error
  dramatically. Note that we left cells empty in Table~\ref{tbl:exps},
  where overhead could not significantly be determined wrt. the t-test
  for the 95\% confidence interval.
%
What is noteworthy is that \code{getDeviceId()} and
\code{getSimSerialNumber()} have significant lower overhead than
\code{getLastKnownLocation()} and \code{sendTextMessage()}, as both
former method signatures have no arguments that require unmarshalling. 
%
%Instead we
%can access IP addresses directly from the arguments of the syscall
%\code{sys\_connect()} and send it to \code{DroidTracerService}.
%
The call \code{getLastKnownLocation()} has the highest overhead. A
probable explanation seems to be that its arguments contain several
complex objects, for example, one of type \code{LocationRequest}. Their
unmarshalling involves additional reflection calls; that is, to find and
invoke the method \code{createFromParcel()}, which a class has to
implement, if it wants to be sent through Binder. As
  \code{sendTextMessage()} contains only Java primitives as arguments,
  its unmarshalling overhead is slightly lower.

% getDeviceId() does not involve the transmission of
% any method arguments, its unmarshalling is slightly more expensive than
% that of sendTextMessage().

% A probable explanation seems to that unmarshalling of primitive
% arguments, such as a telephone number or the content of an SMS, adds no
% significant overhead to the various invocations of unmarshalling methods
% of DroidTracerService, some of which return immediately when no
% arguments are passed.  In other words, for average sized arguments, the
% unmarshalling alone is a negligible factor.
%
% One can observe that despite querying getDeviceId() involves no sending
% of method arguments, its unmarshalling costs slightly more time than the
% one of sendTextMessage().  It is most likely that unmarshalling
% primitive arguments such as the telephone number of the recipient and
% the content of the SMS (encoded as strings), adds no significant time to
% the overall function calls being executed in DroidTracerService.
%

% Besides measuring the overhead for isolated executions of API calls, we
% also analysed the influence of our add-on on common user operations,
% when we are intercepting, but no interesting events worth unmarshalling
% occur. For example, we measured the application load time of an app,
% which is the time from a user's click on its icon until it gets
% displayed on the screen. During the start of an app Binder is used
% heavily, but the overhead for our test apps is with 3.9\% almost
% neglectable.

% \begin{table}[ht]
% \begin{center} {\footnotesize
%     \caption{Macro...}
% \begin{tabular}{lccc}
%    & \multicolumn{1}{c}{Android} & \multicolumn{1}{c}{Add-on} & \multicolumn{1}{c}{Overhead}\\\hline
% Application Load Time & 423 & 440 & 3.9\% \\[0ex]
% Address book (read) & - & - & - \%\\[0ex] 
% Open photo in gallery & - & - & - \% \\[0ex]

%   & \multicolumn{1}{c}{Android} & \multicolumn{1}{c}{kprobes only} &
% \multicolumn{1}{c}{with unmarshalling}\\\hline
% SMS & 836.16 & 852.79  & 959.36\\[0ex] % 2.0, 14.7
% IMEI & 449.64 & 474.29 & 537.29\\[0ex] % 5.5, 19.4
% Location & 271.60 & 285.02 & 329.18\\[0ex] % 4.9, 21.2

% \hline
% \end{tabular} }
% \end{center}
% \label{turns}
% \end{table}

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "main"
%%% End: 

intro_andi.tex
In a nutshell, monitoring a system means gaining state information while
it executes, for example, for the purpose of profiling (cf.\
\cite{Yoon2012}) or security hardening (cf.\
\cite{EGC+2010,XSA2012,BGH+2013}), the latter being also our motivation
although our technical contribution is entirely application-agnostic.
%
For Android, efficient monitoring relies on having access to low-level
(and under normal circumstances inaccessible) system events, such as
Linux system calls, for example, that are generated by the running apps.
% %
% for example: an app sends an SMS to number $x$, queries the current
% location, reads the address book, writes a content $y$ to the memory
% card, exchanges information with another app, and so forth.
%
% A prerequisite to efficiently monitor an (Android powered) device, be
% it, for example, for security purposes, for debugging or to measure
% power consumption or performance, is gaining access to normally
% inaccessible, low-level system events and program interactions while the
% system operates; for example: an app sends an SMS to number $x$, queries
% the current location, reads the address book, writes a content $y$ to
% the memory card, exchanges information with another app, and so forth.
%
%The existing Android monitoring approaches % for Android
Existing monitoring approaches are roughly distinguishable as being
either \emph{app-} or \emph{platform-centric}: while the former
basically rewrite and repackage apps under scrutiny in order to
intercept the relevant events and app interactions,
% in order to gather otherwise inaccessible low-level system events that
% are needed for the actual system analysis
%the latter normally intercept interactions with the system by modifying
the latter are usually known to rely on modifications to some key system
components
%key components 
of the Android platform, %itself,
such as its API, virtual machine (Dalvik VM), the various system
services, C/C++ libraries, the OS kernel, and whatever else is needed
for an application at hand. 
%
In this paper, we present a %platform-centric
monitoring add-on for Android, which is platform-centric, yet does
\emph{not} require such comprehensive system modifications.
% ---on the
% contrary, our goal is to provide an easy to install and easy to use solution for 


% In fact, applications are many, such as debugging, analysing power
% consumption or performance (cf.\ \cite{Yoon2012}), but most often lie in
% the context of system security (cf.\ \cite{EGC+2010,XSA2012,BGH+2013}),
% which is also our focus (although the add-on itself is
% application-agnostic).

% we need to wipe device when unlocked, AppGuard wipes data of app when reinstalled



% Dynamic approaches to securing Android running devices often intercept the
% information-flow between apps and the Android OS, in order to gather
% hidden low-level system events needed for their actual analysis; for

% example: a certain app sends an SMS, queries the current
% location, read the address book, writes a file to the memory card,
% exchanges information with other apps, and so forth.
% %
% Those approaches can mainly be distinguished as \emph{app-} or
% \emph{platform-centric}, i.e., while former rewrite and
% repackage untrusted apps in order to redirect security-relevant method
% calls to some kind of embedded or external security monitor,
% % a guard method
% % and repackage 
% %the source or
% %usually the bytecode or native C/++ code of an app to redirect security
% %relevant method calls to an embedded security
% %monitor~, 
% latter %manipulate or
% intercept interactions with the system % between apps and the system
% % ~\cite{EGC+2010}
% by %placing security controls into
% modifying different high- or low-level components of the Android
% software stack, such as the Android API, Dalvik VM, system services, C/++
% shared libraries, kernel, etc.

% Working at the application level, however, exposes
% Aurasium to easy detection or evasion attacks by malicious
% Android applications
%
% changing an app cannot easily kept stealthy and an malicious app aware
% of this could reverse security modifications or
% bypass them.

As app-centric monitoring does not even require root access
%  nor
% modifications 
to the Android platform, it, %, which,
arguably, %gives it
has an edge over the platform-centric approaches described in the
literature, as far as usability goes.
%
For example, AppGuard \cite{BGH+2013}, which manages the modification
and repackaging process of untrusted apps entirely on a user's ``off the
shelf'' phone
%one of the most sophisticated and
%also commerically developed tools,
has been downloaded more than one million times, hinting at the fact
that it is not just used by a select group of domain experts---on the
contrary  \cite{BGH+2013}.
%
However, the ease in usability comes at the expense of some inherent
vulnerabilities, namely that the added security controls and event
interception code are actually being executed within the very same
(Java) app they are meant to keep an eye on.
%
AppGuard redirects method calls in the Java layer by altering method
references in the Dalvik VM, but cannot take note of system calls that
are happening deeper down the stack.
% running in the very same process as the
% target app itself.
% for the user comes not without some inherent,
% generally not solvable %security
% bypass vulnerabilities, as the security controls are running within the
% same process as the target app.
% % if ch
% anges are restricted to application level.
%
Aurasium \cite{XSA2012}, another app-centric monitoring tool, works by
redirecting low-level function pointers away from an app's dynamically
linked Bionic C library to a security monitor, which only gives users
the desired security benefits if the modified app does not provide its
own C library---for whatever reason.
%
% Similarly, AppGuard, which redirects method calls % on Java level
% by altering method references in the Dalvik VM, is unable to monitor
% system calls invoked from native level.
%
Besides, 
% Further challenges for app-centric approaches exist, such as
decompiling and changing %closed source code of
third-party apps usually violates the licence agreement and %also
destroys their original signatures and therefore the ability to automatically update in the future.
% , which amongst other effects results
% in apps not being automatically updateable any longer.
%  where latter, for example, results in
% stopping to receive automatic updates from the google-play
% store.
However, AppGuard solves this particular problem by also taking control
over updates for the ``patched'' apps.
%to watch and apply future updates for rewritten apps.
%

% Furthermore, all data gets lost when re-installing the app
% to embedded security controls.



% AppGuard and Aurasium both disable reflection AppGuard native code
% cannot be analysed, and later loaded native code cannot be secured.


%The main drawback of app-centric approaches is that you actively have to
%monitor an app, which is only possible if you know of its existence (not
%the case for spy apps, like Mobile Spy, StealthGenie, mSpy (those can
%spy even on Facebook Messanger, skype, twitter if device is
%rooted).

% IIC
%While platform-centric approaches require root by definition,


% app-centric rely on reading the source on the phone

%4) Security method: static analysis, dynamic analysis, monitoring, virtualisation

The platform-centric approaches described in the literature (cf.\
\cite{EGC+2010, DBLP:journals/corr/GunadiT13, Bugiel2012, Hornyack2011,
  NKZ2010}) %\TODO{AB: Jan, gibt's da mehr Papers als nur TaintDroid? JCK:
  %Ja, 8,3,10,11 sind platform-centric und werden in \S2
  %aufgelistet.} %normally
generally tie deeper into the platform, and so they need to find ways to
cope with %exposed to
the extensive market fragmentation surrounding the Android platform
(cf.\ \cite{HZF+2012}); that is, they have to make sure that their
changes are ported to various versions of the OS as well as to different
hardware platforms, some of which do not lend themselves well to running
custom-built Android versions, due to closed-source device drivers, for
example.
%
% , on the other hand, face difficulties in
% dealing with the software and hardware fragmentation of the Android
% market \cite{HZF+2012}\TODO{AB@JCK: Das scheint mir keine Quelle zu
%   sein, die die Aussage belegt, sondern in der irgendwas ueber
%   Fragmentation steht, richtig?}, i.e., %depending on their portability,
% they have %great effort
% to maintain their analysis for all the various existing and future
% Android versions and devices.
%
% have a higher barrier to be installed on a user's phone
%
%have more difficulties in becoming widely used, as a) depending on their
%portability, it can be almost impossible to maintain the analysis for
%every
%can include great effort to maintain
%multiple patches to integrate their analysis into the 
%existing and future Android version out there, and b) require the user
%to compile and deploy a custom Android for her specific hardware at
%hand.
%
TaintDroid \cite{EGC+2010} is a pioneering platform-centric tool for
taint flow analysis, which requires modifications beginning from the OS
kernel all the way up to the Dalvik VM.  Although it is being actively
ported to newer versions of Android since its inception, users of
vendor-specific Android releases may find it difficult to use, unless
they are sufficiently experienced to not only compile their own version
of Android, including the TaintDroid changes, but also to make it work
on a hardware platform of their choice.
%
On the other hand, these deep ties into the platform enable analyses
that go beyond what is possible with app-centric tools, since
information can be tracked down to the OS kernel level as is needed for
taint flow analysis.
%
%It can be said, that low-level the approaches are more vulnerable to
%Android software and hardware fragmentation, as
%
%However, the individual dynamic analyses oftentimes “reinvent
%the wheel” to some extent; that is, each conservatively 
%
%to circumvent its built-in security mechanisms
%in order to gather low-level system events needed for their actual
%analysis; for example: a certain app has just sent an SMS, queried the
%current location, read the address book, written a file to the memory
%card, exchanged information with other apps, and so forth.
%“Conserva- tively”, because on the one
%hand side these changes are undertaken, such that the platform still
%runs the installed apps as per usual, but at the same time access is
%granted to the otherwise non-interceptable events that apps produce when
%being run.
%Hence, this introduces a hard dependency between the actual analysis,
%which can be per- formed, e.g., in terms of yet another app, 
%and a custom Android platform that needs to be specifically compiled
%for the hardware at hand. 
%
%
% 1) slightly branded and forked version from different carrier
% 2) running binary closed source drivers.
%
% Needless to say, assuming an analysis would be available as a patch for
% all Android frameworks in the wild, not all users are a) able to access
% the sources of the specific Android software stack including binary
% drivers running on their device, and b) possess the means or
% knowledge to compile and deploy a custom version of Android.



%Needless to say, not all users possess the
%means or knowledge to roll out their own version of Android, and app
%providers lack the capacity to cover a fragmented market of devices,
%some of which are less easy to modify than others.

\textbf{Our approach}, conceptually, is a combination of the advantages
of app- and platform-centric monitoring; that is, to offer a software
add-on that can be loaded even into a currently running Android system,
yet is able to trace app interactions all the way down to the OS kernel
level.
% To solve the matter of intercepting low-level
% system events once and for most dynamic app security analyses, we have
% developed an add-on for the Android platform that does not require any
% changes to neither the framework nor the apps themselves.
%a kernel module whose main task it is to
%intercept low-level system events and to forward them to a user-space
%client.
% While other approaches normally follow the information flow be-
%tween apps and the system, and then modify all the involved key system
%services along its way, such as LocationManager, Telepho- nyManager,
%etc., we gather all information centrally within the kernel.
%To that end, we have almost fully reverse engineered Android’s binder,
%which is Android’s main kernel module to pass information from one app
%or service to another.
% It can be plugged to the running system and, therefore, needs no
% recompiling of the entire platform.
%
Technically, this functionality is mostly provided by an OS kernel
module, which uses Linux' own kernel debugging facility (called
\code{kprobes}\footnote{https://www.kernel.org/doc/Documentation/kprobes.txt})
to intercept system calls (see also \S\ref{sec:droidTracer}).  As such,
our approach is strictly platform-centric and does not just apply to
specifically prepared apps, but everything that is executed on the
system.  %Moreover,
In fact, we are able to intercept Android's own inter process
communication (IPC) mechanism called
Binder,\footnote{http://developer.android.com/reference/android/os/Binder.html}
and can therefore gather information on almost all possible interactions
between apps and the Android platform or via the platform.
%
However, as platform-centric approach, we too require root privileges,
if only to load the module.  This may seem restrictive, but one should
keep in mind that it has become somewhat common practice to obtain root
privileges on unlocked devices in order to use custom ROMs like
CyanogenMod,\footnote{http://www.cyanogenmod.org} install utilities like
firewalls or packet filters, or to be able to edit system files.
%
Our add-on is available as open source software under the moniker
DroidTracer from \url{http://kuester.multics.org/DroidTracer/}.

In the remainder, we will shed some light on DroidTracer's internals
(\S\ref{sec:droidTracer}), how it may be put to good use
(\S\ref{sec:rv}), and discuss its performance overhead
(\S\ref{sec:exps}).  Some conclusions are given in \S\ref{sec:conc}.
% by measuring the
% execution time of its various constituents as well as that of an example
% application built on top of it (see \S\ref{sec:rv}).


%  %and apps
% when DroidTracer is active.


% Moreover, one does not need to recompile or even replace the entire
% Android stack, for replacing the kernel, which is normally done to gain
% root access.  For common devices, kernels are even readily available on
% the net, maintained by a worldwide network of Android enthusiasts, or
% can be specifically compiled for a device on an ordinary PC, much like
% the standard Linux kernel.\footnote{cf.\
%   http://source.android.com/source/building-kernels.html}


% , centrally from
% within the OS kernel.
% At its heart lies a kernel module that makes use of kprobes
% \cite{kprobes} and allows to intercept system calls, including Android's
% internal IPC mechanism, called Binder. This way we gather information
% about almost all possible interactions of apps with the Android OS
% centrally within the kernel.
%

% On such a low-level of abstraction, however, the high-level semantics of
% system events and IPC calls is usually lost.  To see this, think of an
% app that wants to send an SMS message to a specific number.  It will
% invoke a number of API functions with according arguments, including the
% message's content, number of receiver, etc.\ which will eventually pass
% the Binder and be received either by a system service or a helper app.
% On the Binder-level, however, superfluous information such as the
% invoked functions' names, their arguments, etc.\ are either completely
% removed or compactly encoded to streamline communication.  Hence, to
% restore the original function call along with its arguments, our module
% forwards the intercepted information to a user-space client, which first
% uses reflection in order to obtain a function's signature, i.e., name
% and data types of arguments (if any), and then invokes the very same
% demarshalling algorithms that Android uses internally to restore the
% arguments at the other end.

% %  function call arguments that
% % correspond to an event are compactly encoded, and function call names
% % not transmitted.  To interpret the raw data, our module calls a
% % user-space client, whose task it is to reassemble and restore the
% % corresponding method invocations, including the original Java function
% % call arguments. %, for almost every Android version that exists.
% % %
% % Basically, it uses reflection to obtain the signature of the callee and
% % then follows the very same steps Android's uses internally to demarshall
% % the information at the other


% This is possible by using reflection to obtain the signature of the callee 

% the very same demarshalling methods that the
% Android platform uses internally for that purpose and to 

% This is achieved by accessing the same version specific demarshalling
% methods as the Android API and by mimicking the natural demarshalling
% process, i.e., identifying the original method signature by Java
% reflection and reading the method parameters in the correct order from
% the raw stream.\TODO{AB: Letzten Satz versteht kein Mensch.}

%We use a minified netlink library compiled into the app, to
%bidrectionally and efficiently communicate with the kernel module.
%

% Also, replacing a device's
% kernel to achieve this,

% As this process is carrier specific
% there is no single process, for example, Google turned off module
% support in its kernels since Android version 4.3.  Nevertheless, one can
% bootthis do not hinder to boot once a flash a rebaked kernel to one's
% device, as this can be done independently of the Android framework on
% top.

% %As such, our module gives a very detailed view on a running app’s
% %behaviour; that is, provides the user with a trace of low-level
% %events. While loading a kernel module still requires root privileges, so
% %does replacing an off-the- shelf Android platform with a custom-built
% %one. The entry barrier to our solution is, therefore, comparatively low,
% %since no further system modifications are necessary at all in order to
% %be used on almost any Android-device in existence.

% The second major part of our contribution is an application of this
% module, in the following referred to as DroidTracer, for monitoring and
% formally reasoning about app behaviour. It can be considered a novel
% form of behavioural detection, where (security) policies are specified
% in a formal (first-order) logic that was recently introduced in
% \cite{BKV2013}. Unlike other specification languages used in this area,
% this one, in our opinion, bears the advantage that it not only allows
% users to specify a certain order of events (that may be regarded as
% suspicious), but also to assert properties of the associated data; for
% example: which number was an SMS sent to, what was its content, which
% domain did an email come from, which contact was written to the
% addressbook, and so forth. Moreover, since the language also features
% quantification and function symbols, it is expressively equivalent to
% Turing machines and, arguably, sufficient even for non-trivial policies.
% What is more, our corresponding empirical evaluation shows that, unlike
% similar analyses for Android, the computational overhead of this
% low-level event interception is almost negligible. In contrast, the
% overhead of our behavioural detection module depends on the complexity
% of the monitored policy and the number of apps being monitored at a
% given time—ranging from almost negligible to not practically feasible,
% at least in intuitive terms.

% To summarise, This paper makes two important contributions.
% %
% \begin{itemize}
% \item A platform add-on that is capable to intercept interactions
%   between apps and the Android OS. It has high portability and has a
%   lower barrier for user's to install, as no recompiling of the entire
%   framework is necessary. In the worst case, the kernel needs to be
%   replaced or temporarily rebooted.
% \item A novel form of behavioural detection to monitor and formally
%   reason about app behaviour ...
% \end{itemize}

% no polling
% netlink
% find example for platform policy, IIC, etc.

% our policy language can also do privilege escalation, etc.

% Contributions are:
% * requires root as all platform-centric approaches, but no modifications 
%   to the Android stack under the assumption the kernel was compiled with
%   module support and kprobes enabled.
%   The kernel can be easily replaced, or temporarily rebooted with a different one   
% * our approach does not require to be maintained for different Android versions, 
%   as it uses specific mechanisms of the Android version our approach is applied to
% * powerful event stream analysis based on low-level events, that covers ...

%%% Local Variables: 
%%% mode: latex
%%% TeX-master: "main"
%%% End: 

main.tex
% TEMPLATE for Usenix papers, specifically to meet requirements of
%  USENIX '05
%  originally a template for producing IEEE-format articles using LaTeX.
%   written by Matthew Ward, CS Department, Worcester Polytechnic Institute.
% adapted by David Beazley for his excellent SWIG paper in Proceedings,
%   Tcl 96
% turned into a smartass generic template by De Clarke, with thanks to
%   both the above pioneers
% use at your own risk.  Complaints to /dev/null.
% make it two column with no page numbering, default is 10 point

% Munged by Fred Douglis <douglis@research.att.com> 10/97 to separate
% the .sty file from the LaTeX source template, so that people can
% more easily include the .sty file into an existing document.  Also
% changed to more closely follow the style guidelines as represented
% by the Word sample file. 

% Note that since 2010, USENIX does not require endnotes. If you want
% foot of page notes, don't include the endnotes package in the 
% usepackage command, below.

% This version uses the latex2e styles, not the very ancient 2.09 stuff.
\documentclass[letterpaper,twocolumn,10pt]{article}

\usepackage{enumitem}
\setlist{nolistsep}
\usepackage{todo}
\usepackage{float}
\usepackage{booktabs,dcolumn,caption}
\usepackage{xcolor}
\usepackage{colortbl}
\usepackage{usenix,epsfig,endnotes}
\usepackage{hyperref}

\colorlet{tablerowcolor}{gray!10} % Table row separator colour = 10% gray
\newcommand{\rowcol}{\rowcolor{tablerowcolor}} %
\newcommand{\code}[1]{\textsf{#1}}
\newcommand{\tred}[1]{{\color{red}#1}}


\begin{document}

% https://www.usenix.org/sites/default/files/atc14cfp_092013.pdf
% Short papers:
%
% Authors with a contribution for which a full paper is 
% not appropriate may submit short papers of at most 6 pages with the 
% same formatting guidelines as full papers. Examples of short paper 
% contributions include:
% * Original or unconventional ideas at a preliminary stage of development
% * The presentation of interesting results that do not require a fulllength paper, such as negative results or experimental validation
% * Advocacy of a controversial position or fresh approach

% Our contribution: Bleeding edge Runtime verifaction for Android (we
% have RV contribution that now works on Android). We could mention this
% in the conclusion as understatement (we have a bigger master plan). 

%don't want date printed
\date{}

%make title bold and 14 pt font (Latex default is non-bold, 16 pt)
%\title{\Large \bf A modular system-centric approach to monitoring Android-apps}
% \title{\Large \bf A platform-centric add-on for monitoring Android-apps}

% wenn man nen kernel modul hat, hat man keine standardisierte
% kommunikation vom kernel in den user-space (eigentlich show stopper)

% andere anwendungen haben genau dieses problem: ansonsten kann man nur
% das framework veraendern (das ist die prequiste), siehe  (cf., Alwen, TaintDroid)

% das ist das grosse problem


% was ist das Problem? Und dann die loesung dazu; dann erst
% wertgeschaetzt; oder was waere wenn es die lsg nicht gaebe; warum
% haben wir die einzige richtige lsg gewaehlt

% im binder kodiert, damit die kommunikation schneller ist

%\title{\Large \bf An Add-On for the Platform-Centric Monitoring of Android Apps}
%\title{\Large \bf Truly Modular, Platform-Centric Monitoring of Android Apps}
\title{\Large \bf Platform-Centric Android Monitoring---Modular and Efficient}

%for single author (just remove % characters)
\author{
{\rm Jan-Christoph K\"uster}\\
NICTA and Australian National University
\and
{\rm Andreas Bauer}\\
% Technische Universit\"at M\"unchen and NICTA
TU Munich, Germany, and NICTA
% copy the following lines to add more authors
% \and
% {\rm Name}\\
%Name Institution
} % end author

%\thanks{NICTA is funded by the Australian Government
%    as represented by the Department of Broadband, Communications and
%    the Digital Economy and the Australian Research Council through the
%    ICT Centre of Excellence program.}

\maketitle

% Use the following at camera-ready time to suppress page numbers.
% Comment it out when you first submit the paper for review.
\thispagestyle{empty}

\subsection*{Abstract}
\input{abstract_andi}

\section{Introduction}
\label{sec:intro}
\input{intro_andi}

% Features\endnote{Remember to use endnotes, not footnotes!} galore, plethora of promises.\\

%\section{DroidTracer}
% \section{Design and Implementation}
% \section{The Ins and Outs of Event Interception}
\section{How It All Works}
\label{sec:droidTracer}
\input{droidTracer}

%\section{MonitorMe}
%\label{sec:monitorMe}
%\input{monitorMe}

%\section{Platform-Centric Runtime Verification}
%\section{What You Can Do With It}
%\section{A User's Perspective}
\section{Use Cases---Runtime Verification}
\label{sec:rv}
\input{application}

% \section{Experiments}
%\section{How Efficient Is It?}
\section{Performance Overhead}
\label{sec:exps}
\input{experiments}

% \section{Related work}
% \label{sec:relatedWork}
% \input{related_work}

\section{Conclusions and Future Work}
\label{sec:conc}
\input{conclusion}


\section{Acknowledgments}

NICTA is funded by the Australian Government as represented by the
Department of Broadband, Communications and the Digital Economy and the
Australian Research Council through the ICT Centre of Excellence
program.

{\footnotesize \bibliographystyle{acm}
\bibliography{bibliography}}

%\theendnotes

\end{document}








main.bbl
\begin{thebibliography}{10}

\bibitem{BGH+2013}
{\sc Backes, M., Gerling, S., Hammer, C., Maffei, M., and von Styp-Rekowsky,
  P.}
\newblock App{G}uard - {F}ine-grained policy enforcement for untrusted
  {A}ndroid applications.
\newblock Tech. Rep. A/02/2013, Saarland University, 2013.

\bibitem{BKV2013}
{\sc Bauer, A., K{\"u}ster, J.-C., and Vegliach, G.}
\newblock From propositional to first-order monitoring.
\newblock In {\em RV\/} (2013), vol.~8174 of {\em LNCS}, Springer.

\bibitem{Bugiel2012}
{\sc Bugiel, S., Davi, L., Dmitrienko, A., Fischer, T., Sadeghi, A.-R., and
  Shastry, B.}
\newblock Towards taming privilege-escalation attacks on {A}ndroid.
\newblock In {\em NDSS\/} (2012), The Internet Society.

\bibitem{Chen:2009:PTS:1532891.1532921}
{\sc Chen, F., and Ro\c{s}u, G.}
\newblock Parametric trace slicing and monitoring.
\newblock In {\em TACAS\/} (2009), vol.~5505 of {\em LNCS}, Springer.

\bibitem{EGC+2010}
{\sc Enck, W., Gilbert, P., Chun, B.-G., Cox, L.~P., Jung, J., McDaniel, P.,
  and Sheth, A.~N.}
\newblock Taintdroid: an information-flow tracking system for realtime privacy
  monitoring on smartphones.
\newblock In {\em OSDI\/} (2010), USENIX.

\bibitem{EOMC2011}
{\sc Enck, W., Octeau, D., McDaniel, P., and Chaudhuri, S.}
\newblock A study of {A}ndroid application security.
\newblock In {\em USENIX Security Symposium\/} (2011), USENIX.

\bibitem{FFC+2011}
{\sc Felt, A.~P., Finifter, M., Chin, E., Hanna, S., and Wagner, D.}
\newblock A survey of mobile malware in the wild.
\newblock In {\em SPSM\/} (2011), ACM.

\bibitem{DBLP:journals/corr/GunadiT13}
{\sc Gunadi, H., and Tiu, A.}
\newblock Efficient runtime monitoring with metric temporal logic: A case study
  in the {A}ndroid operating system.
\newblock {\em CoRR abs/1311.2362\/} (2013).

\bibitem{HZF+2012}
{\sc Han, D., Zhang, C., Fan, X., Hindle, A., Wong, K., and Stroulia, E.}
\newblock Understanding {A}ndroid fragmentation with topic analysis of
  vendor-specific bugs.
\newblock In {\em WCRE\/} (2012), IEEE.

\bibitem{Hornyack2011}
{\sc Hornyack, P., Han, S., Jung, J., Schechter, S., and Wetherall, D.}
\newblock These aren't the droids you're looking for: retrofitting {A}ndroid to
  protect data from imperious applications.
\newblock In {\em CCS\/} (2011), ACM.

\bibitem{NKZ2010}
{\sc Nauman, M., Khan, S., and Zhang, X.}
\newblock Apex: extending android permission model and enforcement with
  user-defined runtime constraints.
\newblock In {\em ASIACCS\/} (2010), ACM.

\bibitem{DBLP:journals/tissec/Schneider00}
{\sc Schneider, F.~B.}
\newblock Enforceable security policies.
\newblock {\em ACM Trans. Inf. Syst. Secur. 3}, 1 (2000).

\bibitem{XSA2012}
{\sc Xu, R., Sa\"{\i}di, H., and Anderson, R.}
\newblock Aurasium: practical policy enforcement for {A}ndroid applications.
\newblock In {\em USENIX Security Symposium\/} (2012), USENIX.

\bibitem{Yoon2012}
{\sc Yoon, C., Kim, D., Jung, W., Kang, C., and Cha, H.}
\newblock {AppScope}: Application energy metering framework for {A}ndroid
  smartphone using kernel activity monitoring.
\newblock In {\em USENIX ATC\/} (2012), USENIX.

\bibitem{ZJ2012}
{\sc Zhou, Y., and Jiang, X.}
\newblock Dissecting {A}ndroid malware: Characterization and evolution.
\newblock In {\em SSP\/} (2012), IEEE.

\end{thebibliography}
