21f7bc85f9
* Fix leaks * Remove unnecessary new lines * Add checks for actual buffer length before attempting reading it. * Xtensa: add xtensa support * Xtensa fixes - fix MCExpr - fix Xtensa_add_cs_detail - add `add_cs_detail` - add `MCExpr *MCOperand_getExpr(const MCOperand *MC)` `void printExpr(const MCExpr *E, SStream *O)` autosync fix - fix StreamOperation.py - replace `report_fatal_error` with `CS_ASSERT` - fix patch StreamOperation.py - replace `assert` with `CS_ASSERT` - fix AddCSDetail.py - fix QualifiedIdentifier * Xtensa fix * Xtensa fix .py * add Xtensa to the fuzzer * Xtensa `LITBASE`: add a basic implementation * Xtensa `LITBASE`: add a integration test * Xtensa: fix cs_v6_release_guide.md * Xtensa: fix `XTENSA_OP_GROUP_MEMOPERAND` * Xtensa: fix * Xtensa: fix Targets.py * Use isUint and isInt all over Xtensa * Add documentation about LITBASE functionality * Fix typo * Replace hard with Capstone assert * Xtensa: fix arch_config.json * Xtensa: fix --------- Co-authored-by: Rot127 <unisono@quyllur.org> |
||
|---|---|---|
| .. | ||
| driverbin.c | ||
| drivermc.c | ||
| fuzz_decode_platform.c | ||
| fuzz_diff.c | ||
| fuzz_disasm.c | ||
| fuzz_disasm.options | ||
| fuzz_harness.c | ||
| fuzz_llvm.cpp | ||
| fuzzit.sh | ||
| fuzzitid.txt | ||
| Makefile | ||
| onefile.c | ||
| platform.c | ||
| platform.h | ||
| README | ||
| README.md | ||
Fuzzing
Build the fuzz target
To build the fuzz target, you can simply run make with appropriate flags set :
ASAN_OPTIONS=detect_leaks=0 CXXFLAGS="-DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION -fsanitize=address -fsanitize=fuzzer-no-link" CFLAGS="-DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION -fsanitize=address -fsanitize=fuzzer-no-link" LDFLAGS="-fsanitize=address" make
You can replace address with another sanitizer : memory or undefined
The fuzz target is then suite/fuzz/fuzz_bindisasm2
You can find this in travis configuration .travis.yml
Another way is to use oss-fuzz, see https://github.com/google/oss-fuzz/blob/master/projects/capstone/build.sh
Troubleshooting
If you get cc: error: unrecognized argument to ‘-fsanitize=’ option: ‘fuzzer’ check if you have a workable
version of libfuzz installed. Also try to build with CC=clang make
Interpret OSS-Fuzz report
A reported bug by OSS-fuzz looks usually like this:
...
#20 0x7f3a42062082 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId: 0702430aef5fa3dda43986563e9ffcc47efbd75e)
#21 0x55ad814876dd in _start (build-out/fuzz_disasmnext+0x5246dd)
DEDUP_TOKEN: raise--abort--
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: ABRT (/lib/x86_64-linux-gnu/libc.so.6+0x4300b) (BuildId: 0702430aef5fa3dda43986563e9ffcc47efbd75e) in raise
==62==ABORTING
MS: 0 ; base unit: 0000000000000000000000000000000000000000
0x7,0xe8,0x3,0x4e,0xc0,0xf8,
\007\350\003N\300\370
It emits the bytes fed to Capstone in the last two lines.
The first byte determines the arch+mode. The following bytes the actual data producing the crash.
You can run ./fuzz_decode_platform to get the arch+mode used:
./fuzz_decode_platform 0x7
cstool arch+mode = aarch64
And reproduce the bug with cstool:
# Make sureevery hex number has two digits!
cstool -d aarch64 0xe8,0x03,0x4e,0xc0,0xf8,
Make sure the every hex number has two digits (0x3 -> 0x03)!
cstool won't parse it correctly otherwise.
Fuzz drivers
There are custom drivers :
- driverbin.c : prints cstool command before running one input
- drivermc.c : converts MC test data to raw binary data before running as many inputs as there are lines in a file
- onefile.c : simple one file driver
For libfuzzer, the preferred main function is now to use linker option -fsanitize=fuzzer
Fuzzit integration
Travis will build the fuzz target with the different sanitizers. Then, Travis will launch sanity fuzzit jobs as part of continuous integration (for each of the sanitizers) The fuzzit target ids are stored in a configuration file fuzzitid.txt and used by fuzzit.sh