Uno Studio Empirico sui Consumi Energetici in Ambiente Android e Possibili Attacchi di Sicurezza

TESI IN SICUREZZA - LUGLIO 2013 1
Uno Studio Empirico sui Consumi Energetici in
Ambiente Android e Possibili Attacchi di
Sicurezza
Giuseppe De Rosa, Marco Fazzone, Sabato Napolitano, Michele Tufano
Università degli Studi di Salerno, 84084 Fisciano (SA), Italia
{g.derosa30, m.fazzone, s.napolitano16, m.tufano10}@studenti.unisa.it
Sommario—Viene presentato uno studio di analisi dei consumi energetici su dispositivi mobili Android. Sono stati
misurati i consumi energetici delle varie tecnologie web messe a disposizione da HTML5 e Javascript. I risultati di
tali misurazioni sono stati ottenuti attraverso dei test eseguiti con l’ausilio della suite di Energy-Testing BatteryBench
realizzata a tale scopo. I test hanno evidenziato quali tecnologie risultano essere maggiormente dispendiose in termini
di consumo energetico. Quest’ultime sono state utilizzate per realizzare un attacco di Denial of Service energetico altres`ı
chiamato Battery Drain.
Index Terms—Android, Sicurezza, Consumi, Energia, Batteria, Test, Web, HTML5, Codec.
!
1 INTRODUZIONE
OGNI giorno 1,3 milioni di nuovi dispositivi
Android, tra tablet e smartphone, vengo-
no attivati. La base di installazioni conta 480
milioni di dispositivi nel mondo.
International Data Corporation (IDC) stima che
il solo mercato dei tablet supererà quello dei PC
nel 2015 [1], mentre se si considera l’intero mer-
cato mobile (smartphone + tablet) il sorpasso a
discapito dei PC è già avvenuto.
L’utenza si sta spostando sempre più sul
mobile, e con esso, di conseguenza, anche
quell’insieme di operazioni che finora erano
esclusivamente ad appannaggio dei computer.
Oggigiorno i sempre più evoluti dispositivi
mobile gestiscono una miriade di informazioni
personali ed attività, rappresentando per molte
persone strumenti indispensabili nel quotidia-
no. Browsing internet, social networking, com-
• Prof. Alfredo De Santis
E-mail: ads@dia.unisa.it
• Dr. Aniello Castiglione
E-mail: castiglione@acm.org
• Prof. Ugo Fiore
E-mail: ufiore@dia.unisa.it
Esame di Sicurezza, Corso di Laurea in Informatica
munication e gaming, tra le principali attività
svolte con essi.
Lo sviluppo hardware di questi dispositivi
mostra una crescita esponenziale, supportata
dall’ampio bacino d’utenza e da una forte
concorrenza tra le case costruttrici.
Ogni anno processori, memorie, display e
altre componenti diventano sempre più veloci,
migliori ed economiche, perlomeno per chi le
produce. Vengono offerte maggiore capacità,
pixel del display e potenza computazionale.
La legge di Moore1
a proposito resta ancora
valida e la tecnologia dietro gli smartphone
cresce esponenzialmente. Attualmente più che
mai questi ultimi hanno processori più veloci,
memorie di massa più economiche, maggiore
RAM e display di alta qualità. La stessa dif-
ferenza tra uno smartphone attuale e uno di
qualche anno fa è enorme.
La tecnologia costruttiva delle batterie tut-
tavia non ha subito lo stesso miglioramento.
Se da un lato si può affermare che il proces-
so evolutivo non sia completamente fermo, lo
1. ”Le prestazioni dei processori, e il numero di transistor ad esso
relativo, raddoppiano ogni 18 mesi.”[2]

stesso procede però molto lentamente. Il diva-
rio è palese se paragonato a quello rapido ed
esponenziale che accompagna le restanti com-
ponenti, che nel tempo tendono a incrementare
le loro prestazioni e a miniaturizzarsi. Rispetto
a queste ultime la batteria occupa ancora gran
parte della struttura di un telefono.
Tale fenomeno è dovuto a diversi fattori.
Innanzitutto lo sviluppo delle batterie sem-
bra realmente procedere più lentamente rispet-
to alle altre componenti. Basti pensare che la
tecnologia su cui si basano le batterie per dispo-
sitivi mobili è, da diversi anni, ancora quella
agli ioni di litio, con lievi miglioramenti.
In secondo luogo, la tendenza odierna è quel-
la di fornire dispositivi sempre più sottili e
leggeri. Piuttosto che sfruttare i vantaggi che
si avrebbero mantenendo le stesse dimensioni,
con una maggiore autonomia, i produttori di
smartphone forniscono batterie sempre più sot-
tili in modo da poter ridurre le dimensioni dei
loro terminali.
Infine, un ruolo influente lo giocano anche
i software che necessitano di sempre più po-
tenza, insieme a notifiche push e servizi in
background sempre attivi.
In questo contesto diviene di fondamenta-
le importanza una gestione oculata dell’ener-
gia. La batteria diviene quindi il punto debo-
le dell’infrastruttura dei dispositivi mobili e,
pertanto, forte candidato passibile di attacco.
In questo lavoro si indaga su possibili at-
tacchi indotti al fine di ottenere un consumo
energetico anomalo della batteria di dispositivi
mobili Android.
La scelta di questa piattaforma è dovuta al
miglior trend di espansione rispetto agli altri
S.O. mobile e alla maggior facilità di misura-
zione e analisi grazie alle API native e al codice
aperto del sistema Android.
Il lavoro svolto è stato articolato in diverse
fasi. Si è partiti da un prima fase di spe-
rimentazione nella quale è stato osservato il
consumo energetico dei codec audio/video te-
stati singolarmente in ambiente controllato. Più
precisamente i test eseguiti hanno riguardato
la riproduzione di file video e audio di durata
variabile. Dall’analisi dei risultati è emerso che
i codec più dispendiosi in termini energetici so-
no H264 per i file video e Wave per i file audio.
Tali codec sono stati utilizzati nell’ultima fase
della sperimentazione in cui è stata realizzata
una pagina web malevola con l’impiego delle
più recenti tecnologie web messe a disposizio-
ne da HTML5, Ajax e Javascript. Confrontando
il consumo energetico della pagina realizzata
con i normali siti web di comune utilizzo si
è riuscito ad ottenere un consumo energetico
pari ad 11 volte il consumo delle stesse pagine
in HTML.
Di seguito vengono illustrati i capitoli attra-
verso i quali si articolerà questo documento: Il
capitolo 2 illustra lo stato dell’arte nell’ambito
in cui il nostro lavoro si vuole inserire. Nel
capitolo 3 viene introdotto l’attacco di sicu-
rezza realizzato. Il capitolo 4 descrive la spe-
rimentazione effettuata in termini di misura-
zioni energetiche e realizzazione dell’attacco di
sicurezza.
2 STATO DELL’ARTE
In letteratura, molti articoli scientifici trattano
dei consumi energetici in ambiente Android.
La maggior parte di essi si focalizzano sulla
misurazione dei consumi dei singoli modu-
li hardware che formano l’infrastruttura degli
smartphone. Il lavoro ”An Analysis of Power
Consumption in a smartphone”[3] offre un’analisi
approfondita dell’utilizzo energetico delle varie
componenti hardware. In questo studio vengo-
no mostrati i risultati di misurazioni fisiche ef-
fettuate tramite sensori di resistori posizionati
sui circuiti degli smartphone.
Un altro lavoro importante è rappresenta-
to da: ”Accurate Online Power Estimation and
Automatic Battery Behavior Based Power Model
Generation for smartphones” [4]. Quest’ultimo si
differenzia dal precedente per la metodologia
di misurazione che, in questo caso, avviene
anche via software e non solo in maniera fisica.
In questo lavoro viene descritto Power Tutor:
un tool che offre una stima in tempo reale
del consumo energetico dei vari componenti
hardware del dispositivo Android. La stima
viene fatta sulla base di un modello di scarica
(come descritto nel capitolo del capitolo 7 di
[4]).
Tale modello viene generato con la tecnica
PowerBooter che prevede i seguenti passi:

1) Ottenere la curva di scarica della batteria
(Figura 1). Il voltaggio della batteria viene
registrato nel tempo fino all’esaurimento
di essa.
2) Determinare il consumo di ogni componente
hardware nei vari stati di utilizzo (es. idle,
low, high). Variando lo stato di utilizzo
di un componente (lasciando gli altri in-
variati) viene registrata a distanza di un
minuto, per quindici minuti, il voltaggio
della batteria.
3) Si effettua una regressione per derivare il mo-
dello di scarica. Tramite il dataset ottenuto,
utilizzando la tecnica di bootstrap [10],
viene generato il modello di scarica.
Il modello cos`ı ottenuto è stato validato con-
frontando i dati misurati fisicamente attraverso
un power meter con quelli stimati utilizzando
il modello precedentemente generato (come
descritto nel capitolo 6 di [4]).
Figura 1: Curva di scarica della batteria rappresentata in
un grafico Voltaggio/stato di scarica.
PowerTutor offre un servizio di profiling
energetico (Figura 3), mostrando le
informazioni dei consumi della batteria
in tempo reale, sia per i singoli moduli
presenti nello smartphone, sia per
le singole applicazioni in esecuzione
sul dispositivo (Figura 2).In dettaglio,
tramite l’utilizzo delle API standard
di Android (android.media.AudioManager,
android.net.wifi.WifiManager, an-
droid.hardware.SensorManager, etc.) viene
monitorato lo stato dei singoli moduli
hardware. Coi dati rilevati viene calcolato
il consumo energetico dei componenti sulla
base del modello precedentemente generato
attraverso interpolazione.
Figura 2: Schermata del profiling di PowerTutor
È doveroso segnalare, inoltre, il lavoro di
Battery Exhaustion Attack Detection with Small
Handheld Mobile Computers [8] in cui, attraverso
algoritmi e moduli di comunicazione Wi-Fi e
Bluetooth, si realizzano Battery Drain Attacks,
ovvero attacchi di sicurezza che mirino ad otte-
nere un denial of service attraverso l’esaurimento
delle risorse energetiche dei dispositivi mobili.
Infine, per l’analisi dei codec audio/video,
in Video network traffic and quality comparison of
VP8 and H.264 SVC [7] viene fatto uno studio
di confronto sulla qualità, data rate e la velocità
di encoding.
In questo articolo, viene condotto un lavoro
di analisi del consumo energetico dei codec

Figura 3: Schermata del profiling di PowerTutor
multimediali che, a differenza di quanto fatto
nel lavoro di Seeling[7], si concentra sui consu-
mi energetici dei codec anziché sui fattori di
data rate, qualità etc. Prendendo spunto dal
lavoro di Buennemeyer[8], anche nel nostro
studio viene interpretato il consumo di batteria
come una possibile vulnerabilità per i sistemi
mobili, ma, allo stesso tempo ci distinguiamo
da esso perché utilizziamo i codec supportati
da Android ed HTML5, per eseguire l’attacco
di Battery Drain.
3 ATTACCO DI SICUREZZA
L’attacco di sicurezza progettato, si basa sull’i-
dea di sfruttare al massimo il consumo ener-
getico dei codec audio/video analizzati, uti-
lizzando quelli che sono risultati più energy
inefficient, al fine di ottenere un Battery Drain.
Inoltre, in combinazione all’utilizzo dei conte-
nuti multimediali, abbiamo previsto l’utilizzo
di funzionalità che mirassero a sfruttare a pieno
tutte le risorse disponibili, includendo funzioni
di: lettura/scrittura di file in memoria, chiama-
te AJAX e caricamento di font non presenti nel
dispositivo.
La tipologia di attacco è stata scelta pensan-
do all’utilizzo da parte dell’utente medio di un
dispositivo mobile escludendo, quindi, l’idea
di poter installare sui dispositivi applicazioni
di terze parti e puntando ad eseguire l’attacco
attraverso una pagina web.
La scelta di utilizzare il web per condurre
l’attacco di Battery Drain è stata presa in base
alla semplicità con cui l’utente può accedervi,
considerando la possibilità di poter navigare
senza l’installazione di alcun software aggiun-
tivo. Durante la progettazione dell’attacco, ci
siamo posti il vincolo che l’utente non debba
accorgersi che l’attacco è in corso. Questa scelta
ha implicato diverse difficoltà nella realizzazio-
ne e nelle scelte implementative del sito web
malevolo, attraverso il quale condurre l’attacco.
L’attacco è stato realizzato utilizzando stru-
menti relativi alle tecnologie di sviluppo
HTML5, Javascript, AJAX e php, le quali ven-
gono utilizzate al fine di realizzare uno script
malevolo, inserito in quella che all’utente appa-
re come una normale pagina web, che esegue
tutte le funzionalità più costose in termini ener-
getici e di computazione, senza dare all’utente
la possibilità di distinguere la nostra pagina da
un’altra priva di codice malevolo.
4 SPERIMENTAZIONE
L’attacco è stato pianificato sulla base dei
risultati ottenuti in fase di sperimentazione,
nella quale abbiamo osservato il consumo
energetico dei vari codec audio/video, testati
singolarmente in ambiente controllato.
La sperimentazione, dunque, si è svolta in
3 step principali: inizialmente è stato prepa-
rato un ambiente di test controllato in modo
da automatizzare il testing dei consumi ener-
getici, successivamente sono stati eseguiti tali
test sui diversi codec multimediali compatibi-
li con HTML5, infine, dall’analisi dei risultati
precedenti è stato creato il sito malevolo.

4.1 Creazione ambiente di test
Il successo del nostro studio si basava sull’ot-
tenere misurazioni affidabili dei consumi ener-
getici in modo da poter effettuare le migliori
scelte per l’attacco di sicurezza. A tal fine si
è reso necessario creare un ambiente di test
controllato che automatizzasse il testing dei
consumi in modo che i risultati non fossero,
quindi, influenzati da errori e rumore umano.
Abbiamo creato BatteryBench, applicazione
Android che effettua benchmark energetici e
automatizza le seguenti tipologie di test:
• Video
• Audio
• Stress
L’applicazione è divisa in 3 omonime sezioni,
in cui ognuna predispone la scelta dei possibili
test da effettuare per la categoria scelta. Nella
sezione Video (Figura 5) è possibile effettuare i
test energetici sulla riproduzione dei contenuti
video e dei relativi codec. Si può selezionare il
codec da testare, la durata del test in minuti,
e l’opzione che abilita/disabilita l’audio del
video. In modo analogo per quanto riguarda
la sezione Audio (Figura 4), dedicata ai test
sui consumi della riproduzione di file audio,
è possibile scegliere il codec e la durata in
minuti del test. Infine la sezione Stress (Figura
6) è dedicata al testing di una serie di script
malevoli. Tale sezione viene definita in questo
modo poiché gli script in questione tentano di
esaurire le risorse energetiche del dispositivo
mobile stressandone il consumo. Di seguito
vengono riportati gli script di stress:
• HTML5 Web Storage
• Ajax Stress Calls
• Fonts Stress Calls
• Hidden Muted Video
• Hidden Muted Audio
• Hidden Infrasound Audio
È possibile selezionare attraverso apposite
checkbox le opzioni da attivare e la durata del
test in minuti. In dettaglio, attraverso questa
sezione è possibile creare uno stress test perso-
nalizzato in base all’esigenze dell’utente e dei
dati da raccogliere abilitando o disabilitando
una determinata opzione.
I risultati dei consumi energetici vengono
misurati da PowerTutor, il cui codice con licenza
libera è stato inglobato all’interno della no-
stra applicazione. All’interno di quest’ultima, il
codice di PowerTutor viene richiamato quando
necessario, come se fosse una semplice routine.
Nonostante siano disponibili molteplici ap-
plicazioni per Android che offrono servizi di
misurazione dei consumi energetici (quali Bat-
teryDoctor o DU Battery Saver), si è scelto di
utilizzare PowerTutor poiché è risultato l’unico,
tra quelli trovati, che, oltre a fornire valutazio-
ni dei consumi energetici dettagliati per ogni
componente hardware del dispositivo e per
ogni applicazione in esecuzione, sia stata anche
comprovata la sua affidabilità nelle misurazioni
attraverso rilevazioni fisiche con strumentazio-
ni adeguate (”Accurate Online Power Estima-
tion and Automatic Battery Behavior Based Power
Model Generation for smartphones” [4]).
Nello studio sopracitato vengono validate
le misurazioni solo per alcuni device mobili
Android, tra i quali però non compare lo smart-
phone utilizzato nella nostra sperimentazione.
PowerTutor installato sul nostro device (HTC
Incredible S) utilizza un modello generico di
scarica della batteria (e quindi non costruito ad-
hoc) migliorato attraverso i log anonimi inviati
dagli utenti di PowerTutor che utilizzano lo stes-
so dispositivo. Questo ovviamente comporta
degli errori di stima del consumo energetico.
Tuttavia, data la natura comparativa dei test
della nostra sperimentazione, non era impor-
tante conoscere precisamente il consumo ener-
getico in termini di joule bens`ı capire quali
codec e tecnologie fossero più dispendiosi.
Infine, la licenza libera di PowerTutor, a dif-
ferenza della maggior parte delle altre appli-
cazioni di profiling disponibili closed source,
ci ha permesso di automatizzare la fase di
testing abilitando/disabilitando via codice il
profiling. Tale automazione non sarebbe stata
possibile con applicazioni esterne closed sour-
ce, in quanto avrebbero necessitato di un input
dell’utente, il quale avrebbe inevitabilmente
compromesso le misurazioni (es. precisione in

termini di tempo; pressione di tasti a schermo
che comportano consumo).
Figura 4: Schermata di Battery Bench per il testing dei
codec audio.
Con riferimento alla figura 7 illustriamo i
relativi passi di esecuzione del programma
BatteryBench:
1) Vengono settati i parametri del test
(tipologia di testing, tempo, codec etc...);
2) Viene lanciato il test attraverso l’apposito
tasto;
3) Viene avviato il profiling di PowerTu-
tor configurato in modo da misurare
il consumo energetico della sola ap-
plicazione browser che verrà lanciata
successivamente;
Figura 5: Schermata di Battery Bench per il testing dei
codec video.
4) Viene avviato il browser predefinito di
sistema con la pagina web relativa al test
selezionato;
5) Allo scadere del tempo definito al passo
1, il browser viene chiuso.
6) Viene interrotto il servizio di profiling di
PowerTutor
7) Viene mostrata una nuova finestra in cui
si possono osservare i risultati del test.
È da sottolineare che l’avvio del profiling
precedentemente l’apertura del browser non
comporta errori di stima in quanto PowerTu-
tor, configurato appositamente per il browser,
inizierà a misurare da quando il processo del
browser sarà attivo.

Figura 6: Schermata di Battery Bench con le varie
opzioni per il lancio dello stress-test.
La pagina dei risultati (Figura 8) mostra il
consumo del browser rispetto ai singoli mo-
duli presenti nello smartphone. Tali risultati
possono essere memorizzati in un ﬁle di log.
4.2 Analisi e monitoraggio dei consumi
In questa fase, `e stato monitorato il consumo di
tutti i codec multimediali previsti dallo stan-
dard HTML5 che fossero, allo stesso tempo,
supportati dal browser stock di Android:
HTML5 Video
• H.264
• WebM
• Theora (non supportato [5])
Figura 7: Schema del funzionamento di Battery Bench.

HTML5 Audio
• Ogg Vorbis
• WAV PCM
• MP3
• AAC
• WebM Vorbis
• Ogg Opus
Di conseguenza, i nostri test non compren-
dono il codec Theora.
Figura 8: Schermata dei risultati di Battery Bench
ottenuta attraverso PowerTutor.
4.2.1 Metodologia di Test
I test sono stati eseguiti su uno smartphone
Android a nostra disposizione, in particolare
HTC Incredible S con Android 2.3, processore
Qualcomm Snapdragon 1024MHz, Display 4’
TFT 480*800 pixel.
La durata dei singoli test segue questi step
incrementali:
• 5 min
• 15 min
• 30 min
Il dispositivo viene riavviato ad ogni step e
la cache del sistema svuotata per avere, ad ogni
test, lo stesso ambiente di partenza.
Siccome il consumo della batteria non è uni-
forme, ma dipende dallo stato di scarica in cui
essa si trova [4], tutti i test sono stati eseguiti
partendo dallo stato di carica completa della
batteria del dispositivo.
I test sono stati eseguiti con l’ausilio di
BatteryBench.
4.2.2 Test eseguiti
I test eseguiti riguardano la riproduzione di
files video (con o senza traccia audio) e di files
audio di durata variabile (5, 15 e 30 minuti).
Precisamente ogni test consiste nella visita di
una pagina web contenente una traccia video
o audio codificata con uno dei codec elencati
precedentemente.
I test riguardanti i video contenenti trac-
cia audio avranno le seguenti combinazioni di
codec audio/video e formato:
• mp4: H.264/MPEG4 (AAC LC)
• WebM: VP8/Vorbis
Di seguito vengono elencati i test eseguiti:
HTML5 Video con traccia audio
• mp4: H.264/MPEG4 (AAC LC)
HTML5 Video con traccia audio muta
• mp4: H.264/MPEG4
HTML5 Audio
• Ogg Vorbis
• WAV PCM
• MP3
• AAC
• WebM Vorbis
Nella Tabella 19 vengono mostrati i test
video eseguiti con le varie combinazioni di
tempo, volume e codec.
Analogamente, nella Tabella 2 vengono mo-
strati i test audio eseguiti per i diversi codec e
step di tempo.

TestID Codec Volume Time
1 H264 Max 30 Minutes
4 H264 Min 30 Minutes
7 WebM Max 30 Minutes
10 WebM Min 30 Minutes
Tabella 1: Test Video
TestID Codec Time
1 MP3 30 Minutes
2 MP3 15 Minutes
3 MP3 5 Minutes
4 Wave 30 Minutes
5 Wave 15 Minutes
6 Wave 5 Minutes
7 Opus 30 Minutes
8 Opus 15 Minutes
9 Opus 5 Minutes
10 Vorbis 30 Minutes
11 Vorbis 15 Minutes
12 Vorbis 5 Minutes
13 AAC 30 Minutes
14 AAC 15 Minutes
15 AAC 5 Minutes
16 WebM 30 Minutes
17 WebM 15 Minutes
18 WebM 5 Minutes
Tabella 2: Test Audio
4.2.3 Risultati
Di seguito vengono riportati i grafici dei
risultati dei test sui codec audio per gli step da
5, 15, 30 minuti (rispettivamente Figure 15, 16 e
17) e sui codec video per gli stessi step di tempo
previsti da 5, 15, 30 minuti (rispettivamente
Figure 19, 20 e 21). Sono stati, inoltre, ricavati
i relativi diagrammi di Pareto (Figure 18 e
22) in modo da ottenere un’informazione
quanto più dettagliata possibile circa
la percentuale di consumo energetico
prodotto da ciascun modulo hardware.
Video: Durante la sperimentazione è emerso
un consumo costantemente in crescita del
codec H264 nei singoli step da 5, 15, 30
minuti. Il gap energetico tra H264 ed il codec
di comparazione WebM rimane costante per
ogni step, aumentando in maniera funzionale
rispetto al tempo di test.
Inoltre, il trend energetico descritto in prece-
denza, è stato registrato anche per i test effet-
tuati sui medesimi codec e tempi, con traccia
audio muta, in particolare, si osserva come il
volume dell’audio influisca in minima parte
nel consumo energetico del modulo audio, cos`ı
come riportato anche nello studio [4].
Dai test è risultato che il modulo più
dispendioso in termini energetici è quello
LCD, che singolarmente costituisce il
53% del consumo totale. La somma dei
moduli LCD, Audio, CPU risulta essere
il 92% dell’intero dispendio energetico
prodotto, lasciando al modulo Wi-Fi
il dispendio minore con il solo 8%.
Audio: Per quanto riguarda i test eseguiti
sui codec audio, non è emersa una situazione
del tutto definita, poiché i consumi energetici
di alcuni codec sono risultati piuttosto variabili
nei singoli step da 5, 15, 30 minuti. Tuttavia
si è notato un consumo medio maggiore del
codec Wave, soprattutto nei tempi brevi, come
risulta dai relativi grafici riportati in appendice
A.
Analizzando il consumo medio dei singoli
moduli abbiamo notato che la componente Au-
dio insieme al modulo CPU costituiscono l’80%
circa del consumo energetico totale, mentre
il modulo Wi-Fi assorbe il 20% dell’energia
utilizzata per compiere la riproduzione audio.
Per i test audio non è stato preso in considera-
zione il modulo LCD, non essendo ovviamente
rilevante nel confronto.
4.2.4 Overhead comunicazione con il Server
Al termine di questa prima fase di test, ab-
biamo cercato di quantificare l’impatto del-
la comunicazione con il server in termini di
consumo energetico. L’obiettivo era quello di
confrontare i diversi codec multimediali senza
l’overhead della comunicazione e scambio dati
tra il client e il server. In altre parole, si voleva
scoprire se un codec intrinsecamente energy effi-
cient in termini di riproduzione e codifica, veni-
va penalizzato nei test energetici a causa della
dimensione del file e quindi del trasferimento
dati. Ovviamente una semplice esclusione del
consumo del modulo Wi-Fi non rappresenta, a

nostro parere, una strategia affidabile in termini
assoluti.
La strategia che volevamo adottare era quella
di trasferire un file multimediale di piccole di-
mensioni e ripeterlo in loop per l’intera durata
del test.
Non è stato tuttavia possibile portare avanti
tale tecnica, date le politiche di risparmio ener-
getico adottate dal browser stock di Android.
Quest’ultimo ignora la funzionalità associata al
tag loop [9] previsto dallo standard HTML5,
che permette la riproduzione in loop di un
contenuto multimediale.
Per aggirare il problema abbiamo provato
ad utilizzare le funzionalità di Javascript per
simulare un loop. Nello specifico abbiamo pro-
vato a richiamare la funzione play sull’elemento
multimediale ogni volta che la riproduzione
terminava. Tale tecnica è stata dapprima testata
su un browser per PC, con esito positivo, ma
lo stesso non si è riscontrato sul browser stock
di Android.
In conclusione, non abbiamo potuto annul-
lare l’overhead di comunicazione come piani-
ficato, ma abbiamo dovuto cercare un modo
alternativo per avere un termine di paragone
nei consumi dei contenuti audio/video.
Per eseguire i test sui contenuti multimediali
annullando l’overhead della comunicazione in
rete abbiamo effettuato le stesse misurazioni
eseguite precedentemente, ma questa volta uti-
lizzando il player multimediale di Android per
riprodurre gli audio/video.
4.3 Testing locale
Come descritto in precedenza, volevamo
avere dei termini di confronto sui consumi
energetici dei codec multimediali annullando
il consumo e l’overhead del modulo Wi-Fi,
che influisce pesantemente sui consumi per il
trasferimento di file molto grandi e poco adatti
allo streaming (es. Wave). Visto il fallimento
di tutti gli altri tentativi di riprodurre i
file multimediali all’interno del browser, in
ambiente locale, abbiamo provato ad effettuare
le nostre misurazioni utilizzando il player
multimediale stock di Android per riprodurre
i suddetti file.
TestID Type Codec Time
1 Video H264 5 Minutes
4 Video WebM 5 Minutes
5 Video Wave 15 Minutes
6 Video Wave 30 Minutes
7 Audio MP3 5 Minutes
10 Audio Wave 5 Minutes
13 Audio Vorbis 5 Minutes
16 Audio AAC 5 Minutes
19 Audio WebM 5 Minutes
Tabella 3: Test eseguiti utilizzando il riproduttore mul-
timediale stock di Android. I diversi file sono stati
precedentemente memorizzati in memoria locale per
annullare l’overhead di comunicazione su rete.
La metodologia applicata per il testing in
locale è stata del tutto simile a quella utilizzata
per il testing su rete precedentemente descritto.
In particolare, abbiamo testato i file codificati
con i codec ritenuti meno efficienti in termini
energetici nella precedente fase di testing, ov-
vero: Wave per i contenuti audio e H264 per
quelli video. I file sono stati memorizzati sul
supporto di memorizzazione di massa dello
stesso dispositivo mobile utilizzato per le altre
fasi di testing. L’apparecchio è stato riavviato
ad ogni iterazione del testing (5min, 15min,
30min) quest’ultimo effettuato sempre con bat-
teria completamente carica. La pianificazione
dei test locali è stata riportata in Tabella 3,
in cui sono descritte le diverse iterazioni del
testing. Com’è possibile notare dalla Tabella
3, il codec audio Opus non è presente, dal
momento che i riproduttori multimediali di
Android non supportano il sudetto codec come
riportato nella guida ufficiale per gli svilup-
patori [6], quindi non è stato possibile fornire
statistiche per i file codificati in Opus.
Le misurazioni energetiche, come per i prece-
denti test, sono state registrate grazie a Po-
werTutor, il quale veniva avviato appena dopo
l’accensione, subito prima dell’esecuzione della
riproduzione dei files. I risultati ottenuti ven-

gono riportati di seguito sotto forma di grafici,
mentre le relative tabelle numeriche vengono
descritte all’interno dell’apposita appendice B.
In Figura 9, Figura 10 e Figura 11 possiamo
osservare il consumo energetico di ogni
modulo hardware per i due tipi di codec video.
Ogni figura si riferisce ad un determinato step
di tempo (5 min, 15 min, 30 min). Allo
stesso modo, in Figura 12, vengono mostrati i
consumi ( in Joule ) nello step da 5 min. per i
diversi tipi di codec audio, per ogni modulo
coinvolto nella riproduzione ne viene riportato
il dispendio energetico. In Figura 13 e Figura
14 è possibile osservare il comportamento
degli stessi codec audio per gli step di testing
di 15 min (Figura 13) e 30 min (Figura 14).
Da quanto si può osservare nei grafici, i test
locali, non hanno fatto altro che confermare i
risultati osservati precedentemente con i test
comparativi su rete. Seppur in maniera più
attenuata, per via del minor sforzo di calcolo
da parte del componente CPU, il codec H264
vince il confronto con WebM, riconfermandosi
come codec video più energeticamente costoso.
Per i codec audio, Wave, continua ad essere
il più dispendioso in termini energetici,
soprattutto per la differenza di consumi del
modulo CPU, il quale incide maggiormente
nella differenza dei consumi con gli altri codec.
4.4 Costruzione sito malevolo
Grazie ai risultati ottenuti in fase di sperimen-
tazione sui codec audio/video, abbiamo po-
tuto individuare quei codec che fossero meno
efficienti in termini di risparmio energetico.
Con queste informazioni abbiamo sviluppato
una pagina web con scripts malevoli, tali da
esaurire l’energia del dispositivo nel più breve
tempo possibile.
La base di partenza è stata una pagina in
HTML statico di Wikipedia, all’interno della
quale abbiamo nascosto contenuti multimediali
e gli scripts malevoli descritti in seguito.
4.4.1 Descrizione sito malevolo
In questa sezione sono descritte brevemente
le tecnologie utilizzate per realizzare il sito
malevolo.
• Video e audio nascosti e con volume a zero.
I video sono stati inseriti all’interno della
pagina, in modo da non dare all’utente
la percezione della loro presenza. Per i
video sono stati nascosti i controlli ed è
stato settato il tag di autoplay, impostando
l’audio a 0, al fine di renderli invisibili,
le dimensioni sono state impostate a 0*0
pixel. Per gli audio è stata seguita la stessa
logica.
• Utilizzo di codec specifici. I codec uti-
lizzati per i contenuti multimediali sono
stati scelti in maniera mirata, sulla base dei
risultati della sperimentazione e dei con-
fronti sui risultati. Abbiamo perciò scelto
H264 (video) e Wave (audio).
• Scrittura e cancellazione continua di dati.
Utilizzando la funzionalità di Web Storage
fornita da HTML5 abbiamo inserito uno
script che esegue ogni 6 secondi la scrittura
e cancellazione all’interno della memoria
di un file contenente una stringa di 25Kb.
• Chiamate continue con Ajax. Per tenere
sempre attivo il modulo Wi-Fi con un con-
tinuo scambio di dati con il web, abbiamo
incluso delle chiamate AJAX ad intervalli
regolari di 1 secondo.
• Richiesta di diversi font. Al fine di stressa-
re ulteriormente il modulo CPU, abbiamo
incluso l’utilizzo all’interno della pagina
di fonts considerati unsafe dai browser;
ovvero quei fonts non inclusi di default
all’interno dei browser. In questo modo,
costringiamo il sistema a cercare i fonts da
caricare all’interno del dispositivo stesso.
• Utilizzo di infrasuoni. Per aumentare il
consumo di tutti i moduli, abbiamo in-
trodotto, tra i contenuti multimediali, dei
file audio codificati con codec Wave che
riproducessero una traccia in infrasuoni
(2Hz) al massimo del volume digitale.
La Tabella 4 mostra i test di stress effettuati.
4.4.2 HTML5 vs HTML4.01
Per la realizzazione del sito malevolo abbiamo
utilizzato lo standard HTML5 che ci ha permes-
so di inserire all’interno della pagina contenuti
multimediali in modo semplice ed efficace per
nostri fini. HTML5 definisce due nuovi tag,

Figura 9: Risultati dei test locali relativi ai codec video - 5 min. con riferimento alla Tabella 11

Figura 12: Risultati dei test locali relativi ai codec audio - 5 min. con riferimento alla Tabella 14

Figura 15: Risultati Codec Audio - 5 min. con riferimento alla Tabella 5

Figura 18: Diagramma di Pareto riferito ai Codec Audio

Figura 19: Risultati Codec Video - 5 min. con riferimento alla Tabella 8

Figura 22: Diagramma di Pareto riferito ai Codec Video

TestID Stress Option
1 None
2 HTML5 Web Storage
3 Ajax Stress Calls
4 Fonts Stress Calls
5 Hidden Muted Video
6 Hidden Muted Audio
7 Hidden Infrasound Audio
8 All
9 https://www.facebook.com
Tabella 4: Test Stress
<video> e <audio>, che definiscono lo standard
per incorporare un audio o un video in una
pagina web.
Se avessimo dovuto utilizzare l’ultima ver-
sione precedente ad HTML5, ovvero la versio-
ne 4.01 dello standard HTML, l’efficacia del
sito malevolo sarebbe stata ridotta e alcune
componenti impossibili da utilizzare.
Infatti, in HTML4.01 non è previsto un sup-
porto nativo per video e audio. Per permettere
la loro esecuzione, essi necessitano di essere
incorporati usando tecnologie che si basano su
Adobe Flash o su Apple QuickTime. In riferi-
mento alla tecnologia Adobe Flash, essa è stata
ormai abbandonata da molti sistemi operativi
mobile per motivi di efficienza e di sicurezza.
Inoltre non è possibile nascondere video e/o
audio.
Infine non sarebbe stato possibile utilizzare
la tecnologia Web Storage, introdotta appunto
con HTML5, la quale consente una memoriz-
zazione di dati sul dispositivo client molto più
efficace dei cookie, e per tale motivo più adatta
ai nostri scopi.
4.4.3 Risultati
I consumi energetici del sito prodotto sono
stati testati in maniera molto fine, abilitando un
solo tipo di script per volta. I risultati raccolti
sono stati organizzati all’interno di un grafico
(Figura 23) in cui possiamo notare quale script
risulta essere il più energy inefficient.
4.4.4 Confronto consumi
Una volta realizzata la pagina web malevola
abbiamo condotto uno studio comparativo con
le altre pagine web di utilizzo quotidiano, qua-
li: la stessa pagina di Wikipedia dalla quale
siamo partiti per realizzare la pagina male-
vola ed una pagina di Facebook. Registran-
do ed analizzando i consumi, abbiamo potuto
confrontarli (Figura 24).
4.5 Massive Dynamic Web Attack
In seguito ai normali test, abbiamo voluto di-
scostarci dai soli obiettivi prefissati di Battery
Drain Attack, cercando di testare i limiti di
stress sopportabili da un dispositivo mobile.
Abbiamo creato una ulteriore pagina web ma-
levola di Dynamic Web Attack, nella quale
abbiamo incluso gli script malevoli descritti
in precedenza e forzato, in maniera dinami-
ca, l’inserimento dei contenuti multimediali ad
intervalli di 1 secondo. Conducendo l’esperi-
mento sul dispositivo sotto testing, abbiamo
notato che dopo soli 3’ e 10”, si verificava
un overflow in memoria, il browser e tutte
le altre applicazioni e servizi in esecuzione in
background, compreso il servizio di gestione
della UI, venivano chiusi da Android stesso
con la conseguente perdita di dati non salvati
ed un consumo ulteriore dovuto al riavvio
dell’interfaccia.
5 CONCLUSIONI
Valutando i risultati ottenuti in fase di testing
è emerso che i codec più dispendiosi in ter-
mini energetici sono risultati essere H264 per
i contenuti video e Wave per gli audio. Questi
formati sono stati inseriti poi in una normale
pagina HTML statica di Wikipedia, in manie-
ra invisibile, insieme ad altri script esposti in
precedenza, per creare la pagina web malevola.
Confrontando il consumo energetico della
pagina da noi realizzata con i normali siti web
di comune utilizzo siamo riusciti ad ottenere un
consumo energetico pari ad 11 volte il consumo
della stessa pagina in HTML e consumi pari
al 4.5 volte maggiori rispetto ad una pagina di
Facebook. Siamo giunti alla conclusione che at-
traverso l’impiego malevolo delle più semplici
e note tecnologie web, si ottengono consumi
energetici tali da portare la batteria del dispo-
sitivo in uso alla scarica in tempi molto più
brevi.

Figura 23: Confronto tra i consumi (in Joule) dei diversi script malevoli presenti nella pagina di stress test con
riferimento alla Tabella 17
6 SVILUPPI FUTURI
Il naturale proseguimento di tale studio `e rap-
presentato dal continuo aggiornamento dei casi
di test, sia per quanto riguarda i nuovi co-
dec multimediali che verranno introdotti, sia
per le future tecnologie web che si avranno a
disposizione.
Si necessita, inoltre, di incrementare il nu-
mero di dispositivi su cui effettuare bench-
mark. Una possibile soluzione potrebbe esse-
re il rilascio dell’applicazione ”Battery Bench”
sullo store Android in modo da ricevere ano-
nimamente log di esecuzioni di test da utenti
volontari.
Validazione dei risultati con misurazioni
ﬁsiche sull’hardware.
APPENDICE A
RISULTATI TEST CODEC
A.1 Codec Audio
CPU Audio Wi-Fi
Wave 93.40 134.10 94.90
Opus 58.40 128.20 72.60
Vorbis 49.80 122.80 65.20
WebM 87.20 117.20 61.70
MP3 98.80 116.90 69.40
AAC 47.10 118.80 60.40
Tabella 5: Valori di consumo energetico (espressi in
Joule) ottenuti dal testing dei codec audio per 5 minuti.
CPU Audio Wi-Fi
Wave 313.40 354.20 178.80
Opus 264.20 338.40 175.70
Vorbis 318.90 364.80 185.10
WebM 307.80 357.50 197.10
MP3 289.30 313.80 161.90
AAC 297.70 343.80 178.80

Figura 24: Confronto dei consumi (in Joule) tra le diverse pagine web con riferimento alla Tabella 18
CPU Audio Wi-Fi
Wave 673.90 693.50 332.80
Opus 675.80 694.60 324.50
Vorbis 667.70 695.10 329.10
WebM 665.90 689.80 318.50
MP3 689.90 693.10 247.60
AAC 669.40 675.10 269.30
A.2 Codec Video
CPU LCD Audio Wi-Fi
H264 93.20 289.80 109.80 50.80
WebM 97.50 278.50 90.30 66.80
H264 vol. 0 87.70 284.50 106.40 63.10
WebM vol. 0 91.50 273.20 76.80 52.80
Joule) ottenuti dal testing dei codec video per 5 minuti.
CPU LCD Audio Wi-Fi
H264 305.40 901.80 337.10 158.60
WebM 297.60 825.30 323.30 129.70
H264 vol. 0 268.20 826.50 332.90 126.40
WebM vol. 0 270.50 815.70 331.40 128.20
CPU LCD Audio Wi-Fi
H264 653.40 1785.00 685.80 241.30
WebM 637.70 1589.00 665.10 191.80
H264 vol. 0 558.40 1689.10 581.00 230.50
WebM vol. 0 548.70 1654.00 565.50 196.40

APPENDICE B
RISULTATI TEST LOCALI
CPU LCD Audio
H264 52.40 311.40 118.30
WebM 48.90 310.90 107.20
Joule) ottenuti dai test di riproduzione in ambiente locale
dei ﬁle video per 5 minuti.
CPU LCD Audio
H264 167.50 840.70 342.50
WebM 154.80 835.50 317.90
CPU LCD Audio
H264 328.80 1674.00 692.40
WebM 318.40 1643.00 691.80
CPU Audio
MP3 37.10 109.90
Wave 39.80 112.60
Vorbis 32.40 111.80
AAC 29.40 110.50
WebM 34.90 111.80
dei ﬁle audio per 5 minuti.
CPU Audio
MP3 99.50 345.60
Wave 118.40 364.80
Vorbis 112.90 353.90
AAC 118.10 365.10
WebM 115.80 328.90
CPU Audio
MP3 214.80 695.40
Wave 235.90 701.90
Vorbis 221.90 675.10
AAC 117.80 698.20
WebM 221.30 687.50
APPENDICE C
RISULTATI TEST SITO MALEVOLO
CPU Wi-Fi Audio
Infrasounds 54.90 197.70 117.80
Audio 61.20 186.80 110.60
Video 84.20 161.80 60.30
Web Storage 113.90 13.80 0.00
Ajax 32.50 34.60 0.00
Fonts 28.50 39.40 0.00
Tabella 17: Valori di consumo energetico (espressi
in Joule) ottenuti dallo stress test per ogni opzione
applicabile.
CPU Wi-Fi Audio
Static HTML 25.70 33.60 0.00
Battery Drain Attack 283.80 228.36 153.90
facebook.com 75.40 72.70 0.00
Joule) ottenuti dal confronto delle diverse pagine web
prese in esame.
APPENDICE D
INVENTARIO FILE UTILIZZATI
Type Codec Size
Audio AAC 28.8 MB
Audio MP3 28.9 MB
Audio Ogg Opus 34.1 MB
Audio Ogg Vorbis 28.1 MB
Audio Wave 318.3 MB
Audio WebM 28.9 MB
Video H264 43.4 MB
Video WebM 15.4 MB
Audio Infrasuono Wave 53.1 MB
Tabella 19: File utilizzati

APPENDICE E
CODICE SORGENTE
Di seguito vengono elencati i ﬁle sorgenti uti-
lizzati durante la sperimentazione, disponibili
al seguente link: https://www.dropbox.com/
sh/cxgyl09fzdjoagj/5ShETNttio
audio
BatteryTest . php
s t r e s s
video
./ audio :
src
TestAudioAac . html
TestAudioMP3 . html
TestAudioOpus . html
TestAudioVorbis . html
TestAudioWav . html
TestAudioWebM . html
./ audio/src :
audio . aac
audio . m4a
audio .mp3
audio . ogg opus . opus
audio . ogg vorbis . ogg
audio .wav
audio .webm
./ s t r e s s :
addAudio . php
addFonts . php
addInfra . php
addObj . php
ajax . php
audio
audio . php
BatteryDrainAttack . php
doRequest . php
f i l l&erase . j s
fonts . php
fonts . t x t
infra
infrasounds . php
linkAudio . t x t
l i n k I n f r a . t x t
link . t x t
S i c u r e z z a f i l e s
Sicurezza . html
video
video . php
./ s t r e s s /audio :
audio .wav
./ s t r e s s /infra :
1hz .wav
./ s t r e s s /video :
NoAudio .mp4
./ video :
src
TestVideoH264 . html
TestVideoH264NoAudio . html
TestVideoWebM . html
TestVideoWebMNoAudio . html
./ video/src :
NoAudio .mp4
NoAudio .webm
video .mp4
video .webm
RINGRAZIAMENTI
Si ringraziano gli autori di PowerTutor per la
licenza libera (GNU General Public License) sotto
la quale `e stata rilasciata la sopracitata ap-
plicazione, utilizzata nel nostro studio per il
rilevamento dei consumi energetici.

RIFERIMENTI BIBLIOGRAFICI
[1] Ryan Reith, Tom Mainelli e Michael Shirer ”IDC Forecasts
Worldwide Tablet Shipments to Surpass Portable PC Shipments
in 2013, Total PC Shipments in 2015”
http://www.idc.com/getdoc.jsp?containerId=
prUS24129713, 28 Maggio 2013.
[2] Legge di Moore
http://it.wikipedia.org/wiki/Legge di Moore, 1965.
[3] A. Carroll e G. Heiser ”An Analysis of Power Consumption
in a smartphone”, In Proceedings of the 2010 USENIX
conference on USENIX annual technical conference, pp.
2-12.
[4] L. Zhang, B. Tiwana, R. P. Dick, Z. Qian, Z. M. Mao, Z.
Wang e L. Yang: ”Accurate Online Power Estimation and
Automatic Battery Behavior Based Power Model Generation for
Smartphones”, In Proceedings of the 8th IEEE/ACM/IFIP
International Conference on Hardware/Software Codesign
and System Synthesis 2010, pp. 1-10.
[5] Compatibility table for support of the Ogg/Theora video
format
http://caniuse.com/ogv, 2013.
[6] Supported Media Formats http://developer.android.com/
guide/appendix/media-formats.html
[7] P. Seeling F. Fitzek, G. Ertli, A. Pulipaka e M. Raisslein:
”Video Network Trafﬁc And Quality Comparison Of VP8 And
H264 SVC”, In Proceedings of the 3rd Workshop on Mobile
Video Delivery, 2010, pp. 1-5.
[8] T.K.Buennemeyer, M. Gora, R. Marchany e J. Tront:
”Battery Exhaustion Attack Detection With Small HandHeld
Mobile Computers”, In Proceedings of IEEE International
Conference on Portable Information Devices, 2007, pp. 1-5.
[9] HTML5 Autoplay, Loop and Muted: table list of which
browser support the autoplay, loop and muted attributes
http://www.longtailvideo.com/html5/autoloop/.
[10] Wikipedia
Bootstrapping (statistics)
http://en.wikipedia.org/wiki/Bootstrapping (statistics).

Uno Studio Empirico sui Consumi Energetici in Ambiente Android e Possibili Attacchi di Sicurezza

Recommandé

Recommandé

Contenu connexe

En vedette

En vedette (9)

Similaire à Uno Studio Empirico sui Consumi Energetici in Ambiente Android e Possibili Attacchi di Sicurezza

Similaire à Uno Studio Empirico sui Consumi Energetici in Ambiente Android e Possibili Attacchi di Sicurezza (20)

Uno Studio Empirico sui Consumi Energetici in Ambiente Android e Possibili Attacchi di Sicurezza