摘要：發(fā)現(xiàn)分析資源文件的過(guò)程中，發(fā)現(xiàn)了一個(gè)數(shù)據(jù)庫(kù)。激活碼明碼保存。激活碼的發(fā)布和驗(yàn)證分開(kāi)激活碼的發(fā)布由項(xiàng)目負(fù)責(zé)將激活碼明文交由發(fā)布渠道，如印刷或其他銷(xiāo)售渠道。這樣即使激活碼數(shù)據(jù)庫(kù)被泄露也不怕其用來(lái)被激活。

本文隱去了公司名、人名、應(yīng)用名、以及應(yīng)用特征等敏感信息。 本文作者@CuGBabyBeaR

前段時(shí)間看見(jiàn)一個(gè)能夠和現(xiàn)實(shí)進(jìn)行交互的應(yīng)用，覺(jué)得挺有意思，恰巧有一個(gè)下午的空閑時(shí)間，于是就把APP下載下來(lái)進(jìn)行分析。

應(yīng)用本身是免費(fèi)的，但是解鎖功能需要激活碼，并且交互需要攝像頭識(shí)別相應(yīng)卡片（Augmented Reality AR卡）。去他們的官方淘寶店看了看，算下來(lái)是5塊錢(qián)一張，正在打折。

整個(gè)APK 120m+ ，顯然是將模型數(shù)據(jù)放在APK中，通過(guò)攝像頭識(shí)別卡片，通過(guò)識(shí)別到的內(nèi)容調(diào)用不同的模型，和卡片的姿態(tài)進(jìn)行交互。

使用apktool dex2jar 反編譯應(yīng)用，通過(guò)jd-gui查看源代碼。代碼分為3部分：一是主activity的代碼，二是QR識(shí)別的代碼，三是Unity3D。顯然游戲使用的引擎是Unity3D，而其中部分代碼混淆過(guò)，類(lèi)名和變量名都改成了a b c等無(wú)意義的名字，這一部分代碼可能是來(lái)自 https://developer.vuforia.com/ 。

稍微分析了一下activity的代碼后，便放棄了。然后轉(zhuǎn)去研究資源文件。res的資源文件只有應(yīng)用圖標(biāo)而已，有意義的資源都在assets里。除開(kāi)QR識(shí)別的資源外，就是Unity3D使用的dll和模型文件了。模型文件進(jìn)行了簡(jiǎn)單的分割，意義不明。

分析資源文件的過(guò)程中，發(fā)現(xiàn)了一個(gè)數(shù)據(jù)庫(kù)。一開(kāi)始對(duì)其并不在意，在分析完assets中的資源文件之后，關(guān)注點(diǎn)就轉(zhuǎn)移到這個(gè)數(shù)據(jù)庫(kù)身上了。是一個(gè)sqlit3數(shù)據(jù)庫(kù)，用SQLite Expert 打開(kāi)后，其中有兩個(gè)表。一個(gè)表是卡的數(shù)據(jù)，數(shù)據(jù)列兩列，包括卡的代碼和是否啟用。另一個(gè)表的列名讓我很在意“ActivedCode”，難道是激活碼？找到第一行此列值，輸入到應(yīng)用里，發(fā)現(xiàn)...激活了...

我頓時(shí)就凌亂了，另外一列的名字叫QRCode 。于是找了最后一行的QRCode，找了一個(gè)在線(xiàn)QR碼生成器，QRCode輸入進(jìn)去，用應(yīng)用識(shí)別生成的QR圖。又激活了。

因?yàn)锳R卡本身只是一張卡片，卡片只是通過(guò)卡片上圖案特征進(jìn)行識(shí)別的。而在其他的AR卡應(yīng)用中（如PSV的和其他非盈利性的Android AR卡應(yīng)用）即便是復(fù)印的也可以被正確識(shí)別。而這個(gè)應(yīng)用中有卡片的圖片，只要將圖片提取或者截屏下來(lái)，按照原卡片的大小打印裁切，應(yīng)該是可以用的...如果這3萬(wàn)條數(shù)據(jù)被泄露出去...恐怕這款應(yīng)用是賺不到錢(qián)了。

我去這個(gè)公司的官網(wǎng)，找到了一個(gè)該應(yīng)用IOS版開(kāi)發(fā)者的QQ號(hào)，把這件事和他說(shuō)了一下，他說(shuō)轉(zhuǎn)告同事去處理了。

過(guò)了半個(gè)月，我又想起了這件事，找那位開(kāi)發(fā)者要了Android版開(kāi)發(fā)者的QQ號(hào)。和Android版開(kāi)發(fā)者交流了一下，他說(shuō)是測(cè)試的時(shí)候?qū)?shù)據(jù)庫(kù)放進(jìn)了APK中，發(fā)布的時(shí)候忘記拿出來(lái)了，而數(shù)據(jù)庫(kù)也從新的APK中去掉了。

這個(gè)事件還算是完美地解決了。不過(guò)出現(xiàn)這個(gè)問(wèn)題的原因，除了Android應(yīng)用本身，容易被反編譯的客觀原因之外，我感覺(jué)有兩個(gè)主要主觀原因：

(1) 沒(méi)有分開(kāi)開(kāi)發(fā)環(huán)境和生產(chǎn)環(huán)境。不過(guò)Android開(kāi)發(fā)環(huán)境中貌似沒(méi)有原生的開(kāi)發(fā)生產(chǎn)分開(kāi)的功能，只能用ANT。這樣的話(huà)有一個(gè)土辦法，做一個(gè)checklist，每次發(fā)布按照這個(gè)checklist做，這樣就不會(huì)有不應(yīng)該出現(xiàn)在產(chǎn)品中的東西遺留在產(chǎn)品中。

(2) 激活碼明碼保存。雖然說(shuō)一般激活碼的數(shù)據(jù)庫(kù)都只會(huì)放在服務(wù)器上，不會(huì)被泄露出來(lái)。然而如果一個(gè)不小心數(shù)據(jù)庫(kù)被流出了，作為最后的保險(xiǎn)，我認(rèn)為數(shù)據(jù)庫(kù)本身最好還是加密一下。所有可用激活碼的明文，由項(xiàng)目負(fù)責(zé)一人管理。激活碼的發(fā)布和驗(yàn)證分開(kāi)：激活碼的發(fā)布由項(xiàng)目負(fù)責(zé)將激活碼明文交由發(fā)布渠道，如印刷或其他銷(xiāo)售渠道。而負(fù)責(zé)激活的服務(wù)器上激活碼的數(shù)據(jù)庫(kù)都是使用不可逆加密算法加密的密文。驗(yàn)證的時(shí)候用戶(hù)輸入激活碼后，服務(wù)器將輸入內(nèi)容加密，與數(shù)據(jù)庫(kù)中的內(nèi)容進(jìn)行比較，執(zhí)行激活操作。這樣即使激活碼數(shù)據(jù)庫(kù)被泄露也不怕其用來(lái)被激活。

文章轉(zhuǎn)載自：伯樂(lè)在線(xiàn) - CuGBabyBeaR