Fachbereich 3 Informatik. Bachelorarbeit. über das Thema

Transkript

1 Fachbereich 3 Informatik Bachelorarbeit über das Thema Modellierung von Informationen zur Interprozesskommunikation in Android-Anwendungen für Datenflussdiagramme Autor: Florian Thomas fthomas@tzi.de Matrikelnummer: Erstgutachter: Zweitgutachter: Dr. Karsten Sohr Prof. Dr. Ute Bormann Abgabedatum:

2 INHALTSVERZEICHNIS I Inhaltsverzeichnis I Inhaltsverzeichnis II II Abbildungsverzeichnis III Listing-Verzeichnis IV Abkürzungsverzeichnis IV V VII 1 Einleitung Ziel der Arbeit Vorgehen Kapitelübersicht Grundlagen Informationssicherheit Android Interprozesskommunikation Bedrohungsmodell Unerlaubtes Empfangen von Intents Unerlaubtes Senden von Intents Entwurf der Benchmark Anwendungen Activities Intents Pending Intents Services Statische Analyse IDE-Probleme Verwendete Tools Dare Epicc Android Threat Modeling Platform der Universität Bremen Fazit Validierung und Evaluation von Epicc Benchmarks Auswertung Einführung der Erweiterung von Epicc Anpassungen des Datenmodells Implementierungsdetails Explizite Intents Senden impliziter Intents Empfangen impliziter Intents Evaluation der Implementierung Testdurchführung Android-Anwendungen für Datenflussdiagramme Seite II

3 INHALTSVERZEICHNIS Testauswertung Vollständigkeit der Daten im Datenflussdiagramm Fazit und Ausblick 55 6 Quellenverzeichnis 57 Android-Anwendungen für Datenflussdiagramme Seite III

4 VERZEICHNISSE II Abbildungsverzeichnis Abb. 1 Auflistung aller Rechte, die von der Android Anwendung (App) benötigt werden Abb. 2 Auswahl einer passenden App für eine Videodatei Abb. 3 Beispielgraph zum IDE-Problem (Quelle: [Bodb]) Abb. 4 Übersicht zum Analyseablaufs Abb. 5 UML-Diagramm des Modells der Threat Modeling Platform (Ausschnitt) Abb. 6 UML-Diagramm des neu entworfenen Modells (Ausschnitt) Abb. 7 Erzeugtes Datenflussdiagramm zu Adobe Reader Abb. 8 Datenflussdiagramm zur App StartActivity Abb. 9 Datenflussdiagramm zur App StartActivity Android-Anwendungen für Datenflussdiagramme Seite IV

5 VERZEICHNISSE III Listing-Verzeichnis Lst. 1 Beispielcode zum IDE-Problem (Quelle: [Bodb]) Lst. 2 StartActivity - relevanter Quellcode (MainActivity) Lst. 3 StartActivity - Epicc Ausgabe Lst. 4 StartActivity2 - relevanter Quellcode (MainActivity) Lst. 5 StartActivity2 - Epicc Ausgabe Lst. 6 StartLinkedActivity - relevanter Quellcode (StartLinkedActivity) Lst. 7 StartLinkedActivity - Epicc Ausgabe Lst. 8 StartLinkedActivity2 - relevanter Quellcode (StartLinkedActivity21).. 22 Lst. 9 StartLinkedActivity2 - Epicc Ausgabe Lst. 10 SendBroadcast - relevanter Quellcode (SendBroadcastActivity) Lst. 11 SendBroadcast - Epicc Ausgabe Lst. 12 SendBroadcastWithPermission - relevanter Quellcode (MainActivity). 24 Lst. 13 SendBroadcastWithPermission - Epicc Ausgabe Lst. 14 BroadcastReceiver - relevanter Quellcode (Manifest) Lst. 15 BroadcastReceiver - Epicc Ausgabe Lst. 16 BroadcastReceiver2 - relevanter Quellcode (MainActivity) Lst. 17 BroadcastReceiver2 - Epicc Ausgabe Lst. 18 BroadcastReceiver3 - relevanter Quellcode (BroadcastReceiver3) Lst. 19 BroadcastReceiver3 - Epicc Ausgabe Lst. 20 BroadcastReceiverWithPermission - relevanter Quellcode () Lst. 21 BroadcastReceiver3 - Epicc Ausgabe Lst. 22 BroadcastReceiverWithPermission2 - relevanter Quellcode (Manifest). 29 Lst. 23 BroadcastReceiverWithPermission2 - Epicc Ausgabe Lst. 24 RandomIntent - relevanter Quellcode (MainActivity) Lst. 25 RandomIntent - Epicc Ausgabe Lst. 26 ViewImageViaIntent - relevanter Quellcode (ViewImageViaIntent) Lst. 27 ViewImageViaIntent - Epicc Ausgabe Lst. 28 PendingIntent - relevanter Quellcode (activity) Lst. 29 PendingIntent - Epicc Ausgabe Lst. 30 PendingIntent2 - relevanter Quellcode (MainActivity) Lst. 31 PendingIntent2 - Epicc Ausgabe Lst. 32 StartService - relevanter Quellcode (StartService) Lst. 33 StartService - Epicc Ausgabe Lst. 34 StartBinder - relevanter Quellcode (BindingActivity) Lst. 35 StartBinder - Epicc Ausgabe Lst. 36 AIDL - relevanter Quellcode (MainActivity) Lst. 37 AIDL - Epicc Ausgabe Lst. 38 AidlClient - relevanter Quellcode (MainActivity) Lst. 39 AidlClient - Epicc Ausgabe Lst. 40 AidlServer - relevanter Quellcode (IRemote.aidl) Lst. 41 AidlServer - relevanter Quellcode (ArithmeticService) Lst. 42 AidlServer - Epicc Ausgabe Lst. 43 Epicc - Manifest Lst. 44 Epicc - Einleitung der Kommunikationsauflistung Android-Anwendungen für Datenflussdiagramme Seite V

6 VERZEICHNISSE Lst. 45 Epicc - Senden eines expliziten Intents Lst. 46 Epicc - aidl Service Lst. 47 Epicc - Senden eines impliziten Intents Lst. 48 Epicc - dynamischer Receiver mit Berechtigung Lst. 49 Epicc - dynamischer Receiver Android-Anwendungen für Datenflussdiagramme Seite VI

7 VERZEICHNISSE IV Abkürzungsverzeichnis AIDL Android Interface Description Language API Application Programming Interface APK Android Package App Android Anwendung DFD Datenflussdiagramm DVM Dalvik Virtual Machine GUI Graphical User Interface IDE Interprocedural Distributive Environment IPC Inter-process communication IFDS interprocedural, finite, distributive, subset PNG Portable Network Graphics TZI Technologie-Zentrum Informatik Android-Anwendungen für Datenflussdiagramme Seite VII

8 Kapitel 1 Einleitung 1 Einleitung In den letzten zehn Jahren haben Smartphones einen gewaltigen Sprung in ihrer Entwicklung gemacht und sind für jeden erschwinglich geworden. Fast jeder besitzt mindestens ein solches Gerät und ist somit immer erreichbar, was zur Folge hat, dass sie kaum noch aus dem Alltag wegzudenken sind. Für die Besitzer von Smartphones und Tablets ergibt sich deshalb die Frage nach der Sicherheit ihres Gerätes und der darauf gespeicherten persönlichen oder beruflichen Daten. Bei dieser Betrachtung ist besonders das Android Betriebssystem relevant, da es nicht nur in Smartphones, sondern auch in Tablets, Wearables und Autos Anwendung findet. Darüber hinaus ist es mit einem Marktanteil von 70 Prozent im dritten Quartal des Jahres 2014 innerhalb Europas vertreten und somit das dort am weitesten verbreitete Betriebssystem für mobile Geräte [Mil]. Durch die hohe Verbreitung des Betriebssystems entsteht ein großer Anreiz, Apps zu entwickeln, die ihre Nutzer ausspionieren und die Daten über das Internet weitergeben, um dort verkauft oder ausgenutzt zu werden. Aus diesem Grunde ist es wichtig, sich mit dem Thema zu beschäftigen und zu versuchen, solche Apps zu identifizieren, um mögliche Schäden zu vermeiden. 1.1 Ziel der Arbeit Ziel dieser Arbeit ist es, Interprozesskommunikationen in Android-Anwendungen aufzudecken und so zu modellieren, dass sie von der gegebenen Threat Modeling Platform der Universität Bremen übernommen und als Kanten in einem Datenflussdiagramm dargestellt werden können. Die Darstellung soll dabei Kommunikationen über sowohl einzelne als auch mehrere Apps hinweg erfassen können. Die extrahierten Datenflussdiagramme können später zur Analyse der IT-Sicherheit genutzt und entsprechend weiterverarbeitet werden. Dazu wird ein Datenmodell entworfen, welches das bereits existierende der Threat Modeling Platform erweitert und alle neu gesammelten Informationen darstellen kann. Um diese zu erhalten, sollen mit einem geeigneten Werkzeug statische Datenflussanalysen durchgeführt werden. Die erhaltenen Ergebnisse dieser Analysen werden anschließend zur Erweiterung des Datenmodells genutzt. Dabei bezieht die Analyse möglichst viele Komponenten der Apps sowie deren Kommunikationsmöglichkeiten im Android Betriebssystem mit ein. Die gefundenen Kommunikationen sollen im abschließend generierten Datenflussdiagramm als Kante dargestellt werden. Abschließend soll das Ergebnis dieser Arbeit evaluiert werden, um zu bestätigen, dass alle Android-Anwendungen für Datenflussdiagramme Seite 1

9 Kapitel 1 Einleitung erfassbaren Informationen korrekt verarbeitet und in das neue Modell überführt worden sind. 1.2 Vorgehen Das Herangehen an die Arbeit beginnt mit dem Evaluieren des vorhandenen Tools Epicc, das zur Analyse der Apps genutzt werden soll. Das Programm wird an der Pennsylvania State University entwickelt [?] und soll zur Darstellung der Kanten Interprozesskommunikationen innerhalb von Apps finden. Dazu werden verschiedene Apps implementiert, die einzelne oder später auch mehrere Kommunikationsmöglichkeiten besitzen. Anschließend wird Epicc mit diesen Apps getestet, um festzustellen, ob und welche Fälle erkannt werden und wie viel Informationen gesammelt werden. Sollten diese nicht ausreichen, wird das Tool so angepasst, dass weitere Informationen ausgegeben werden können. Diese sollen anschließend so gefiltert werden, dass nur die Hinweise auf mögliche Kommunikationsvorgänge übrig bleiben. Diese werden in ein neu entwickeltes Zwischenformat gebracht, das von der Threat Modeling Platform verarbeitet werden kann, um die Interprozesskommunikationen darstellen zu können. Die Übernahme neuer von Epicc gesammelter Informationen durch die Anwendung setzt eine Erweiterung des bestehenden Datenmodells und eine Veränderung der zu Grunde liegenden Architektur voraus. Im letzten Schritt muss die vorgenommene Implementierung evaluiert werden, um festzustellen, ob die von Epicc erhobenen Daten vollständig und korrekt übernommen worden sind. Der Benchmark wird zur Evaluation der eigenen Implementierung um Apps aus dem Google Play Store erweitert werden. 1.3 Kapitelübersicht Der Aufbau der Arbeit gliedert sich im Anschluss an die Einleitung in ein Grundlagenkapitel, das dem Leser das nötige Wissen vermittelt, um im folgenden Kapitel der Beschreibung des Benchmarks, der Tools und insgesamt dem Verlauf der Arbeit folgen zu können. Im Anschluss an die Evaluation des Tools Epicc mit dem Benchmark wird das neue Datenmodell beschrieben und nachfolgend werden Implementierungsdetails zu dem in dieser Arbeit entwickelten Tool genauer ausgeführt. Abschließend wird die neue Implementierung ebenfalls evaluiert und es wird ein Fazit gezogen sowie ein Ausblick für die weitere Bearbeitung des Problems gegeben. Android-Anwendungen für Datenflussdiagramme Seite 2

10 Kapitel 2 Grundlagen 2 Grundlagen Dieses Kapitel erklärt die Grundlagen, die zum Verständnis der Arbeit wichtig sind. Begonnen wird mit dem Begriff Informationssicherheit (Abschnitt 2.1), gefolgt von einer Übersicht zum Android Betriebssystem und seinen Komponenten (Abschnitt 2.2). Nachfolgend werden die Kommunikationsmöglichkeiten von Android detailliert beschrieben (Abschnitt 2.3) und daraus abgeleitete Angriffsszenarien (Abschnitt 2.4) und Benchmarks (Abschnitt 2.5) als Vorbereitung auf das Kapitel 3 kurz genannt. Abschließend werden verwendete Methoden (Abschnitt 2.6 und 2.7) und Tools (Abschnitt 2.8) erläutert. 2.1 Informationssicherheit Das Thema dieser Arbeit ordnet sich dem Oberthema der Informationssicherheit unter, hier mit Bezug auf Android-Anwendungen. Der Begriff Sicherheit besitzt in diesem Umfeld zwei Bedeutungen, die beispielsweise im Englischen durch verschiedene Begriffe voneinander abgegrenzt sind. Zum einen existiert der Ausdruck Safety, der Aussagen über die Funktions- und Betriebssicherheit macht, im Folgenden jedoch von geringerer Wichtigkeit ist. Zum anderen der Begriff Security, der die richtige Bedeutung des Wortes für diesen Kontext wiedergibt. Er beschreibt die Sicherung eines IT-Systems gegen Angriffe oder unabsichtliche Fehlbedienung [BSG] einer Anwendung. Dies geschieht im Rahmen dieser Arbeit insoweit, dass die Analyse bestehender Apps dem Aufdecken von Schwachstellen oder ungewolltem Schadcode dienen kann. Es wird somit vorrangig ein Schutz für die Apps und ihre Daten und nicht für das gesamte System vorgestellt. 2.2 Android Um mögliche Schwachstellen in einem Android System aufdecken zu können, muss man die Funktionsweise, Zusammensetzung und Kommunikationsmöglichkeiten des Systems selbst und seiner Apps verstehen. Dazu wird im Folgenden ein kurzer Überblick über die genannten Aspekte gegeben. Android ist ein von der von Google gegründeten Open Handset Alliance [OHA] entwickeltes Betriebssystem, das auf Linux basiert, dessen Quellcode offen einsehbar ist und das vorrangig für Smartphones verwendet wird. Viele Hersteller nutzen eine für die eigenen Ansprüche angepasste Version des Betriebssystems auf ihren Geräten und statten diese mit einer Auswahl an meist selbst entwickelten Apps aus. Android-Anwendungen für Datenflussdiagramme Seite 3

11 Kapitel 2 Grundlagen Die auf dem Smartphone installierbaren Apps sind in der Programmiersprache Java geschrieben und werden zusätzlich von vielen Drittanbietern auf einem der dafür vorgesehenen Marktplätze angeboten. Dazu gehört unter anderem der offizielle Marktplatz Google Play Store [Gooc] oder der Amazon App-Shop [Ama]. Neben dem oft kostenlosen Erwerb einer App in diesen Shops besteht außerdem die Möglichkeit, sie als Installationsdatei (Android Package (APK)) direkt aus dem Internet herunterzuladen, beispielsweise von einem Blog, auf dem ein Student seine selbst geschriebene App vorstellt. Mit der großen und unüberschaubaren Auswahl an Anbietern von Apps kommt jedoch auch das Risiko, dass nicht jede vollständig auf Schadsoftware untersucht werden kann, bevor sie auf das Gerät gelangt. Eine solche Untersuchung ist zum Teil sehr zeitaufwendig und es existieren noch keine Analysen, die eine hundertprozentige Garantie für die Sicherheit einer App geben können. Aus diesem Grund gibt es im Android Betriebssystem Mechanismen, die die Daten des Nutzers und die Apps untereinander schützen sollen. Als erste Schutzmaßnahme läuft eine App in einer virtuellen Umgebung (Dalvik Virtual Machine (DVM)), in der sie nur Zugriff auf die eigenen Daten hat, da allgemein angenommen wird, dass jede App schädlich ist. Um diese Möglichkeiten zu erweitern, muss ein Entwickler im Manifest seiner App Rechte definieren, die er erhalten möchte, wie zum Beispiel den Zugriff auf das Internet. Jede App benötigt ein solches Manifest, da dieses wie ein Inhaltsverzeichnis funktioniert. Die meisten Komponenten der App werden dort aufgelistet und weitere Informationen, wie die Version der App, angegeben. Der Nutzer bekommt diese angeforderten Rechte vor der Installation angezeigt und muss entscheiden, ob er der App soweit vertraut, dass er diese Anfragen bestätigen möchte, ansonsten wird der Vorgang abgebrochen. Durch eine sinngemäße Gruppierung von ähnlichen Rechten, wie zum Beispiel dem Durchsuchen von auf dem Gerät gespeicherten Bildern und dem Auslesen der SD-Karte des Telefons zur Obergruppe Fotos/Medien/Dateien, soll die Übersichtlichkeit der Auflistung bewahrt werden (siehe Abbildung 1). Sollte eine App beispielsweise zur Bearbeitung von Fotos nach dem Recht fragen, das Internet nutzen zu dürfen, könnte dies ein Indiz dafür sein, dass die App nicht seriös ist. Das ist allerdings nicht sicher und oftmals ist die Liste an Berechtigungen zu umfangreich oder zu allgemein, sodass der Nutzer keine Lust hat, sie vollständig zu lesen oder sich ausreichend zu informieren und sie stattdessen einfach bestätigt. Hinzu kommt, dass durch Ausnutzung von Kommunikationsfunktionen (Interprozesskommunikation, siehe Kapitel 2.3) zwischen Apps, die das Betriebssystems bereitstellt, der Mechanismus der Berechtigungsvergabe nicht mehr aussagekräftig genug ist. Sollte der Nutzer sich beispielsweise eine App zum Anzeigen von Fotos und eine zum Surfen im Android-Anwendungen für Datenflussdiagramme Seite 4

12 Kapitel 2 Grundlagen Abbildung 1: Auflistung aller Rechte, die von der App benötigt werden Web installieren, so benötigt erstere Rechte zum Öffnen von auf dem Smartphone gespeicherten Fotos und letztere nur das Recht, Daten in das Internet zu senden und von dort zu empfangen. In bestimmten Fällen reicht das allerdings schon aus, da die Foto App ihre Daten an die Internet App weitergeben kann, welche diese verschickt. Das genannte Beispiel zeigt nur eine von vielen Möglichkeiten, die Interprozesskommunikation auszunutzen, da neben der unerwünschten Kommunikation zwischen zwei Apps auch intern verschickte Nachrichten mitgelesen, gestohlen oder ersetzt werden können. Ein Erkennen von unerlaubten Kommunikationen in diesem Kontext erfordert folglich eine genauere Einsicht in die verwendeten Komponenten. Zu den wichtigsten Komponenten gehören Activities, Services und Broadcast Receiver, deren Funktionalität im Folgenden kurz beschrieben werden soll. Content Provider werden an dieser Stelle vernachlässigt, da sie nicht in der Lage sind, Nachrichten (Intents) zu verschicken oder zu empfangen. Intents sind Pakete, die Angaben zum Empfänger sowie Daten für diesen enthalten und für die Kommunikation in Android genutzt werden (Intents werden in Kapitel 2.3 genauer beschrieben). Eine Anwendung besteht meist aus mehreren Activities [Gooa], die für die Darstellung einer für den Nutzer sichtbaren Bildschirmoberfläche (Graphical User Interface (GUI)) Android-Anwendungen für Datenflussdiagramme Seite 5

13 Kapitel 2 Grundlagen und deren Funktionalität zuständig sind. Je Funktion existiert meist eine Activity, zum Beispiel für das Anzeigen eines Fotos. Ein Knopfdruck auf teilen würde daraufhin eine neue Activity starten, die die gewünschte Aufgabe bearbeiten kann und nicht zu der aktuellen App gehören muss. Des Weiteren stellt Android Services zur Verfügung [Goof], die im Hintergrund laufend Aufgaben, zum Beispiel einen Download für eine App, erledigen können. Wenn dies vom Entwickler absichtlich oder teils unabsichtlich so festgelegt wird, kann der Service einer App auch von anderen genutzt werden, indem die Schnittstelle zur Nutzung des Services für fremde Apps freigegeben wird. Die Definition eines Services kann im Code oder auf der Grundlage einer AIDL-Datei (Android Interface Description Language) erfolgen, die knapp vorgibt, welche Funktionalität mindestens vom Service angeboten werden muss. Aus der AIDL-Datei kann direkt Code generiert werden, was die Implementierung eines Services über mehrere Apps hinweg vereinfacht. Neben den auf unbestimmte Dauer laufenden Hintergrundservices gibt es gebundene Services, die ebenfalls eine Aufgabe für eine andere Komponente erfüllen, deren Laufzeit jedoch auf die Bearbeitungszeit dieser Aufgabe beschränkt ist. In der Umsetzung wird dieser Unterschied ebenfalls deutlich, weil jeweils andere Methoden für das Versenden der unterschiedlichen Intents genutzt werden (startservice und bindservice) [Goob]. Den dritten grundlegenden Bestandteil bilden die Broadcast Receiver [Good], die für das Empfangen von Intents innerhalb des Systems gedacht sind und diese an Activities oder Services weiterreichen. Ein Broadcast beschreibt das Versenden eines Intents ohne festes Ziel (implizit) innerhalb des Systems, sodass dieses oder der Nutzer einen Empfänger anhand der mitgegebenen Aufgabe identifizieren muss. Um Intents empfangen zu können, muss man dies entweder direkt im Code (dynamisch) oder alternativ im Manifest der App angeben. 2.3 Interprozesskommunikation Android bietet Entwicklern eine Vielzahl von Möglichkeiten, um mit den Komponenten ihrer oder fremder Apps kommunizieren zu können. Dies fördert die Wiederverwendbarkeit einzelner Module und die Zusammenarbeit von Apps verschiedener Entwickler. Zentraler Baustein der Kommunikation sind verschiedene Arten von Intents, die einerseits dafür zuständig sind Activities und Services zu starten oder letztere zu stoppen und zu binden. Binden bezeichnet das Verknüpfen einer Komponente mit dem Service, um ihn nutzen zu können. Andererseits dienen Intents der Nachrichtenübermittlung in Form eines Pakets, das verschiedene Daten enthalten kann. Android-Anwendungen für Datenflussdiagramme Seite 6

14 Kapitel 2 Grundlagen Dabei können diese entweder an ein bestimmtes Ziel, zum Beispiel eine Activity (explizit), oder ohne festes Ziel (implizit) mit einem bestimmten Zweck (Action) verschickt worden sein. Dieser gibt beispielsweise an, dass das verschickte Paket ein anzuzeigendes Bild enthält, damit das Betriebssystem die Nachricht nur noch an Apps weiterreicht, die dieses auch verarbeiten können. Der Inhalt des Paketes (Data) kann noch durch weitere Spezifikationen erweitert werden, wie das Format des Bildes (Type), weitere Informationen zur verarbeitenden Komponente (Category) oder andere Daten, die später genutzt werden können (Extras) [Good]. Durch das implizite Verschicken von Informationen kann es passieren, dass das Betriebssystem mehrere Apps findet, die für die gewünschte Operation in Frage kommen. In diesem Fall muss der Nutzer eine Entscheidung treffen und auswählen, welche genutzt werden soll (siehe Abbildung 2). Sollten hingegen mehrere Services in Frage kommen, so ist für den Nutzer nicht sichtbar, welcher vom System gewählt wurde. Dies stellt ein Sicherheitsrisiko dar, widerspricht den Androidrichtlinien für Entwickler [Gooe] und ist ab der Android Version 5.0 (Application Programming Interface (API) Level 21) grundsätzlich verboten. Abbildung 2: Auswahl einer passenden App für eine Videodatei Die App, welche den Intent letztlich erhält, kann die darin enthaltenen Daten weiterverarbeiten, darf dies jedoch nur mit den eigenen Berechtigungen tun. Sollte es notwendig sein, dass bestimmte Rechte innerhalb der Verarbeitung erforderlich sind, so kann die Nachricht Android-Anwendungen für Datenflussdiagramme Seite 7

15 Kapitel 2 Grundlagen als Pending Intent verschickt werden. Das bedeutet, dass die App, die die Nachricht erhält, die Rechte der sendenden App für die Dauer der Bearbeitung erhält. Dieser Schritt setzt somit ein Vertrauen voraus, dass die übertragenen Rechte rechtmäßig genutzt werden. Weiterhin sollte der Pending Intent geschützt werden, indem man die Zielkomponenten direkt spezifiziert oder spezielle Rechte fordert, um den Intent erhalten zu dürfen. 2.4 Bedrohungsmodell Nach der Einführung der Kommunikationsmöglichkeiten und Komponenten des Android Betriebssystems soll ein kurzer Überblick über konkrete Angriffspunkte gegeben werden. Dieser Abschnitt orientiert sich an dem Paper Analyzing Inter-Application Communication in Android [CPFGW] und führt die dort gegebenen Beispiele aus, da Epicc vor genau den hier genannten Angriffsmethoden warnen kann Unerlaubtes Empfangen von Intents Broadcasts sind so ausgelegt, dass sie potentiell von allen Komponenten empfangen werden können, wenn diese nur einen entsprechenden Intent-Filter definiert haben. Ohne einen zusätzlichen Schutz durch Berechtigungen ist es somit leicht, Broadcasts mitzulesen, ohne dass der Nutzer dies mitbekommt (Broadcast Theft). Ähnlich zum zuvor genannten Szenario können sich Activities von bösartigen Apps für die impliziten Intents von anderen Apps registrieren. Diese können den Inhalt der Intents auslesen, wenn der Nutzer versehentlich oder auf Grund eines geschickt gewählten Namens die falsche App auswählt (siehe Abbildung 2). Einen besonderen Fall bilden hier die Apps, die darüber hinaus dem Nutzer optisch vortäuschen, eine andere App zu sein, um so beispielsweise Nutzernamen und Passwort zu erhalten, die für die App gedacht waren, die der Nutzer ursprünglich starten wollte (Activity Hijacking). Genau wie Activities können auch Services sich für das Empfangen von Intents registrieren. Sie haben jedoch aus Sicht des Angreifers den Vorteil, dass der Nutzer keinen Einfluss auf die Wahl des Services hat, der den Intent empfangen soll und den Auswahlprozess nicht einmal mitbekommt. Dieser ist darüber hinaus noch zufällig und bietet keinen Schutz gegen das unerlaubte Ansprechen durch schadhafte Komponenten (Service Hijacking). Die getroffene Auswahl des Nutzers oder des Systems für eine Activity oder einen Service kann sich in der Folgezeit noch weiter auswirken. Ein jetzt gebundener Service oder eine ausgewählte und als Standardanwendung für diesen Dateityp festgelegte App, beispielsweise zum Öffnen von Videodateien, können so agieren wie der ursprüngliche Android-Anwendungen für Datenflussdiagramme Seite 8

16 Kapitel 2 Grundlagen Empfänger des Intents, damit sie weitere Anfragen erhalten und so Informationen weitergeben können. Der Empfang eines Intents durch eine unberechtigte Anwendung kann neben der direkten Weitergabe von Informationen noch dazu führen, dass Rechte anderer Komponenten durch geschicktes Anfragen und Abfangen des Intents missbraucht werden oder diese komplett übernommen werden. Letzteres ist beim erfolgreichen Empfangen von Pending Intents der Fall, die dem Empfänger alle Rechte des Senders übertragen Unerlaubtes Senden von Intents Alternativ zum Mitlesen oder Abfangen von Nachrichten können diese auch mit Absicht ins System geschickt werden, um dort Schaden zu verursachen. Im Fokus stehen hier die Broadcast Receiver, die auf das Empfangen von ins System geschickten Nachrichten ausgelegt sind und als von außerhalb der eigenen App ansprechbar (exported) markiert sind. Vertrauen diese einem Intent blind, so kann leicht eine ungewollte Aktion durch die weiterverarbeitende Komponente ausgelöst werden oder es wird in Folgeschritten auf falschen oder schadhaften Daten weitergearbeitet (Malicious Broadcast Injection). Ein impliziter oder expliziter Intent kann auch direkt zu einer exported Activity gelangen, was zur Folge hat, dass diese gestartet wird. Einerseits können durch die Activity andere Komponenten beeinflusst oder Daten geändert oder beschädigt werden. Andererseits kann, ohne Wissen des Nutzers, aus einer schadhaften App zu einer anderen Anwendung gewechselt werden. Dieser könnte dort zum Beispiel Änderungen vornehmen, die nicht für diese App gedacht waren und so selbst Schaden verursachen, indem er ungewollt Daten verändert oder löscht. Letztlich ist es noch möglich, dass die aufgerufene Activity sensible Daten an die schadhafte App zurückgibt, wenn sie ihre Arbeit beendet hat (Malicious Activity Launch). Auch Services, die als exported markiert wurden, können, wenn sie nicht ausreichend durch Berechtigungen geschützt werden, unrechtmäßig ausgenutzt werden. Die Probleme, die entstehen können, decken sich mit den zuvor genannten der Activities. Es kann ebenfalls zu ungewollter Veränderung oder dem Löschen von Daten sowie der Weitergabe von Informationen kommen. Zusätzlich stellen Services dem Aufrufer Methoden zur Verfügung, die dieser Nutzen kann, um an weitere Daten zu gelangen oder anderen Schaden zu verursachen (Malicious Service Launch). 2.5 Entwurf der Benchmark Anwendungen Nachdem in den vorangegangenen Abschnitten des Kapitels Grundlagenwissen gesammelt worden ist, lässt sich nun ein Satz von minimalistischen Apps erstellen, die jeweils Android-Anwendungen für Datenflussdiagramme Seite 9

17 Kapitel 2 Grundlagen eine Möglichkeit der Interprozesskommunikation nutzen. Die entstandene Sammlung soll während der weiteren Arbeit als Benchmark für fremde und eigene Tools verwendet werden, um zu prüfen, ob diese die Merkmale der Apps erkennen. Der Benchmark lässt sich in die folgenden vier Oberkategorien Activities, Intents, Pending Intents und Services einteilen, die in Abschnitt 3.1 genauer aufgelöst werden. Es wird zu jeder Kurzbeschreibung eine Referenz zum entstandenen Benchmark gegeben. Dort folgt eine genauere Beschreibung Activities Das Starten einer Activity während der Laufzeit kann klar vorgegeben sein (siehe Benchmark B1 im Kapitel 3.1) oder von einem Faktor wie zum Beispiel dem Zufall abhängen (B2, B12). Zusätzlich kann das Erkennen von gestarteten Activities durch verschachtelte Aufrufe über mehrere Komponenten hinweg erfolgen (B3 und B4) Intents Beim Versenden von Intents kann dies implizit (B5) über einen Broadcast oder explizit geschehen (B1). Zusätzlich können sie durch eine Berechtigung geschützt sein (B6, B10, B11), um festzulegen, wer diese empfangen darf. Zum Empfangen eines Intents muss dies im Manifest (B7) oder direkt im Code (B8) beim System angemeldet werden. Bei einer Registrierung im Manifest lassen sich weitere Spezifikationen zur Art des Inhalts des Intents machen (B9), zum Beispiel Format des enthaltenen Bildes als Portable Network Graphics (PNG) Datei (data:mimetype). Außer eigenen Komponenten als Empfänger lässt sich ein Intent auch implizit an fremde Apps, zum Beispiel einen Bildbetrachter, schicken (B13). Dazu wird mindestens eine Action angegeben, die den Inhalt eines Intents beschreibt Pending Intents Pending Intents können entweder an eigene Komponenten innerhalb einer App (B14) oder an eine fremde Komponente (B15) weitergereicht werden Services Die Definition eines Services kann als Klasse im Code erfolgen, für andere nutzbar gemacht werden (exported=true, B16) und gegebenenfalls eine Schnittstelle (Binder, B17) zur Verfügung stellen, die bestimmte Funktionen für andere Komponenten nutzbar macht. Android-Anwendungen für Datenflussdiagramme Seite 10

18 Kapitel 2 Grundlagen Neben der Definition im Code kann ein Service durch eine AIDL-Datei vorgegeben werden. Falls dieser beispielsweise von einer großen Zahl an anderen Komponenten genutzt werden soll, erleichtert dies die Verbreitung. Dabei kann der Service bereitgestellt (B20) und von einer fremden Komponente (B19) oder innerhalb der App (B18) verwendet werden. 2.6 Statische Analyse Die Untersuchung der Apps innerhalb der Arbeit erfolgt in Form einer statischen Analyse. Das bedeutet, dass die Anwendung als APK-Datei vorliegt und noch nicht auf einem Gerät installiert ist. APK-Dateien werden nach der Entwicklung einer App erstellt und enthalten alle für die Installation auf dem Gerät relevanten Daten. Dabei wurde unter anderem der von Menschen lesbare Quellcode in unlesbaren, für Maschinen interpretierbaren Bytecode umgewandelt (kompilieren). Im Anschluss an das initiale Entpacken der APK-Datei folgt, als Vorverarbeitungsschritt für Epicc, das Dekompilieren der erhaltenen Dateien. Das beschreibt das Zurückführen von Bytecode in Quellcode, was jedoch nicht verlustfrei passiert. Es gehen Informationen wie Kommentare oder Variablenbenennungen verloren. Trotzdem können die entstandenen Dateien im nächsten Schritt analysiert werden. Zur Durchführung einer statischen Analyse ist es somit nicht nötig, dass die App auf dem Gerät installiert ist und ausgeführt wird [Goe][Kos]. Dies bedeutet im Umkehrschluss, dass keine Laufzeitinformationen, wie zum Beispiel die Auslastung der Netzwerkverbindung, zur Verfügung stehen. Dennoch lassen sich aus dem Programmcode Erkenntnisse ziehen, da Schlüsselwörter der Programmiersprache (hier: Java) oder Muster und Blöcke im Code bekannte Auffälligkeiten ausweisen können. Weiter lassen verwendete Datenstrukturen wie zum Beispiel Intents und deren Initialisierung bzw. Veränderung Rückschlüsse auf mögliche Kommunikationen zu. 2.7 IDE-Probleme IDE-Probleme (Interprocedural Distributive Environment) stammen aus der Klasse der IFDS-Probleme (interprocedural, finite, distributive, subset), die 1995 von Reps, Horwitz und Sagiv definiert worden sind [RHS]. Die Grundidee besteht aus der Reduktion von Programmanalyse-Problemen in Erreichbarkeitsprobleme innerhalb von Graphen [Boda]. Dazu wird ein Graph aufgebaut, der den Programmfluss darstellt und der mit Erreichbarkeitsanalysen durchsucht wird. Android-Anwendungen für Datenflussdiagramme Seite 11

19 Kapitel 2 Grundlagen Diese Idee soll im Folgenden an einem kurzen Beispiel verdeutlicht werden. Gegeben sei der Pseudocode aus Listing 1 und die Vorgabe, dass die Rückgabe der Methode secret niemals auf der Konsole ausgegeben werden darf (print). 1 void main ( ) { 2 i n t x = s e c r e t ( ) ; 3 i n t y = 0 ; 4 y = foo ( x ) ; 5 p r i n t ( y ) ; 6 } 7 8 i n t foo ( i n t p ) { r eturn p ; } Listing 1: Beispielcode zum IDE-Problem (Quelle: [Bodb]) Die Analyse des gegebenen Codes liefert den Graph in Abbildung 3. Dargestellt wird die Änderung des Inhalts der Variablen x und y in Abhängigkeit vom Programmfluss durch die Anweisungen aus Listing 1. Die 0 beschreibt eine leere wahre Aussage und dient beispielsweise der Beschreibung von unbedingten Startwerten. Dies ist in der ersten illegalen Informationsflusskante (rot) zu sehen, die von 0 zu x verläuft und angibt, dass der neue Wert von x unabhängig vom Ausgangswert war, da dieser hier direkt überschrieben wird. 0 x y Kontrollfluss int x = secret(); Datenfluss 0 x y illegaler Informationsfluss int y = 0; 0 x y Aufruf 0 p y = foo(x); return p; 0 x y 0 Rückgabe p print(y); Abbildung 3: Beispielgraph zum IDE-Problem (Quelle: [Bodb]) Android-Anwendungen für Datenflussdiagramme Seite 12

20 Kapitel 2 Grundlagen Interessant ist besonders der rot markierte Pfad, der die Lösung des Erreichbarkeitsproblems darstellt und gleichzeitig die Tatsache aufzeigt, dass eine Verletzung der Vorgabe vorliegt. Folgt man der Rückgabe der Methode secret, so wird diese zu Beginn in die Variable x geschrieben und anschließend der Methode foo übergeben. Die Rückgabe von foo, die x entspricht, wird in die Variable y geschrieben und letztlich mit Hilfe von print auf der Konsole ausgegeben. Das bedeutet, dass die geheimen Informationen aus der Rückgabe von secret für unberechtigte sichtbar werden. Die unerlaubte Weitergabe der Informationen wurde hier erfolgreich aufgedeckt und wird in Epicc auf Kommunikationsflüsse in Apps übertragen. 2.8 Verwendete Tools Dieser Abschnitt gibt einen Überblick über den Nutzen und die Funktionsweise von Epicc und weiterer genutzter Tools Dare Zur initialen Vorverarbeitung einer APK-Datei wird Dare genutzt, das den Bytecode in Java Code dekompiliert. Anschließend liegt die Anwendung in einem für Epicc nutzbaren Format vor Epicc Zur Analyse der Apps wird das Programm Epicc (Effective and Precise Inter Component Communication) der Pennsylvania State University [?] genutzt. Es baut auf Soot [Gro] auf, einem bekannten Codeanalyse-Tool für Java und Android und versucht Interprozesskommunikationen oder allgemeiner den Informationsfluss innerhalb von Android Apps aufzudecken und diesen gegebenenfalls als Risiko einzustufen. Das Erfassen der Kommunikation beschränkt sich innerhalb der Analyse speziell auf die Schnittstellen, sogenannte Exit und Entry Points, an denen Intents verschickt oder empfangen werden können und dem Verweisen dieser aufeinander, falls sie miteinander kommunizieren können. Das Tool verfolgt dabei im Gegensatz zu vielen vergleichbaren Programmen einen Ansatz, der darauf ausgelegt ist, False-Positives, zum Beispiel fälschlicherweise als Kommunikationspartner markierte Punkte in der analysierten Anwendung, zu vermeiden. Gewährleistet wird dies, da der von Soot bereitgestellte IDE- Solver Heros drei spezielle Eigenschaften besitzt, er ist flow-sensitive, context-sensitive und inter-procedural. Der Begriff flow-sensitive bedeutet, dass beispielsweise die Veränderungen an einer Variable, die einen Intent enthält, über den gesamten Programmverlauf beobachtet werden. Android-Anwendungen für Datenflussdiagramme Seite 13

21 Kapitel 2 Grundlagen Sollte der Fall eintreten, dass der Intent mehrmals verschickt und zwischen der Nutzung verändert wird, so kann zu jedem Zeitpunkt genau gesagt werden, welchen Zustand der Intent besitzt [OMJ + 13]. Weiterhin ist der Ansatz context-sensitive, da für jeden Methodenaufruf der Rückgabewert exakt ermittelt wird, anstatt eine allgemeine Menge an möglichen Rückgabewerten über alle Fälle hinweg zu ermitteln. Nimmt man für dieses Beispiel an, dass allen Aufrufen am Ende der Analyse die gleiche Gesamtmenge an möglichen Rückgabewerten zugewiesen wird, so ist das Ergebnis nicht falsch, da der wirkliche Wert in der Menge enthalten ist. Durch die Verallgemeinerung entsteht jedoch das Risiko False-Positves zu erzeugen [OMJ + 13]. Drittens beschreibt inter-procedural die Betrachtung des gesamten Programms oder einer App mit Hilfe eines Kontrollflussgraphen. Dies hat ebenfalls den Vorteil, dass im Verlauf der Analyse zum Beispiel genauere Rückschlüsse über mögliche Werte eines Intents gemacht werden können, anstatt alle denkbaren Wertekombinationen betrachten zu müssen [HB]. In einem ersten Schritt der Analyse durch Epicc erfolgt das Einlesen der zu analysierenden Anwendung und die Aufteilung dieser in kleinste Bestandteile, meist einzelne Anweisungen. Diese dienen dem Aufbau eines Kontrollflussgraphen, der den Ausführungsablauf der App darstellt und der im Folgeschritt in ein IDE-Problem umformuliert werden kann. Die Hauptaufgabe des Programms stellt die Überführung der Eingabe als Inter-process communication (IPC)-Problem in ein IDE-Problem dar, da für dieses eine Lösung effektiv berechnet werden kann. Ein IPC-Problem bezeichnet die Suche nach Kommunikationen zwischen verschiedenen Prozessen. Zuvor findet noch eine String-Analyse statt, die im Code unveränderlich festgelegte Werte herausfiltert, die beispielsweise an wichtige Methoden wie Intent.setAction oder Intent.addCategory übergeben werden. Die Ergebnisse werden im Folgeschritt an einen in Soot enthaltenen IDE-Solver (Heros) weitergegeben, der darauf spezialisiert ist, IDE-Probleme effizient zu lösen. Das Resultat sind zum Beispiel Informationen über einen Intent, die angeben, ob dieser implizit oder explizit verschickt wurde und welche weiteren Daten er enthält. Zusätzlich wird bestimmt, wie viele mögliche Werte der Intent annehmen kann. Dies ist nötig, da ein Broadcast Receiver, der im Intent-Filter die Action A und die Category C definiert, Intents empfangen kann, die entweder die Action A und Category C besitzen oder nur die Action A. Neben dem allgemeinen Auffinden von möglichen Start- oder Endpunkten einer Kommunikation ist Epicc in der Lage, potenzielle Bedrohungen aus dieser Menge herauszufiltern und zu nennen. Zu den erfassten Sicherheitsrisiken gehören das Mitlesen von Broadcasts Android-Anwendungen für Datenflussdiagramme Seite 14

22 Kapitel 2 Grundlagen ( Broadcast Theft (Sniffing), zum Beispiel in B5, B6, B12), das Einschleusen von fremden Broadcasts in das System ( Malicious Broadcast Injection, zum Beispiel in B7, B8, B9, B10, B11) und das unerlaubte Starten ( Malicious Service Launch, zum Beispiel in B16, B17, B18, B20) oder Nutzen von Services ( Service Hijacking, zum Beispiel in B19) Android Threat Modeling Platform der Universität Bremen Die zu erweiternde Software wird im Rahmen des ZertApps Projekts [Zerb] vom Technologie- Zentrum Informatik (TZI) der Universität Bremen und Partnern wie dem Fraunhofer- Institut für Sichere Informationstechnologie, SAP, der datenschutz cert GmbH, Otaris und der Technischen Universität Darmstadt entwickelt. Ziel des Projektes ist es, ein System zu schaffen, das tiefgreifende Analysen von Android Apps durchführen kann, um im Anschluss eine Sicherheitszertifizierung für diese ausstellen zu können. Dies wäre beispielsweise vor der Veröffentlichung einer App im Google Play Store sinnvoll, da so im Vorfeld gefundene Probleme beseitigt werden können und die von Google durchgeführten Maßnahmen oft nicht ausreichen [Zera]. Zu den von der Threat Modeling Platform durchgeführten, über den Stand der Technik hinausgehenden Analysemethoden gehören statische und dynamische Analysen, die speziell auf das Android System ausgelegt sind. Hinzu kommen plattformunabhängige Analysen, die den Fokus auf HTML5 und Java legen. Ergänzend soll das Zusammenspiel von mehreren Apps betrachtet werden. Die Software liegt als Eclipse Plugin vor und ist in der Lage, eine gegebene APK-Datei zu analysieren und eine Datenstruktur aufzubauen, die alle relevanten Informationen zu den Komponenten und dem System enthält. An diese Datenstruktur soll im Verlauf der Arbeit das neu entwickelte Modell angepasst werden. 2.9 Fazit In diesem Kapitel wurden die Grundlagen zum Android Betriebssystem und seinen Komponenten vermittelt. Es wurden Begriffe wie Activity, Broadcast Receiver, Service und Intent eingeführt. Ergänzend wurden verwendete Methoden und Probleme, wie zum Beispiel das IDE-Problem erklärt und genutzte Tools beschrieben. Somit kann nachfolgend, durch die Evaluation von Epicc, mit der Vorbereitung für die Erweiterung des Datenmodells begonnen werden. Android-Anwendungen für Datenflussdiagramme Seite 15

23

24 Kapitel 3 Validierung und Evaluation von Epicc 3 Validierung und Evaluation von Epicc In diesem Kapitel wird beschrieben, wie das verwendete Tool Epicc gegen den beschriebenen Benchmark getestet (Abschnitt 3.1) und evaluiert (Abschnitt 3.2) wurde. 3.1 Benchmarks Als Benchmark wurden verschiedene Apps implementiert, die jeweils eine Information über genau eine Kommunikationsmethode senden oder empfangen können. Als Vorbereitung wurden die zugehörigen APKs der beschriebenen Apps mit Dare dekompiliert. Je Beispiel ist ein Verweis auf die Erwartungen des Epicc-Durchlaufes gegeben, denen die Ergebnisse in gekürzter Form gegenübergestellt werden. Bevor auf die einzelnen Benchmark- Anwendungen genauer eingegangen wird, werden diese mit einer Kurzbeschreibung aufgelistet. B1. StartActivity: Startet auf Knopfdruck eine zweite Activity. B2. StartActivity2: Startet auf Knopfdruck zufällig eine von zwei Activities. B3. StartLinkedActivity: Startet eine Activity über die Java Klasse Util, der Intent wird dort erstellt. Util ist eine in der App enthaltene Klasse. B4. StartLinkedActivity2: Startet eine Activity über die Java Klasse Util, der Intent wird in MainActivity erstellt und an Util weitergegeben. Util ist hier ebenfalls in der App enthalten. B5. SendBroadcast: Verschickt einen selbst definierten Intent per Broadcast (com.example.sendbroadcast). B6. SendBroadcastWithPermission: Verschickt einen Broadcast vom Typ myaction. Der Empfänger benötigt die Berechtigung root.example.mypermission, um den Intent zu erhalten. B7. BroadcastReceiver: Gibt einen Toast aus, wenn ein Intent vom Typ com.example.sendbroadcast empfangen wurde (Intent-Filter im Manifest registriert). B8. BroadcastReceiver2: Gibt einen Toast aus, wenn ein Intent vom Typ com.example.sendbroadcast empfangen wurde (Intent-Filter im Java Code registriert). B9. BroadcastReceiver3: Besitzt in der Deklaration der Intent-Filter im Manifest eine Angabe aller möglichen <data> Spezifikationen (scheme, host, port, path, pathpattern, pathprefix, mimetype). Android-Anwendungen für Datenflussdiagramme Seite 17

25 Kapitel 3 Validierung und Evaluation von Epicc B10. BroadcastReceiverWithPermission: Gibt einen Toast aus, wenn ein Intent vom Typ myaction empfangen wurde (Intent-Filter im Code registriert). Der Empfänger benötigt die Berechtigung root.example.mypermission, um den Intent zu erhalten. B11. BroadcastReceiverWithPermission2: Gibt einen Toast aus, wenn ein Intent vom Typ myaction empfangen wurde (Intent-Filter im Manifest registriert). Der Empfänger benötigt die Berechtigung root.example.mypermission, um den Intent zu erhalten. B12. RandomIntent: Verschickt zufällig einen expliziten Intent (startet zweite Activity) oder impliziten Intent (vom Typ myaction ). B13. ViewImageViaIntent: Erstellt einen Intent mit der Action ACTION VIEW und dem Typ image/png. B14. PendingIntent: Gibt einen Pending Intent von einer Activity an eine zweite weiter. B15. PendingIntent2: Sendet einen Pending Intent an den Alarmmanager, der nach Ablauf einer bestimmten Zeit eine Activity startet, die einen Toast anzeigt. B16. StartService: Enthält einen Service, dessen exported Flag auf true gesetzt wurde und der auf Knopfdruck gestartet werden kann (terminiert nach kurzer Zeit). B17. StartBinder: Enthält einen Service, dessen exported Flag auf true gesetzt wurde und der seine Methode mit Hilfe eines Binders zur Verfügung stellen kann. B18. AIDL: Besitzt einen mittels AIDL-Datei definierten Service, der innerhalb der App implementiert und genutzt wird. B19. AidlClient: Nutzt den per AIDL-Datei definierten Service (CALCULATOR) einer anderen App (AIDLServer). B20. AidlServer: Stellt einen durch eine AIDL-Datei vorgegebenen Service (CALCULATOR) für andere Apps zur Verfügung. Im Folgenden wird auf die aufgelisteten Benchmarks genauer eingegangen, indem relevante Quellcodeabschnitte kurz aufgeführt werden. Zusätzlich erfolgt eine Angabe der Erwartungen an die Analyse, die den tatsächlichen Ergebnissen gegenübergestellt werden. Android-Anwendungen für Datenflussdiagramme Seite 18

26 Kapitel 3 Validierung und Evaluation von Epicc B1. StartActivity Die Beschreibung der Benchmarks und der Erwartungen an diese erfolgt in diesem Abschnitt immer nach einem bestimmten Muster. Daher wird dieses im ersten Beispiel genauer erläutert, um zu verdeutlichen was gezeigt worden ist. Das erste Listing zeigt die Stelle des Quellcodes der App, an der die Kommunikation stattfindet. Diese sollte, wie in den Erwartungen formuliert, durch die Analyse erkannt werden. 1 p u b l i c void s t a r t A c t i v i t y ( View view ) { 2 I n t e n t i n t e n t = new I n t e n t ( t h i s, MainActivity2. c l a s s ) ; 3 s t a r t A c t i v i t y ( i n t e n t ) ; 4 } Listing 2: StartActivity - relevanter Quellcode (MainActivity) Erwartung: Die gestartete Activity sowie die Activity, aus der heraus sie gestartet wurde, sollen erkannt werden, genauso der Ort des Aufrufs (startactivity in MainActivity, Listing 2 Zeile 3). Nach der Beschreibung der Ausgangslage wird die Analyse durchgeführt und das Ergebnis im folgenden Listing gezeigt. Zu sehen sind gefundene Komponenten, die nach Arten, beispielsweise Activities, sortiert sind. Anschließend werden die zugehörigen Kommunikationen aufgeführt. Diese werden jeweils durch einen Spiegelstrich eingeleitet. Die Angabe der Kommunikationen enthält den Sender und mögliche enthaltenen Werte, die darauf schließend lassen, ob es sich um einen impliziten oder expliziten Intent handelt. Weiterhin können noch Zusatzinformationen, wie Berechtigungen, angegeben sein. 1 A c t i v i t i e s : 2 com. example. root. s t a r t a c t i v i t y. MainActivity 3 com. example. root. s t a r t a c t i v i t y. MainActivity2 4 5 com/ example / root / s t a r t a c t i v i t y / MainActivity / s t a r t A c t i v i t y ( Landroid / view /View ; ) 6 I n t e n t value : 1 p o s s i b l e value ( s ) : 7 Package : com/ example / root / s t a r t a c t i v i t y, Class : com/ example / root / s t a r t a c t i v i t y / MainActivity2, Listing 3: StartActivity - Epicc Ausgabe Ergebnis (wie erwartet): Die gestartete Activity (MainActivity2, Listing 3 Zeile 3 und Zeile 7) und die ursprüngliche Activity (MainActivity, Listing 3 Zeile 2 und Zeile 5) mit Aufruf (startactivity, Listing 3 Zeile 5) werden gefunden. Android-Anwendungen für Datenflussdiagramme Seite 19

27 Kapitel 3 Validierung und Evaluation von Epicc B2. StartActivity2 1 p u b l i c void s t a r t A c t i v i t y ( View view ) { 2 i n t x=(math. random ( ) <0.5)? 0 : 1 ; 3 4 I n t e n t i n t e n t ; 5 i f ( x==1){ 6 i n t e n t = new I n t e n t ( t h i s, MainActivity2. c l a s s ) ; 7 } e l s e { 8 i n t e n t = new I n t e n t ( t h i s, MainActivity3. c l a s s ) ; 9 } 10 s t a r t A c t i v i t y ( i n t e n t ) ; 11 } Listing 4: StartActivity2 - relevanter Quellcode (MainActivity) Erwartung: Die beiden möglicherweise gestarteten Activities (MainActivity2 und MainActivity3, Listing 4 Zeile 6 und Zeile 8) sowie die ursprüngliche Activity (MainActivity) sollen erkannt werden, genauso der Ort des Aufrufs (startactivity, Listing 4 Zeile 10). 1 A c t i v i t i e s : 2 com. example. root. s t a r t a c t i v i t y 2. MainActivity 3 com. example. root. s t a r t a c t i v i t y 2. MainActivity2 4 com. example. root. s t a r t a c t i v i t y 2. MainActivity3 5 6 com/ example / root / s t a r t a c t i v i t y 2 / MainActivity / s t a r t A c t i v i t y ( Landroid / view /View ; ) 7 I n t e n t value : 2 p o s s i b l e value ( s ) : 8 Package : com/ example / root / s t a r t a c t i v i t y, Class : com/ example / root / s t a r t a c t i v i t y 2 / MainActivity3, 9 Package : com/ example / root / s t a r t a c t i v i t y, Class : com/ example / root / s t a r t a c t i v i t y 2 / MainActivity2, Listing 5: StartActivity2 - Epicc Ausgabe Ergebnis (wie erwartet): Die beiden Activities, die gestartet werden (MainActivity2, Listing 5 Zeile 3 und Zeile 9 und MainActivity3, Listing 5 Zeile 4 und Zeile 8), die eigentliche Activity (MainActivity, Listing 5 Zeile 2 und Zeile 6) sowie der Ort des Aufrufs (startactivity, Listing 5 Zeile 6) werden gefunden. Android-Anwendungen für Datenflussdiagramme Seite 20