Android alkalmazások kommunikációjának monitorozása

SZAKDOLGOZAT-FELADAT Sűrű Balázs (IEMQRA) szigorló mérnök informatikus hallgató részére

Android alkalmazások kommunikációjának monitorozása Az okostelefonok egyre nagyobb elterjedésével kiemelten fontos, hogy az azokon futó alkalmazások megbízhatóan működjenek. A működés vizsgálatának egyik lehetősége, hogy az alkalmazás kommunikációját megfigyeljük, és azon ellenőrizzük, hogy a megfelelő üzeneteket küldi-e az alkalmazás a specifikációnak előírt sorrendben. A hallgató feladata egy olyan megoldás és prototípus kidolgozása, ami meg tudja figyelni a telefonra telepített alkalmazások hálózati kommunikációját, és jelezni tud, ha az a specifikálttól valamilyen formában eltér. A hallgató feladatának a következőkre kell kiterjednie:  Tekintse át az Android okostelefon platform működését.  Vizsgálja meg, hogy milyen módszerekkel lehetséges megfigyelni a telefonon futó alklamazások kommunikációját.  Tervezzen meg egy programot, ami képes megfigyelni a kommunikációt.  Implementálja a megtervezett programot, majd mutassa be annak működését. Tanszéki konzulens: Dr. Micskei Zoltán, adjunktus Külső konzulens: Budapest, 2015. február 19.

…………………… Dr. Jobbágy Ákos tanszékvezető

Budapesti Műszaki és Gazdaságtudományi Egyetem Villamosmérnöki és Informatikai Kar Méréstechnika és Információs Rendszerek Tanszék

Sűrű Balázs

ANDROID ALKALMAZÁSOK KOMMUNIKÁCIÓJÁNAK MONITOROZÁSA

KONZULENS

Dr. Micskei Zoltán Imre BUDAPEST, 2015

Tartalomjegyzék Összefoglaló .................................................................................................................................. 5 Abstract ......................................................................................................................................... 6 1.

2.

3.

4.

Bevezetés .............................................................................................................................. 7 1.1.

A feladat bemutatása .................................................................................................... 8

1.2.

A dolgozat szerkezete.................................................................................................... 9

Irodalomkutatás / Háttérismeretek .................................................................................... 10 2.1.

Android ........................................................................................................................ 10

2.2.

Példaalkalmazás: ASNE könyvtár ................................................................................ 14

Tervezés............................................................................................................................... 16 3.1.

Követelmények ............................................................................................................ 16

3.2.

Felhasználói felület...................................................................................................... 16

3.3.

Kommunikáció megfigyelésének módszerei ............................................................... 17

3.3.1.

Üzenetek sorosítása ............................................................................................ 18

3.3.2.

Üzenetek továbbítása a Monitornak ................................................................... 19

3.3.3.

Hálózati kommunikáció szűrése .......................................................................... 20

3.3.4.

Rendszerüzenetek elkapása ................................................................................ 21

3.4.

Üzenetek feldolgozása ................................................................................................ 22

3.5.

Önálló Laboratórium tapasztalatai .............................................................................. 23

3.5.1.

Üzenet továbbításos módszer ............................................................................. 23

3.5.2.

Hálózati kommunikáció szűrési módszer ............................................................ 23

Implementáció .................................................................................................................... 26 4.1.

4.1.1.

Monitorozó alkalmazás osztályai ........................................................................ 27

4.1.2.

Felhasználói felület.............................................................................................. 31

4.1.3.

A monitorozó aktivitás diagramja ....................................................................... 36

4.2.

5.

6.

Monitorozó alkalmazás ............................................................................................... 27

Az ASNE könyvtár ........................................................................................................ 37

4.2.1.

Az ASNE alkalmazás ............................................................................................. 38

4.2.2.

Az alkalmazás továbbfejlesztése ......................................................................... 39

Ellenőrzés / Tesztelés .......................................................................................................... 43 5.1.

Hozzáférhető forráskódú alkalmazással való tesztelés ............................................... 43

5.2.

Nem hozzáférhető forráskódú alkalmazással való tesztelés....................................... 45

Összefoglalás ....................................................................................................................... 48 6.1.

Konklúzió ..................................................................................................................... 48

6.2.

Továbbfejlesztési lehetőségek .................................................................................... 49

Irodalomjegyzék .......................................................................................................................... 50

3

HALLGATÓI NYILATKOZAT

Alulírott Sűrű Balázs, szigorló hallgató kijelentem, hogy ezt a szakdolgozatot meg nem engedett segítség nélkül, saját magam készítettem, csak a megadott forrásokat (szakirodalom, eszközök stb.) használtam fel. Minden olyan részt, melyet szó szerint, vagy azonos értelemben, de átfogalmazva más forrásból átvettem, egyértelműen, a forrás megadásával megjelöltem. Hozzájárulok, hogy a jelen munkám alapadatait (szerző(k), cím, angol és magyar nyelvű tartalmi kivonat, készítés éve, konzulens(ek) neve) a BME VIK nyilvánosan hozzáférhető elektronikus formában, a munka teljes szövegét pedig az egyetem belső hálózatán keresztül (vagy autentikált felhasználók számára) közzétegye. Kijelentem, hogy a benyújtott munka és annak elektronikus verziója megegyezik. Dékáni engedéllyel titkosított diplomatervek esetén a dolgozat szövege csak 3 év eltelte után válik hozzáférhetővé.

Kelt: Budapest, 2015. 05. 18.

Sűrű Balázs ...…………………………………………….

4

Összefoglaló A mobiltelefonok egyre fontosabb szerepet töltenek be az életünkben, így a rajtuk futó alkalmazások megbízható és biztonságos működése is egyre hangsúlyosabb. Megfelelő tervezéssel és alapos teszteléssel a hibás működések jelentős része kiszűrhető, azonban a tapasztalatok szerint még így is maradnak hibák a szoftverekben, amit csak a futás során, megfelelő monitorozással lehet észrevenni, és esetlegesen beavatkozni. A feladatom egy olyan monitorozó alkalmazás elkészítése, amivel Android rendszeren futó alkalmazások hálózati üzeneteit lehet megfigyelni és azok alapján következtetéseket levonni az alkalmazás helyes működéséről. Ehhez meg kell ismerni, hogyan lehet megfigyelni egy alkalmazás hálózati kommunikációját – akár van hozzáférésünk az alkalmazás forrásához, akár nincs -, hogyan lehet abból meghatározni, hogy milyen magasabb szintű üzeneteket küld vagy fogad éppen az alkalmazás, és hogyan lehet eldönteni egy üzenetsorozatról, hogy az megfelel-e az elvárt működésnek (amit pl. forgatókönyvek segítségével lehet megadni). A feladathoz hozzátartozik egy kellően komplex hálózati kommunikációt végző alkalmazás fejlesztése, vagy használata, amivel a monitorozó alkalmazás helyes működése igazolható. A félév során jobban megismerkedtem az Android platformra való fejlesztés módjával, feltérképeztem, hogy milyen lehetőségeket nyújt a platform az alkalmazások monitorozására. Ezeket elemeztem előnyeik és hátrányaik figyelembe vételével és mérlegeltem elkészíthetőségüket. A módszerek közül kiválasztottam és megvalósítottam kettőt; egyet arra az esetre, amikor ismert a monitorozandó alkalmazás forráskódja és egy másikat ismeretlen forráskód esetére. Az alkalmazás fejlesztése közben szempont volt a kibővíthetőség és a mások számára is olvasható, tiszta kód írása. A dolgozatban nem csak a megoldás dokumentálására, hanem a fejlesztés közben felmerült hibák bemutatására is törekedtem. A félévre kitűzött célommal – egy Android alkalmazások monitorozására való megoldás elkészítésével - a félév végére elkészültem, továbbá a két megvalósított monitorozási módszert teszteltem a példaalkalmazással. A tesztelés eredményeit elemezve elmondhatom, hogy az alkalmazás alkalmas más alkalmazások hálózati kommunikációjának megfigyelésére, ha azok forráskódja elérhető, vagy nem használnak titkosítást. 5

Abstract The mobile phones play an increasingly important role in our lives, therefore the reliable and secure functioning of applications running on them are getting more and more prominent too. With proper planning and thorough testing much of malfunctions can be filtered out, but experiences show still remaining bugs in the software that can be notified by monitoring, and in case possibly avoided by an intervention. My task is to develop an application, which is monitoring the network messages of other applications and validates its correct functioning. To do this, you must know how to observe an application’s network communications – whether we have access to the source code or not -, how to determine what kind of higher-level messages have been sent or received by the application, and how to decide whether the sequence of messages is compliant to the required operation (which can be specified e.g. by using predefined scenarios). The task also includes the development or the usage of network communicating application, which is complex enough to justify the proper functionality of the monitoring application. During the semester I managed to deepen my knowledge in developing to Android platform and scanned the different ways of monitoring an application provided by the platform. Furthermore, I analyzed the advantages and disadvantages of these monitoring techniques and weighted up their implementation efforts. From the mapped methods I chose two and implemented them; one for the case that the source code of the application is available and another for application with unknown sources. During the development the main aspects were the future extendibility of the solution and the clean code. In my thesis – beside properly document the solution - I also demonstrate the errors that occurred during the development. By the end of the semester I managed to reach my target – that is preparing an Android application to monitor other applications – and to test the two monitoring methods together with the related example application. By analyzing the results of the test, I can state, that the application is suitable for monitoring the network communication of other applications, if its source code is available, or no encryption has been used in the messages. 6

1.

Bevezetés Mai

világunkban

a

legrohamosabb

fejlődést

a

számítástechnikában

tapasztalhatjuk. Az elmúlt 20 év alatt olyan nagyot változott a világ, ahogy azt senki nem merte volna megjósolni korábban. A számítástechnika mára minden iparágba, minden országba, szinte valamennyi emberhez közvetve vagy közvetlenül eljutott már. Ez különösen igaz a mobiltelefon szektorra, amivel a szakdolgozatom foglalkozik. A fejlődés mértékét a mobiltelefonok gyors ütemben egymást követő generációi jól érzékeltetik. Az első mobilok, vagyis kommunikálásra alkalmas hordozható készülékek a 80-as évek elején jelentek meg, hatalmas külön táskányi akkumulátorral és kagylóval. Méretét tekintve csak a 90-es évekre érte el azt a nagyságot, ami valóban alkalmas arra, hogy mindennapi tevékenységünk során magunkkal hordjuk azt. Meg kell jegyeznem, hogy ezt a luxust akkor még csak nagyon kevesen engedhették meg magunknak az ára miatt. A mobiltelefonok kezdetben alapvetően telefonálásra alkalmas funkciója mára teljesen megváltozott. Az alap funkció minőségi javulásán túl megannyi újjal gyarapodott, miközben mérete csökkent és felhasználói felülete javult. A mobilt kezdetben az az igény hozta létre, hogy azon - vezetékes társaival ellentétben bárhonnan, az alközpontoktól távol, kiépített vezetékes kapcsolat nélkül is kezdeményezhessünk, illetve fogadhassunk telefonhívást. Erre később számos további kiegészítő és új funkció épült rá, mint az sms, beépített antenna, színes kijelző, beépített kamera, multimédiás lejátszó, internet elérés, és így tovább. Míg a mobiltelefonok ilyen nagymértékű változásokon mentek keresztül a vezetékes telefonok többé-kevésbe maradtak eredeti funkciójuknak, a telefonálásnak. Ezeket a fejlett mobiltelefonokat a mai emberek okostelefonoknak hívják, utalva ezzel a korábban csak PC-n, mára már mobilon is elérhető funkcionalitásokra. Ezek a telefonok már teljes értékű operációs rendszerrel rendelkeznek, melyek szabványosított interfészeket és platformot nyújtanak az alkalmazásfejlesztőknek. Mindemellett a hagyományos „butított” telefonok is a piacon maradtak még - ugyan kisebb számban - a megbízhatóságuk és készenléti idejük miatt. Ezen paraméterekkel az okostelefonok ma

7

még nem tudnak versenyezni a nagy kijelző, állandó adatkapcsolat, és bonyolult operációs rendszerük miatt melyek együttesen szinte „falják” az akkumulátort. Egy

komolyabbnak

mondható

mai

okostelefon

már

olyan

hardver

konfigurációval rendelkezik, ami vetekszik egy alap asztali számítógépével. A rohamos hardver fejlesztés mellett persze a telefonon futó alkalmazások is egyre komolyabbak. Szinte számítógépes szintű, Full HD felbontású grafikus játékoktól kezdve a felhasználó közeli szövegszerkesztőig, email-ig, böngészőig stb. minden megtalálható. Ugyanakkor ezek a programok egyre több személyes adatunkat érik el, ezért egyre nagyobb az igény azok megbízható, kitesztelt működésére. Ennek a jogos elvárásnak egyrészről eleget lehet tenni az odafigyelő fejlesztéssel, másrészt külön erre a célra fejlesztett alkalmazások használhatók a biztonságkritikus alkalmazások ellenőrzésére, validálására. Szakdolgozatom témájául egy az előzőekben ismertetett külső, a biztonságot ellenőrző alkalmazás fejlesztését választottam. Ezen belül is a dolgozatom a hálózati kommunikációval foglalkozik kiemelten. Az alkalmazások többsége már mind használ valami féle internetes kommunikációt, ezért természetesen adódik az igény egy – az internetes komunkációt monitorozó és azt elemző alkalmazás iránt.

1.1. A feladat bemutatása Szakdolgozatom során egy programot kell megterveznem és implementálnom Android operációs rendszerű telefonra. Ennek a programnak alkalmasnak kell lennie arra, hogy más, a telefonon futó alkalmazás hálózati kommunikációját monitorozza akár van hozzáférésünk az alkalmazás forrásához, akár nincs - és egy megadott szabályt figyelembe véve eldöntse egy adott üzenetsorozatról, hogy az megfelel-e az elvárt működésnek. Az alkalmazás tesztelhetősége végett kerestem egy nyílt forráskódú programot, amit kibővítve a saját kódrészleteimmel alkalmas lesz a saját programom kipróbálására. Önálló laboratórium tárgy keretén belül már elkészítettem egy kezdetleges monitorozó alkalmazást, melyet egy pár kimeneteles képfeltöltő alkalmazással teszteltem. Szakdolgozatom során felhasználom ezt az alkalmazást és az ott megtapasztalt ismereteket.

8

1.2. A dolgozat szerkezete A következő fejezetekben röviden bemutatom az Android operációs rendszert, majd

megvizsgálom

kommunikációjának

milyen

lehetőségek

monitorozására.

Ezután

vannak

alkalmazások

megmutatom

a

hálózati

tervezést

még

implementáció nélkül és esettanulmányt ismertetek a problémával kapcsolatban. Az implementáció részletezése után az ellenőrzés fele veszem az irányt és kész esetekkel próbálom ki az alkalmazást. Végül kiértékelem az elkészült monitorozó alkalmazást, a teszt eredményeket figyelembe véve.

9

2.

Irodalomkutatás / Háttérismeretek Feladatom elvégzéséhez feltétlenül szükség volt az Android rendszer alapos

megismerésére.

Egy

egyszerű

alkalmazás

elkészítésének

megtanulásán

túl

tanulmányoznom kellett azok belső felépítését, a rendszer nyújtotta szolgáltatásokat, rendszeren belüli kommunikációs módszereket, háttérben való futási lehetőségeket, és a dinamikus felülethez való megoldásokat.

2.1. Android Az Android elsősorban érintőképernyős mobil eszközökre fejlesztett nyílt forráskódú, Linux alapú operációs rendszer. A rendszert még az Android Inc. cég kezdte fejleszteni a 2000-es évek elején, amit felvásárolt a Google, majd az Open Handset Alliance szövetség folytatta, mely mára 84 cég irányításával (köztük a legnagyobb szoftver és hardver gyártó cégekkel: Google, HTC, Sony, Dell…) fejleszt nyílt szabványokat mobil eszközökre, melyek célja a rugalmas, könnyen fejleszthető rendszer létrehozása. A 2014 végén mért adatok szerint a mobil telefonok piacán az Android operációs rendszerű telefonok több mint 75%-os részesedést értek el világszerte. Ez a siker betudható a merész újításoknak, az ingyenességének és a nyílt forráskódú platformnak. Ezen tulajdonságoknak köszönhetően a mobiltelefon gyártok letettek saját rendszerük fejlesztéséről és inkább a nyílt forráskódú Android-ot használják és formálják azt saját igényük szerint. Sikerekhez hozzájárult továbbá az, hogy a széles körben elterjedt jól dokumentált Java programnyelvben lehet fejleszteni az alkalmazásokat. Az alkalmazásokat Java nyelven fejlesztik az operációs rendszeren futó módosított Java virtuális gépre, melyet Dalvik-nak neveznek. A platform alapját a Linux kernel adja (egyfajta absztrakciós réteg a hardver és a szoftver architektúra elemei között), mely tartalmazza az eszközön található hardverek meghajtó programjait, valamint felügyeli a memória kezelést és folyamatok ütemezését. Ezeket a szolgáltatásokat használják a Linux rendszerekben lévő programkönyvtárak és részben ezekre épül a Dalvik virtuális gép is. A rendszer fentebbi részein már csak Java forrást találunk melyek a futó programokért és a felhasználó összeköttetéséért felelősek. Ezen 10

alkalmazásokat a Dalvik gép futtat, ami akár teljesen elrejti a Linux által használt fájlrendszert és csak az Android Runtime engedte részeket láthatjuk. A telefonra telepített minden alkalmazás saját folyamat, egy saját Dalvik VM példányon fut, vagyis egy elkülönített környezetben. Az alkalmazásnak ezt a biztonságos környezetét „security sandbox”-nak nevezik. A biztonsághoz kötődik még az Android „szükséges legkevesebb jogosultság” elve is, miszerint alkalmazás fejlesztés során pontosan definiálni kell, hogy az alkalmazás az erőforrások mely komponenseit szeretnénk majd használni. Ezen engedélyeket a felhasználónak telepítéskor el kell fogadnia. Ez védelmet nyújt a rendszer komponenseinek illetéktelen használatától. Az egyes alkalmazásokhoz a kernel egy külön felhasználói azonosítót is rendel, ez csak a rendszer által ismert, az alkalmazás nem tud róla… az Android tehát egy több felhasználós Linux alapú rendszer, ahol minden alkalmazás egy külön felhasználó. Az egyedi azonosítóknak köszönhetően a dedikált memóriaterület is egyszerűen menedzselhető, továbbá csökken a biztonsági kockázat, mivel nem fordulhat az elő, hogy egy alkalmazás olyan memória terültre írna vagy olvasna, ami nem hozzá tartozik. A dedikált memória terület az alkalmazás indításakor foglalódik, és akkor fejeződik be, ha már semmilyen komponense nem fut annak, illetve előfordulhat kényszerített memória felszabadítás, ha a telefon memóriája betelt és a rendszernek többre lenne szüksége. Az Android memóriakezelése tehát nincs túl bonyolítva, amíg elegendő memória áll rendelkezésre a rendszer szolgáltatásai és az aktuális aktív alkalmazás futásához, addig nem történik memória felszabadítás, viszont amint többre lenne szükség, a rendszer elkezdi felszabadítani a legrégebben használt alkalmazások memóriáit addig, amíg eleget nem kapott. A felszabadítás előtt az alkalmazások értesítést kapnak arról, így eltudjuk menteni aktuális állapotukat, amiket újbóli elindítás esetén visszatölthetnek. Egy alkalmazás az alábbi 4 komponens típusból rakható össze tetszőleges összeállításban: 

Activity-k



Service-ek



Content Provider-ek



Broadcast Receiver-ek

11

1. ábra Az Android komponensei [3]

Mindegyik alkalmazásnak különböző szerepe van az alkalmazáson belül, önállóan aktiválódhatnak, vagy akár egy másik alkalmazás is aktiválhat egyes komponenseket. Az alkalmazásokhoz tartozik még egy leíró, úgynevezett „manifest” XML állomány, melynek deklarálnia kell az alkalmazás komponenseit, a szükséges hardver konfigurációt és a szükséges minimális Android verziót. Az egyik legfontosabb, leggyakrabban használt komponens az Activity. Leginkább egy ablakként képzelhető el, tipikusan egy képernyő, a felhasználó interfésze az alkalmazással. A felhasználók az Activity komponensen keresztül végezhetnek műveleteket, vagy olvashatják az alkalmazás állapotát. Önálló grafikus kezelőfelület. Általános felállás az, hogy létezik egy fő Activity, ami az alkalmazás indításánál töltődik be és ehhez tartozhat több lazán csatolt, amik akár Activity-ből is indíthatóak. Azt, hogy melyik lesz a fő Activity a Manifest állományban jelöljük. Új Activity indításakor az előző eltűnik/leáll, de a rendszer megőrzi az úgynevezett „back stack” LIFO veremben. Vissza gomb nyomására a legfelső Activity kerül ki a sorból és kapja meg a vezérlést. Minden egyes életciklus váltásról az Activity értesítést kap úgynevezett „callback”-eken

keresztül.

Ezek

a

metódusok

felüldefiniálhatóak,

vagyis

megmondhatjuk, hogy az Activity hogyan reagáljon az őt érintő változásokra. A lehetséges életciklus változásokat a 2. ábra szemlélteti:

12

2. ábra Activity életciklusok [2]

A Service komponenst leggyakrabban arra használják, hogy valami komplexebb számítási műveletet végezzenek a háttérben, pl.: zenelejátszó, fájl letöltés, szinkronizálás, renderelés… Service-k nem rendelkeznek felhasználói megjelenítővel, az Activity-n vagy felugró elemekkel valósítható meg. Fontos figyelni arra, hogy egy Service alapból az alkalmazás szálán végzi a feladatait, tehát ha erőforrás igényes a feladat érdemesebb egy külön szálat indítani. A Content Provider komponens funkciója az adat és az üzleti logika réteg elválasztása alkalmazáson belül. Tipikus alkalmazása natív adatbázisokhoz való hozzáférés (sms, névjegyzék…), illetve adatok elérhetővé tétele más alkalmazások számára. Feladata az adatforrás elfedése a kérő elől, illetve a kommunikáció lebonyolítása. Az utolsó komponens típus a Broadcast Receiver, melynek feladata a rendszerben szórt üzenetek felügyelete. Segítségével regisztrálhatunk bizonyos alkalmazás eseményekre, melyek bekövetkezéséről futásidőben értesülünk majd. Tipikus használata alkalmazáson belüli vagy kívüli komponens számára való üzenet küldésre, például elérhető internet kapcsolatára való feliratkozás szinkronizálás indításához. A komponens témakörhöz szorosan kapcsolódó fogalom az Intent, mely futásidejű kötést valósít meg alkalmazás komponensei között. Az Intent egy absztrakt leírása az aktuálisan végrehajtandó műveletnek. Leggyakrabban új Activity indításakor használják, ami lehet explicit és implicit is. Különbség az, hogy míg explicitnél módnál

13

ismerjük a hívandó osztályt, implicitnél csak azt tudjuk, hogy mire szeretnénk használni. Például tudjuk, hogy egy képet szeretnénk megjeleníteni, de nem tudjuk, hogy melyik alkalmazással.

2.2. Példaalkalmazás: ASNE könyvtár Az önálló laboratóriumi munkámban csak egy nagyon egyszerű képfeltöltő alkalmazást használtam a monitorozó alkalmazásom tesztelésére. Továbbfejlesztéshez szükség volt egy komplexebb hálózati forgalmat lebonyolító alkalmazásra. Mivel nyílt forráskodó projektre volt szükségem, azt elsősorban a GitHub-on (web alapú Git repository hosting szolgáltatás) kerestem. Több projekt kipróbálása után végül egy orosz programozó, Evgeny Kondrashkin fejlesztette ASNE (Android Social Networks) elnevezésű, közösségi oldalakat összefogó alkalmazást választottam.

3. ábra ASNE projekt [9]

Manapság a közösségi hálózatok integritása Android-dal igencsak elterjedt, ez egyszerűvé teszi a bejelentkezést és a tevékenységek megosztását. Erre az integrációra több mód is létezik, a fejlesztők általában hozzáadják a közösségi oldalak natív SDKját, vagy az API-jukat használják, ha létezik hozzájuk. Az SDK vagy API nyújt bejelentkezést a telepített közösségi oldal alkalmazásával, vagy natív dialógusokon keresztül. Egy ilyen alkalmazás fejlesztése bonyolult, mert sok időt kell szánni a különböző hálózatok szoftver fejlesztő környezetükkel, majd ezek együttes működését összehangolni.

14

De mi van, ha valaki egynél több ilyen közösségi hálózatot szeretne összekapcsolni a saját alkalmazásával? Ez esetben össze kéne hangolni őket, rosszabb esetben újra csinálni az integrációkat. Ez vezette a fejlesztőt arra az ötletre, hogy egy általános interfészt fejlesszen az összes közösségi hálózathoz. Az ASNE tehát egy nyílt forráskódú moduláris könyvtár, ami lehetőséget nyújt választani az elérhető közösségi oldalak közül, amikhez teljes SDK-t és egy általános interfészt nyújt a gyakran használt funkciókhoz, mint például bejelentkezés, megosztás, barátok listája… Időt és energiát spórol a meglévő közösségi oldalakhoz, de a kiterjeszthetősége miatt könnyen adható majd új hálózat is hozzá a jövőben egy új modulként az előzőek mintájára. Létezik egy egyszerű alkalmazás is, ami ennek a lib-nek a használatát mutatja be. Ennek segítségével kezdtem el használni, megismerni azt, illetve igényeim szerint új funkciókkal ellátni, majd implementálni a monitorozáshoz szükséges kódot.

15

3.

Tervezés Ebben a fejezetben bemutatom a rendszer megtervezésének folyamatát. Először

is, a feladat specifikációjából összegyűjtöttem a követelményeket és ezeket analizáltam. Mindezek

pontos

figyelembevételével

elkészítettem

egy

megvalósíthatósági

tanulmányt, amely lefedi a grafikus felület leírásától kezdve az Android-on való monitorozás módszereinek a feltérképezéséig a teljes megvalósítást. A tervezés keretein belül szempont volt a korábbi Önálló Laboratórium keretében elvégzett munkámnak – vagy annak egyes részeinek - lehetséges felhasználása.

3.1. Követelmények Az alkalmazás tervezése fázisában a következő célokat tűztem ki magamnak: 

Tetszőleges

alkalmazás

legyen

monitorozható,

ha

ismerjük

a

forráskódját, ha nem. 

Minden monitorozandó alkalmazáshoz legyen egy konfigurációs fájl, ami

tartalmazza az azonosításhoz szükséges adatokat, a monitorozási módot, és a helyes hálózati kommunikáció szekvenciáját. 

A

kiértékelt

eredmény

legyen

kiexportálható

és

az

esetleges

továbbfejlesztéshez legyen feldolgozható formában. 

Az alkalmazás rendelkezzen egy letisztult, egyszerűen használható

felhasználói felülettel. 

Legyen egy kellően komplex minta alkalmazás, hogy az alkalmazás

tesztelhető legyen.

3.2. Felhasználói felület A felhasználói felület igényessége és könnyen kezelhetőség végett „mockup” terveket készítettem magamnak, hogy az implementálás majd gördülékenyen menjen. Úgy gondoltam, hogy a tervezésnél leírt funkciók kielégítéséhez elég lesz két Activity. Egy kezdő képernyő, ami tartalmazza a kétféle monitorozási mód kezelő felületét, valamint a beregisztrált monitorozandó alkalmazások listáját. A másik Activity egy, a listán szereplő alkalmazás értékelőjét fogja tartalmazni. Ez a komponens nem lesz

16

alkalmazáshoz kötve, hanem csak egyfajta keretet fog adni, amibe a kiválasztott alkalmazás eredményei megjelennek. A listában felsorolt alkalmazások kattinthatóak lesznek és az eseménykezelőjük tölti majd be a következő Activity-t. A vissza gombra kattintva tudjuk majd újra előtérbe hozni a kezdőképernyőt. A két Activity-hez tartozó rajzolt kép itt látható:

4. ábra Mockup tervek

3.3. Kommunikáció megfigyelésének módszerei Az alkalmazás implementációjánál döntő szerepe van a monitorozás mikéntjének. Pontosan utána kell olvasni annak, hogy milyen megoldások léteznek és mik az előnyeik. Fontos szempont legalább egy olyan megoldásnak a megléte is, amihez nem kell a gyári rendszert bolygatnunk és a készülék garanciájának elvesztését kockáztatni. A következőkben feltérképezem azt, hogy hogyan lehet megfigyelni egy alkalmazás hálózati kommunikációját (akár van hozzáférésünk az alkalmazás forrásához, akár nincs), hogyan lehet abból meghatározni, hogy milyen magasabb szintű üzeneteket küld vagy fogad éppen, és hogyan lehet eldönteni egy üzenetsorozatról, hogy az megfelel-e az elvárt működésnek (amit pl. forgatókönyvek segítségével lehet megadni). 17

Ez a döntés később meghatározója lehet az alkalmazás hatékonyságára, akár időbeli gyorsaságra, akár a használt erőforrásra is gondolunk. A következőkben a megvizsgált lehetőségek kerülnek bemutatásra és mérlegelésre.

3.3.1. Üzenetek sorosítása Az egyik legkézenfekvőbb megoldás lenne, ha a monitorozandó alkalmazás a folytatott kommunikációt egy fájlba mentené, ami elérhető lenne a monitorozó alkalmazás számára. Ez esetben meg kell egyezni az adatmentés formájában, elnevezésében, illetve a tárolás helyében. A mentés helye akár kötetlen is lehet, de akkor a kiértékelés előtt egy keresést kéne futtatni, ami igencsak erőforrás igényes lenne. A monitorozónak még szüksége lesz egy szabálybázisra, ami alapján a kiértékelést elkészítheti. Az alábbi ábrán egy kitalált alkalmazás bejelentkezési kísérletét láthatjuk:

5. ábra Üzenet sorosítási folyamat

A megvalósítás előnyei: 

Könnyen implementálható és tesztelhető.

A megvalósítás hátrányai: 

Ehhez a megoldáshoz ismernünk kell a monitorozandó alkalmazást, hiszen annak forráskódjába bele kell írnunk a sorosítás funkciót.



További hátrány jelent a fájl karbantartása, bizonyos telítettség esetén azt üríteni kell, valamint addig helyet foglal a többi alkalmazás elöl. Biztonságtechnikai szempontokból sem a legoptimálisabb ez a megoldás, hiszen az eredményekbe bárki könnyen bele „piszkálhat”, így téves eredményt kapnánk.



18

3.3.2. Üzenetek továbbítása a Monitornak Egy másik kézenfekvő megoldás lehet az Android Broadcast komponens használata, hiszen az

pont az alkalmazások közti üzenetszórás kezelésére,

megvalósítására való. Az üzenetek, jelen esetben a hálózati kommunikációs események valós időben kerülnének a monitorozó alkalmazáshoz, amiben csak feliratkozunk az eseményekre, majd feldolgozzuk azokat. Szintén szükség lesz a forráskódra, mert Broadcast üzeneteket fel kell paramétereznünk majd elküldenünk az egyes események bekövetkezése után. Az alábbi ábrán szintén az alkalmazás bejelentkezési kísérletét láthatjuk az üzenet továbbításos modellben:

6. ábra Üzenettovábbítási folyamat

A megvalósítás előnyei: 

Szebb és kisebb implementáció



Biztonságosabb, mint a sorosítás, megfelelő ismeretek híján, nem lehet lehallgatni, vagy hamis adatokat küldeni megtévesztés gyanánt



Nem generál ideiglenes adatot, csak továbbítja azokat



Takarékosabb az erőforrásokkal, az előző megoldásnál

A megvalósítás hátrányai: 

A megvalósításhoz ismernünk kell a monitorozandó alkalmazást, ugyanis annak forráskódjában meg kell valósítanunk az üzenetek továbbítását a Monitor felé



Ha ismerjük, hogy a monitorozó alkalmazás, milyen üzenetekre iratkozott fel, akkor könnyen injektálhatunk hamis üzeneteket, vagy lehallgathatjuk azokat



Egyszerű Broadcast regisztrálás, de az Activity-t magát nem érjük el 19

3.3.3. Hálózati kommunikáció szűrése Elképzelhető lehet egy olyan megoldás is miszerint a két alkalmazásnak nem feltétlen kell egymással kommunikálni, hanem a monitorozó alkalmazást kell felkészíteni arra, hogy az okostelefon adatforgalmát szűrni tudja. Persze tudnia kell azt, hogy milyen üzenetek számára a relevánsak, melyekre figyeljen oda és elemezze, de a figyelt alkalmazás kódjába nem szükséges saját kódot beilleszteni. Egy okostelefon teljes adatforgalmát monitorozni nagy és nem triviális feladat, mivel már szinte az összes alkalmazás generál valami forgalmat, nem beszélve a rendszer saját alkalmazásairól, szolgáltatásairól. Az ábra, a már ismert bejelentkezési kísérletet mutatja a modellben:

7. ábra Hálózatszűrési folyamat

A megvalósítás előnyei: 

Nincs szükség a monitorozandó alkalmazás forráskódjára, nem kell kódot injektálni bele



Csak az azonosításhoz szükséges adatokra és a szabálybázisra van szüksége a monitorozó programnak

A megvalósítás hátrányai: 

Nehezen behatárolható a szűrés időpontja



Nagy többletterhelést jelenthet kiszűrni a keresendő alkalmazás üzeneteit Egy rosszindulatú alkalmazás könnyen leterhelheti a monitorozást, ha pont ugyanakkor generál nagy forgalmat



20

3.3.4. Rendszerüzenetek elkapása Bonyolultabb, de bizonyos szemszögből talán a legjobb megoldás az lenne, ha a monitorozandó alkalmazás adatforgalmát az Android hálózati kommunikációjáért felelős komponenséből nyernénk ki. Azt kellene megvalósítani, hogy ha a monitorozandó alkalmazáshoz tartozó üzenet eljut a komponenshez, akkor az továbbítsa azt a monitorozó alkalmazás felé, aztán végezze a feladatát. Ezzel a megoldással mindkét alkalmazás komplexitása csökkenne, ámde egy rendszerbe belepiszkálni mindig kockázatos. Egy esetleges rejtett hibával, amit nem vettünk észre nem csak más, korábban jól működő alkalmazást ronthatunk el, hanem ami még rosszabb, az Android működésében is kárt tehetünk. A modellre alkalmazott példa ábrája:

8. ábra Rendszerüzenet elkapási folyamat

A megvalósítás előnyei: 

Nincs szükség a monitorozandó alkalmazás forráskódjára, nem kell kódot injektálni bele



A monitor csak az üzenetek feldolgozásánál aktív

A megvalósítás hátrányai: 

Körültekintően kell bánni a rendszerüzenetekkel

21

3.4. Üzenetek feldolgozása Potenciálisan több alkalmazásnak az üzeneteit kell majd feldolgozni, így azok feldolgozására célszerű már tervezési időben készülni. Az ASNE példaalkalmazással több, egymáshoz hasonló közösségi oldal üzeneteit (bejelentkezés, profil oldal betöltése, barátok listája…) fogjuk elkapni, tehát érdemes ezen oldalak üzeneteit megjelölni valamivel, ami egyértelműen azonosítja őket. Egy jó elgondolás lehet például az, ha az üzenetek végére odaírjuk a közösségi oldal nevét kapcsos zárójelekkel körülvéve, ezután az üzenetek elkülönítettek lesznek a többi oldal üzeneteitől. Az alkalmazás az üzeneteket a beérkezési sorrendjük szerint egy listában fogja tárolni. Ennek a listának a szekvenciáját kell, majd a konfigurációs fájl szabályai szerint vizsgálni. Az alkalmazások szabályleírói minden esetben egy külső fájlba kell, hogy kerüljenek, amit majd a monitorozó program olvas be és dolgoz fel. Fontos, hogy mind az emberek és maga a hardver is könnyen olvassa azt, ezért az erre specifikus XML formátumot fogom használni. Az üzenetek a hozzájuk tartozó alkalmazás tag-jei közé kerüljenek. Minden szöveges üzenethez célszerű egy azonosító számot rendelni, ekkor csupán egy szám feltüntetésével megadható, hogy egy adott azonosítójú üzenetnek mi a szövege, és hogy azt mely üzenetek követhetik helyesen.

9. ábra Üzenet feldolgozási ábra

Ha feldolgoztuk a monitorozott alkalmazáshoz tartozó szabályleírást és adott a lezajlott kommunikáció üzeneteinek listája, akkor már elég csak végig mennünk kettesével az üzeneteken és ellenőrizni, hogy létezik-e a szabályok között az adott üzenetpároshoz tartozó bejegyzés.

22

3.5. Önálló Laboratórium tapasztalatai A 3.3-as alfejezetben felsorolt lehetőség felkutatását az Önálló Laboratórium tárgy során végeztem. A félév során belemélyedtem az Android alkalmazások közti kommunikációs lehetőségekbe és megvalósítottam az üzenet továbbításos és a hálózati forgalom szűrési módot, így a monitorozás biztosított úgy is, ha ismerjük annak forráskódját, és úgyis ha nem. Az alkalmazás felhasználói része akkor, tulajdonképp csak egy Activity-ből állt egy szövegmezővel, amibe feldolgozott adatok kerültek, ebben a formában más felhasználónak nem adható ki. A program működés ellenőrzéséhez fejlesztettem egy egyszerű képfeltöltő alkalmazást, ami egy a galériából kiválasztott képet tölt fel a szerverre. A következőkben a korábban implementált két megoldással kapcsolatos tapasztalatokat írom le és elemzem.

3.5.1. Üzenet továbbításos módszer Az interneten rengeteg segítséget találni Broadcast témakörben. A szakmai cikkek olvasgatása után az implementáció nem volt különösen nehéz, nem ütköztem akadályokba. A példaalkalmazás ugyan működött, de a kevés állapot miatt nem lehetett rendesen letesztelni. A továbbiakban szükség lesz egy kellően komplex hálózati kommunikációt folytató alkalmazásra, amivel a monitorozó alkalmazás tesztelés alá vehető.

3.5.2. Hálózati kommunikáció szűrési módszer A hálózati kommunikáció szűrése, vagyis a megoldásnak az a része, amihez nincs szükség kód írására az alkalmazásba, jóval összetettebb volt. Az interneten böngészve ugyan sok olyan megoldást találni, mellyel az egyes alkalmazásokhoz tartozó hálózati kapcsolatokat tudjuk megfigyelni, de az átvitt hasznos adat olvasására nem találtam konkrét megoldás.

23

3.5.2.1.

netstat

Unix-szerű operációs rendszereken, amilyen az Android is, hálózati kapcsolatok megjelenítésére a netstat (network statistics) nevű eszköz a legalkalmasabb. Ez egy parancssori eszköz, mely képes megjeleníteni a kimenő és bejövő kapcsolatokat, az irányítótáblákat, és egyéb más hálózati statisztikákat, melyek a Unix rendszereken megszokott kötőjellel elválasztott paraméteres parancsokkal adhatóak meg. A netstat-ot általában hibakeresésre, hálózati problémák megtalálására illetve hálózati teljesítmény mérésre szokták használni. Ebben az esetben az üzenetek hasznos adatának kiolvasására netstat segítségével azonban nincs lehetőségünk.

3.5.2.2.

tcpdump

Egy másik, szintén Unix alapú operációs rendszereken működő eszköz a tcpdump. A tcpdump egy általános csomag analizáló parancssorból futtatható eszköz. Lehetőséget nyújt a felhasználónak a hálózaton küldött vagy fogadott csomagok megjelenítésére. Ez az eszköz már alkalmas lehet a feladatra, ha párosítani tudjuk a csomagot a monitorozandó alkalmazással, vagy magában a csomagban találunk olyan adatot, amivel be tudjuk azonosítani. A feladatot nehezíti, hogy a hálózaton átvitt adatok általában személyes információkat tartalmaznak és ezeket biztonsági okokból kódolni szokták. A kódolt adatokat, ha sikerül is elkapni, visszafejteni nem triviális dolog. További nehézség, hogy a tcpdump egy adminisztrátor szintű alkalmazás, amit mellesleg bináris formában fel kell másolni a telefonra, mert alapból nincs rajta. Ehhez a telefon root-olására van szükség, máskülönben az alkalmazások hálózati forgalom követésére semmilyen lehetőségünk nincs. (A root-olás egy folyamat, melynek eredményeképp privilegizált kontrollt kapunk az Android alrendszerei felett.)

24

3.5.2.3.

A fejlesztésnél alkalmazott szűrési módszer

A fejlesztésnél az alkalmazást a saját root-olt ZTE Blade típusú telefonomon futtattam és teszteltem. Az Önálló Laboratórium című tárgy végére sikerült egy működő, tcpdump-ot használó, alkalmazások csomagjait monitorozó alkalmazást fejlesztenem. Bár az alkalmazás a példaalkalmazásra működött, de ebben a formában még nem bonyolult használhatónak. A monitorozás kezdetén el kell indítani egy szolgáltatást, ami külön szálban elindítja a tcpdump-ot http get és post üzenet szűrővel és egy ideiglenes fájlba menti a kimenetet. A szolgáltatás leállítása után az alkalmazás beolvassa a tcpdump eredményeit és feldolgozza azt. A feldolgozás során a kiolvasott csomagokban keres a konfigurációs fájlban megadott üzenetekkel egyezőt, majd találat esetén a nyilvántartásba veszi. A feldolgozás után az üzenetek szekvenciáját összehasonlítja a szabálybázisban megadottakkal. A jelenlegi megoldás legnagyobb baja az, hogy, ha a felhasználó szolgáltatást nem állítja le időben, akkor a tcpdump-pal szűrt adatok mérete nagyon nagy, akár feldolgozhatatlanul nagy is lehet. Gondoljunk bele hány alkalmazás van telepítve a telefonra, ezekből mennyi fut a háttérben, és szinte mindegyik végez valamiféle hálózati kommunikációt. Ezek alapján a jövőben célszerű lenne egy olyan változtatás, ami a csomagokat egyből vizsgálja, feldolgozza, így sok erőforrást takaríthatnánk meg. Egy további finomítási lehetőség, a monitorozandó alkalmazás aktivitásának figyelése lenne, vagyis csak akkor használjuk a tcpdump-ot, mikor valamelyik felügyelt alkalmazásunk ténylegesen forgalmat generál. Egy ilyen automatizált felügyeletet a netstat együttes használatával lehetne megoldani.

25

4.

Implementáció Az Android-ra történő fejlesztés során szükség van egy szoftver fejlesztő

keretrendszerre (IDE), magára a fejlesztői környezetre (SDK) továbbá az egyszerű és gyors tesztelhetőség végett Android-os virtuális gépre, vagy használható saját telefon is. IDE + SDK Fejlesztésre az Android Studio legfrissebb 1.1-es verzióját használtam. Az Android Studio 2013-ban lett bemutatva kifejezetten Android-ra való fejlesztésre, így nem kell külön bajlódni az Android fejlesztői eszközök (ADT) letöltésével és telepítésével, az már tartalmazza ezeket, sőt egy arra való felületen a számunkra szükséges Android SDK-kat is összeválogathatjuk. Az SDK-kal elérhetővé válnak a fordításhoz és hibakereséshez szükséges alkalmazásprogramozási interfészek (API). Futtató környezet A fejlesztett program futtatására, kipróbálására, pedig a Genymotion Android emulátort. A Genymotion egy x86-ra épített Virtuális Android környezet és Virtualbox. Előnye, hogy nem egy ARM emulator, szóval teljesítménye jóval nagyobb, mint az Android SDK Emulator-nak. Az elkészült rendszer felépítése:

10. ábra A rendszer felépítése

A monitorozó alkalmazás beolvassa a konfigurációs fájlt, az abban talált alkalmazásokat a megadott móddal monitorozza és az eredményt egy XML fájlba menti.

26

A következőkben a megvalósítás fontosabb aspektusait szeretném részletekbe belemenően megmutatni. A könnyebb érthetőség végett a bonyolultabb részeknél diagramokat használok.

4.1. Monitorozó alkalmazás 4.1.1. Monitorozó alkalmazás osztályai Az alkalmazás elkészítéséhez 9 osztályt hoztam létre, melyek használatával elértem a célkitűzésben megfogalmazottakat és a programom képes paraméterül átadott alkalmazások hálózati forgalmának monitorozására. A megjelenítéshez két Activity-t hoztam létre. A konfigurációs fájl beolvasásáért és az eredmények kimentéséért a HandleXML osztály a felelős. A kétféle monitorozási módot a MyReceiver és a PacketAnalyzer osztály valósítja meg. Az alkalmazások adatfeldolgozására egy saját Application objektumot használtam. A következőkben ezen osztályok felelősségeit mutatom be. A projekt osztálydiagramja a 11. ábrán tekinthető meg, az osztályokat pedig az alfejezetek részletezik.

4.1.1.1.

Application

Kezeli az egyes alkalmazásokról tárolandó adatokat: 

alkalmazás neve



monitorozás típusa



üzenetváltás állapotai (lista)



állapot átmenetek (lista)



üzenetek (lista)



üzenet szekvencia helyessége Továbbá van egy Check() metódusa, ami végigmegy az eddig kapott üzeneteken.

Minden egyes üzenetet a neve alapján azonosítja a hozzátartozó átmenet állapothoz. Minden állapot átmenethez tartozik egy megengedett elő és utóállapot. A függvény ellenőrzi, hogy a beazonosított állapotok helyes sorrendben követik-e egymást. Az üzenetek listához tartozik még egy Clear() metódus is, ami felhasználói kérés esetén alaphelyzetbe állítja azt. 27

11. ábra Monitorozó alkalmazás osztálydiagramja

28

4.1.1.2.

ApplicationState

Egy adott azonosítójú állapothoz kapcsol beszédes leírást.

4.1.1.3.

ApplicationTransition

Egy objektum a hálózati üzenetek sorrendiség ellenőrzéséhez. Tárolja egy adott alkalmazás hálózati forgalmához tartozó átmeneteket. Ez alapján tudunk később következtetéseket tenni arról, hogy az új üzenet után helyes maradt-e a szekvencia. Az osztály minden átmenethez tárolja azt, hogy melyik állapotból jött az üzenet és ez alapján melyik állapotba léphet át, valamint tárolja az átmenethez tartozó üzenetet. Az olvashatóság végett az üzenet első karaktere mindig egy „!”, vagy „?”, ami az üzenetváltás irányára utal. Ha „!” karakterrel kezdődik, akkor az alkalmazás küldte azt a szervernek, ha „?”, akkor a kliens fogadta a szervertől.

4.1.1.4. A

ApplicationMessages monitorozandó

alkalmazás

üzenetváltásainak

tárolására

való.

Ezen

objektumokból álló lista tartalma alapján tudunk következtetéseket levonni a szekvencia helyességéről. Végigolvassuk a listát, majd vizsgáljuk, hogy az adott üzenethez tartozó állapotot elérhetjük-e az előző állapotból. Ehhez a konfigurációs fájlban specifikált ApplicationTransition listát használjuk.

4.1.1.5.

HandleXML

Ez az osztály felelős a konfigurációs fájl beolvasásáért és feldolgozásáért, valamint végzi az egyes monitorozott alkalmazások eredményeinek XML konvertálását, és a fájlba mentést. Ez minden új üzenet feldolgozás után megtörténik és minden alkalmazáshoz egy külön XML fájl tartozik, amelyeket a monitorozott alkalmazás neve és a vételezés dátuma azonosít. A fájl az okostelefon külső tárhelyén a HttpPacketMonitor mappába kerül mentésre. Az XML fájlok olvasására, generálására az XMLPullParser interfészt, a fájlba íráshoz az XMLSerializer interfészt használtam. Az XML típus miatt az adatok egyszerűen kezelhetőek és nyitottak a változtatásra, az írás/olvasás, pedig az interfészeknek köszönhetően, algoritmikusan megy. 29

4.1.1.6.

MyReceiver

Ez az osztály valósítja meg azt a monitorozási módot, mikor a figyelt alkalmazás a hálózati kommunikációs üzeneteit továbbítja az alkalmazásomnak. A továbbítás módját broadcast üzenetek küldésével oldottam meg. A programban a kívánt esemény bekövetkezése után kell, hogy lefusson az üzenet szórás, amit nekünk kell beleírni, vagyis szükség van a forráskódra. Az alkalmazás az intent megoldáson alapul, ami lehetővé teszi a program kód és a különböző alkalmazások közötti futásidejű kötés, összekapcsolás (runtime binding) megvalósítását. Ennek legjelentősebb felhasználása az aktivitások, műveletek dinamikus indításában rejlik. Alapja egy, a végrehajtandó műveletek (action) absztrakt leírását tartalmazó passzív adatstruktúra. A hálózati üzenet kiváltási helyén létrehozok tehát egy intent-et. Az intent extrájába elhelyezem a továbbítandó üzenetet, beállítom a végrehajtási típusát, majd a sendBroadcast hívással szétküldöm az üzenetet. Ezt a következő kódrészleten figyelhetjük meg. protected static void broadcastCustomIntent(String msg) { String pn = MainActivity.PACKAGE_NAME; Intent intent = new Intent("MyCustomIntent"); intent.putExtra("message", msg); intent.putExtra("appname", context.getResources().getString(R.string.app_name)); intent.setAction("hu.bme.iemqra.INTENT_with_msg_data"); context.sendBroadcast(intent); } 12. ábra Broadcast üzenetet kiváltó függvény

A monitorozó alkalmazásban a broadcast elkapásához először hozzá kell adni egy intent-filtert a manifest fájlhoz, amivel megadjuk, hogy milyen broadcast üzenetekre figyeljen az alkalmazás. Ezek után a MyReceiver osztályban, ami a BroadcastReceiver osztályból öröklődik, felüldefiniáljuk az onReceive függvényt. A függvény megkapja az elkapott broadcast intent-et amiből visszafejti a hordozott információit és feldolgozza azokat. A feldolgozás után hívja meg az Application osztály Check() függvényét, ami megvizsgálja a szekvencia helyességét. Ha az ellenőrzés során helytelen szekvenciát kapunk, akkor figyelmeztetésként beillesztünk egy „!! FAILED !!” sort, ami a későbbi futásokra nem lesz hatással. Abban az esetben, ha az üzenetet azonosítani se tudjuk, vagyis nem találjuk a konfigurációs fájlban, akkor egy Toast üzenetben értesítjük erről a felhasználót. 30

4.1.1.7.

PacketAnalyzer

Ez az osztály valósítja meg azt a monitorozási módot, mikor az okostelefonon átmenő hálózati forgalmat figyeli és szűri az alkalmazás. Az analyzer a tcpdump nyílt forráskódú, hatékony, parancssori (command line) interfész csomag sniffer alkalmazáson alapszik. A programot root-olt telefonról, superuser jogosultságokkal kell indítani a promiscuous módú használathoz. Erre a célra a Wireshark (korábban Ethereal) is alkalmas lenne, ám annak GUI felülete nem szkriptelhető. A PacketAnalyzer osztály a Service osztályból öröklődik, így az biztonságosan tud

külön

szálon

a

háttérben

futni.

A

következő

paranccsal

Runtime.getRuntime().exec("su") létrehoztam egy root jogokkal ellátott folyamatot, majd futtatom a következő parancsot: tcpdump –i any –p -nnvvXSs 1514 -A port 80. A tcpdump paraméterezésének jelentései: interface kapcsoló -i any promiszkusz mód tiltása -p ASCI kódolás -A összegyűjti az első 1514 bájtnyi adatot -s1514 payload hozzáadása -X részletes adatok megjelenítése -vv abszolút megjelenítés relatív helyett -S nem fedi el a címeket névvel -nn A tcpdump manuális leállítása (ezt úgy lehetne automatizálni, hogy például netstat-al ellenőrizzük, hogy fut-e még a monitorozott alkalmazás) után feldolgozásra kerül az, majd a kiértékelt eredmény az alkalmazás nyilvántartásába kerül.

4.1.2. Felhasználói felület A monitorozó broadcast része ugyan nem igényel felhasználói beavatkozást, és egy XML megjelenítővel visszanézhetőek lennének az eredmények is, de mégis csak kényelmesebb egy olyan felület, amit a tervezési résznél mutattam, plusz a tcpdump-hoz úgyis kell néhány kezelőgomb. Az implementáció során a tervezett rajzot követtem.

31

4.1.2.1.

MainActivity

Ez az osztály valósítja meg alkalmazás motorját, itt van statikusan inicializálva az Application objektum egy listája, amit a többi osztály is használ. Az Activity osztályból öröklődik, így saját grafikus felülete van, mely képes kezelni a felhasználó interakcióit. Ahogy arról már fentebb beszéltem az Activity különböző életciklus változásiról értesítő „callback”-eket felüldefiniálhatjuk. Az Activity onCreate() metódusába kell minden inicializáló részt megvalósítanunk, mert az csak egyszer az Activity létrejöttekor fut le. Alkalmazásom esetében itt végzem el a konfigurációs fájl beolvasását, vagyis hívom meg a HandleXML osztály parseConfig() metódusát. Ezután a monitorozandó alkalmazásokhoz készítek programozottan gombkezelőket. Ugyan minden Activity-hez tartozik egy „layout” fájl, ez definiálja a felhasználói interfész vizuális elrendezését, amihez az Android biztosít egy egyszerű XML szótárt, de ez nem tud dinamikusan változó adatokat kezelni. Azt, hogy milyen alkalmazásokat kell majd monitorozni mindig a konfigurációs fájlból fog kiderülni, nem tudjuk azt a programba égetni. Egy gomb és eseménykezelőjének programozott implementációjának menete a következő: 

inicializálunk egy gombot



beállítjuk a gomb specifikus értékeket, mint szöveg, szín, azonosító…



egy layoutparam változóban tudunk illeszkedéssel, mérettel kapcsolatos dolgokat beállítani, majd a gomb setLayoutParams() metódusával hozzáadni



megvalósítjuk az eseménykezelőt



a findViewById() hívással megkeressük azt a layout-ot, ahova helyezni szeretnénk a gombot és az addView() metódussal hozzáadjuk

Az alkalmazásom esetében a gombokat egy erre a célra létrehozott LinearLayout-hoz adom hozzá. Mindegyiket új sorba, vízszintesen középre helyezem el. A gomb szélessége minden esetben pont a kijelző fele lesz színe pedig az alkalmazáshoz tartozó eddigi üzenetek helyességétől függően lesz zöld vagy piros.

32

Az ide vonatkozó kódrészlet: final Button myButton = new Button(this); myButton.setText(a.getName()); myButton.setTag(a.getName()); myButton.setTextColor(Color.WHITE); LinearLayout.LayoutParams lp = new LinearLayout.LayoutParams(LinearLayout.LayoutParams.WRAP_CONTENT, LinearLayout.LayoutParams.WRAP_CONTENT); Display display=((WindowManager) getSystemService(Context.WINDOW_SERVICE)).getDefaultDisplay(); lp.width = display.getWidth()/2; lp.gravity= Gravity.CENTER_HORIZONTAL; lp.setMargins(0,10,0,0); myButton.setLayoutParams(lp); if(a.isCorrect()){ myButton.setBackgroundColor(Color.parseColor("#205212")); } else{ myButton.setBackgroundColor(Color.parseColor("#800F0F")); }

A gombok esemény kezelője lenyomáskor világosabb színre állítja azt, felengedéskor pedig elindítja a DetailedActivity-t az intent extrájában a saját nevével. Ezt a következő kódrészlet mutatja: myButton.setOnTouchListener(new View.OnTouchListener() { public boolean onTouch(View v, MotionEvent event) { switch ( event.getAction() ) { case MotionEvent.ACTION_DOWN: if(a.isCorrect()) myButton.setBackgroundColor(Color.parseColor("#35D447")); else myButton.setBackgroundColor(Color.parseColor("#FF001E")); break; case MotionEvent.ACTION_UP: if(a.isCorrect()) myButton.setBackgroundColor(Color.parseColor("#205212")); else myButton.setBackgroundColor(Color.parseColor("#800F0F")); Intent myIntent = new Intent(MainActivity.this, DetailedActivity.class); myIntent.putExtra("key", a.getName()); MainActivity.this.startActivity(myIntent); break; } return true; } });

Az onResume() callback felüldefiniálásban, vagyis mikor újra előtérbe kerül a MainActivity ellenőrzöm, hogy a tétlen idő óta változott-e az alkalmazások üzeneteinek sorrend helyessége, majd állítom ehhez a gombok színeit.

33

A MainActivity-ben van még a tcpdump-os monitorozási mód gombjainak az eseménykezelője

megvalósítva.

Az

erőforrások

takarékossági

miatt

a

start

megnyomására csak akkor indul el a PacketAnalyzer szolgáltatás, ha van olyan alkalmazás, amihez tcpdump monitorozási mód van beállítva, ha nincs, arról Toast üzenetben kap értesítést a felhasználó. Stop gomb megnyomásakor a szolgáltatás leáll. A MainActivity függvénye még a notify() ami igazából az alkalmazások üzenetszekvenciájának ellenőrzéséhez tartozik. Ha az hibát talál, akkor arról a felhasználót egy NotificationBar-ban elhelyezett üzenettel is értesíti. Ilyet csak Activityből származtatott osztály tud elhelyezni, azért került ide. A függvény létrehoz egy függő intent-et, aminek az extrájába helyezi az alkalmazás nevét, és a notifikációra kattintva elindítja a DetailedActivity-t.

13. ábra MainActivity és NotificationBar futáskép

4.1.2.2.

DetailedActivity

A DetailedActivity a monitorozott alkalmazások állapotainak megjelenítéséért felelős. Azért, hogy az összes alkalmazást egy Activity-ben jeleníthessük meg és ne kelljen külön-külön Activity-ket csinálni, a startActivity() hívás intent paraméter extrájába egy kulcs-érték párral berakjuk a kívánt alkalmazás nevét. Az Activity az 34

onCreate() inicializáló metódusban kiolvassa ezt a beállítást az intent extrájából és átadja a fillFields() függvénynek. Ez a fillFields() függvény felelős azért, hogy az Application listából kikeresse a részletezni kívánt alkalmazást és feltöltse a tableLayoutban szereplő mezőket, úgy, mint monitorozott alkalmazás neve, monitorozás típusa, alkalmazáshoz tartozó hálózati üzenetek és a sorrendiségük helyessége. A layout-hoz tartozik még egy gomb, amit, ha megnyom a felhasználó törli az alkalmazáshoz tartozó eddigi üzeneteket. Erre akkor lehet szükség, ha régóta monitorozunk és a sok üzenet miatt kezelhetetlen az amúgy görgethető felületű megjelenítő. A gomb színe sárgára vált, ha a szekvenciában valami hiba van. Mikor az alkalmazás újra előtérbe kerül, az onResume() callback-ben újra meghívódik a fillFields() metódus, hátha változás történt, amíg más Activity volt előtérben. A sok Activity váltás miatt elkerülendő, hogy a BackStack-re kerüljenek az előző állapotú Activity-k, ezért a DetailedActivity-re váltáskor mindig töröljük a listát, garantálva, hogy csak egy, a legfrissebb legyen felül. Ezt az intent flag állításával érhetjük el: Intent myIntent = new Intent(c, DetailedActivity.class); myIntent.setFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP | Intent.FLAG_ACTIVITY_SINGLE_TOP);

A DetailedActivity működéséről a következő képeket készítettem:

14. ábra DetailedActivity futásképei

35

4.1.3. A monitorozó aktivitás diagramja

15. ábra Monitorozó alkalmazás aktivitás diagramja

A diagramon jól nyomon követhető, ahogy a beolvasott konfigurációs fájl adta alkalmazásokon végig iterál a monitorozó és annak típusától függően végzi a Broadcast-os vagy a tcpdump-os monitorozást, majd kiértékeli az eredményt és azt fájlba írja.

36

4.2. Az ASNE könyvtár A következőkben a GitHub-os ASNE könyvtárról és alkalmazásról, majd azt felhasználva a saját példa alkalmazásomról fogok írni. Mikor letöltöttem a projektet az utolsó módosítások fél éve voltak rajta, így nem is volt annyira meglepő, hogy nem fordult elsőre a kód. A legtöbb probléma a Gradle projekt automatizáló és függőség követő eszközzel volt. Ez részben egy frissített verzió miatt volt, ami miatt nem találta az átnevezett függvényeket, illetve elavult könyvtárakat használt a közösségi oldalakhoz. A problémák kiküszöbölése után elindult az ASNE alkalmazás. A monitorozó alkalmazásommal ellentétben az ASNE alkalmazás Fragmenteket használ. A Fragment-ek nagyon hasonlóak az Activity-k, tulajdonképpen egyfajta al-Activity-k. Önálló életciklussal rendelkeznek és egy időben akár több Fragment-et is megjeleníthetünk a felhasználói felületen, rugalmasan kezelhetőek és mindegyik önálló, saját logikával rendelkezik. Minden Fragment egy Activity-hez van rendelve. Önálló BackStack-kel rendelkeznek, vagyis megoldható, hogy a vissza gomb hatására a korábbi előtérben lévő Fragment-ekre ugráljunk, illetve ha elfogytak, akkor ugorjunk az előző Activity-re.

37

4.2.1. Az ASNE alkalmazás Az ASNE osztálydiagramját az alábbi. ábra mutatja be.

16. ábra ASNE osztálydiagramja

38

A projekt tehát egy Activity-vel rendelkezik, ami először megjeleníti a MainFragment-et, ami egy bővíthető gomblista a különböző közösségi hálózatokhoz. Egy gombra kattintva a közösségi oldal API-ján keresztül felugrik a bejelentkező felület, vagy ha már korábban bejelentkeztünk, akkor lekéri profilunkat és megjeleníti a ProfileFragment. A ProfileFragment-ből megtudjuk nézni barátaink listáját, amit a FriendsFragment jelenít meg, vagy megoszthatunk valamit. Az egész projekt lényegében csak egy keret pár Fragment-el a főbb API hívások működéseinek szemléltetésére. Az alkalmazás magja az ASNE könyvtár SocialNetwork osztálya. Ebben az osztályban vannak összegyűjtve a közösségi oldalak API-jai. Tehát, ha például beakarunk jelentkezni az egyik közösségi oldalra, akkor példányosítanunk kell a SocialNetwork osztályt és meghívni a requestLogin() metódusát.

4.2.2. Az alkalmazás továbbfejlesztése A letöltött alkalmazásban megosztás funkciója a legtöbb közösségi oldal APIjával nem működött, vagy egy, a programba égetett szöveget tudott csak megosztani, ezért azt tovább fejlesztettem. Először a ProfileFragment layout-ját írtam át. A személyes profil adatok rész alá csináltam egy szövegbeviteli mezőt és két gombot a szöveg, illetve a kép megosztáshoz.

17. ábra A változtatott Fragment kinézete

39

Ezután implementáltam a két gomb eseménykezelőjét. A megfelelő API függvényt a SocialNetwork osztályból kerestem ki. Szöveget megosztani a requestPostDialog(), képet a requestPostPhoto() metódussal tudunk. Sajnos az egyes közösségi oldalak, mint például a Facebook is megszigorította az ismeretlen alkalmazások jogosultságait, így képet egyáltalán nem, de szöveget is csak link formájában enged megosztani. Figyelmeztetésként az eseménykezelőt elláttam felugró dialógusokkal, illetve magába a szövegbeviteli mezőbe is instrukciókat olvashatunk, ha a facebook Fragment töltődött be. A Fragment-ek a közösségi oldalakat id-jük alapján azonosítják. Ezt az id-t használják például a keretek és a gombok közösségi oldal specifikus színezésére. /** * SocialNetwork Ids in ASNE: * 1 - Twitter * 2 - LinkedIn * 3 - Google Plus * 4 - Facebook * 5 - Vkontakte * 6 - Odnoklassniki * 7 - Instagram */

18. ábra Figyelmeztetések

40

Az üzenettovábbításos monitorozáshoz csupán két új függvényt írtam hozzá a MainActivity-hez. A getSocialPlatform() metódus, ami visszaadja id alapján a közösségi hálózat nevét (erre azért van szükség, hogy meg tudjunk különböztetni kétféle közösségi

hálózathoz

való

bejelentkezést)

és

broadcastCustomIntent()

az

üzenetszóráshoz: protected static void broadcastCustomIntent(String msg) { String pn = MainActivity.PACKAGE_NAME; Intent intent = new Intent("MyCustomIntent"); intent.putExtra("message", msg); intent.putExtra("appname", context.getResources() . getString(R.string.app_name)); intent.setAction("hu.bme.iemqra.INTENT_with_msg_data "); context.sendBroadcast(intent); } protected static String getSocialPlatform(int num){ String platform; switch(num){ case 1: platform = "twitter"; break; case 2: platform = "linkedin"; break; case 3: platform = "googleplus"; break; case 4: platform = "facebook"; break; default: platform = "not defined"; break; } return platform; }

Ezek után már csak elkell helyezni a függvényhívást azokra a helyekre ahol kapcsolatot létesítünk a közösségi hálózat kiszolgálójával. Például a kijelentkezés gomb eseménykezelőjébe, hogy a kijelentkezés eseménye bekerüljön a monitorozó alkalmazás üzenetfeldolgozójába. case R.id.action_logout: socialNetwork.logout(); getActivity().getSupportFragmentManager().popBackStack(); MainActivity.broadcastCustomIntent("Logout [" + MainActivity.getSocialPlatform(networkId) + "]"); return true;

41

Az alkalmazáshoz tartozó eseményátmenetek a 19. ábrán tekinthetőek meg. A konfigurációs fájlhoz tartozó szabályokat ezek alapján hoztam létre.

19. ábra ASNE akciódiagramja

42

5.

Ellenőrzés / Tesztelés Az alkalmazásokat, egymástól külön, inkrementálisan fejlesztettem. Ennek során

számomra új technológiákat kellett megértenem és használnom, ezek működését külön ellenőriznem majd integrálnom a már meglévő alkalmazásba. A teszteket virtuális Google Galaxy Nexus (4.2.2) telefonnal illetve a saját első generációs ZTE Blade (4.0.4) telefonommal végeztem. A megvalósított monitorozó alkalmazás alkalmas a kiválasztott applikáció hálózati üzeneteinek analizálására, függetlenül attól, hogy annak forráskódja hozzáférhető-e vagy sem. Ezt a két működést külön fogom tesztelni pozitív és negatív esetekre is. A felhasználó okozta hibás működésre részben felkészültem, ám ezek tesztelésére ebben a fejezetben nem térek ki.

5.1. Hozzáférhető forráskódú alkalmazással való tesztelés Erre az esetre monitorozandó alkalmazásként az ASNE példaprogramot választottam.

A

broadcast

üzenetek

eldobásához

szükséges

függvényeket

implementáltam és létrehoztam a konfigurációs fájlt, amit a monitorozó alkalmazás fog használni az üzenetsorozat kiértékeléshez. A tesztek során a példaprogram következő funkcionalitásait vizsgáltam: 

bejelentkezés facebook-ba



profil oldal betöltése



www.bme.hu link megosztása



kilépés



bejelentkezés twitter-be



BME I épület képének megosztása



barátok megnézése



vissza a profil oldalra



kilépés

43

A teszt során a monitorozó alkalmazásom sikeresen analizálta és azonosította a hálózati protokoll üzeneteket, mindamellett a megosztott link és a hozzá tartozó kép hiánytalanul, változtatás nélkül megjelent a közösségi oldalon (lásd a következő ábrán).

20. ábra: A sikeresen lefutott teszt

Az ASNE alkalmazás szabályában szándékosan benne hagytam egy hibát, hogy azt az esetet is lehessen tesztelni mikor egy üzenet rossz sorrendben érkezik a monitorozó alkalmazáshoz. A beállított szabály szerint a felhasználó csak akkor léphet át egy új közösségi oldalra, ha az előzőekből már sikeresen kijelentkezett, azaz példaképpen a következő eseménysorozaton végighaladva, a monitorozó alkalmazásnak hibás működést kell jelentenie: 

bejelentkezés facebook-ba



profil oldal betöltése



barátok megtekintése



profil oldal betöltése

o visszatérés a főmenübe 

bejelentkezés twitter-be 44

Ahogy arra számítani lehetett, mikor a twitter-be próbálunk bejelentkezni figyelmeztetést kapunk, illetve a részletezésnél is látjuk az üzenetek hibás szekvenciáját (lásd ábra).

21. ábra Hibás működése tesztelése

5.2. Nem tesztelés

hozzáférhető

forráskódú

alkalmazással

való

Ebben az esetben a monitorozandó alkalmazás szintén az ASNE program volt, ám a kiértékelésnél az előző esettel ellentétben most csak a tcpdump szűrés eredményeire hagyatkoztam. Mivel nem saját kódról van szó először azt vizsgáltam, hogy találok e bármi jellegzetes információt a szűrt csomagokban, amik alapján egyértelműen azonosítható például az az esemény, amikor a profil adatunkat kérjük le a közösségi oldal szerverétől. Ha emulátoron vizsgáljuk a kommunikációt, akkor nyugodtan használhatjuk a számítógép valamely grafikus csomag analizáló szoftverért, mint a WireShark, vagy Fiddler. Abban az esetben, ha a teszt valódi Android, és nem virtuális okostelefonon fut, ahol Wireshark hálózati analizátor nem, de tcpcump érhető el, a hálózati adatforgalom analizálása offline módon történhet. A tcpdump és a WireShark ugyanazt a pcap könyvtárat használja a csomagok szűrésére, mi lehetővé teszi a lementett hálózati

45

forgalom offline analizálását az a lementett szűrési eredmények átmozgatása után a telefonról a számítógépre. A számítógépen például a WireShark ugyanazt a grafikus felületet nyújtja az analízisre, mint a virtuális emulált telefon esetében. Azért, hogy egy részletesebb, jobban kezelhető információt kaphassak az okostelefon használata során történt hálózati kommunikációról, a Fiddler alkalmazást használtam. A monitorozó alkalmazást az alább leírt módon konfiguráltam a Fiddlerhez, hogy az meg tudja jeleníteni az ugyanazon hálózaton levő telefon HTTP/HTTPS csomagjait: 

A virtuális Android hálózati adapterét Bridged-re állítottam, ezáltal standard 192.168.x.x IP címet kap a router-től és úgy fog viselkedni, mint bármely más fizikai eszköz a hálózaton.



A Fiddler beállításai: o 8888-as port-on hallgatózás o távoli számítógép kapcsolódásának engedélyezése o HTTPS forgalom elkapása és visszafejtése



A virtuális android haladó wifi beállításainál manuálisan hozzáadtam a 8888-as proxy port-ot és gazdagépnek beállítottam a számítógépnek kiosztott IP-t.

Az elkapott hálózati csomagokat elemezve azt tapasztaltam, hogy a használt közösségi hálók (facebook, twitter, linkedin) mindegyike a bejelentkezést követően SSL titkosítást használ a kliens és szerver közti kommunikációhoz. A titkosítás visszafejtésében a proxy használata nem segített. Megfigyelhetjük vele a szerver publikus kulcsát és a domain nevét, mivel egyik sem titkos, de mindez a csomagok visszafejtésre nem elég, ráadásul a közösségi oldalak szerverei nem fogadják el a proxy által továbbított tanúsítványt. A HTTPS csomagok visszafejtésével nem volt időm komolyabban foglalkozni a szakdolgozatom keretein belül, bonyolultsága miatt azt inkább egy külön dolgozat keretében képzelem el.

46

22. ábra: Az üzenetküldés titkosítása

Az ábrán egy tetszőleges üzenet elküldése követhető nyomon a tikosítással együtt. Jól látható, hogy tcpdump-pal már csak a titkosított üzeneteket kaphatjuk el, amikből nem vonhatunk le következtetéseket. Ahhoz, hogy forráskód nélküli alkalmazások titkosított hálózati üzeneteit elemezhessük a 3.3.4-es fejezetben leírt módszert kellene kipróbálni, amire nem jutott időm.

47

6.

Összefoglalás Egy olyan rendszer elkészítése volt a feladatom, mely felügyelni tudja más

Android alkalmazások hálózati működésének megbízható működését, hibás esetben, pedig figyelmeztetni arról a felhasználót. A dolgozatom során bemutattam a probléma hátterét, a kiválasztott megoldást, a tervezés részletes lépéseit, a rendszer megoldás implementálását, és az elkészült program tesztelését. A fejlesztés során új technológiákat ismertem meg, új kihívásokkal kerültem szembe, sikeresen mélyítettem el tudásomat az Android platform ismereteiben és a Java programozásban, valamint új ismeretekre tettem szert a hálózati kommunikáció témakörében. A tervezés során külön kitértem az ismert és ismeretlen forráskódú alkalmazások problémakörére, és kidolgoztam ezekre egy-egy monitorozási módszert, melyekkel megfigyelhető az általuk generált hálózati forgalom. A dolgozatomban két monitorozó módszer implementálására jutott idő. Egy az ismert forráskódú alkalmazások és egy az ismeretlenek monitorozásához. Az alkalmazás kipróbálásához egy külső kellően komplex nyílt forráskódú alkalmazást használtam, kiegészítve új, saját funkciókkal a tesztelhetőség végett. A tesztelés eredménye összességében sikeres volt, viszont egyelőre nem minden hálózati üzenet figyelhető meg vele.

6.1. Konklúzió Kijelenhető, hogy azok az alkalmazások, amelyek forráskódja hozzáférhető, tökéletesen monitorozható és megfigyelhető! Mindehhez a rendszerbe csatlakozásuk előtt csak minimális kódbővítés szükséges. Szükség van továbbá egy új függvényre, ami a hálózati üzeneteknek a monitorozó alkalmazáshoz való továbbításáért lesz felelős. Ezután elégséges ezt a függvényt meghívni a kód azon részein, ahol implementálva vannak a hálózati kommunikáció monitorozandó, számunkra érdekes részei. Ugyanakkor azon alkalmazások esetében, amelyek forráskódjához nem férünk hozzá, a hálózati forgalmuk nem minden esetben teljesen megfigyelhető.

48

Mindenekelőtt, lévén a megfigyelés során a telefon teljes hálózati forgalmát analizáljuk, a megfigyeléshez ismerni kell a megfigyelendő alkalmazás hálózati jellemzőit (pl. protokoll, port, stb.). Erre a legegyszerűbb módszer az lehet, ha felvesszük a kapcsolatot az alkalmazás fejlesztőjével és megkérdezzük, hogy miről ismerhetőek fel az alkalmazás csomagjai. Ha ez nem lehetséges, egy hálózati csomag analizáló szoftver segítségével keresnünk kell a csomagokban jellegzetes, visszatérő információt, ami segítségével összeállíthatjuk az alkalmazáshoz tartozó szabályleírást. A megvalósított módszer egyetlen hátránya, hogy, ha a kiszemelt alkalmazás titkosítást használ, akkor azokat az üzeneteket nem tudjuk azonosítani, vagyis azok nem megfigyelhetőek a monitorozó alkalmazással.

6.2. Továbbfejlesztési lehetőségek Az elkészült monitorozó alkalmazás tehát jelenleg nem tud olyan alkalmazást megfigyelni, amelyik titkosítást használ és emellett nem ismert a forráskódja. Mindenképpen érdemes lenne ezt a korlátozást feloldani. Első körben célszerű lenne kipróbálni

a

3.3.4-es

fejezetben

leírt

módszert.

Feltéve,

hogy

a

hálózati

rendszerüzenetek elkapásával valószínűleg láthatóvá válnának a csomag analízis számára a titkosítás előtt elküldött csomagok is, ezek a csomagok már alkalmasak lennének a hálózati protokoll analízisére is. Továbbá, a monitorozott üzenetek most, beérkezési sorrendben egy listában kerülnek eltárolásra. Érdemes lehet azokhoz egy időbélyeget kapcsolni, hiszen az alkalmazás huzamosabb használatakor a sok hasonló bejegyzés közül nehéz lenne időben azonosítani a hiba keletkezését. Emellett a monitorozó alkalmazás konfigurációs fájlja jelen verzióban csak szövegszerkesztővel olvasható illetve, módosítható. Megfontolandó a konfiguráció módosításának lehetőségének az applikációba emelése, például egy fülön, ahol azt ellenőrizheti vagy akár szerkesztheti is a felhasználó. Végezetül nagyobb átalakítást igényelne, ugyanakkor kényelmes felületen nyernénk vele a monitorozó alkalmazás funkcióihoz egy weboldalt létrehozni. A weboldal bejelentkezés után megjelenítené az adott telefonon megfigyelt alkalmazások kiértékelését. Külön előnye lenne a megoldásnak a távoli elérés egy olyan nem hétköznapi használatra szánt telefonhoz, amely valamilyen dedikált feladatot lát el, ám az nem könnyen hozzáférhető vagy földrajzilag távol van (pl.: riasztóra bekötött telefon, vagy társasház kapuját működtető telefon…). 49

Irodalomjegyzék [1] Ekler Péter, Fehér Marcell, Forstner Bertalan, Kelényi Imre (2012): Android-alapú szoftverfejlesztés – Az Android rendszer programozásának bemutatása, Szak Kiadó Kft. ISBN 978-963-9863-27-9

[2] Android hivatalos dokumentációja http://developer.android.com/guide/index.html

[3] Ekler Péter, Fehér Marcell, Erdődy-Nagy Zsombor, Gerencsér Péter: Android alapú szoftverfejlesztés, BME (VIAUAV21) https://www.aut.bme.hu/Course/android [4] Armel Bourgon (2011 június 2): Tcpdump futtatása http://abd-tech.blogspot.hu/2011/06/run-tcpdump-from-android-application.html

[5] Ismeretlen szerző (2013 október 18): Broadcast üzenet küldése, elkapása http://hmkcode.com/android-sending-receiving-custom-broadcasts/

[6] Sunil Gupta (2013 szeptember 18): Fájl feltöltése szerverre http://sunil-android.blogspot.hu/2013/09/file-upload-on-php-server-in-android.html

[7] Pete Houston (2011 október 27): XML feldolgozás, exportálás http://xjaphx.wordpress.com/2011/10/27/android-xml-adventure-create-write-xml-data/

[8] Ismeretlen szerző (2013 július 6): Android notifikáció http://androidexample.com/Create_Notification_Alert__Android_Example/index.php?view=article_discription&aid=102&aaid=124

[9] Evgeny Gorbin (2014 szeptember 2): ASNE alkalmazás https://github.com/gorbin/ASNETutorial

[10]

Brian (2013 november 6): Android mobil web forgalmának elkapása Fiddler-rel

http://www.cantoni.org/2013/11/06/capture-android-web-traffic-fiddler

[11] Ismeretlen szerző (2014 augusztus 5): SSL forgalom visszafejtése Wiresharkban http://support.citrix.com/article/CTX116557

[12]

VirtualBox hivatalos dokumentációja: 6. fejezet virtuális hálózatok

https://www.virtualbox.org/manual/ch06.html

50