# TransferFuzz **Repository Path**: init0000/TransferFuzz ## Basic Information - **Project Name**: TransferFuzz - **Description**: No description available - **Primary Language**: Unknown - **License**: Not specified - **Default Branch**: main - **Homepage**: None - **GVP Project**: No ## Statistics - **Stars**: 0 - **Forks**: 0 - **Created**: 2025-12-24 - **Last Updated**: 2025-12-24 ## Categories & Tags **Categories**: Uncategorized **Tags**: None ## README # TransferFuzz The code and dataset of the paper are at [https://github.com/Siyuan-Li201/TransferFuzz](https://github.com/Siyuan-Li201/TransferFuzz). We introduce TransferFuzz, a novel vulnerability verification framework, to verify whether vulnerabilities propagated through code reuse can be triggered in new software. - Input: A fuzz driver script of the target binary. A basic binary with PoC. - Output: The PoCs of the target binary. We have enhanced the code and documentation to automate all steps: - **Function-level Trace Extraction**. We wrote Python scripts to automate calls to GDB to extract function call stacks after crashes. - **Key-bytes Trace Extraction**. We use PIN for taint analysis and judge whether tainted bytes come directly from POC bytes. - **Trace Guided Fuzzing**: We wrap the modified code parts in macro definitions, enabling easy migration to new fuzzing technologies. - **Crash Classification**. We wrote a shell script to automatically determine whether the fuzzing process is finished by viewing the crash address through GDB.

## 1. Introduction - code: The sourcecode of TransferFuzzt - bin: The 76 binaries used in the paper (along with two .so file). Since Git LFS is not easily accessible, you can download all binaries from [bin](https://drive.google.com/file/d/1TU1o0J5mpTFPEo-683DP01fV2IcrM_Hm/view?usp=sharing) here. - poc: The 53 POCs of the 15 CVE vulnerabilities.

## 2. Reproduction of the veridied vulnerability code #### 2.1 Reproduction of the 53 vulnerabilities (38 new and 15 origin vulnerabilities) 1. Download the binaries and POCs from `/bin` and `/poc`. 2. Execute the binaries with poc by the harness below. (To meet environment dependencies, it is recommended to run in the provided Docker container.) #### 2.2 harness 1. tiffsplit-2016-10095: tiffsplit @@ 2. tiffsplit-2016-5318: tiffsplit @@ 3. thumbnail-2016-10095: thumbnail @@ 4. thumbnail-2016-5318: thumbnail @@ 5. tiffcmp-2016-10095:tiffcmp @@ @@ 6. tiffcmp-2016-5318: tiffcmp @@ @@ 7. cxxfilt-2016-4487: cxxfilt < @@ 8. cxxfilt-2016-4489: cxxfilt < @@ 9. cxxfilt-2016-4490: cxxfilt < @@ 10. cxxfilt-2016-4491: cxxfilt < @@ 11. cxxfilt-2016-4492: cxxfilt < @@ 12. cxxfilt-2016-6131: cxxfilt < @@ 13. objdump-2016-4487: objdump -t -C @@ 14. objdump-2016-4489: objdump -t -C @@ 15. objdump-2016-4490: objdump -t -C @@ 16. objdump-2016-4491: objdump -t -C @@ 17. objdump-2016-4492: objdump -t -C @@ 18. objdump-2016-6131: objdump -t -C @@ 19. nm-new-2016-4487: nm-new -C @@ 20. nm-new-2016-4489: nm-new -C @@ 21. nm-new-2016-4490: nm-new -C @@ 22. nm-new-2016-4491: nm-new -C @@ 23. nm-new-2016-4492: nm-new -C @@ 24. nm-new-2016-6131: nm-new -C @@ 25. addr2line-2016-4487: addr2line -e @@ -C -f 0x3dc8 26. addr2line-2016-4489: addr2line -e @@ -C -f 0x3dc8 27. addr2line-2016-4490: addr2line -e @@ -C -f 0x3dc8 28. addr2line-2016-4491: addr2line -e @@ -C -f 0x0000 29. addr2line-2016-4492: addr2line -e @@ -C -f 0x3dc8 30. addr2line-2016-6131: addr2line -e @@ -C -f 0x0000 31. strip-2017-7303: strip -o /dev/null @@ 32. objcopy-2017-7303: objcopy @@ 33. swftophp-2017-11733: swftophp @@ 34. swftophp-2018-8807: swftophp @@ 35. swftophp-2018-8962: swftophp @@ 36. swftoperl-2017-11733: swftoperl @@ 37. swftoperl-2018-8807: swftoperl @@ 38. swftoperl-2018-8962: swftoperl @@ 39. swftocxx-2017-11733: swftocxx @@ 40. swftocxx-2018-8807: swftocxx @@ 41. swftocxx-2018-8962: swftocxx @@ 42. swftopython-2017-11733: swftopython @@ 43. swftopython-2018-8807: swftopython @@ 44. swftopython-2018-8962: swftopython @@ 45. swftotcl-2017-11733: swftotcl @@ 46. swftotcl-2018-8807: swftotcl @@ 47. swftotcl-2018-8962: swftotcl @@ 48. libav-2018-11102: avconv -y -i @@ 49. ffmpeg-2018-11102: ffmpeg -y -i @@ 50. libjpeg-turbo-2018-20330: tjbench @@ 90 51. mozjpeg-2018-20330: tjbench @@ 90 52. poppler-2017-18267: poppler @@ 53. xpdf-2017-18267: xpdf @@

## 3. Reproduction of the Fuzzing process ### 3.1 Build #### 3.1.1 Build from docker TransferFuzz is built on SelectFuzz. Since SelectFuzz's Docker image is relatively large, TransferFuzz is also large. For a more flexible build, you can also compile it yourself. ```bash 1 sudo docker pull anonymous4paper/transferfuzz # You need to execute "echo core >/proc/sys/kernel/core_pattern" on the host to support AFL fuzzing. ``` #### 3.1.2 Build from source code (Not recommended) Place the `/code` directory in the root (`/`) of the SelectFuzz environment and rename it to `/transferfuzz`. You can ignore error messages when executing "make" commands in `/transferfuzz/llvm_mode`. ```bash 1 cd /transferfuzz 2 make clean all 3 cd llvm_mode 4 make clean all ```
### 3.2 Have a quick start You can quickly verify the data in the paper with the following command. #### 3.2.1 Start fuzzing ```bash 1 cd /transferfuzz/scripts/evaluation/ 2 ./tiffcmp-2016-10095.sh # When "Hamed: Finished PAG initialization..." is displayed, it may take some time (especially for a large project like binutils, which may take 10-20 minutes). This is the static analysis step of SelectFuzz, has nothing to do with the technology of this paper, and the time is acceptable. ``` #### 3.2.2 Check the crashes (Auto crash classification) Many crashes will be generated during the fuzzing process. The *auto_verify.sh* script can be used to determine whether the expected POC is generated in the current crashes directory. the string "poc" in `` will be replaced by POCs in ``, which is similar to the "@@" used in AFL. Usage: ```bash 1 cd /transferfuzz/scripts/verify 2 ./auto_verify.sh 3 cat ./result.txt # Due to different project version, some vuls automatic verification may fail. You can read the crash_report.txt and check whether the verification is successful by function sequence. ``` Example: ```bash 1 cd /transferfuzz/scripts/verify 2 ./auto_verify.sh /transferfuzz/scripts/evaluation/tiffcmp-2016-10095/obj-dist/tools/tiffcmp "poc poc" /transferfuzz/scripts/evaluation/tiffcmp-2016-10095/obj-dist/out/crashes "tif_dir.c:1056" 3 cat ./result.txt ``` We use another binary *objdump* as an example too to demonstrate the usage: ``` 1 ./auto_verify.sh /data/bin/binutils_2.26/objdump "-t -C poc" /result/objdump-2016-4487/crashes "cplus-dem.c:4319" ```
### 3.3 Full process You can run the complete TransferFuzz with the following command. (e.g. Use tiffsplit as basic binary and tiffcmp as target binary) #### 3.3.1 Function-level Trace Extraction Automatically generate the `cve-2016-10095-functrace.txt` file. Put the basic binary and poc into the directory `/data/bin/` and `/data/poc/` (The basic binary *tiffsplit* can be found at */bin* of github and the poc *tiffsplit-2016-10095-poc* can be found at */poc* or generated by Directed Fuzzing) ```bash 1 cd /transferfuzz/scripts/func_trace 2 ./get_trace.sh /data/bin/tiffsplit "poc" /data/poc ./result.txt 3 python3 ./deal_trace.py ./result.txt cve-2016-10095-functrace.txt ``` #### 3.3.2 Key-bytes Trace Extraction Automatically generate the `cve-2016-10095-keybytes.txt` file. Put the basic binary and poc into the directory `./bin/` and `./poc/` (The basic binary *tiffsplit* can be found at */bin* of github and the poc *tiffsplit-2016-10095-poc* can be found at */poc* or generated by Directed Fuzzing) ```bash 1 cd /transferfuzz/scripts/keybytes_trace 2 pin -t ./taint_test.so -i ./poc/tiffsplit-2016-10095-poc -v tiffcp -- ./bin/tiffsplit ./poc/tiffsplit-2016-10095-poc 3 python3 get_fuzz_dict.py ./taint_trace.out ./cve-2016-10095-keybytes.txt ``` #### 3.3.3 Trace Guided Fuzzing put the `cve-2016-10095-functrace.txt` to `/transferfuzz/scripts/fuzz_functrace/` and rename it to `cve-2016-10095.txt`. put the `cve-2016-10095-keybytes.txt` to `/transferfuzz/scripts/fuzz_dict/` and rename it to `cve-2016-10095.txt`. ```bash 1 cd /transferfuzz/scripts/evaluation 2 ./tiffcmp-2016-10095.sh ``` #### 3.3.4 Check the crashes (Auto crash classification) ```bash 1 cd /transferfuzz/scripts/verify 2 ./auto_verify.sh /transferfuzz/scripts/evaluation/tiffcmp-2016-10095/obj-dist/tools/tiffcmp "poc poc" /transferfuzz/scripts/evaluation/tiffcmp-2016-10095/obj-dist/out/crashes "tif_dir.c:1056" 3. cat ./result.txt ```

## 4. Verify a new vulnerability - Prepare a basic binary and a target binary that reuses the code from the basic binary. - Prepare a basic poc or generate poc by Directed Fuzzing. - Run the **Function-level Trace Extraction** module and the **Key-bytes Trace Extraction** module to extract traces. - Run **Trace Guided Fuzzing** for the target binary. - Run the **Auto crash classification** to check vulnerability propagation.

## 5. Result Analysis 35 of the 38 new vuls in the paper were successful. In addition to the three unverified vulnerabilities presented in the paper, we also discovered two others (CVE-2022-34526 and CVE-2017-9147) that also could not be verified. We analyzed these bad cases to inform future research. The main reasons for the unverifiable vulnerabilities are as follows: - Existing methods are prototypes and require additional engineering efforts, such as in-process instrumentation, to adapt to more software (For three unverified vulnerabilities presented in the paper). - Some vulnerabilities are difficult to trigger by fuzzing, and there are no key bytes to bypass the conditional branch (For CVE-2022-34526 and CVE-2017-9147).

## 6. Migrate TransferFuzz to new fuzzing technology instead of SelectFuzz We use macro definitions in `/code` to wrap all the code that needs to be modified. We have successfully implemented TransferFuzz based on AFLGo, WindRanger and SelectFuzz. If you want to support more frameworks, please contact us.