模糊測試只是提供潛在無效、意外或隨機資料作為程式的輸入，是在大型軟體系統中尋找錯誤的極其有效的方法，並且是軟體開發生命週期的重要組成部分。
Android 的建置系統透過包含來自 LLVM 編譯器基礎架構專案的libFuzzer來支援模糊測試。 LibFuzzer 與被測庫鏈接，並處理模糊測試會話期間發生的所有輸入選擇、突變和崩潰報告。 LLVM 的清理程序用於幫助記憶體損壞檢測和程式碼覆蓋率指標。
本文介紹了 Android 上的 libFuzzer 以及如何執行偵測建置。它還包括編寫、運行和自訂模糊器的說明。
設定和建構
為了確保裝置上運行有可用的映像，您可以下載出廠映像並刷新裝置。或者，您可以下載 AOSP 原始程式碼並按照下面的設定和建置範例進行操作。
設定範例
此範例假設目標裝置是 Pixel ( taimen )，並且已準備好進行 USB 偵錯 ( aosp_taimen-userdebug )。您可以從Driver Binaries下載其他 Pixel 二進位。
mkdir ~/binexport PATH=~/bin:$PATHcurl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repochmod a+x ~/bin/reporepo init -u https://android.googlesource.com/platform/manifest -b mainrepo sync -c -j8wget https://dl.google.com/dl/android/aosp/google_devices-taimen-qq1a.191205.008-f4537f93.tgztar xvf google_devices-taimen-qq1a.191205.008-f4537f93.tgz./extract-google_devices-taimen.shwget https://dl.google.com/dl/android/aosp/qcom-taimen-qq1a.191205.008-760afa6e.tgztar xvf qcom-taimen-qq1a.191205.008-760afa6e.tgz./extract-qcom-taimen.sh. build/envsetup.shlunch aosp_taimen-userdebug
建構範例
運行模糊目標的第一步是取得新的系統映像。我們建議至少使用最新的 Android 開發版本。
- 透過發出以下命令來執行初始建置：
m
- 若要允許您刷新設備，請使用適當的組合鍵將設備啟動到快速啟動模式。
- 使用以下命令解鎖引導程式並刷新新編譯的映像。
fastboot oem unlockfastboot flashall
目標裝置現在應該已準備好進行 libFuzzer 模糊測試。
寫一個模糊器
為了說明如何在 Android 中使用 libFuzzer 編寫端對端模糊器，請使用以下易受攻擊的程式碼作為測試案例。這有助於測試模糊器，確保一切正常運作，並說明崩潰資料的樣子。
這是測試功能。
#include <stdint.h>
#include <stddef.h>
bool FuzzMe(const char *data, size_t dataSize) {
return dataSize >= 3 &&
data[0] == 'F' &&
data[1] == 'U' &&
data[2] == 'Z' &&
data[3] == 'Z'; // ← Out of bounds access
}
要建置並執行此測試模糊器：
- 模糊目標由兩個檔案組成：建構檔案和模糊目標原始碼。在您要模糊測試的庫旁邊的位置建立文件。為模糊器指定一個描述模糊器功能的名稱。
- 使用 libFuzzer 編寫模糊目標。模糊目標是一個函數，它會取得指定大小的資料塊並將其傳遞給要進行模糊測試的函數。這是易受攻擊的測試函數的基本模糊器：
#include <stddef.h> #include <stdint.h> extern "C" int LLVMFuzzerTestOneInput(const char *data, size_t size) { // ... // Use the data to call the library you are fuzzing. // ... return FuzzMe(data, size); } - 告訴 Android 的建置系統建立模糊器二進位。若要建立模糊器，請將此程式碼新增至
Android.bp檔案：cc_fuzz { name: "fuzz_me_fuzzer", srcs: [ "fuzz_me_fuzzer.cpp", ], // If the fuzzer has a dependent library, uncomment the following section and // include it. // static_libs: [ // "libfoo", // Dependent library // ], // // The advanced features below allow you to package your corpus and // dictionary files during building. You can find more information about // these features at: // - Corpus: https://llvm.org/docs/LibFuzzer.html#corpus // - Dictionaries: https://llvm.org/docs/LibFuzzer.html#dictionaries // These features are not required for fuzzing, but are highly recommended // to gain extra coverage. // To include a corpus folder, uncomment the following line. // corpus: ["corpus/*"], // To include a dictionary, uncomment the following line. // dictionary: "fuzz_me_fuzzer.dict", } - 使模糊器在目標（裝置）上運作：
SANITIZE_TARGET=hwaddress m fuzz_me_fuzzer
- 使模糊器在主機上運作：
SANITIZE_HOST=address m fuzz_me_fuzzer
為了方便起見，定義一些 shell 變量，其中包含模糊目標的路徑和二進位檔案的名稱（來自您之前編寫的建置檔案）。
export FUZZER_NAME=your_fuzz_target
遵循這些步驟後，您應該已經建立了一個模糊器。模糊器的預設位置（對於本範例 Pixel 建置）是：
在主機上執行模糊器
host_supported: true,請注意，僅當您希望模糊測試的程式庫受主機支援時才可套用此操作。
$ANDROID_HOST_OUT/fuzz/x86_64/$FUZZER_NAME/$FUZZER_NAME
在設備上運行模糊器
我們想使用adb將其複製到您的裝置。
- 若要將這些檔案上傳到裝置上的目錄，請執行下列命令：
adb rootadb sync data - 使用下列命令在裝置上執行測試模糊器：
adb shell /data/fuzz/$(get_build_var TARGET_ARCH)/$FUZZER_NAME/$FUZZER_NAME \ /data/fuzz/$(get_build_var TARGET_ARCH)/$FUZZER_NAME/corpus
這會產生與下面的範例輸出類似的輸出。
INFO: Seed: 913963180
INFO: Loaded 2 modules (16039 inline 8-bit counters): 16033 [0x7041769b88, 0x704176da29), 6 [0x60e00f4df0, 0x60e00f4df6),
INFO: Loaded 2 PC tables (16039 PCs): 16033 [0x704176da30,0x70417ac440), 6 [0x60e00f4df8,0x60e00f4e58),
INFO: -max_len is not provided; libFuzzer will not generate inputs larger than 4096 bytes
INFO: A corpus is not provided, starting from an empty corpus
#2 INITED cov: 5 ft: 5 corp: 1/1b exec/s: 0 rss: 24Mb
#10 NEW cov: 6 ft: 6 corp: 2/4b lim: 4 exec/s: 0 rss: 24Mb L: 3/3 MS: 3 CopyPart-ChangeByte-InsertByte-
#712 NEW cov: 7 ft: 7 corp: 3/9b lim: 8 exec/s: 0 rss: 24Mb L: 5/5 MS: 2 InsertByte-InsertByte-
#744 REDUCE cov: 7 ft: 7 corp: 3/7b lim: 8 exec/s: 0 rss: 25Mb L: 3/3 MS: 2 ShuffleBytes-EraseBytes-
#990 REDUCE cov: 8 ft: 8 corp: 4/10b lim: 8 exec/s: 0 rss: 25Mb L: 3/3 MS: 1 ChangeByte-
==18631==ERROR: HWAddressSanitizer: tag-mismatch on address 0x0041e00b4183 at pc 0x0060e00c5144
READ of size 1 at 0x0041e00b4183 tags: f8/03 (ptr/mem) in thread T0
#0 0x60e00c5140 (/data/fuzz/arm64/example_fuzzer/example_fuzzer+0xf140)
#1 0x60e00ca130 (/data/fuzz/arm64/example_fuzzer/example_fuzzer+0x14130)
#2 0x60e00c9b8c (/data/fuzz/arm64/example_fuzzer/example_fuzzer+0x13b8c)
#3 0x60e00cb188 (/data/fuzz/arm64/example_fuzzer/example_fuzzer+0x15188)
#4 0x60e00cbdec (/data/fuzz/arm64/example_fuzzer/example_fuzzer+0x15dec)
#5 0x60e00d8fbc (/data/fuzz/arm64/example_fuzzer/example_fuzzer+0x22fbc)
#6 0x60e00f0a98 (/data/fuzz/arm64/example_fuzzer/example_fuzzer+0x3aa98)
#7 0x7041b75d34 (/data/fuzz/arm64/lib/libc.so+0xa9d34)
[0x0041e00b4180,0x0041e00b41a0) is a small allocated heap chunk; size: 32 offset: 3
0x0041e00b4183 is located 0 bytes to the right of 3-byte region [0x0041e00b4180,0x0041e00b4183)
allocated here:
#0 0x70418392bc (/data/fuzz/arm64/lib/libclang_rt.hwasan-aarch64-android.so+0x212bc)
#1 0x60e00ca040 (/data/fuzz/arm64/example_fuzzer/example_fuzzer+0x14040)
#2 0x60e00c9b8c (/data/fuzz/arm64/example_fuzzer/example_fuzzer+0x13b8c)
#3 0x60e00cb188 (/data/fuzz/arm64/example_fuzzer/example_fuzzer+0x15188)
#4 0x60e00cbdec (/data/fuzz/arm64/example_fuzzer/example_fuzzer+0x15dec)
#5 0x60e00d8fbc (/data/fuzz/arm64/example_fuzzer/example_fuzzer+0x22fbc)
#6 0x60e00f0a98 (/data/fuzz/arm64/example_fuzzer/example_fuzzer+0x3aa98)
#7 0x7041b75d34 (/data/fuzz/arm64/lib/libc.so+0xa9d34)
#8 0x60e00c504c (/data/fuzz/arm64/example_fuzzer/example_fuzzer+0xf04c)
#9 0x70431aa9c4 (/data/fuzz/arm64/example_fuzzer/example_fuzzer+0x519c4)
Thread: T1 0x006700006000 stack: [0x007040c55000,0x007040d4ecc0) sz: 1023168 tls: [0x000000000000,0x000000000000)
Thread: T0 0x006700002000 stack: [0x007fe51f3000,0x007fe59f3000) sz: 8388608 tls: [0x000000000000,0x000000000000)
Memory tags around the buggy address (one tag corresponds to 16 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
08 00 cf 08 dc 08 cd 08 b9 08 1a 1a 0b 00 04 3f
=> 27 00 08 00 bd bd 2d 07 [03] 73 66 66 27 27 20 f6 <=
5b 5b 87 87 03 00 01 00 4f 04 24 24 03 39 2c 2c
05 00 04 00 be be 85 85 04 00 4a 4a 05 05 5f 5f
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Tags for short granules around the buggy address (one tag corresponds to 16 bytes):
04 .. .. cf .. dc .. cd .. b9 .. .. 3f .. 57 ..
=> .. .. 21 .. .. .. .. 2d [f8] .. .. .. .. .. .. .. <=
.. .. .. .. 9c .. e2 .. .. 4f .. .. 99 .. .. ..
See https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html#short-granules for a description of short granule tags
Registers where the failure occurred (pc 0x0060e00c5144):
x0 f8000041e00b4183 x1 000000000000005a x2 0000000000000006 x3 000000704176d9c0
x4 00000060e00f4df6 x5 0000000000000004 x6 0000000000000046 x7 000000000000005a
x8 00000060e00f4df0 x9 0000006800000000 x10 0000000000000001 x11 00000060e0126a00
x12 0000000000000001 x13 0000000000000231 x14 0000000000000000 x15 000e81434c909ede
x16 0000007041838b14 x17 0000000000000003 x18 0000007042b80000 x19 f8000041e00b4180
x20 0000006800000000 x21 000000000000005a x22 24000056e00b4000 x23 00000060e00f5200
x24 00000060e0128c88 x25 00000060e0128c20 x26 00000060e0128000 x27 00000060e0128000
x28 0000007fe59f16e0 x29 0000007fe59f1400 x30 00000060e00c5144
SUMMARY: HWAddressSanitizer: tag-mismatch (/data/fuzz/arm64/example_fuzzer/example_fuzzer+0xf140)
MS: 1 ChangeByte-; base unit: e09f9c158989c56012ccd88111b82f778a816eae
0x46,0x55,0x5a,
FUZ
artifact_prefix='./'; Test unit written to ./crash-0eb8e4ed029b774d80f2b66408203801cb982a60
Base64: RlVa
在範例輸出中，崩潰是由fuzz_me_fuzzer.cpp第 10 行引起的：
data[3] == 'Z'; // :(
如果data長度為 3，則這是一個簡單的越界讀取。
運行模糊器後，輸出通常會導致崩潰，並且有問題的輸入會保存在語料庫中並給出 ID。在範例輸出中，這是crash-0eb8e4ed029b774d80f2b66408203801cb982a60 。
要在裝置上進行模糊測試時檢索崩潰訊息，請發出此命令，並指定您的崩潰 ID：
adb pull /data/fuzz/arm64/fuzz_me_fuzzer/corpus/CRASH_ID請注意，若要將測試案例儲存到正確的目錄，您可以使用語料庫資料夾（如上例所示）或使用artifact_prefix參數（例如 `-artifact_prefix=/data/fuzz/where/my/crashes /走`）。
在主機上進行模糊測試時，崩潰資訊會出現在執行模糊器的本機資料夾中的崩潰資料夾中。
產生線路覆蓋範圍
行覆蓋對於開發人員來說非常有用，因為他們可以找出程式碼中未覆蓋的區域，並相應地更新模糊器，以便在未來的模糊測試運行中命中這些區域。
- 為了產生模糊器覆蓋率報告，請執行下列步驟：
CLANG_COVERAGE=true NATIVE_COVERAGE_PATHS='*' make ${FUZZER_NAME} - 將模糊器及其相依性推送到裝置後，使用
LLVM_PROFILE_FILE執行模糊目標，如下所示：DEVICE_TRACE_PATH=/data/fuzz/$(get_build_var TARGET_ARCH)/${FUZZER_NAME}/data.profrawadb shell LLVM_PROFILE_FILE=${DEVICE_TRACE_PATH} /data/fuzz/$(get_build_var TARGET_ARCH)/${FUZZER_NAME}/${FUZZER_NAME} -runs=1000 - 首先從裝置中拉出 profraw 文件，然後將 html 報告產生到名為coverage-html 的資料夾中，產生覆蓋率報告，如下所示：
adb pull ${DEVICE_TRACE_PATH} data.profrawllvm-profdata merge --sparse data.profraw --output data.profdatallvm-cov show --format=html --instr-profile=data.profdata \ symbols/data/fuzz/$(get_build_var TARGET_ARCH)/${FUZZER_NAME}/${FUZZER_NAME} \ --output-dir=coverage-html --path-equivalence=/proc/self/cwd/,$ANDROID_BUILD_TOP