Andorid-APP 安全測試（二）

繼上一篇Andorid-APP 安全測試（一）的內容

此流程圖是我在學校為學生講課時按課程安排做的，測試點可做為參考，主要為APP自身漏洞的客戶端測試為主。後續文章會繼續完善~

APP面臨的主要風險

客戶端：

傳統逆向分析類（反編譯、除錯、加密/簽名破解…）

使用者已經中招類（輸入記錄、匯出元件、程序注入…）

服務端：

系統元件類（MS12-020、ShellShock、心血、ST2…）

業務應用類（注入跨站越權執行上傳下載弱口令…）

本地客戶端測試

本章我主要介紹的本地客戶端的測試，所需要的環境、工具、APK檔案結構、架構、測試點等。

客戶端測試 - 元件匯出安全

什麼是元件？

• 安卓APP以元件為單位進行許可權宣告和生命週期管理；

元件有什麼用？

• 安卓系統的元件共有四種，其主要用途分別為：

• Activity：呈現可供使用者互動的介面，是最常見的元件；

• Service：長時間執行後臺作業，常見於監控類應用；

• Content Provider：在多個APP間共享資料，比如通訊錄；

• Broadcast Receiver：註冊特定事件，並在其發生時被啟用

• 什麼是許可權宣告？

• 安卓系統定義了許多許可權宣告項，分別對應一些作業系統功能

許可權宣告有什麼用？

• 如果一個APP或元件在沒有宣告許可權的情況下就呼叫相關API，會被拒絕訪問；

• 但如果聲明瞭相關許可權，安裝的時候就會有提示；

• 這樣一來，使用者就可以評估使用該APP可能帶來的風險

什麼是元件匯出？

• 簡而言之，就是別的APP也可以訪問這個元件。

• 再總而言之，就是元件許可權的控制。

元件匯出有什麼用？

• 有些APP的功能需要提供一些介面給其它APP訪問，就需要把相關的介面功能放在一個匯出的元件上。

元件匯出有什麼危害？

因為許可權宣告是以元件為單位的，A元件呼叫B元件的功能來訪問作業系統API時，適用於B元件的許可權宣告。

如果B作為匯出元件，沒有進行嚴格的訪問控制，那麼A就可以通過呼叫B來訪問原本沒有宣告許可權的功能，構成本地許可權提升。

四大元件詳細介紹

Activity元件漏洞

Activity是Android元件中最基本也是最為常見用的四大元件之一，是一個負責與使用者互動的元件。Activity元件中存在以下常見的漏洞。 (1)activity繫結browserable與自定義協議activity設定“android.intent.category.BROWSABLE”屬性並同時設定了自定義的協議android:scheme意味著可以通過瀏覽器使用自定義協議開啟此activity。可能通過瀏覽器對app進行越權呼叫。(2)ActivityManager漏洞ActivityManager類中的killBackgroundProcesses函式，用於殺死程序，屬於風險API。還有通過ActivityManager被動嗅探intent。Intent嗅探指令碼首先呼叫一個Context.getSystemService()函式，並傳給它一個ACTIVITY_SERVICE標誌的識別符號，該函式返回一個ActivityManager類的例項，它使得該指令碼能夠與activity manager進行互動，並通過這個物件呼叫ActivityManager.getRecentTasks()方法。最後把intent相關的資訊格式化成字串返回出來。

Service元件

作為Android中四大元件之一，擁有重要的地位。Service具有和Activity一樣的級別，只是沒有介面，是運行於後臺的服務。其他應用元件能夠啟動Service，並且當用戶切換到另外的應用場景，Service將持續在後臺執行。另外，一個元件能夠繫結到一個service與之互動（IPC機制），例如，一個service可能會處理網路操作，播放音樂，操作檔案I/O或者與內容提供者（content provider）互動，所有這些活動都是在後臺進行。從表面上看service並不具備危害性，但實際上service可以在後臺執行一些敏感的操作。Service存在的安全漏洞包括：許可權提升，拒絕服務攻擊。沒有宣告任何許可權的應用即可在沒有任何提示的情況下啟動該服務，完成該服務所作操作，對系統安全性產生極大影響。

BroadcastReceiver匯出漏洞

當應用廣播接收器預設設定exported='true'，導致應用可能接收到第三方惡意應用偽造的廣播，利用這一漏洞，攻擊者可以在使用者手機通知欄上推送任意訊息，通過配合其它漏洞盜取本地隱私檔案和執行任意程式碼。Android 可以在配置檔案中宣告一receiver或者動態註冊一個receiver來接收廣播資訊，攻擊者假冒APP構造廣播發送給被攻擊的receiver，是被攻擊的APP執行某些敏感行為或者返回敏感資訊等，如果receiver接收到有害的資料或者命令時可能洩露資料或者做一些不當的操作，會造成使用者的資訊洩漏甚至是財產損失。

Content Provider元件漏洞

Content Provider為儲存和獲取資料提供統一的介面。可以在不同的應用程式之間共享資料。（1）讀寫許可權漏洞Content Provider中通常都含有大量有價值的資訊，比如用的電話號碼或者社交帳號登入口令，而確認一個content provider是否有能被攻擊的漏洞的最好的辦法，就是嘗試攻擊它一下。可以用drozer來尋找一些不需要許可權的contentprovider:dz> runapp.provider.info –permission null這條命令能列出所有不需要任何讀寫許可權的Content Provider，然後找到相對應的包，去訪問給定包存放在它的Content Provider中的資料。如果一些Content Provider的URI不需要讀許可權，那就可以通過drozer工具提取其中的資料。在某些情況下，設定和執行讀寫許可權不當，也會將ContentProvider中的資料暴露給攻擊者。除了提取資料，對於寫許可權管理不當的Content Provider還可以向其中寫入資料，使得攻擊者可以將惡意資料插入到資料庫中。（2）Content Provider中的SQL%E6%B3%A8%E5%85%A5/">SQL注入漏洞和Web漏洞類似，安卓APP也要使用資料庫，那就也有可能存在SQL注入漏洞。主要有兩類，第一類是SQL語句中的查詢條件子語句是可注入的，第二類是投影操作子句是可注入的。使用drozer可以很容易的找出查詢條件子句可注入的content provider。dz> runapp.provider.query [URI] –selection “1=1”也可以使用其他恆為真的值，例如“1-1=0”，“0=0”等等。如果APP存在SQL注入漏洞，那麼輸入這行指令後就會返回資料庫中的整張表。（3）Provider檔案目錄遍歷漏洞當Provider被匯出且覆寫了openFile方法時，沒有對Content Query Uri進行有效判斷或過濾。攻擊者可以利用openFile()介面進行檔案目錄遍歷以達到訪問任意可讀檔案的目的。

元件測試工具-drozer

Drozer是MWRLabs開發的一款Android安全測試框架。是目前最好的Android安全測試工具之一

環境準備：

1 手機獲得root許可權

2 adb.exe、配置android環境變數

3 手機usb連線開啟debug模式(在設定>關於手機>連續點選多次版本號,即可開啟開發者模式)

4 Window下安裝drozer

5安裝完drozer後在其目錄下把agent.apk安裝到手機

連線準備：

1 drozer console devices

啟動drozer：

adb forward tcp:31415 tcp:31415   //將pc端31415的所有資料轉發到手機上的31415埠

drozer console connect   //使用drozer console 連線agent

獲取手機上所有安裝的app包名：run app.package.list  加上”-f [app關鍵字]”查詢某個app，如 run app.package.list -f sieve

獲取sieve的基本資訊run app.package.info –a com.mwr.example.sieve

可以看到sieve的版本資訊，資料儲存目錄，使用者ID，組ID，共享庫，許可權等資訊

run app.package.attacksurface  com.mwr.example.sieve

run app.activity.info -a com.mwr.example.sieve

runapp.activity.start--componentcom.mwr.example.sievecom.mwr.example.sieve.PWList

run app.provider.info -a com.mwr.example.sieve

結合上面檢視攻擊面的資訊，這2個content provider都可匯出，com.mwr.example.sieve.DBContentProvider/Keys 是需要讀寫許可權的

往下關於drozer工具的使用百度都有詳細的介紹，這裡不再做繼續介紹。

客戶端測試 - 元件匯出安全配置

元件完全滿足以下條件之一，則可以匯出

顯式聲明瞭android:exported="true"

未顯式宣告android:exported="false"；

元件不是Content Provider；

元件包含<intent-filter>；

未顯式宣告android:exported="false"；

元件是Content Provider；

宣告API最小版本<17；

AndroidManifest.xml

AndroidManifest.xml是Android應用的入口檔案，它描述了package中暴露的元件（activities, services, 等等），他們各自的實現類，各種能被處理的資料和啟動位置。 除了能宣告程式中的Activities, ContentProviders, Services, 和In

android:allowClearUserData(‘true’ or ‘false’)

使用者是否能選擇自行清除資料，預設為true，程式管理器包含一個選擇允許使用者清除資料。當為true時，使用者可自己清理使用者資料，反之亦然

Device XXX requires that applications explicitely declare themselves as debuggable in their manifest.
Application XXX does not have the attribute ‘debuggable’ set to TRUE in its manifest and cannot be debugged.

android:exported 是Android中的四大元件 Activity，Service，Provider，Receiver 四大元件中都會有的一個屬性。

總體來說它的主要作用是：是否支援其它應用呼叫當前元件。
預設值：如果包含有intent-filter 預設值為true; 沒有intent-filter預設值為false。

客戶端測試 - 本地敏感資訊保安

檢視應用程式所在目錄（需root許可權）

一般為：/data/data/{APP包(package)名}/

如遇.db檔案，多為SQLite資料庫。

正常的檔案許可權最後三位應為空（類似“rw-rw----”），目錄可以多一個執行位（類似“rwxrwx—x”）

Line"/>

Android系統的五種資料儲存形式:

分別是檔案儲存、SP儲存、資料庫儲存、contentprovider 內容提供者、網路儲存

檔案儲存:

以I/O流的形式把資料存入手機記憶體或SD卡，可以儲存大資料，如音樂、圖片或視訊等。對於手機記憶體來說系統會根據每個應用的包名建立一個/data/data/包名/的資料夾，訪問自己包名下的目錄是不需要許可權的，並且 Android 已經提供了非常簡便的 API 可以直接去訪問該資料夾。訪問時可以用getFilesDir()和getCacheDir(),兩個的區別是系統會自動清理後者中的內容。

SD卡中的檔案通常位於mnt/sdcard目錄下，不同生產商生產的手機這個路徑可能不同。操作sd卡的時通常要判斷下sd卡是否可用以及剩餘空間是否足夠，因為部分手機的SD卡可解除安裝，SD卡處於非掛載狀態時，無法進行讀寫操作。另外一點，對SD卡的讀取和寫入操作均需要相應的許可權，否則無法完成。獲取SD卡路徑的方法是Environment.getExternalStorageDirectory()，其餘操作與檔案儲存基本類似。

shared preferences：SP儲存

可以看到goatdroid應用的使用者名稱和密碼都以明文的形式儲存在 shared preferences中SP儲存本質上是一個XML檔案，以鍵值對的形式存入手機記憶體中。常用於儲存簡單的引數設定，如登陸賬號密碼的儲存，視窗功能狀態的儲存等，該儲存檔案位於：data/data/包名/shared_prefs資料夾中。使用的時候，首先需要通過context.getSharedPrefrences(String name,int mode)獲取SharedPrefrences的例項物件，儲存資料時，用SharedPrefrences的例項物件得到SharedPrefrences檔案的編輯器，在編輯器中用putXxx()新增資料，之後務必用commit提交資料，否則無法獲取資料。取資料時，直接用getXxx()方法。

sp儲存自動生成xml檔案，其的路徑如下：

資料庫儲存：

資料庫所有信息都儲存在單一檔案內，佔用記憶體小，並且支援基本SQL語法，是專案中經常被採用的一種資料儲存方式，通常用於儲存使用者資訊等,例如在手機上做一個學生資訊管理系統。SQLite 是一款內建到移動裝置上的輕量型的資料庫，SQLiteOpenHelper 是Android 提供的一個抽象工具類，負責管理資料庫的建立、升級工作。資料庫的路徑為：/data/data/應用包名/databases/資料庫。

從手機檔案中匯出資料庫檔案並不可以直接開啟，因此可以用視覺化工具和sqlite3操作工具進行檢視。這裡介紹sqlite3工具的使用。具體需要的步驟如下：

1. 執行adb shell命令進入Linuxne核心；

2. 使用cd進入資料庫所在的路徑 cd: /data/data/應用包名/databases;

3. 進入資料庫模式: sqlite3 資料庫名.db;

4. 執行SQL語句

Content Provider：

Content Provider，中文名是記憶體提供者，Android四大元件之一，內容提供者是應用程式之間共享資料的介面，以資料庫形式存入手機記憶體，可以共享自己的資料給其他應用使用。之所以需要設計一個單獨的控制元件來操作資料，是為了實現應用程式之間的資料傳遞。通過檢視DDMS中的目錄結構可以看出，資料庫檔案對於其他應用來說是不可讀、不可寫，而日常生活中又需要獲取其他應用的資料，尤其是系統自帶軟體的資料。比如開啟QQ或者微信時會提示是否同步聯絡人，又比如備份簡訊的時候，這些都需要訪問和操作其他應用的資料庫。因此谷歌工程師在底層軟體中集成了大量的方法利用記憶體提供者的原理，類似於在資料庫中提供一個對外訪問的路徑，供其他應用訪問。

具體操作是：建立內容提供者解析器，定義要訪問的Uri的路徑。Uri路徑有著固定的格式：”content://主機名/匹配字元”。 利用內容提供者解析器進行增刪改查，和要操作的資料庫之間建立聯絡。以上內容通常用來理解內容提供者的工作原理，實際工作中很少用到自定義的內容提示者。實際中用的比較多的是用內容提供者作業系統聯絡人、系統簡訊等系統應用的資料庫。

先看一下簡訊和手機聯絡人有關的資料庫所在的路徑。簡訊在Android 模擬器下存放在的路徑是：/data/data/com.android.providers.telephony/databases/目錄，聯絡人在Android 模擬器下存放在的路徑是：/data/data/com.android.providers.contacts/databases/目錄。對於簡訊資料庫我們關心的表資料有：address、type、body、date，分別表示傳送者號碼、簡訊型別（收還是發）、簡訊內容、日期。對於聯絡人資料庫的三張表一定要按照一定的順序依次查詢才能得到相關的資料，在這不做解釋。儘管開發的時候不需要了解簡訊和手機聯絡人的資料庫路徑，但是要明白簡訊和手機聯絡人的資料是存在資料庫中的，同時資料庫對外是不開放的。

與簡訊有關的資料庫的目錄結構：

網路儲存：

網路儲存是最容易理解的一種儲存方式了。其實說簡單點就是檔案的上傳和下載。經常聽到的雲備份就是這種形式。優勢也很明顯，即把資料儲存到伺服器，不儲存在本地，使用的時候直接從網路獲取，避免了手機端資訊丟失以及其他的安全隱患。因此，對於這種形式就不作多的解釋

客戶端測試 - 本地敏感資訊保安

用logcat命令檢視APP的日誌

清空日誌  ：logcat -c

實時檢視日誌 ：logcat

一次性輸出 ：logcat -d

釋出APP前，去掉Log輸出程式碼

用DDMS命令檢視APP的日誌

客戶端測試 – 簽名檔案的分析檢測

對apk進行簽名需要用到簽名證書和簽名工具。Android系統要求對APP進行簽名的數字證書可以由開發者自己生成。簽名工具有jarsigner和signapk。jarsigner是Java本身自帶的一個工具，他也可以對jar進行簽名的；而signapk是專門為了Android應用程式apk進行簽名的工具。二者的區別是：jarsigner工具簽名時使用的是keystore簽名檔案，signapk工具簽名時使用的是pk8，x509.pem檔案。

簽名檔案分析

應用簽名完後在應用的META-INF目錄下會有三個檔案：

CERT.RSA、CERT.SF和MANIFEST.MF。

MANIFEST.MF：這是摘要檔案。程式遍歷Apk包中的所有檔案(entry)，對非資料夾非簽名檔案的檔案，逐個用SHA1生成摘要資訊，再用Base64進行編碼。如果你改變了apk包中的檔案，那麼在apk安裝校驗時，改變後的檔案摘要資訊與MANIFEST.MF的檢驗資訊不同，於是程式就不能成功安裝。

說明： 這是Android簽名驗證過程的第一步，保證每個APK包內的每個檔案與MANIFEST.MF中的摘要值一一對應，修改某個檔案內容，必須修改MANFEST.MF檔案中的摘要值，使他們對應起來。

CERT.SF：這是對摘要的簽名檔案。對前一步生成的MANIFEST.MF，對MANIFEST.MF中的每一條內容分別進行SHA1計算，然後再用Base64編碼轉換。此外，把MANIFEST.MF的內容也進行SHA1計算，並且計算BASE64編碼。將上述內容寫入CERT.SF檔案中。

（這是為了防止通過篡改檔案和其在MANIFEST.MF中對應的SHA1摘要值來篡改APK，要對MANIFEST的內容再進行一次數字摘要）。

CERT.RSA檔案中儲存了公鑰、所採用的加密演算法等資訊，此外重要的，還包括對CERT.SF中的內容的用私鑰進行加密之後的值。

說明：在這一步，即使開發者修改了程式內容，並生成了新的摘要檔案，MANIFEST.MF能與內容對應起來，CERT.SF也能與內容對應起來，但是攻擊者沒有開發者的私鑰，所以不能生成正確的簽名檔案（CERT.RSA）。系統在對程式進行驗證的時候，用開發者公鑰對不正確的簽名檔案進行解密，得到的結果對應不起來，所以不能通過檢驗，不能成功安裝檔案。

簽名工具使用：

jarsigner是JDK提供的針對jar包簽名的通用工具, jarsigner只支援V1簽名

位於JDK/bin/jarsigner.exe

apksigner是Google官方提供的針對Android apk簽名及驗證的專用工具, 默認同時使用V1和V2簽名

位於Android SDK/build-tools/SDK版本/apksigner.bat

不管是apk包,還是jar包,本質都是zip格式的壓縮包,所以它們的簽名過程都差不多(僅限V1簽名),

以上兩個工具都可以對Android apk包進行簽名.

V1和V2簽名的區別

在Android Studio中點選選單 Build->Generate signed apk... 打包簽名過程中,

可以看到兩種簽名選項 V1(Jar Signature)  V2(Full APK Signature),

從Android 7.0開始, 谷歌增加新簽名方案 V2 Scheme (APK Signature);

但Android 7.0以下版本, 只能用舊簽名方案 V1 scheme (JAR signing)

V1簽名:

來自JDK(jarsigner), 對zip壓縮包的每個檔案進行驗證, 簽名後還能對壓縮包修改(移動/重新壓縮檔案)

對V1簽名的apk/jar解壓,在META-INF存放簽名檔案(MANIFEST.MF, CERT.SF, CERT.RSA),

其中MANIFEST.MF檔案儲存所有檔案的SHA1指紋(除了META-INF檔案), 由此可知: V1簽名是對壓縮包中單個檔案簽名驗證

V2簽名:

來自Google(apksigner), 對zip壓縮包的整個檔案驗證, 簽名後不能修改壓縮包(包括zipalign),

對V2簽名的apk解壓,沒有發現簽名檔案,重新壓縮後V2簽名就失效, 由此可知: V2簽名是對整個APK簽名驗證

V2簽名優點很明顯:

簽名更安全(不能修改壓縮包)

簽名驗證時間更短(不需要解壓驗證),因而安裝速度加快

注意: apksigner工具默認同時使用V1和V2簽名,以相容Android 7.0以下版本

檢視V1和V2簽名方式

java -jar CheckAndroidSignature.jar xxxx.apk

{"ret":0,"msg":"","isV1OK":true,"isV2":true,"isV2OK":true,"keystoreMd5":"8f701cdd1c0d8856e440363185c7daf7"}

簽名步驟

1.生成金鑰對(已有金鑰庫,可忽略)

Eclipse或Android Studio在Debug時,對App簽名都會使用一個預設的金鑰庫:

預設在C:\Users\使用者名稱\.android\debug.keystore（非安全簽名）

金鑰庫名:   debug.keystore

金鑰別名:   androiddebugkey

金鑰庫密碼: android

1.生成金鑰對

 keytool -genkeypair -keystore debug.keystore -alias release -validity 30000

為什麼報錯了：

這是因為許可權問題：你的jdk目錄在c盤，當前使用者無寫入許可權。

所以要麼更改jdk的儲存目錄，要麼更改許可權

方法一更改儲存目錄：就是講jdk從c盤挪到其它盤。

方法二更改許可權：以管理員身份執行CMD。

我已管理員許可權執行CDM

keytool -list -v -keystore debug.keystore

現在debug.keystore金鑰庫中有兩對金鑰, 別名分別是androiddebugkey release

jarsigner -keystore debug.keystore MyApp.apk androiddebugkey

jarsigner -keystore debug.keystore -digestalg SHA1 -sigalg SHA1withRSA MyApp.apk androiddebugkey

 apksigner sign --ks debug.keystore MyApp.apk

apksigner sign --ks debug.keystore --ks-key-alias androiddebugkey MyApp.ap

4.簽名驗證

1.方法一(keytool,只支援V1簽名校驗)

進入JDK/bin, 輸入命令

keytool -printcert -jarfile MyApp.apk (顯示簽名證書資訊)

引數:

-printcert           列印證書內容

-jarfile <filename>  已簽名的jar檔案 或apk檔案

apksigner verify -v MyApp.apk
Verifies
Verified using v1 scheme (JAR signing): true
Verified using v2 scheme (APK Signature Scheme v2): true
Number of signers: 1

keytool -printcert -file path

APK解壓後的檔案，將簽名檔案中CERT.RSA拿出來用apktool 單獨檢視

客戶端測試 - 鍵盤記錄保護

常見的Android鍵盤記錄主要依靠讀取/dev/input/event0裝置

需要root。

需要編寫專門的Native測試工具

鍵盤、觸屏之類均能捕獲到。

也有通過註冊輸入法來竊聽鍵盤的方法。

客戶端測試 - 螢幕錄影測試

即連續截圖，通過視覺反饋效果來竊聽密碼等敏感資訊：

adb shell /system/bin/screencap -p 安卓裝置中的輸出png路徑

需要root。

screencap輸出到安卓裝置中，不是輸出到電腦中。

注意： FLAG_SECURE會妨礙screencap，

但對於root許可權下直接讀取螢幕快取的方法是不起作用的，測試中不被認定為有效修復。

敏感資訊輸入不提供視覺反饋

客戶端測試 - 程序注入保護

設法在目標APP的程序空間中執行一段程式碼。

一般的方法是在Native層通過pTrace，讓遠端程序載入一個.so連結庫，從而侵入目標程序空間。

需要root；

需要編寫專門的Native測試工具；

GDB也使用了類似的方法來操作遠端程序。

反除錯技術實現複雜，一般通過加殼解決

客戶端測試 - Activity/介面劫持保護

在目標APP啟動時，立即彈出一個假介面覆蓋之。

一般是通過Broadcast Receiver來監聽目標APP的android.intent.action.BOOT_COMPLETED事件。

在JAVA層完成，不需要root

誘騙使用者在假介面上操作，以獲取其敏感資訊，很難察覺Android 5.0以後從系統機制層面解決了這個問題，因此如果APK宣告的最小API版本≥21，

此項無需測試，直接記為安全。

ApkTool解包後會產生apktool.yml，內含關於API版本的宣告資訊。

客戶端測試 – 除錯資訊檢測

檢測程式（含伺服器端和客戶端）除錯資訊是否關閉，除錯資訊中是否寫入敏感資訊

通過執行程式，檢視logcat等除錯日誌資訊，是否有洩漏重要的URL地址、提示資訊、除錯資訊等敏感關鍵字以及程式邏輯的關鍵流程。對於HTML頁面，需要在瀏覽器端開啟，並檢查其中的JS程式碼等是否存留其他除錯資訊

這裡我們用的方式是DDMS：

DDMS 的全稱是Dalvik Debug Monitor Service，是 Android 開發環境中的Dalvik虛擬機器除錯監控服務。

這個工具存放在SDK-tools路徑下,啟動方法: [1]

1) 直接雙擊ddms.bat執行;

2) 在Eclipse除錯程式的過程中啟動DDMS

雙擊ddms開啟

我們看到有很多日誌輸出，可以觀察執行日誌中是否帶有敏感資料

然後我們找到我們要分析的那個應用包

看他的程序ID是2484

然後下面的輸出程序都是2484的

實時日誌中若輸出除錯資訊，攻擊者可根據輸出資訊分析應用程式的執行邏輯，對應用程式進行惡意破壞；也可能洩露使用者敏感資訊。

客戶端測試 –Sqlite .db檔案的匯出

我們的app裡面用到sqlite資料庫的時候， 會生成一個db檔案，儲存在我們手機中。有的時候，在除錯資料庫，很想看一下里面的表結構是否正確，這個時候就十分苦惱，因為這個db檔案不能夠直接拿出來，我們知道，在DDMS裡面有一個FileExplorer，它裡面儲存著手機中的各個資料夾，但是嘗試開啟裡面的資料夾的時候，卻發現怎麼點都沒有東西，是真的沒有嗎？其實是我們沒有獲取到訪問這個資料夾的許可權。下面我們就開始一步一步的拿到真機除錯中的db檔案。

DDMS可以直接看手機裡檔案，如圖：

Data/data/應用包名databases/

我們可以看到.db檔案就是他的sqllite檔案。可以直接匯出

如果開啟檔案許可權不夠的話，這裡利用就可以利用adb直接給開啟的路徑授權：

比如：

進去adb 然後chmod 777 /data/data/com.demo.app/databases/

在匯出.db檔案後，可以本地開啟.db檔案，分析是否存在敏感資訊

推薦工具：

客戶端測試 – Sqlite加密檢測

Android 系統的Sqlite資料庫是一個輕量級且沒有加密功能的資料庫，但有時候我們的資料庫儲存了一些重要的資訊，不想讓別人知道，就需要對資料庫加密。但大多數的加密都需要收費的，而Sqlcipher是免費的。下面我們用sqlcipher來加密資料庫。

配置工程：

注意assets下的檔案

我們可用工具，對APP解包後，分析.so檔案，

用APK改之理解包了一個APK：

分析出Sqlite資料庫已做加密，做加密後的檔案.db匯出後是無法開啟的：