摘要：發現分析資源文件的過程中，發現了一個數據庫。激活碼明碼保存。激活碼的發布和驗證分開激活碼的發布由項目負責將激活碼明文交由發布渠道，如印刷或其他銷售渠道。這樣即使激活碼數據庫被泄露也不怕其用來被激活。

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

前段時間看見一個能夠和現實進行交互的應用，覺得挺有意思，恰巧有一個下午的空閑時間，于是就把APP下載下來進行分析。

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

整個APK 120m+ ，顯然是將模型數據放在APK中，通過攝像頭識別卡片，通過識別到的內容調用不同的模型，和卡片的姿態進行交互。

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

稍微分析了一下activity的代碼后，便放棄了。然后轉去研究資源文件。res的資源文件只有應用圖標而已，有意義的資源都在assets里。除開QR識別的資源外，就是Unity3D使用的dll和模型文件了。模型文件進行了簡單的分割，意義不明。

分析資源文件的過程中，發現了一個數據庫。一開始對其并不在意，在分析完assets中的資源文件之后，關注點就轉移到這個數據庫身上了。是一個sqlit3數據庫，用SQLite Expert 打開后，其中有兩個表。一個表是卡的數據，數據列兩列，包括卡的代碼和是否啟用。另一個表的列名讓我很在意“ActivedCode”，難道是激活碼？找到第一行此列值，輸入到應用里，發現...激活了...

我頓時就凌亂了，另外一列的名字叫QRCode 。于是找了最后一行的QRCode，找了一個在線QR碼生成器，QRCode輸入進去，用應用識別生成的QR圖。又激活了。

因為AR卡本身只是一張卡片，卡片只是通過卡片上圖案特征進行識別的。而在其他的AR卡應用中（如PSV的和其他非盈利性的Android AR卡應用）即便是復印的也可以被正確識別。而這個應用中有卡片的圖片，只要將圖片提取或者截屏下來，按照原卡片的大小打印裁切，應該是可以用的...如果這3萬條數據被泄露出去...恐怕這款應用是賺不到錢了。

我去這個公司的官網，找到了一個該應用IOS版開發者的QQ號，把這件事和他說了一下，他說轉告同事去處理了。

過了半個月，我又想起了這件事，找那位開發者要了Android版開發者的QQ號。和Android版開發者交流了一下，他說是測試的時候將數據庫放進了APK中，發布的時候忘記拿出來了，而數據庫也從新的APK中去掉了。

這個事件還算是完美地解決了。不過出現這個問題的原因，除了Android應用本身，容易被反編譯的客觀原因之外，我感覺有兩個主要主觀原因：

(1) 沒有分開開發環境和生產環境。不過Android開發環境中貌似沒有原生的開發生產分開的功能，只能用ANT。這樣的話有一個土辦法，做一個checklist，每次發布按照這個checklist做，這樣就不會有不應該出現在產品中的東西遺留在產品中。

(2) 激活碼明碼保存。雖然說一般激活碼的數據庫都只會放在服務器上，不會被泄露出來。然而如果一個不小心數據庫被流出了，作為最后的保險，我認為數據庫本身最好還是加密一下。所有可用激活碼的明文，由項目負責一人管理。激活碼的發布和驗證分開：激活碼的發布由項目負責將激活碼明文交由發布渠道，如印刷或其他銷售渠道。而負責激活的服務器上激活碼的數據庫都是使用不可逆加密算法加密的密文。驗證的時候用戶輸入激活碼后，服務器將輸入內容加密，與數據庫中的內容進行比較，執行激活操作。這樣即使激活碼數據庫被泄露也不怕其用來被激活。

文章轉載自：伯樂在線 - CuGBabyBeaR