Name Date Size #Lines LOC

..--

class-verifier-corpus/H25-Apr-2025-

dex-verifier-corpus/H25-Apr-2025-

Android.bpH A D25-Apr-202563.5 KiB1,3561,338

README.mdH A D25-Apr-20253 KiB11076

create_corpus.pyH A D25-Apr-20251.1 KiB3515

dex.dictH A D25-Apr-2025329 1210

libart_verify_classes_fuzzer.ccH A D25-Apr-20259 KiB233155

libart_verify_dex_fuzzer.ccH A D25-Apr-20251.6 KiB4318

README.md

1# Building the ART Fuzzer
2
3There are two ways to run one of the existing fuzzers: on host or on device.
4The building and running takes place in the full Android platform
5tree (aosp-main-with-phones). For host there's the possibility of using a
6smaller AOSP Android manifest (master-art). The latter is faster to build,
7because it only has the sources and dependencies required for the module.
8
9In the following tutorial we use the class verification fuzzer. We set a shell
10variable with the fuzzer's name for convenience. Their names can be found in
11the Android.bp file, under the cc_fuzz build rules.
12
13```
14FUZZER_NAME=libart_verify_classes_fuzzer
15```
16
17## Common steps for host and device
18
191. Navigate to the root directory of the android repository.
20
212. From the console, set up the development environment.
22
23    ```
24    source build/envsetup.sh
25    ```
26
273. Build the fuzzer for host/device
28
29    The command is composed of:
30
31    ```
32    lunch <product>-trunk_staging-<variant>
33    SANITIZE_HOST=address make ${FUZZER_NAME}
34    ```
35
36    For host you can use any valid lunch target, for example:
37
38    ```
39    lunch silvermont-trunk_staging-eng
40    ```
41
42    For device, you have to select your target according to the device
43    you are using it to run the fuzzer.
44
45    ```
46    lunch aosp_husky-trunk_staging-userdebug
47    ```
48
49## Host
50
514. Run the fuzzer
52
53    In this example we assume an x86_64 host architecture:
54
55    ```
56    out/host/linux-x86/fuzz/x86_64/${FUZZER_NAME}/${FUZZER_NAME} \
57    out/host/linux-x86/fuzz/x86_64/${FUZZER_NAME}/corpus
58    ```
59
60    The first part of the command is the path to the fuzzer's binary, followed by the
61    corpus. See [llvm.org/docs/LibFuzzer](https://llvm.org/docs/LibFuzzer.html#options)
62    for more valid flags. For example, you can add the flag `-print_pcs=1` which makes
63    it more verbose.
64
65## Device
66
674. Add the fuzzer's files on the device
68
69    ```
70    adb root
71    adb sync data
72    ```
73
745. Run the fuzzer
75
76    Any supported architecture can be used. For example, for arm64:
77
78    ```
79    adb shell /data/fuzz/arm64/${FUZZER_NAME}/${FUZZER_NAME} \
80    /data/fuzz/arm64/${FUZZER_NAME}/corpus
81    ```
82
83    The first part of the command is the path to the fuzzer's binary and the next
84    one is the corpus.
85
86## Corpus
87
88The fuzzer uses a corpus as a starting point in order to generate new inputs
89representing DEX files. Our current corpus contains a mix of hand-created DEX
90files, regression tests, and DEX files from our test suite. Also, when the fuzzer
91generates a new input and it proves that it offers more code coverage,
92it is added to the existing corpus as a DEX file.
93
94If you want to run with the initial corpus, it needs to be removed and built again.
95
96For host, assuming an x86_64 host architecture:
97
98```
99rm -rf out/host/linux-x86/fuzz/x86_64/${FUZZER_NAME}/corpus
100SANITIZE_HOST=address make ${FUZZER_NAME}
101```
102
103For device, you also need to sync the data. For example, for arm64:
104
105```
106adb shell rm -rf /data/fuzz/arm64/${FUZZER_NAME}/corpus
107SANITIZE_HOST=address make ${FUZZER_NAME}
108adb sync data
109```
110