摘要

在本文中我們將證明，在現今許多手機模型上都有的hover（floating touch，懸浮觸控）技術可以被惡意軟體濫用，用來記錄系統範圍內的所有觸屏輸入。通過這種攻擊，執行在Android系統上的惡意軟體可以獲取使用者的敏感資訊諸如密碼、PIN，記錄使用者的社交，掌握使用者的行為。為評估此類攻擊，我們實現了一款POC（proof-of-concept，概念驗證）惡意軟體Hoover，讓它在後臺執行並記錄下前臺應用程式的輸入。

與現在廣為人知的邊通道攻擊（side channel  attack）不同，本文是第一篇證明了hover技術的安全隱患以及它盜取使用者輸入的潛在可能性。我們也討論了減輕此類攻擊的方法，並發現不能通過簡單的限制許可權或者提高使用者意識來實現，因為這將大大縮減hover技術的使用率。

關鍵詞

Android，hover技術，使用者輸入，攻擊

1. 引言

近年來輸入推理攻擊（input inference attack）迅速發展，此類攻擊是指盜取使用者部分或全部輸入。這並不足為奇，因為此類攻擊可以讓人對使用者有大概的瞭解，或者獲取使用者的敏感資訊諸如登入資訊、信用卡卡號、私人信件等等。

現有的攻擊主要是應用程式層面的，通過phishing（釣魚）或介面偽裝（UI redressing）誘使使用者輸入敏感資訊。其他攻擊利用手機上的感測器作為邊通道，通過讀取不同感測器，例如加速器、迴轉儀和麥克風，推斷使用者輸入。在Android上，讀取這些感測器（麥克風除外）的資訊並不需要特殊的許可權。

本文我們介紹一種新的基於Android裝置的輸入推理攻擊，比起前人的工作，我們這個攻擊準確率更高、更通用。我們的攻擊同時影響裝置上執行的所有應用程式（它是系統範圍內的），而且它並不是專門為哪一款應用程式定製。它可以持續以高準確率收集使用者輸入，而且對環境條件不敏感。之前的方法要麼針對特定的輸入型別（比如，數字鍵）是應用程式級別的，是粗粒度的，要麼是隻在特定條件下有效（有限的手機移動，明確的手機位置，有限的環境噪聲）。我們的攻擊不是基於軟體漏洞或者系統錯誤配置，而是基於新的未預料到的對新興的hover技術的使用。

自從Samsung—手機市場的一大巨頭，將hover技術應用到Galaxy S4,S5和Note系列以後，hover技術方才流行起來。因此本文所提到的攻擊會影響到數以萬計的使用者。Hover技術，如圖1所示，會引發一種特別的事件（hover event，hover事件），此類事件可以讓使用者在沒有物理接觸螢幕的情況下與裝置進行互動。我們將展示如何利用此類hover event進行強有力的，系統範圍內的輸入推理攻擊。

圖1：Hover技術。輸入裝置在沒有接觸到裝置螢幕的情況下引發特殊的事件（hover event）。最右圖展示了使用者在輸入裝置沒有接觸到螢幕的情況下與手機進行互動。

為獲取足夠的post-tap（點選後）hover event以便正確推斷精確點選座標，在使用者對前臺app進行每一次點選後，我們的攻擊方式是立刻謹慎地建立（create）和銷燬（destroy）覆蓋視窗（overlay windows）。先前的phishing、clickjacking和UI redressing技術也建立覆蓋視窗，但是都得用到SYSTEM_ALERT_WINDOW許可權。我們的攻擊方式並不依賴於該許可權：我們的攻擊不需要任何許可權。而且，我們利用覆蓋視窗的方式也不一樣。我們的攻擊是持續的，對使用者完全透明，不會影響使用者與前臺app的互動，也不會將使用者重定向到其他的惡意view上，更不會以任何方式欺騙使用者——此前的攻擊都做不到這點。

為評估此類攻擊，我們實現了一款POC（proof-of-concept，概念驗證）惡意軟體Hoover，讓它在後臺持續執行並記錄下前臺應用程式的hover輸入。但是，要實現我們的攻擊我們還得克服一些技術挑戰。我們最初的實驗表明hover技術，很令人意外，並不直接獲取使用者點選的位置。相對的，hover事件散落在更廣闊的區域。因此，為成功預測輸入事件座標，我們首先要知道使用者是如何與手機進行互動的。為達到此目的，我們進行了一個使用者實驗，讓20個志願者用安裝了hoover的裝置進行兩項操作：隨便在螢幕上點、輸入英文。Hoover收集到的hover event將用來訓練迴歸模型以預測點選位置和用來生成一個推斷輸入鍵位的分類器。

事實證明，我們的攻擊對觸控筆和手指輸入均有效。而且手指點選的誤差為100px，觸控筆誤差只有2px。而在鍵盤輸入事件中，觸控筆和手指的鍵盤鍵位推斷的正確率分別為98%和79%。

我們的這種攻擊最直觀的應用就是獲取使用者的輸入資訊，並且是系統範圍內的。比如說，Hoover可以記錄敏感輸入，例如pin，密碼還有社交資訊（資訊類app，郵件）。當然還有其它更微妙的應用。比如，Hoover可以刻畫使用者與裝置的互動方式，也就是形成使用者的生物計量學簡介。這份簡介又可以用來，比如說，僅對裝置主人的限制訪問，或者幫助敵手繞過現有的基於生物認證技術的按鍵[20]。

針對我們的攻擊，我們討論了應對策略，發現要麼不能對抗此類攻擊，要麼將影響系統或hover技術的使用。

最後，本文有如下貢獻：

我們介紹了一種全新的、系統範圍內的基於hover技術的Android使用者輸入推斷攻擊。

我們實現了Hoover，一款POC惡意app。

我們實現了使用者測試，證明了Hoove的正確性。

我們討論了可能的應對策略，發現此類攻擊很難抵禦。

本文後面的組織如下：第二部分我們介紹有關hover技術的相關概念和Android系統的view的UI元件。第三部分，描述本文要考慮的問題以及我們的攻擊。接下來，第四部分是Hoover的實現和評估。攻擊實現是在第五部分，在第六部分我們討論可能的抵禦策略。第七部分回顧在本領域的相關工作，第八部分總結並展望未來。

2. 背景知識

在這部分，我們介紹一些關於hover技術和Alert Window的背景知識。Alert Window是Android手機app中比較常用的UI元素。

2.1 Android的hover技術

Hover（或者floating touch，懸浮觸屏）技術可以讓使用者在不物理接觸螢幕的情況下與移動裝置進行互動。我們在圖1已經展示過這個概念了。該技術於2012年由Sony Xperia Device[32]引入，基於結合互電容和自電容感知。被Sony引入後，在2013年11月下旬，hover技術被Asus用到它的Fonepad Note 6中。最終興起是在Samsung，手機市場一大巨頭，將它用到Galaxy S4,S5和GalaxyNote系列。單單是Samsung就出售了超過1億臺支援hover技術的裝置[5,6,11,15]——它們都是本文所提到的攻擊的潛在目標。

Hover是這麼處理的：當使用者與螢幕互動時，系統可以在未觸控到它的時候就檢測到輸入裝置的位置。尤其是，當輸入裝置徘徊在螢幕周圍20mm的時候（見圖1），作業系統會在規定區域觸發一類特殊的使用者輸入事件——hover event。App以x,y座標的形式獲取輸入裝置的精確位置。只要獲取了輸入裝置的位置，位置將被髮送到View——Android使用者介面內建模組——以監聽事件。更具體點，就是當使用者徘徊在螢幕上方並點選螢幕後，作業系統產生的事件流是這樣的：當輸入裝置接近螢幕（小於20mm）,系統就針對（x,y）座標發起一系列hover event。當觸控到螢幕的時候，hover退出事件（hover exit event）就緊隨著按下事件（touch down event）觸發。Touch up事件意味著觸控完成。之後，當使用者將輸入裝置帶離觸控點的時候其他一系列的hover event會再次觸發。最後，當輸入裝置離開懸浮區域，也就是說，距離螢幕的懸浮高度大於20mm，就產生hover exit event。

2.2 View 物件

Android通過WindowManager處理系統視覺化和螢幕上的app UI控制元件。它的工作主要是管理和生成window、view、button、image和在螢幕上出現的其他物件。基於攻擊的目的，可以產生不同的view（主動view，例如button；或被動view，例如image）以獲取hover event和觸控事件。View的模式是可以改變的，通過設定或不設定特定的標誌，可以化被動為主動。這些標誌可以通過WindowManager介面的updateViewLayout() API實現。比如說，要將某個view變為被動，需設定FLAG_NOT_FOCUSABLE和FLAG_NOT_TOUCHABLE。第一個flag避免view獲得鍵位輸入焦點，第二個flag讓其無法攔截觸控事件或者hover event。通過設定這兩個標誌，靜態view就不會影響裝置的正常使用，即使是它在其他window的上面。另外，通過設定某個view的FLAG_WATCH_OUTSIDE_TOUCH，當螢幕上某處，並且在該view的外面發生點選事件，無需知道點選的位置，也能精確獲取該view。

在本文中，我們將會用到在其他物件，包括前臺app的view頂層的view。這些view要麼是Alert Window要麼是Toast Window。Alert Window不僅用在像簡訊和電話這種內建app中也用在其他app中——根據IzzyOnDroid對應用商店的爬蟲發現，有著上億次下載的超過600款app都用到了Alert Window。要產生Alert Window，WindowManager介面需SYSTEM_ALERT_WINDOW許可權，這部分由產生該view的service完成。但是，用Toast類的話，實現我們的攻擊所需要的功能不用任何許可權。但是因為Toast Window的技術更難處理，此類實現比較複雜。因此，我們先用Alert Window實現我們的攻擊，稍後在4.6節再解釋如何不需要特殊許可權實現攻擊。

3. 攻擊

我們攻擊的目標是以高精確率（比如，低誤差）和高粒度（比如，在按鍵鍵位級別）追蹤使用者的每一次點選。只要使用者與之互動的裝置支援hover，那麼不管輸入裝置是手指還是觸控筆，攻擊都有效。而且，攻擊不應該被使用者察覺，也就是說，攻擊不會以任何形式影響使用者與裝置的互動。

在描述攻擊之前，我們先宣告假設和敵手模式。

3.1 假設和敵手模式

我們假設使用者執行的手機支援hover技術。使用者用觸控筆或手指與裝置互動都沒有關係。

我們假設的情節是，攻擊者控制著在使用者裝置上執行的一款惡意軟體。目標就是，在不被使用者發現的前提下獲取使用者輸入資訊。在我們第一個攻擊，更容易實現的攻擊中，該惡意軟體只需要兩個許可權：SYSTEM_ALERT_WINDOW，就如前文所說的，這個許可權在很多app中都有，和INETERNET——這個就更常用了，以至於Android將它的保護級別設定位PROTECTION_NORMAL。也就意味著這是無害的，而且所有app都有這兩個許可權，不需要詢問使用者。然後我們再討論不需要SYSTEM_ALERT_WINDOW許可權的攻擊，這個攻擊更復雜些。

3.2 攻擊概述

為追蹤輸入裝置的點選，我們探索Android作業系統傳送hover事件到app的方式。當使用者點選螢幕的時候，會以座標和時間戳的形式形成一系列事件：hover（輸入裝置懸浮）；hover exit和touch down（點選時）；touch up（點選結束）；hover（輸入裝置再次懸浮）。

為觀察這些事件，如果該惡意軟體有SYSTEM_ALERT_WINDOW許可權的話，它可以生成一個透明的AlertWindow覆蓋在上面，不然它也可以如4.6節描述的那樣用Toast類覆蓋實現攻擊。注意到在Android系統中，Alert Window是在其他view的上面的（見第二部分）。一旦建立，該覆蓋視窗可以獲取點選所觸發的一系列hover event，如此便可追蹤輸入裝置。以祕密方式做到這些不驚擾使用者與app的互動並非微不足道。因為，Android只把hover event傳送給收到touch event的view。而且，系統先知touch stream（觸控流）的消耗，所有事件，包括touch down和touch up僅針對一個view。所以，用來追蹤輸入裝置的惡意軟體要麼可以擷取hover event和觸控事件，那這樣就影響對實際app的觸控，要麼就是擷取不到，那這樣就無法推斷使用者輸入。

3.3 實現隱祕性

由敵手控制的惡意軟體不能直接並隱祕的觀察點選事件。但是我們可以證明通過觀察使用者點選之前和之後的hover事件可以隱祕地推斷點選。要正確達到此目的，敵手需在不影響使用者互動的情況下推斷使用者輸入。

更具體一些，我們的攻擊是這麼實現的：惡意軟體生成一個完全透明的Alert Window覆蓋在整個螢幕上。該覆蓋視窗位於其他視窗之上，包括使用者正在用的app。因此，惡意軟體可以追蹤hover event。但是惡意view要及時以一種“聰明的方式”化主動（抓取所有事件）為被動（讓它們順利到達下層app）。惡意軟體通過WindowManager API，可以在影響使用者互動的情況下適時的建立和移除覆蓋視窗。

3.4 抓取點選事件和Hover event

敵手（惡意軟體）是一直執行在受害者裝置上的後臺服務。之前說過，它的難點在於如何知道將覆蓋視窗由主動（將它放到螢幕上）變為被動（將它移除）然後再次變成主動的確切時間。須注意，為保證隱密性，我們只抓取hover event，並不抓取使用者與之互動的app的觸控事件。因此，預測使用者何時停止懸浮輸入裝置進行點選並不簡單。我們通過如下方法進行處理：通過WindowManager，惡意軟體其實是利用了2個view。一個是之前提到的完全透明的Alert Window。第二個，我們稱之為監聽器，其大小為0px，既不抓取懸浮座標也不抓取點選事件。它存在的意義僅僅是告訴惡意軟體何時發生了點選事件。然後惡意軟體Hoover將利用這條資訊移除/重建透明覆蓋視窗。

圖2：Hoover用透明覆蓋視窗抓取post-click hover event。

3.4.1 推斷點選時間。

所有使用者點選都發生在監聽器外面——它的大小是0px。另外，這個view設定了FLAG_WATCH_OUTSIDE_TOUCH，所以當由點選事件引起的touch

down event發生是它會收到通知。結果就是，惡意軟體可以推斷點選的時間戳，雖然它不知道點選位置（見圖2步驟1）。

3.4.2 抓取post-click hover event。

為了推斷點選位置，攻擊者在touch down event觸發後馬上啟用透明覆蓋視窗，點選事件將順利傳送給真正的app。（見圖2步驟2）。這就保證了攻擊不會影響到正常的裝置使用。而覆蓋視窗，從此刻起，攔截輸入裝置從點選位置到下一次點選位置所引起hover event（見圖2步驟3）。

與監聽器的那個view不一樣，監聽器不會攔截使用者的互動，因為它只有0px，覆蓋視窗不能一直是活動的（出現在螢幕上）。不然它會干擾使用者的下一次輸入。同時，覆蓋視窗又必須活躍足夠長的時間，以保證能抓取足夠多的hover event來推斷點選位置。我們的實驗表明，用本文所說的裝置，系統平均每19ms產生一次hover event。我們還發現，70ms的活躍事件足夠獲取足夠多的hover event去推斷點選而不影響使用者互動。這70ms包括了app的使用時間，不是點選時間，是像在鍵盤上輸入時提示輸入鍵位的那部分時間。當活躍時間用完，覆蓋視窗將再次被移除（見圖2步驟4）。

圖3：Hoover收集hover event。用觸控筆輸入時，hover event（h,h,……,h）緊緊跟隨觸控筆的路徑，用手指的話它們就散落在更寬一點的區域。

3.5 推斷點選位置

在這一部分，惡意軟體已經收集了使用者點選所引起的一系列post-click hover event。利用收集到的資訊，攻擊者的目標是推斷使用者點選的具體位置。一個方案是隻用第一次點選所引起的hover event確定點選位置。但是這個方案雖然對觸控筆效果很好，對手指的結果卻不太好。原因就是，觸控筆的接觸面比較下，形成的hover event都僅僅跟隨使用者的移動（見圖3）。所以，第一個post-click hover event（相對的是，點選之前的最後一個hover event）跟事實的點選位置很接近。相反的，手指的接觸面比較大，所以hover event，包括那個點選後的，也不如觸控筆那樣緊密的貼近使用者移動軌跡。這在我們最初的實驗中就已經證實。該實驗結果表明，第一個post-click hover event所抓取的位置很少在點選位置的上方。

出於此，為提高推斷點選位置的正確率，我們決定應用機器學習工具，它不單考慮第一個post-click hover event，而是考慮了70ms內所抓取的全部事件。尤其是，為了一般化輸入推斷攻擊我們應用了迴歸模型。對於有關鍵盤的攻擊（鍵位推斷）我們利用分類器。在高層次上，給定一系列post-click hover event（h,h,……,h），迴歸模型要回答以下問題：“使用者點選的位置在哪裡？”同樣的，分類器輸出最可能是使用者輸入的那個鍵位。為評估攻擊，我們用了數個迴歸模型和分類器，這些模型和分類器用的是scikit-learn[25]框架。我們在下一部分的結果中進行描述。

在我們最初的實驗中，我們注意到不同的使用者有不同的hover event模式。有些使用者移動輸入裝置的速度比較快。就手指而言，手指的形狀和大小所產生的hover模式是不一樣的。為保證點選預測的正確率和魯棒性，我們需要用不同的使用者所產生的資料訓練迴歸模型和分類器。出於此，我們進行了兩類使用者實驗，將在下一部分進行描述。

表一：實驗所用的裝置

4. 評估

4.1 攻擊原型（惡意軟體）和實驗安排

為評估本文所說的攻擊，我們針對Android系統設計了一款惡意軟體原型，叫Hoover。這個原型按邏輯分為兩步：首先收集hoverevent（如第三部分說的）然後分析它們以預測使用者的點選座標。我們用兩個不同的元件來實現這兩步。這兩個元件可以在使用者裝置上同時執行。但是因為功能不同，為了方便分析，我們將它們分開了。Hover event收集元件是在使用者裝置上執行的Android惡意app。分析器用python實現，執行在遠端伺服器。它們之間的通訊通過惡意軟體的INETERNET許可權來實現，INETRNET許可權是普通許可權，所有Android app均預設配置，不會驚擾使用者。

上傳收集到的hover event到遠端伺服器並不需要多大的頻寬。舉個例子，一臺裝置執行四個小時，惡意軟體收集到近3800次使用者點選所引起的hover event。加密後每次點選的hover event是40 Byte，總的就150KB。這樣的資料還是大量使用的結果，我們是為了得到一個上界才進行的。所以，我們相信，在實際生活中，一般使用者點選產生的資料量會非常小。

最後，為進行實驗，我們招募了20名志願者，他們的資料在在下一節中。評估Hoover分兩個場景：一個場景是使用者在螢幕上亂點，另一個是明確的點選鍵盤輸入文字。我們用兩種不同的輸入裝置和表一所展示兩種不同的裝置進行了大量的實驗。但是，Hoover所表現的想法是通用的，不依賴於某個裝置。因此，我們相信，此類攻擊對於其他支援hover技術的Android裝置一樣有效。

4.2 用例和志願者招募

在這一節我們描述用例的具體細節，同時報告為評估攻擊所做的志願者招募。

用例Ⅰ（常規點選）這個用例的目的是收集使用者隨意在螢幕點選的資訊。因此，我們讓志願者玩一個定製遊戲：時不時的點選隨機出現在螢幕上的小球。這個用例持續2分鐘。

用例Ⅱ（文字輸入）這第二個用例主要是鍵盤輸入。志願者被要求輸入喬治奧威爾的《1984》的一段文章。每一段，平均有250個英文字母，包括標點符號。

每個用例由志願者進行3次。第一次用拇指作為輸入裝置，第二次用食指，第三次用觸控筆。我們記錄下實驗中所有使用者點選位置和hover event。

表二：志願者資訊

4.3 post-click hover event的收集時間

研究的第一方面是Hoover在不干擾使用者下一次點選的情況下覆蓋視窗能保持活躍多久。實驗表明，在98%的例子用，點選與點選之間的間隔大於180ms。

接著我們研究post-click hover event的數目是如何影響預測的準確率的。出於此，我們讓兩個志願者進行一個初步實驗研究。最初的實驗結果表明正確率隨著hover

event的數目成比例增長。但是，在前4個event之後，正確率的增長小於1%（4個事件正確率為78%，5個為79%）因此，要評估Hoover原型，我們只需用4個post-click hover event。這個選擇影響Hoover的覆蓋視窗活躍事件，也就是它收集post-click hover event的時間。實際上，我們觀察到，70ms已經足夠了，因為在前4個post-click hover event總是在使用者點選後70ms內發生。

最後，注意到相對於我們實驗觀察到的180ms的點選間隔，我們選擇70ms略微保守。但是，如我們在下一節看到的，預測結果的正確率還是很高的。一方面，長時間的收集能增加post-hover

event的數量提高惡意軟體推斷使用者輸入的正確率。另一方面，當使用者點選的速度非常快——比我們實驗的使用者更快的時候，靜態的、長時間的收集會暴露敵手身份。也就是說，更成熟的敵手應該可以開起任意短時間收集視窗並動態適應使用者的輸入速度。

4.4 Hoover在點選推斷的正確率

在這一節我們給出有關Hoover推斷使用者點選座標的有效性和準確性的實驗結果。一旦Hoover手機到使用者的post-click hover event就將他們傳送給基於機器學習的執行在執行伺服器上的分析器。

4.4.1 推斷使用者常規點選的座標。

分析器應用迴歸模型推斷使用者在螢幕上的點選位置。直觀上，正確率取決於預測使用的模型。因此，我們用了幾個模型來做實驗。包括兩個線性模型（Lasso和線性迴歸），一個決策樹，和一個整合方法（隨機森林）[25]。每個模型的輸入都是Hoover（見第三部分）對每一個使用者每一次點選收集到的post-click

hover event 的座標（x,y）。輸出是預測的點選位置的座標。至於benchmark baseline（基準基線），我們應用簡單的方法輸出第一個觀察到的post-click hover event的座標。

我們用的是留一法交叉驗證（leave-one-out cross-validation）,也就是說，樣本里的所有物件（使用者點選）都經歷測試和驗證。根據對20位志願者進行實驗得到的資料，我們的預測結果如圖4（a）和4（b）所示，分別為觸控筆和手指。我們可以看到不同的迴歸模型的均方根誤差（Root Mean Square Error,RMSE）是不一樣的。

首先，我們觀察到，對於所有的迴歸模型，手指的正確率均低於觸控筆的正確率。這是預料之內的，因為針對觸控筆的hover檢測技術的正確率就比較高（hover

event緊隨著其移動），手指的話，hover event散落在更寬的範圍。雖然如此，兩者的預測也都很不錯。尤其是，觸控筆的預測誤差（estimation error）僅為2px。還要記住，實驗所用的最小的裝置是Note 3 Neo，其大小是720*1280px.

最後，我們注意到，對於觸控筆（見圖4（a））,簡單線性迴歸模型比其他複雜模型的效果更好。但是對於手指（見圖4（b））就不是這樣。實際上，對於手指來說，預測效果最好的是隨機森林模型，其次才是線性模型。我們相信，這依然是因為觸控筆抓取到的hover

event比較精確，相對於手指來說。

4.4.2 推斷鍵盤輸入

為在基於鍵盤的用例中的使用者輸入鍵盤推斷，我們應用如下方法：（1）用先前的方法論推斷對應的點選座標，（2）觀察預測好的點選座標坐落於那些鍵位區域，（3）輸出預測的鍵位。

就像之前所說的，對於用線性迴歸模型進行的觸控筆點選預測，其正確率非常高——與真實點選座標僅有2px的誤差。所以，上面的方法對觸控筆來說不是問題。但是，對手指的話就不那麼使用了，因為誤差太大。因此，我們用了另外一種方法，並針對後面的分類提出了一個問題：“根據觀察到的post-click

hover event，使用者按了哪個鍵？”。同樣的，我們應用了幾個分類模型：兩個基於樹（決策樹和extra tree），Bagging分類器和隨機森林方法[25]。和迴歸問題一樣，我們得用一個基線（baseline）模型作為基準（benchmark）。基線是將第一個post-click

hover event轉換為包含了這個座標的鍵位。實驗結果用10折交叉驗證（10-fold cross-validation）。

關於用例Ⅱ文字輸入的推斷結果如圖4（c）和4（d）所示，分別為觸控筆和手指。首先，我們觀察到，對於兩種輸入方法在鍵位預測上隨機森林模型（Random Forest，RF）的正確率是最高的——手指的是78%（見圖4（d））,觸控筆的是98%（見圖4（c））。值得一提的是，對於手指，baseline和隨機森林模型的結果差距有點大——baseline是40%，隨機數是79%。但是觸控筆的就和正確結果都差不多。尤其是，baseline和表現最好的隨機森林模型僅相差1%,

隨機森林的是98%（見圖4（c））。

這些結果表明，Hoover可以正確偷取使用者在螢幕鍵盤上的輸入。而且，我們相信，在應用更復雜的基於字典的糾正後正確率會有所提升。

圖4：對於用例Ⅰ（圖4（a）和4（b））和用例Ⅱ（圖4（c）和4（d））的評估。Base:Baseline；DT:Decision Tree決策樹；RF，Random Forest 隨機森林；Lasso：Lasso迴歸；LR:Linear Regression 線性迴歸；ET：Extra Trees分類器；BC，bagging 分類器。

4.5 從其它點選中區分鍵盤輸入

Hoover收集所有型別的使用者點選。所以，需要區分螢幕鍵盤點選和其他型別點選。一種方法是利用邊通道，例如，/proc資料夾。Hoover可以用和文獻[8]類似的技術獲取使用者輸入。但是出於兩個原因，我們不能單單用/proc檔案實現鍵盤檢測。第一，它不是完全正確的[8]，有一定的假陽（false positive）和假陰（false negative）。第二，我們不能確定/proc資料夾總是可用的，且所有app都可以接觸到它。

因此，我們應用一個簡單的啟發式方法來解決這個問題。這個方法利用螢幕鍵盤位於裝置螢幕底端這一事實。因此，當使用者進行輸入時，點選更傾向於鍵盤所在區域。最簡單的方法是應用一個estimator（評估者）從所有使用者點選中區分目標鍵盤鍵位。這個方法不會出現假陰。但是會出現假陽。實際上，使用者有很多可能會在螢幕下方進行點選：在需要點選的遊戲，有些遊戲的開始鍵就在這個區域，等等。

為過濾會引起假陽性的點選，我們進一步改進我們的方法。想法很簡單：如果使用者真的是文字輸入，她需要在螢幕下方進行大量連續點選。所以我們過濾掉短點選序列（少於4個字母），這甚至不可能是使用者名稱或密碼。而且，根據經驗，在使用者開啟輸入框開始進行輸入，起碼有500ms的時間間隔她才會敲擊第一個鍵。這個時間是將鍵盤載入到螢幕上所花費的。我們把這個條件新增到啟發式方法中以減少假陽性。

為評估這個啟發式方法，我們收集了一臺手機在48個小時正常使用下（例如，聊天，瀏覽網頁，打電話）的資料。我們收集當使用者開始（和結束）與鍵盤互動的點選事件，hover

event，時間戳。這兩個啟發式方法的假陰性均為0。簡單版本的假陽性為14.1%，改進版本的下降到10.76%（提升了24%）。

這兩個啟發式方法僅僅是概念驗證（proof-of-concept）。我們相信，包含輸入時間與點選觸控時間（也就是使用者把輸入裝置放在螢幕上的時間）差別的更成熟的改進方法能夠減少假陽性。但這超出本文範圍。

4.6 讓Hoover不依賴於SYSTEM_ALERT_WINDOW

至今為止，我們所說的Hoover是通過Alert Window實現的，需要SYSTEM_ALERT_WINDOW許可權。現在，我們證明我們可以不用該許可權就實現同樣的功能，用一種更復雜的方法：利用Toast類[2]。

Toast類用來生成通知或者關於系統的快速訊息（quick message）。關於Toast的一個例子就是當使用者提高或降低音量時出現的音量控制器視窗。他們不需要任何特殊許可權而且可以為任意服務或使用者app所用。更重要的是，和Alert Window一樣，Toast可以抓取hover event，能包含定製的View類物件，而且總是在其他視窗的上面，包括前臺app。因此，監聽器和透明覆蓋視窗都可以由Toast Window生成。

作為概念驗證，我們用Toast Window實現了Hoover的一個版本。Android限制Toast的活躍時間僅為幾秒。所以要實現監聽器就比較困難，因為監聽器應該一直在螢幕上。實際上，利用Toast類，Hoover可以在監聽器消失之前定期地呼叫toast.show()。透明覆蓋視窗不存在這個問題，因為在之前的章節中我們已經驗證過，在監聽器檢測到點選事件後透明視窗只需出現70ms。收集到hover event以後移除覆蓋視窗啟用監聽器。通過此種方法我們可以讓Hoover實現同樣的功能而不需任何其他許可權。

4.7 進一步實現攻擊

先前的論述證明hover event可以用來正確推斷使用者輸入，包括常規點選位置和鍵盤鍵位。

在這一部分，我們給出兩種技術，我們相信，可以提高攻擊和正確率。

語言模式。在評估中我們考慮的是最複雜的情況，也就是沒有假設輸入文字的語言。儘管實驗中志願者們用的是英文，但是對其他任何語言同樣適用。更老練的攻擊者應該首先檢測使用者輸入的語言，然後在用我們描述的方法進行鍵位推斷，應用誤差修正演算法提高正確率。

Per-user模型。在評估中，不管是迴歸模型還是分類器，我們都是由所有使用者實驗所得的資料進行訓練。也就是說，得到的迴歸和分類模型之後也用來評估所有使用者。這個模式的有點是，如果攻擊新使用者，攻擊結果和我們實驗所得結果差不多。但是，我們也可以想一個per-user

模型提高準確率。我們無法用我們的資料庫驗證這個想法，因為我們沒有足夠多的per-user資料。但是，我們對兩個有最多資料點的使用者進行了初步評估。結果顯示per-user模型能改進，尤其是針對手指。實際上，就鍵盤推測正確率，第一個使用者從79%（所有使用者的資料）提升到了83%，第二個則是86%。

4.8 另一種鍵盤輸入方法

針對文字輸入，我們的攻擊非常有效且正確。但是對於滑動輸入文字（swiping text）就不是那麼有效了。實際上，Hoover只在輸入裝置離開螢幕時推斷座標。用swiping，僅能推斷使用者劃過的每一個單詞的最後一個字母。但是，也需注意到，對於類似密碼的文字以及數字或符號，swiping是無效的，須使用者輸入。因此，就算是有swiping，Hoover依然能竊取使用者的敏感資訊，諸如密碼或pin碼。

在攻擊中，我們假設使用者使用的是常規鍵盤。但是，使用者也可能應用其他複雜的安全機制，例如定製鍵盤，在輸入敏感資訊後重新佈置鍵位。這種輸入機制當然能減輕我們的攻擊：這樣Hoover無法將座標與鍵位聯絡起來。但是當使用者發現在那種每次輸入後都重置鍵位的鍵盤上書寫特別痛苦的時候，這種裝置的使用率也會下降。最後，這種機制會傾向於保護類似PIN和證照類敏感資訊，而簡訊、email和其他資訊序列依然暴露在我們的攻擊之下。

本文由看雪翻譯小組lumou編譯，來源Enis Ulqinaku、Luka Malisa、Julinda Stefa、Alessandro Mei、Srdjan Čapkun@ethz.ch

轉載請註明來自看雪社群