Android應(yīng)用內(nèi)話費(fèi)計(jì)費(fèi)安全防控體系＊

黃斐一，余洪，李琳

（咪咕文化科技有限公司，北京 100032）

Android應(yīng)用內(nèi)話費(fèi)計(jì)費(fèi)安全防控體系＊

黃斐一，余洪，李琳

（咪咕文化科技有限公司，北京 100032）

隨著移動(dòng)互聯(lián)網(wǎng)業(yè)務(wù)的飛速發(fā)展，應(yīng)用免費(fèi)、應(yīng)用內(nèi)計(jì)費(fèi)（In-App-Purchase）被越來越多的用戶所接受。主流的計(jì)費(fèi)通道包括支付寶、微信和手機(jī)話費(fèi)支付。本文探討了如何構(gòu)建一個(gè)應(yīng)用內(nèi)話費(fèi)計(jì)費(fèi)的安全防控體系，通過計(jì)費(fèi)SDK軟件加固、異常計(jì)費(fèi)行為發(fā)現(xiàn)、常態(tài)化計(jì)費(fèi)SDK更新和升級(jí)等方式，進(jìn)行端到端的安全管控。

安卓手機(jī)應(yīng)用；應(yīng)用內(nèi)話費(fèi)計(jì)費(fèi)；手機(jī)支付；安全

1 引言

應(yīng)用內(nèi)計(jì)費(fèi)（In-App-Purchase）指用戶可以免費(fèi)下載的手機(jī)應(yīng)用（下稱手機(jī)App或App），但在使用應(yīng)用的過程中購買App內(nèi)的數(shù)字產(chǎn)品并支付費(fèi)用，比如：游戲的道具、虛擬貨幣，音樂和視頻等等。用戶支付的方式多種多樣，主要分為手機(jī)話費(fèi)支付和非話費(fèi)支付兩大類。若App希望提供手機(jī)話費(fèi)的支付能力，它一般需要集成由電信運(yùn)營商提供的話費(fèi)計(jì)費(fèi)SDK，并成為相關(guān)運(yùn)營商的合作伙伴。當(dāng)用戶購買App中的數(shù)字內(nèi)容時(shí)，App就會(huì)調(diào)用話費(fèi)計(jì)費(fèi)SDK提供的話費(fèi)計(jì)費(fèi)通道，通過運(yùn)營商完成代扣費(fèi)。若App希望提供人民幣支付的能力，一般的做法是集成由微信和支付寶提供的支付SDK，并在計(jì)費(fèi)的時(shí)候由App調(diào)用。

從用戶的角度來說，支付分為有密碼支付和無密碼支付。有密碼支付以微信支付、支付寶支付為代表，即每次支付前用戶需要完成登錄、賬號(hào)密碼驗(yàn)證的步驟，方可發(fā)起支付。無密碼支付以運(yùn)營商的手機(jī)話費(fèi)支付為代表，它可以使用用戶的手機(jī)號(hào)碼（本人或他人）完成支付，而無需提前設(shè)定、支付時(shí)使用賬號(hào)和密碼，這種場景以中國移動(dòng)咪咕公司和中國移動(dòng)互聯(lián)網(wǎng)公司的手機(jī)話費(fèi)支付為代表。以中國移動(dòng)咪咕公司的話費(fèi)計(jì)費(fèi)SDK為例，當(dāng)App調(diào)用計(jì)費(fèi)SDK的計(jì)費(fèi)接口時(shí)，SDK根據(jù)一系列條件判定本次計(jì)費(fèi)的策略，包括一鍵支付、圖形驗(yàn)證碼、短信驗(yàn)證碼。一鍵支付策略無需用戶輸入任何信息、直接點(diǎn)擊“確認(rèn)支付”按鈕即可完成計(jì)費(fèi)；圖形驗(yàn)證策略需用戶根據(jù)看到的圖片輸入要求的內(nèi)容、并點(diǎn)擊“確認(rèn)支付”按鈕即可完成計(jì)費(fèi)；短信驗(yàn)證碼需用戶首先填入手機(jī)號(hào)碼、點(diǎn)擊“獲取驗(yàn)證碼”，而后填入獲取到的短信驗(yàn)證碼，并點(diǎn)擊“確認(rèn)支付”按鈕方可完成計(jì)費(fèi)。

在上述無密支付場景中，無論哪一種策略，都無需用戶事先設(shè)定賬號(hào)、密碼。在提供極大支付便利的同時(shí)，也引入了一定的信息安全風(fēng)險(xiǎn)：在沒有用戶輸入賬號(hào)和密碼的前提下，如何確認(rèn)本次計(jì)費(fèi)系使用官方合法的計(jì)費(fèi)SDK發(fā)起，如何確認(rèn)本次支付來自于用戶的真實(shí)意愿和真實(shí)行為。這就是本文需要探討的課題。

2 應(yīng)用內(nèi)話費(fèi)計(jì)費(fèi)安全風(fēng)險(xiǎn)

一個(gè)完整的話費(fèi)計(jì)費(fèi)流程包括計(jì)費(fèi)確認(rèn)頁面展示、用戶確認(rèn)、訂購3個(gè)主要步驟。這3個(gè)步驟都是由運(yùn)營商提供的官方計(jì)費(fèi)SDK承載和展示的。是不法分子往往嘗試破解計(jì)費(fèi)SDK，并且通過破解的計(jì)費(fèi)SDK發(fā)起計(jì)費(fèi)，這樣一來，他們就可以實(shí)現(xiàn)如下幾種非法操作。

2.1 誘導(dǎo)消費(fèi)

惡意App往往將官方計(jì)費(fèi)SDK的計(jì)費(fèi)確認(rèn)頁面進(jìn)行覆蓋、篡改，淡化收費(fèi)提示、修改金額、甚至直接將頁面提示修改為“免費(fèi)”、“贈(zèng)送”等誤導(dǎo)性字眼，以此設(shè)置各類消費(fèi)陷阱誘導(dǎo)用戶完成付費(fèi)。

2.2 計(jì)費(fèi)點(diǎn)盜用

集成運(yùn)營商的話費(fèi)計(jì)費(fèi)SDK的App需要事先報(bào)備和審核，通過審核的App方能被分配一系列的計(jì)費(fèi)點(diǎn)和相應(yīng)的計(jì)費(fèi)SDK。計(jì)費(fèi)SDK需通過一系列安全手段將該SDK與該App進(jìn)行強(qiáng)綁定，防止該計(jì)費(fèi)SDK被使用在非報(bào)備的App上。若不法分子通過逆向和破解的手段將此綁定關(guān)系解除了，即可將該計(jì)費(fèi)SDK集成到其他的非法App中（如涉黃、涉賭類App），利用合法App的計(jì)費(fèi)點(diǎn)進(jìn)行計(jì)費(fèi)。

2.3 暗扣

暗扣特指未經(jīng)過用戶確認(rèn)和允許，在用戶不知情的情況下私自發(fā)起的計(jì)費(fèi)。它需要將用戶手機(jī)中事先植入的木馬、病毒等控制程序，在用戶不知情的情況下模擬用戶發(fā)起計(jì)費(fèi)請求。除此之外，還需要對計(jì)費(fèi)SDK進(jìn)行破解，使得計(jì)費(fèi)請求發(fā)起的時(shí)候無任何計(jì)費(fèi)確認(rèn)頁面彈出、且無需用戶手動(dòng)開展任何確認(rèn)。

3 應(yīng)用內(nèi)話費(fèi)計(jì)費(fèi)安全防控體系

在不使用賬號(hào)、密碼作為用戶計(jì)費(fèi)驗(yàn)證手段和可信根的情況下，計(jì)費(fèi)SDK本身即成為新的可信根。我們需要通過它來保障計(jì)費(fèi)請求系合法的App調(diào)用合法的計(jì)費(fèi)SDK發(fā)起、保障計(jì)費(fèi)請求由用戶本人意愿發(fā)起以及用戶行為的合法性。

為此我們設(shè)計(jì)了一整套話費(fèi)計(jì)費(fèi)安全防控體系，如圖1所示。它主要包括3個(gè)部分：在計(jì)費(fèi)SDK上線前，通過軟件加固的手段防止惡意破解；在計(jì)費(fèi)過程中，一旦發(fā)現(xiàn)非法App通過破解的SDK發(fā)起的計(jì)費(fèi)請求，或用戶行為與正常用戶行為差異極大，即予以攔截；為保證安全加固手段和異常識(shí)別手段的長期有效，計(jì)費(fèi)SDK會(huì)開展周期性的更新。

圖1 話費(fèi)計(jì)費(fèi)安全防控體系

3.1 計(jì)費(fèi)SDK安全加固

計(jì)費(fèi)SDK安全加固是指對SDK的代碼（Java和C）通過各種技術(shù)手段進(jìn)行保護(hù)，防范不法分子通過逆向分析[1]的方法破解代碼的核心邏輯。軟件安全加固包含了一系列的技術(shù)手段，包括代碼混淆、白盒加密、反調(diào)試、反篡改、虛擬機(jī)等。這些軟件加固手段往往不會(huì)單獨(dú)使用，而會(huì)同時(shí)使用、相互守護(hù)。

3.1.1 代碼混淆

代碼混淆[2]是指通過增大代碼復(fù)雜度、冗余度的方法，在正常的業(yè)務(wù)代碼中插入大量的垃圾代碼，對代碼中定義的字符串、變量、數(shù)學(xué)表達(dá)式進(jìn)行變形、等價(jià)變化，對數(shù)據(jù)流和控制流進(jìn)行變形使其增加大量的分支邏輯、跳轉(zhuǎn)邏輯，從而提升代碼逆向分析破解的難度、保護(hù)代碼核心邏輯。

3.1.2 白盒加密

白盒加密[3]不是一個(gè)算法，而是某種加密算法的表現(xiàn)形態(tài)。某種加密算法的白盒加密形態(tài)將原有以字符形態(tài)存在的密鑰（如“123”）變成以代碼的方式存在（如函數(shù)A、B、C的運(yùn)行結(jié)果拼裝而來），提升加解密算法的安全性。

3.1.3 反調(diào)試

調(diào)試技術(shù)指通過計(jì)算機(jī)的調(diào)試接口手段獲取程序運(yùn)行過程中產(chǎn)生重要變量和數(shù)據(jù)的技術(shù)手段。反調(diào)試技術(shù)[4]則是防止被保護(hù)的程序被第三方程序調(diào)試。它主要通過監(jiān)控各類計(jì)算機(jī)調(diào)試接口發(fā)現(xiàn)調(diào)試，通過布置調(diào)試阻礙讓破解者無法調(diào)試，比如一旦發(fā)現(xiàn)調(diào)試即讓被保護(hù)的程序崩潰或退出。

3.1.4 反篡改

對于破解者來說，當(dāng)發(fā)現(xiàn)了他的調(diào)試無法開展下去，且一直被一段反調(diào)試程序破壞的時(shí)候，他往往會(huì)篡改這段反調(diào)試程序，使其不起作用。這時(shí)就是反篡改技術(shù)發(fā)揮作用的時(shí)候。所以說反篡改技術(shù)一般配合其他安全加固手段共同使用，用于守護(hù)其他安全加固手段。當(dāng)這些加固手段被破壞的時(shí)候，發(fā)篡改程序就能夠起到監(jiān)控、發(fā)現(xiàn)、防止篡改的作用。

3.1.5 虛擬機(jī)

圖2 虛擬機(jī)保護(hù)技術(shù)

上述多種軟件加固技術(shù)可以理解為傳統(tǒng)的加固技術(shù)。遺憾的是，被加固的代碼最終會(huì)編譯為x86或ARM CPU能夠識(shí)別的指令集。對于逆向分析者來說，通過專業(yè)的逆向分析工具，如IDA，即可對其進(jìn)行直接開展逆向工作。與傳統(tǒng)加固手段不同的是，代碼虛擬機(jī)化[5]采用將x86或ARM的匯編指令進(jìn)行了變化，如將ARM指令集中的MOVE指令變成了其他的指令命名方式。這樣一來，等同于構(gòu)建了一個(gè)虛擬的CPU，如圖2所示。所有代碼先進(jìn)行虛擬指令變形，在運(yùn)行時(shí)則通過一個(gè)解釋器解釋執(zhí)行。這樣一來，代碼在執(zhí)行的過程中會(huì)按照私有的指令執(zhí)行，并通過解釋器解釋成CPU可以識(shí)別的機(jī)器碼執(zhí)行。這種代碼保護(hù)手段成為虛擬機(jī)保護(hù)（VMProtection）。通過這種手段保護(hù)的代碼無法被IDA直接識(shí)別和逆向。破解者需先攻破虛擬代碼解釋器方能夠開展有效的逆向工作。盡管虛擬機(jī)技術(shù)被業(yè)界公認(rèn)為下一代代碼安全保護(hù)技術(shù)，但是目前尚未有App/SDK真正的使用虛擬機(jī)保護(hù)技術(shù)保護(hù)其代碼。這是因?yàn)樘摂M機(jī)技術(shù)需要在保障安全性的同時(shí)，克服兩大難題：兼容性和運(yùn)行效率。所以虛擬機(jī)保護(hù)產(chǎn)品需要走向成熟還有較長的路要走。

3.2 計(jì)費(fèi)異常識(shí)別

與大型網(wǎng)絡(luò)游戲防范游戲外掛的手段類似[6]，開發(fā)人員會(huì)在計(jì)費(fèi)SDK中代碼中植入“打點(diǎn)”代碼。所謂打點(diǎn)代碼，通俗的說就是一系列與主業(yè)務(wù)邏輯無關(guān)的、以安全功能為主要目標(biāo)的代碼。在計(jì)費(fèi)SDK中，打點(diǎn)代碼不參與計(jì)費(fèi)流程所必須參數(shù)的交互，比如不處理給哪個(gè)用戶計(jì)費(fèi)、購買什么、多少價(jià)格等等。它常常開展復(fù)雜的數(shù)學(xué)計(jì)算和數(shù)學(xué)變換，也往往盡可能多的抓取手機(jī)客戶端的軟硬件信息，如手機(jī)型號(hào)、品牌、操作系統(tǒng)版本等。這些打點(diǎn)代碼獲取的數(shù)據(jù)和信息是進(jìn)行異常識(shí)別的基礎(chǔ)。

根據(jù)HTTP網(wǎng)絡(luò)交互特性，交互報(bào)文的長度是沒有限制的。所以，打點(diǎn)代碼采集的信息的上傳隨著計(jì)費(fèi)SDK客戶端與服務(wù)端的交互同步進(jìn)行。這些信息會(huì)被添加到業(yè)務(wù)報(bào)文后面，隨著業(yè)務(wù)報(bào)文一起被上傳到服務(wù)端?；谑占椒?wù)端的打點(diǎn)信息，服務(wù)端即可以判斷計(jì)費(fèi)SDK是否完整，從而判定識(shí)別非完整計(jì)費(fèi)SDK發(fā)起的計(jì)費(fèi)進(jìn)行異常判定。舉個(gè)非常簡單的例子，打點(diǎn)代碼可以在業(yè)務(wù)報(bào)文后面添加一個(gè)字節(jié)，這個(gè)字節(jié)是常數(shù)“1”。服務(wù)端會(huì)校驗(yàn)每一次計(jì)費(fèi)請求之后有沒有這個(gè)常數(shù)“1”，若沒有則可判定為非法SDK發(fā)起的計(jì)費(fèi)請求。

基于用戶行為的異常判定依據(jù)正常用戶行為模型開展。一般來說，會(huì)事先設(shè)定一系列正常用戶的行為模式。每次計(jì)費(fèi)發(fā)起時(shí)會(huì)通過這些模型進(jìn)行匹配，若匹配到異常行為模型則可直接判定為異常請求；若匹配到正常行為模型則可判定為正常請求；若未匹配到異常模型、亦未匹配到正常模型，系統(tǒng)一般不會(huì)進(jìn)行處置，而留待事后大數(shù)據(jù)分析進(jìn)行判定。未能判定的原因可能是模型不全面，需要抽象該行為并制定新的模型；也可能是單條請求無法判定，需要通過大數(shù)據(jù)關(guān)聯(lián)分析進(jìn)行確認(rèn)。

3.3 計(jì)費(fèi)SDK動(dòng)態(tài)更新

任何安全防護(hù)手段都一直面臨著逆向分析和破解攻擊，所以周期性的更新計(jì)費(fèi)SDK是非常必要的。更新包括對安全加固手段的更新、打點(diǎn)代碼的更新以及異常判定模型的更新。更新分為靜態(tài)更新和動(dòng)態(tài)更新兩種，兩種更新方式各有優(yōu)劣、各有適用場景。靜態(tài)更新指計(jì)費(fèi)SDK更新后需App重新集成新版本的計(jì)費(fèi)SDK，并且將集成了新版SDK的App進(jìn)行重新發(fā)布。這種更新方式往往發(fā)生在計(jì)費(fèi)SDK與App之間的接口發(fā)生變動(dòng)或者計(jì)費(fèi)SDK有較大的框架性變化時(shí)使用。動(dòng)態(tài)更新指計(jì)費(fèi)SDK的自更新，無需App重新集成和發(fā)布。這種更新方式往往在計(jì)費(fèi)SDK進(jìn)行安全性更新以及無較大框架下變化的情況下使用。

4 結(jié)論

本文介紹了一個(gè)計(jì)費(fèi)安全防控體系，它通過計(jì)費(fèi)SDK軟件加固、異常計(jì)費(fèi)行為發(fā)現(xiàn)、常態(tài)化計(jì)費(fèi)SDK更新和升級(jí)等技術(shù)和機(jī)制為安卓手機(jī)應(yīng)用話費(fèi)計(jì)費(fèi)構(gòu)建了端到端的安全保障。當(dāng)然，只有持續(xù)的更新才是保障安全的基石。上述框架中的任何技術(shù)、模型和機(jī)制，都需要持續(xù)不斷的發(fā)掘新技術(shù)、新思路，強(qiáng)有力的對抗破解和逆向分析。

[1] 趙榮彩，龐建民，張靖博. 反編譯技術(shù)與軟件逆向分析[M].北京：國防工業(yè)出版社，2009.

[2] 羅宏，蔣劍琴，曾慶凱. 用于軟件保護(hù)的代碼混淆技術(shù)[J].計(jì)算機(jī)工程， 2006(32).

[3] Gu， Yuan Xiang， Mcrae Paul， Nicolescu Bogdan， et，al. Interlocked binary protection using whitebox cryptography： US 9141787[P].2015.

[4] 徐劍，武爽，孫琦，等. 面向Android應(yīng)用程序的代碼保護(hù)方法研究[J]. 信息網(wǎng)絡(luò)安全， 2014(10).

[5] 章華清. 基于虛擬機(jī)的軟件動(dòng)態(tài)保護(hù)系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[D].西安：西安電子科技大學(xué)， 2016.

[6] 騰訊游戲研發(fā)部游戲安全中心. 游戲安全：手游安全技術(shù)入門[M]. 北京：電子工業(yè)出版社，2016.

Android IAP security management system for Android applications

HUANG FEI-yi, YU Hong, LI Lin
(Migu Culture Technology Co., Ltd., Beijing100032, China)

With the development of mobile Internet, download for free and in-app-purchase is becoming more and more popular.Primary online payment includes Alipay, Tenpay and mobile phone payment. In order to tackle with this problem, an end-to-end IAP security management system for Android applications is introduced in this paper, which includes methodologies of software hardening, abnormal charging detection and frequent SDK update and upgrade.

Android applications; in-app-purchase; mobile phone payment; security

TN929.5

A

1008-5599（2017）09-0013-04

2017-08-26

* 中國移動(dòng)集團(tuán)級(jí)一類科技創(chuàng)新成果，原成果名稱為《多版本、新機(jī)制的App計(jì)費(fèi)安全SDK能力系統(tǒng)》。