boschresearch/gdbfuzzहार्डवेयर ब्रेकपॉइंट्स का उपयोग करके एम्बेडेड सिस्टम की फ़ज़िंग
यह पेपर का सहायक कोड है: 'Fuzzing Embedded Systems using Debugger Interfaces'. पेपर का प्रीप्रिंट यहाँ पाया जा सकता है https://publications.cispa.saarland/3950/. यह कोड उपयोगकर्ताओं को पेपर में रिपोर्ट किए गए परिणामों को पुन: उत्पन्न करने और विस्तारित करने की अनुमति देता है। कृपया परिणामों की रिपोर्ट करते, पुन: उत्पन्न करते या विस्तारित करते समय उपरोक्त पेपर का उल्लेख करें।
.
├── benchmark # गूगल के फ़ज़र टेस्ट सूट को बनाने और प्रयोग चलाने के लिए स्क्रिप्ट्स
├── dependencies # GDBFuzz के लिए निर्भरताएँ स्थापित करने के लिए एक Makefile शामिल है
├── evaluation # कच्चा प्रयोग डेटा, पेपर में प्रस्तुत किया गया
├── example_firmware # एम्बेडेड उदाहरण अनुप्रयोग, मूल्यांकन के लिए उपयोग किए गए
├── example_programs # GDBFuzz का परीक्षण करने के लिए एक संकलित उदाहरण प्रोग्राम और कॉन्फ़िग्स शामिल हैं
├── src # GDBFuzz का कार्यान्वयन शामिल है
├── Dockerfile # सभी GDBFuzz निर्भरताओं के साथ एक डॉकर इमेज बनाने के लिए
├── LICENSE # लाइसेंस
├── Makefile # डॉकर इमेज बनाने या GDBFuzz स्थानीय रूप से स्थापित करने के लिए Makefile
└── README.md # यह README फ़ाइल
GDBFuzz का विचार माइक्रोकंट्रोलर्स से हार्डवेयर ब्रेकपॉइंट्स को कवरेज-निर्देशित फ़ज़िंग के लिए फीडबैक के रूप में उपयोग करना है। इसलिए, GDB का उपयोग एक सामान्य इंटरफ़ेस के रूप में किया जाता है ताकि व्यापक प्रयोज्यता सक्षम हो सके। फर्मवेयर के बाइनरी विश्लेषण के लिए, Ghidra का उपयोग किया जाता है। कोड में विधि का मूल्यांकन करने के लिए एक बेंचमार्क सेटअप शामिल है। इसके अतिरिक्त, उदाहरण फर्मवेयर फ़ाइलें शामिल हैं।
GDBFuzz एम्बेडेड सिस्टम के लिए कवरेज-निर्देशित फ़ज़िंग को सक्षम करता है, लेकिन - मूल्यांकन उद्देश्यों के लिए - मनमाने उपयोगकर्ता अनुप्रयोगों को भी फ़ज़ कर सकता है। माइक्रोकंट्रोलर्स पर फ़ज़िंग के लिए हम GDBFuzz की स्थानीय स्थापना की सलाह देते हैं ताकि परीक्षण के तहत डिवाइस को बिना किसी दोष के फ़ज़ डेटा भेज सकें।
GDBFuzz का परीक्षण Ubuntu 20.04 LTS और Raspberry Pi OS 32-bit पर किया गया है। पूर्वापेक्षाएँ java और python3 हैं। पहले, एक नया वर्चुअल वातावरण बनाएं और सभी निर्भरताएँ स्थापित करें।
virtualenv .venv
source .venv/bin/activate
make
chmod a+x ./src/GDBFuzz/main.py
GDBFuzz निम्नलिखित कुंजियों के साथ एक कॉन्फ़िग फ़ाइल से सेटिंग्स पढ़ता है।
[SUT]
# SUT की बाइनरी फ़ाइल का पथ।
# यह उदाहरण के लिए, एक .elf फ़ाइल या .bin फ़ाइल हो सकता है।
binary_file_path = <path>
# CFG के रूट नोड का पता।
# ब्रेकपॉइंट्स इस CFG के नोड्स पर रखे जाते हैं।
# जैसे 'LLVMFuzzerTestOneInput' या 'main'
entrypoint = <entrypoint>
# इनपुट की संख्या जो ब्रेकपॉइंट हिट किए बिना निष्पादित होनी चाहिए जब तक
# ब्रेकपॉइंट रोटेट न हों।
until_rotate_breakpoints = <number>
# किसी भी समय पर रखे जा सकने वाले ब्रेकपॉइंट की अधिकतम संख्या।
max_breakpoints = <number>
# वे फ़ंक्शन जिन्हें अनदेखा किया जाना चाहिए (ब्लैकलिस्ट)।
# ignore_functions फ़ंक्शन नामों की स्पेस-सेपरेटेड सूची है जैसे 'malloc free'।
ignore_functions = <space separated list>
# {Hardware, QEMU, SUTRunsOnHost} में से एक
# Hardware: एक बाहरी घटक gdb सर्वर शुरू करता है और GDBFuzz इस gdb सर्वर से कनेक्ट हो सकता है।
# QEMU: GDBFuzz QEMU शुरू करता है। QEMU binary_file_path को एम्युलेट करता है और gdbserver शुरू करता है।
# SUTRunsOnHost: GDBFuzz लक्ष्य प्रोग्राम को GDB के भीतर शुरू करता है।
target_mode = <mode>
# इसे False पर सेट करें यदि आप ghidra शुरू करना, SUT का विश्लेषण करना,
# और ghidra ब्रिज सर्वर को मैन्युअल रूप से शुरू करना चाहते हैं।
start_ghidra = True
# सॉफ़्टवेयर ब्रेकपॉइंट (त्रुटि हैंडलिंग कोड के लिए) के पतों की स्पेस-सेपरेटेड सूची।
# इनका निष्पादन एक क्रैश माना जाता है।
# उदाहरण: software_breakpoint_addresses = 0x123 0x432
software_breakpoint_addresses =
# क्या सभी ट्रिगर किए गए सॉफ़्टवेयर ब्रेकपॉइंट को क्रैश माना जाए
consider_sw_breakpoint_as_error = False
[SUTConnection]
# फ़ाइल 'SUT_connection_path' में वर्ग 'SUT_connection_class' यह कार्यान्वित करता है कि
# SUT को इनपुट कैसे भेजे जाते हैं।
# इनपुट उदाहरण के लिए, Wi-Fi, सीरियल, ब्लूटूथ, ... के माध्यम से भेजे जा सकते हैं।
# इस वर्ग को ./connections/SUTConnection.py से इनहेरिट करना चाहिए।
# अधिक जानकारी के लिए ./connections/SUTConnection.py देखें।
SUT_connection_file = FIFOConnection.py
[GDB]
path_to_gdb = gdb-multiarch
# address:port प्रारूप में लिखा गया
gdb_server_address = localhost:4242
[Fuzzer]
# बाइट्स में
maximum_input_length = 100000
# सेकंड में
single_run_timeout = 20
# सेकंड में
total_runtime = 3600
# वैकल्पिक
# एक निर्देशिका का पथ जहाँ प्रत्येक फ़ाइल में एक सीड होता है। यदि आप
# सीड का उपयोग नहीं करना चाहते हैं, तो मान खाली छोड़ दें।
seeds_directory =
[BreakpointStrategy]
# बुनियादी ब्लॉक चुनने की रणनीतियाँ 'src/GDBFuzz/breakpoint_strategies/' में स्थित हैं।
# पेपर के लिए हम निम्नलिखित रणनीतियों का उपयोग करते हैं
# 'RandomBasicBlockStrategy.py' - यादृच्छिक रूप से अप्राप्त बुनियादी ब्लॉक चुनना
# 'RandomBasicBlockNoDomStrategy.py' - पिछले जैसा, लेकिन ट्रांज़िटिवली रीच किए गए नोड्स को प्राप्त करने के लिए डोमिनेंस संबंधों का उपयोग नहीं करता।
# 'RandomBasicBlockNoCorpusStrategy.py' - पहले जैसा, लेकिन इनपुट कॉर्पस को बढ़ने से रोकता है और इसलिए कवरेज माप के साथ ब्लैकबॉक्स फ़ज़िंग की तरह व्यवहार करता है।
# 'BlackboxStrategy.py' - कोई ब्रेकपॉइंट नहीं सेट करता
breakpoint_strategy_file = RandomBasicBlockStrategy.py
[Dependencies]
path_to_qemu = dependencies/qemu/build/x86_64-linux-user/qemu-x86_64
path_to_ghidra = dependencies/ghidra
[LogsAndVisualizations]
# {DEBUG, INFO, WARNING, ERROR, CRITICAL} में से एक
loglevel = INFO
# उस निर्देशिका का पथ जहाँ आउटपुट फ़ाइलें (जैसे ग्राफ़, लॉगफ़ाइलें) संग्रहीत की जाती हैं।
output_directory = ./output
# यदि True पर सेट किया जाता है, तो एक MQTT क्लाइंट UI तत्व (जैसे ग्राफ़) भेजता है
enable_UI = False
एक उदाहरण कॉन्फ़िग फ़ाइल ./example_programs/ में स्थित है, साथ ही एक उदाहरण प्रोग्राम जो benchmark/benchSUTs/GDBFuzz_wrapper/common/ में हमारे फ़ज़िंग हार्नेस का उपयोग करके संकलित किया गया था। निम्नलिखित कमांड के साथ एक घंटे के लिए फ़ज़िंग शुरू करें।
chmod a+x ./example_programs/json-2017-02-12
./src/GDBFuzz/main.py --config ./example_programs/fuzz_json.cfg
हम पहले Ghidra से बाइनरी निष्पादन योग्य का विश्लेषण करने का आउटपुट देखते हैं और फिर जब ब्रेकपॉइंट स्थानांतरित या हिट होते हैं तो संदेश देखते हैं।
कॉन्फ़िग फ़ाइल में निर्दिष्ट output_directory के आधार पर, अब निम्नलिखित संरचना के साथ एक फ़ोल्डर trial-0 होना चाहिए
.
├── corpus # एक फ़ोल्डर जिसमें इनपुट कॉर्पस है।
├── crashes # एक फ़ोल्डर जिसमें क्रैश करने वाले इनपुट हैं - यदि कोई हों।
├── cfg # एड्जेसेंसी सूची के रूप में कंट्रोल फ़्लो ग्राफ़।
├── fuzzer_stats # फ़ज़िंग अभियान के आँकड़े।
├── plot_data # तालिका दिखाती है कि फ़ज़िंग अभियान में किस सापेक्ष समय पर कौन सा बुनियादी ब्लॉक पहुँचा गया था।
├── reverse_cfg # रिवर्स कंट्रोल फ़्लो ग्राफ़।
कॉन्फ़िग फ़ाइल में start_ghidra = False सेट करके, GDBFuzz GUI मोड में चल रहे Ghidra इंस्टेंस से जुड़ता है। इसलिए, ghidra_bridge प्लगइन को स्क्रिप्ट मैनेजर से मैन्युअल रूप से शुरू करने की आवश्यकता है। फ़ज़िंग के दौरान, पहुँचे गए प्रोग्राम ब्लॉक हरे रंग में हाइलाइट किए जाते हैं।
लिनक्स उपयोगकर्ता अनुप्रयोगों पर फ़ज़िंग के लिए, GDBFuzz मानक LLVMFuzzOneInput एंट्रीपॉइंट का लाभ उठाता है जो लगभग सभी फ़ज़र्स जैसे AFL, AFL++, libFuzzer, आदि द्वारा उपयोग किया जाता है। benchmark/benchSUTs/GDBFuzz_wrapper/common में एक रैपर है जिसका उपयोग किसी भी अनुरूप फ़ज़ हार्नेस को एक स्टैंडअलोन प्रोग्राम में संकलित करने के लिए किया जा सकता है जो /tmp/fromGDBFuzz पर एक नामित पाइप के माध्यम से इनपुट प्राप्त करता है। यह एक एम्बेडेड डिवाइस का अनुकरण करने की अनुमति देता है जो एक अच्छी तरह से परिभाषित इनपुट इंटरफ़ेस के माध्यम से डेटा का उपभोग करता है और इसलिए किसी भी एप्लिकेशन पर GDBFuzz चला सकता है। सुविधा के लिए हमने benchmark/benchSUTs में एक स्क्रिप्ट बनाई है जो हमारे मूल्यांकन के सभी प्रोग्रामों को हमारे रैपर के साथ संकलित करती है जैसा कि बाद में समझाया गया है।
नोट: GDBFuzz लिनक्स उपयोगकर्ता अनुप्रयोगों को फ़ज़ करने के लिए नहीं है। इसके लिए AFL++ या अन्य फ़ज़र्स का उपयोग करें। रैपर केवल मूल्यांकन उद्देश्यों के लिए मौजूद है ताकि पैमाने पर बेंचमार्क और तुलना चलाने में सक्षम हो सके।
हमारे दृष्टिकोण की सामान्य प्रभावशीलता डॉकर कंटेनर के रूप में तैनात एक बड़े पैमाने के बेंचमार्क में दिखाई गई है।
make dockerimage
डॉकर कंटेनर में उपरोक्त प्रयोग चलाने के लिए (कॉन्फ़िग फ़ाइल में निर्दिष्ट एक घंटे के लिए), example_programs और output फ़ोल्डर को वॉल्यूम के रूप में मैप करें और GDBFuzz को निम्नानुसार शुरू करें।
chmod a+x ./example_programs/json-2017-02-12
docker run -it --env CONFIG_FILE=/example_programs/fuzz_json_docker_qemu.cfg -v $(pwd)/example_programs:/example_programs -v $(pwd)/output:/output gdbfuzz:1.0
वर्तमान कार्यशील निर्देशिका में ऊपर बताई गई संरचना के साथ एक आउटपुट फ़ोल्डर दिखना चाहिए।
हमारा मूल्यांकन दो भागों में विभाजित है।
GDBFuzz किसी भी GDB सर्वर के साथ काम कर सकता है और इसलिए माइक्रोकंट्रोलर्स के लिए अधिकांश डीबग प्रोब के साथ काम कर सकता है।
पेपर से RQ1 के संबंध में, हम example_firmware में स्थित विभिन्न फर्मवेयर के साथ विभिन्न माइक्रोकंट्रोलर्स पर GDBFuzz निष्पादित करते हैं। प्रत्येक प्रयोग के लिए हम RandomBasicBlock और RandomBasicBlockNoCorpus रणनीति के साथ GDBFuzz चलाते हैं। बाद वाला बिना फीडबैक के फ़ज़िंग की तरह व्यवहार करता है, लेकिन हम अभी भी प्राप्त कवरेज को माप सकते हैं। RQ1 का उत्तर देने के लिए, हम RandomBasicBlock और RandomBasicBlockNoCorpus रणनीति की प्राप्त कवरेज की तुलना करते हैं। संबंधित कॉन्फ़िग फ़ाइलें संबंधित उपफ़ोल्डरों में हैं और अब हम चार डेवलपमेंट बोर्डों पर फ़ज़िंग सेटअप करने का तरीका बताते हैं।
GDBFuzz को GDB सर्वर तक पहुँच की आवश्यकता है। इस मामले में B-L4S5I-IOT01A और इसके ऑन-बोर्ड डीबगर का उपयोग किया जाता है। यह ऑन-बोर्ड डीबगर 'st-util' प्रोग्राम के माध्यम से GDB सर्वर सेट करता है, और localhost:4242 के माध्यम से इस GDB सर्वर तक पहुँच सक्षम करता है।
sudo apt-get install stlink-tools gdb-multiarch
STM32 B-L4S5I-IOT01A के लिए एक फर्मवेयर बनाएं और फ्लैश करें, उदाहरण के लिए arduinojson प्रोजेक्ट।
पूर्वापेक्षा: platformio (pio) स्थापित करें
cd ./example_firmware/stm32_disco_arduinojson/
pio run --target upload
आपकी जानकारी के लिए: platformio ने SUT की एक .elf फ़ाइल यहाँ संग्रहीत की है: ./example_firmware/stm32_disco_arduinojson/.pio/build/disco_l4s5i_iot01a/firmware.elf इस .elf फ़ाइल का उपयोग बाद में Ghidra के लिए उपयोगकर्ता कॉन्फ़िगरेशन में भी किया जाता है।
एक नया टर्मिनल शुरू करें, और GDB सर्वर शुरू करने के लिए निम्नलिखित चलाएँ:
st-util
arduinojson के लिए उपयोगकर्ता कॉन्फ़िगरेशन के साथ GDBFuzz चलाएँ। हम USB पोर्ट के माध्यम से माइक्रोकंट्रोलर को डेटा भेज सकते हैं। माइक्रोकंट्रोलर इस डेटा को सीरियल के माध्यम से SUT को अग्रेषित करता है। हमारे मामले में /dev/ttyACM0 माइक्रोकंट्रोलर बोर्ड के लिए USB डिवाइस है। यदि आपके सिस्टम ने माइक्रोकंट्रोलर बोर्ड को कोई अन्य डिवाइस असाइन किया है, तो कॉन्फ़िग फ़ाइल में /dev/ttyACM0 को अपने डिवाइस में बदलें।
./src/GDBFuzz/main.py --config ./example_firmware/stm32_disco_arduinojson/fuzz_serial_json.cfg
फ़ज़र सांख्यिकी और लॉग ./output/... निर्देशिका में हैं।
pyocd स्थापित करें:
pip install --upgrade pip 'mbed-ls>=1.7.1' 'pyocd>=0.16'
सुनिश्चित करें कि डिवाइस पर 'KitProg v3' है और बोर्ड को उपयुक्त बटन दबाकर 'Arm DAPLink' मोड में डालें। GDB सर्वर शुरू करें:
pyocd gdbserver --persist
एक फर्मवेयर फ्लैश करें और फ़ज़िंग शुरू करें, जैसे:
gdb-multiarch
target remote :3333
load ./example_firmware/CY8CKIT_json/mtb-example-psoc6-uart-transmit-receive.elf
monitor reset
./src/GDBFuzz/main.py --config ./example_firmware/CY8CKIT_json/fuzz_serial_json.cfg
ESP32 के लिए एक फर्मवेयर बनाएं और फ्लैश करें, उदाहरण के लिए platformio के साथ arduinojson उदाहरण।
cd ./example_firmware/esp32_arduinojson/
pio run --target upload
J-Link डीबगर के लिए openocd कॉन्फ़िग फ़ाइल में निम्नलिखित पंक्ति जोड़ें: jlink.cfg
adapter speed 10000
एक नया टर्मिनल शुरू करें, और GDB सर्वर शुरू करने के लिए निम्नलिखित चलाएँ:
get_idf
openocd -f interface/jlink.cfg -f target/esp32.cfg -c "telnet_port 7777" -c "gdb_port 8888"
arduinojson के लिए उपयोगकर्ता कॉन्फ़िगरेशन के साथ GDBFuzz चलाएँ। हम USB पोर्ट के माध्यम से माइक्रोकंट्रोलर को डेटा भेज सकते हैं। माइक्रोकंट्रोलर इस डेटा को सीरियल के माध्यम से SUT को अग्रेषित करता है। हमारे मामले में /dev/ttyUSB0 माइक्रोकंट्रोलर बोर्ड के लिए USB डिवाइस है। यदि आपके सिस्टम ने माइक्रोकंट्रोलर बोर्ड को कोई अन्य डिवाइस असाइन किया है, तो कॉन्फ़िग फ़ाइल में /dev/ttyUSB0 को अपने डिवाइस में बदलें।
./src/GDBFuzz/main.py --config ./example_firmware/esp32_arduinojson/fuzz_serial.cfg
फ़ज़र सांख्यिकी और लॉग ./output/... निर्देशिका में हैं।
TI MSP430 GCC को https://www.ti.com/tool/MSP430-GCC-OPENSOURCE से स्थापित करें
GDB सर्वर शुरू करें
./gdb_agent_console libmsp430.so
या (अधिक स्थिर)। मspdebug को https://github.com/dlbeer/mspdebug/ से बनाएं और उपयोग करें:
until mspdebug --fet-skip-close --force-reset tilib "opt gdb_loop True" gdb ; do sleep 1 ; done
Ghidra TI MSP430 कंट्रोलर के लिए बाइनरी का आउट-ऑफ-द-बॉक्स विश्लेषण करने में विफल रहता है। इसे ठीक करने के लिए, हम फ़ाइल को Ghidra GUI में आयात करते हैं, आर्किटेक्चर के रूप में MSP430X चुनते हैं और ऑटो विश्लेषण को छोड़ देते हैं। इसके बाद, हम 'सिंबल टेबल' खोलते हैं, उन्हें नाम के अनुसार सॉर्ट करते हैं और $C$L* जैसे नामों वाले सभी सिंबल को हटा देते हैं। अब ऑटो विश्लेषण निष्पादित किया जा सकता है। विश्लेषण के बाद, Ghidra GUI से मैन्युअल रूप से ghidra ब्रिज शुरू करें और फिर GDBFuzz शुरू करें।
./src/GDBFuzz/main.py --config ./example_firmware/msp430_arduinojson/fuzz_serial.cfg
pyusb के साथ गैर-रूट उपयोगकर्ता के रूप में USB डिवाइसों तक पहुँचने के लिए हम udev में उपयुक्त नियम जोड़ते हैं। निम्नलिखित पंक्तियाँ /etc/udev/rules.d/50-myusb.rules में पेस्ट करें:
SUBSYSTEM=="usb", ATTRS{idVendor}=="1234", ATTRS{idProduct}=="5678" GROUP="usbusers", MODE="666"
udev को रीलोड करें:
sudo udevadm control --reload
sudo udevadm trigger
पेपर से RQ2 में, हम GDBFuzz की तुलना एम्युलेशन-आधारित दृष्टिकोण Fuzzware से करते हैं। पहले हम शिप किए गए फर्मवेयर फ़ाइलों पर पहले वर्णित अनुसार GDBFuzz और Fuzzware निष्पादित करते हैं। प्रत्येक GDBFuzz प्रयोग के लिए, हम कंट्रोल फ़्लो ग्राफ़ फ़ाइलों से मान्य बुनियादी ब्लॉकों की एक फ़ाइल इस प्रकार बनाते हैं:
cut -d " " -f1 ./cfg > valid_bbs.txt
अब हम फ़ज़वेयर परिणाम के विरुद्ध कवरेज को रीप्ले कर सकते हैं: fuzzware genstats --valid-bb-file valid_bbs.txt
जब क्रैश या हैंग करने वाले इनपुट मिलते हैं, तो वे crashes फ़ोल्डर में संग्रहीत होते हैं। मूल्यांकन के दौरान, हमें निम्नलिखित तीन बग मिले:
GDBFuzz थोड़े संशोधनों के साथ Raspberry Pi होस्ट पर भी चल सकता है:
फ़ाइल ./dependencies/ghidra/support/launch.sh:125 में JAVA_HOME वेरिएबल को हार्डकोड किया जाना चाहिए, उदाहरण के लिए JAVA_HOME="/usr/lib/jvm/default-java"
अन्य बोर्डों पर सॉफ़्टवेयर फ़ज़ करने के लिए, GDBFuzz को चाहिए:
src/GDBFuzz/connections) जो एंट्री पॉइंट पर कोड के निष्पादन को ट्रिगर करता है, जैसे सीरियल कनेक्शनये सभी गुण कॉन्फ़िग फ़ाइल में निर्दिष्ट होने चाहिए।
RQ's 4 - 8 के लिए हम एक बड़े पैमाने का बेंचमार्क चलाते हैं।
पहले, पहले वर्णित अनुसार Docker इमेज बनाएं और गूगल के Fuzzer Test Suite से एप्लिकेशन को benchmark/benchSUTs/GDBFuzz_wrapper/common में हमारे फ़ज़िंग हार्नेस के साथ संकलित करें।
cd ./benchmark/benchSUTs
chmod a+x setup_benchmark_SUTs.py
make dockerbenchmarkimage
इसके बाद benchmark/scripts/benchmark.py और benchmark/scripts/benchmark_aflpp.py में बेंचमार्क सेटिंग्स को अपनी आवश्यकताओं (विशेष रूप से number_of_cores, trials, और seconds_per_trial) के अनुसार अनुकूलित करें और बेंचमार्क इस प्रकार शुरू करें:
cd ./benchmark/scripts
./benchmark.py $(pwd)/../benchSUTs/SUTs/ SUTs.json
./benchmark_aflpp.py $(pwd)/../benchSUTs/SUTs/ SUTs.json
./benchmark/scripts में एक फ़ोल्डर दिखाई देता है जिसमें प्रत्येक प्रयोग के लिए प्लॉट फ़ाइलें (समय के साथ कवरेज), फ़ज़र सांख्यिकी फ़ाइलें, और कंट्रोल फ़्लो ग्राफ़ फ़ाइलें हैं जैसा कि evaluation/fuzzer_test_suite_qemu_runs में है।
GDBFuzz में एक वैकल्पिक सुविधा है जहाँ यह कवर किए गए नोड्स का कंट्रोल फ़्लो ग्राफ़ प्लॉट करता है। यह डिफ़ॉल्ट रूप से अक्षम है। आप इस अनुभाग के निर्देशों का पालन करके और उपयोगकर्ता कॉन्फ़िगरेशन में 'enable_UI' को 'True' पर सेट करके इसे सक्षम कर सकते हैं।
होस्ट पर:
स्थापित करें
sudo apt-get install graphviz
Node का एक हालिया संस्करण स्थापित करें, उदाहरण के लिए यहाँ से विकल्प 2। विकल्प 2 का उपयोग करें, विकल्प 1 का नहीं। इससे node और npm दोनों स्थापित होने चाहिए। संदर्भ के लिए, हमारे संस्करण संख्याएँ हैं (लेकिन नए संस्करण भी काम करने चाहिए):
➜ node --version
v16.9.1
➜ npm --version
7.21.1
वेब UI निर्भरताएँ स्थापित करें:
cd ./src/webui
npm install
mosquitto MQTT ब्रोकर स्थापित करें, उदाहरण के लिए यहाँ देखें
mosquitto ब्रोकर कॉन्फ़िग अपडेट करें: फ़ाइल /etc/mosquitto/conf.d/mosquitto.conf को निम्नलिखित सामग्री से बदलें:
listener 1883
allow_anonymous true
listener 9001
protocol websockets
mosquitto ब्रोकर को पुनरारंभ करें:
sudo service mosquitto restart
जाँचें कि mosquitto ब्रोकर चल रहा है:
sudo service mosquitto status
आउटपुट में 'Active: active (running)' टेक्स्ट शामिल होना चाहिए
वेब UI शुरू करें:
cd ./src/webui
npm start
आपका वेब ब्राउज़र स्वचालित रूप से 'http://localhost:3000/' पर खुलना चाहिए।
GDBFuzz शुरू करें और एक उपयोगकर्ता कॉन्फ़िग फ़ाइल का उपयोग करें जहाँ enable_UI True पर सेट है। आप ऊपर से Docker कंटेनर और arduinojson SUT का उपयोग कर सकते हैं। लेकिन सुनिश्चित करें कि 'enable_UI' को 'True' पर सेट करें।
'नीले' रंग में कवर किए गए नोड कवर हैं। सफ़ेद नोड कवर नहीं हैं। हम केवल उन अनकवर नोड्स को दिखाते हैं जिनका पैरेंट कवर है (यदि कंट्रोल फ़्लो ग्राफ़ बड़ा है तो पूरा कंट्रोल फ़्लो ग्राफ़ बनाने में बहुत समय लगता है)।
GDBFuzz AGPL-3.0 लाइसेंस के तहत ओपन-सोर्स है। विवरण के लिए LICENSE फ़ाइल देखें।
GDBFuzz में शामिल अन्य ओपन सोर्स घटकों की सूची के लिए, फ़ाइल 3rd-party-licenses.txt देखें।