ucsb-seclab/difuzeलिनक्स कर्नेल ड्राइवरों के लिए फ़ज़र
इस रिपॉजिटरी में वे सभी स्रोत (सेटअप स्क्रिप्ट सहित) हैं, जिनकी आपको difuze को चालू करने के लिए आवश्यकता है।
Ubuntu >= 14.04.5 LTS
README देखें
जैसा कि हमारे पेपर में बताया गया है, difuze के दो मुख्य घटक हैं: इंटरफ़ेस रिकवरी और फ़ज़िंग इंजन
इंटरफ़ेस रिकवरी तंत्र LLVM विश्लेषण पास पर आधारित है। इंटरफ़ेस रिकवरी के प्रत्येक चरण को अलग-अलग पास के रूप में लिखा गया है। इंटरफ़ेस रिकवरी को चालू करने के लिए नीचे दिए गए निर्देशों का पालन करें।
यह चरण LLVM और c2xml को स्थापित करने का ध्यान रखता है:
सबसे पहले, सुनिश्चित करें कि आपके पास libxml (c2xml के लिए आवश्यक) है:
sudo apt-get install libxml2-dev
sudo pip install lxml
इसके बाद, हमने एक एकल स्क्रिप्ट बनाई है, जो सभी आवश्यक उपकरणों को डाउनलोड और बिल्ड करती है।
cd helper_scripts
python setup_difuze.py --help
usage: setup_difuze.py [-h] [-b TARGET_BRANCH] [-o OUTPUT_FOLDER]
optional arguments:
-h, --help show this help message and exit
-b TARGET_BRANCH Branch (i.e. version) of the LLVM to setup. Default:
release_38 e.g., release_38
-o OUTPUT_FOLDER Folder where everything needs to be setup.
उदाहरण:
python setup_difuze.py -o difuze_deps
सेटअप को पूरा करने के लिए आपको अपने स्थानीय PATH पर्यावरण चर में संशोधन करने की भी आवश्यकता है। सेटअप स्क्रिप्ट आपको सटीक परिवर्तन बताएगी जो आपको करने हैं।
यह सेटअप के सफल समापन पर निर्भर करता है। हमारे पास एक एकल स्क्रिप्ट है जो सब कुछ बनाती है, आपका स्वागत है।
cd InterfaceHandlers
./build.sh
यह बिल्ड के सफल समापन पर निर्भर करता है। कर्नेल ड्राइवरों पर इंटरफ़ेस रिकवरी घटकों को चलाने के लिए, हमें पहले ड्राइवरों को llvm बिटकोड में बदलना होगा।
सबसे पहले, हमारे पास एक बिल्ड करने योग्य कर्नेल होना चाहिए। इसका मतलब है कि आप नियमित बिल्ड सेटअप का उपयोग करके कर्नेल को संकलित करने में सक्षम होने चाहिए। यानी make।
हम पहले make कमांड के आउटपुट को कैप्चर करते हैं, इस आउटपुट से हम सटीक संकलन कमांड निकालते हैं।
make का आउटपुट उत्पन्न करनाbear make <make के सभी विकल्प>
bear make -j8यह वर्तमान निर्देशिका में एक फ़ाइल compile_commands.json उत्पन्न करेगा।
बस V=1 पास करें और आउटपुट को फ़ाइल में रीडायरेक्ट करें।
उदाहरण:
make V=1 O=out ARCH=arm64 > makeout.txt 2>&1
नोट: एकाधिक प्रक्रियाओं का उपयोग न करें यानी -j। मल्टी-प्रोसेसिंग मोड में चलाने से आउटपुट फ़ाइल गड़बड़ हो जाएगी क्योंकि कई प्रक्रियाएँ आउटपुट फ़ाइल में लिखने का प्रयास करती हैं।
बस इतना ही। इसके बाद, अगले चरण में हमारी स्क्रिप्ट उत्पन्न makeout.txt लेती है और सभी पहचाने गए ड्राइवरों पर इंटरफ़ेस रिकवरी चलाती है।
इंटरफ़ेस रिकवरी के सभी विभिन्न चरण एक स्क्रिप्ट helper_scripts/run_all.py में लिपटे हुए हैं।
कैसे चलाएँ:
cd helper_scripts
python run_all.py --help
usage: run_all.py [-h] [-l LLVM_BC_OUT] [-a CHIPSET_NUM] [-m MAKEOUT]
[-c COMPJSON] [-g COMPILER_NAME] [-n ARCH_NUM] [-o OUT]
[-k KERNEL_SRC_DIR] [-isclang] [-clangp CLANG_PATH]
[-llvmlinkp LLVMLINK_PATH] [-skb] [-skl] [-skp] [-skP]
[-ske] [-skI] [-ski] [-skv] [-skd] [-f IOCTL_FINDER_OUT]
optional arguments:
-h, --help show this help message and exit
-l LLVM_BC_OUT Destination directory where all the generated bitcode
files should be stored.
-a CHIPSET_NUM Chipset number. Valid chipset numbers are:
1(mediatek)|2(qualcomm)|3(huawei)|4(samsung)
-m MAKEOUT Path to the makeout.txt file.
-c COMPJSON Path to the compile_commands_json generated by Bear.
-g COMPILER_NAME Name of the compiler used in the makeout.txt, This is
needed to filter out compilation commands. Ex: aarch64
-linux-android-gcc
-n ARCH_NUM Destination architecture, 32 bit (1) or 64 bit (2).
-o OUT Path to the out folder. This is the folder, which
could be used as output directory during compiling
some kernels.
-k KERNEL_SRC_DIR Base directory of the kernel sources.
-isclang flag to indicate that clang was used to built the
kernel
-clangp CLANG_PATH Absolute path to the clang binary (if not provided,
the one available in the path will be used)
-llvmlinkp LLVMLINK_PATH
Absolute path to the llvm-link binary (if not
provided, the one available in the path will be used)
-skb Skip LLVM Build (default: not skipped).
-skl Skip Dr Linker (default: not skipped).
-skp Skip Parsing Headers (default: not skipped).
-skP Skip Generating Preprocessed files (default: not
skipped).
-ske Skip Entry point identification (default: not
skipped).
-skI Skip Generate Includes (default: not skipped).
-ski Skip IoctlCmdParser run (default: not skipped).
-skv Skip V4L2 ioctl processing (default: not skipped).
-skd Skip Device name finder (default: not skipped).
-f IOCTL_FINDER_OUT Path to the output folder where the ioctl command
finder output should be stored.
यह स्क्रिप्ट सभी पहचाने गए ड्राइवरों पर इंटरफ़ेस रिकवरी बनाती, लिंक करती और चलाती है, जिसमें काफी समय (45 मिनट-90 मिनट) लग सकता है।
उपरोक्त स्क्रिप्ट सभी CPU कोर का उपयोग करने के लिए मल्टीप्रोसेसर मोड में निम्नलिखित कार्य करती है:
उत्पन्न सभी बिटकोड फ़ाइलों को -l तर्क को दिए गए फ़ोल्डर में रखा जाएगा।
यह चरण आपके पास मौजूद कोर की संख्या के आधार पर काफी समय लेता है।
इसलिए, यदि आप पहले ही यह चरण कर चुके हैं, तो आप -skb पास करके इस चरण को छोड़ सकते हैं।
यह लिंकिंग करता है, यह सभी बिटकोड फ़ाइलों के माध्यम से जाता है और संबंधित बिटकोड फ़ाइलों की पहचान करता है जिन्हें लिंक करने की आवश्यकता होती है और उन्हें (llvm-link का उपयोग करके) एक समेकित बिटकोड फ़ाइल में लिंक करता है (जो संबंधित बिटकोड फ़ाइल के साथ संग्रहीत की जाएगी)।
उपरोक्त चरण के समान, आप -skl पास करके इस चरण को छोड़ सकते हैं।
यह चरण हेडर फ़ाइलों में प्रवेश बिंदु घोषणाओं की तलाश करता है और उनके कॉन्फ़िगरेशन को LLVM बिल्ड निर्देशिका के अंतर्गत फ़ाइल hdr_file_config.txt में संग्रहीत करता है।
छोड़ने के लिए: -skp
यह चरण सभी ड्राइवर समेकित बिटकोड फ़ाइलों में सभी प्रवेश बिंदुओं की पहचान करता है।
आउटपुट LLVM बिल्ड निर्देशिका के अंतर्गत फ़ाइल entry_point_out.txt में संग्रहीत किया जाएगा।
फ़ाइल entry_point_out.txt की सामग्री का उदाहरण:
IOCTL:msm_lsm_ioctl:/home/difuze/kernels/pixel/msm/sound/soc/msm/qdsp6v2/msm-lsm-client.c:msm_lsm_ioctl.txt:/home/difuze/pixel/llvm_out/sound/soc/msm/qdsp6v2/llvm_link_final/final_to_check.bc
IOCTL:msm_pcm_ioctl:/home/difuze/kernels/pixel/msm/sound/soc/msm/qdsp6v2/msm-pcm-lpa-v2.c:msm_pcm_ioctl.txt:/home/difuze/pixel/llvm_out/sound/soc/msm/qdsp6v2/llvm_link_final/final_to_check.bc
छोड़ने के लिए: -ske
यह चरण फ़ाइल entry_point_out.txt में सभी प्रवेश बिंदुओं पर मुख्य इंटरफ़ेस रिकवरी घटक (IoctlCmdParser) चलाएगा। प्रत्येक प्रवेश बिंदु के लिए आउटपुट -f विकल्प के लिए दिए गए फ़ोल्डर में संग्रहीत किया जाएगा।
छोड़ने के लिए: -ski
अब, हम उस बिंदु से एक उदाहरण दिखाएंगे जहाँ आपके पास कर्नेल स्रोत हैं और इंटरफ़ेस रिकवरी परिणाम प्राप्त करने के बिंदु तक।
हमने एक mediatek कर्नेल 33.2.A.3.123.tar.bz2 अपलोड किया है। पहले उपरोक्त फ़ाइल को डाउनलोड और निकालें।
मान लें कि आपने उपरोक्त फ़ाइल को ~/mediatek_kernel नामक फ़ोल्डर में निकाला है।
Bear स्थापित करें और नीचे दिए गए चरणों का पालन करें:
cd ~/mediatek_kernel
source ./env.sh
cd kernel-3.18
# कर्नेल के आधार पर निम्नलिखित चरण की आवश्यकता नहीं हो सकती है
mkdir out
make O=out ARCH=arm64 tubads_defconfig
# compile_commands.json उत्पन्न करना
bear make -j8 O=out ARCH=arm64
cd <repo_path>/helper_scripts
python run_all.py -l ~/mediatek_kernel/llvm_bitcode_out -a 1 -c ~/mediatek_kernel/kernel-3.18/compile_commands.json -n 2 -o ~/mediatek_kernel/kernel-3.18/out -k ~/mediatek_kernel/kernel-3.18 -f ~/mediatek_kernel/ioctl_finder_out
उपरोक्त कमांड में काफी समय (30 मिनट - 1 घंटा) लगता है।
सबसे पहले, सभी विश्लेषण परिणाम फ़ोल्डर में होंगे: ~/mediatek_kernel/ioctl_finder_out (-f विकल्प को दिया गया तर्क), प्रत्येक प्रवेश बिंदु के लिए एक .txt फ़ाइल बनाई जाएगी, जिसमें पुनर्प्राप्त इंटरफ़ेस के बारे में सभी जानकारी होगी।
यदि आप केवल इंटरफ़ेस के बारे में जानकारी में रुचि रखते हैं और किसी और चीज़ की परवाह नहीं करते हैं, तो हम अनुशंसा करते हैं कि आप parse_interface_output.py स्क्रिप्ट का उपयोग करें। यह स्क्रिप्ट इंटरफ़ेस रिकवरी पास के पागल आउटपुट को एक साफ और सुसंगत प्रारूप के साथ अच्छी json फ़ाइलों में परिवर्तित करती है।
cd <repo_path>/helper_scripts
python parse_interface_output.py <ioctl_finder_out_dir> <output_directory_for_json_files>
यहाँ <ioctl_finder_out_dir> वही फ़ोल्डर होना चाहिए जो आपने -f विकल्प को दिया था और <output_directory_for_json_files> वह फ़ोल्डर है जहाँ json फ़ाइलें बनाई जानी चाहिए।
आप संबंधित ioctl के इंटरफ़ेस रिकवरी के लिए संबंधित json फ़ाइलों का उपयोग कर सकते हैं।
-g का मान (केवल यदि आप makeout.txt का उपयोग करते हैं)विकल्प -g के लिए मान प्रदान करने के लिए आपको कर्नेल को संकलित करने के लिए उपयोग किए जाने वाले *-gcc बाइनरी का नाम जानना होगा।
यह जानने का एक आसान तरीका makeout.txt में gcc के लिए grep करना होगा और आप कंपाइलर कमांड देखेंगे जिनसे आप *-gcc बाइनरी नाम जान सकते हैं।
हमारे ऊपर के उदाहरण के लिए, यदि आप उदाहरण बिल्ड के लिए grep gcc makeout.txt करते हैं, तो आपको नीचे जैसी कई पंक्तियाँ दिखाई देंगी:
aarch64-linux-android-gcc -Wp,-MD,fs/jbd2/.transaction.o.d -nostdinc -isystem ...
इसलिए, -g का मान aarch64-linux-android-gcc होना चाहिए।
यदि बनाया जाने वाला कर्नेल 32-बिट है, तो बाइनरी सबसे अधिक संभावना arm-eabi-gcc होगी।
Qualcomm (या msm) चिपसेट के लिए, आप *.gcc के बजाय *gcc-wrapper.py देख सकते हैं, ऐसी स्थिति में आपको *gcc-wrapper.py प्रदान करना चाहिए।
-a का मानचिपसेट प्रकार के आधार पर, आपको संबंधित संख्या प्रदान करनी होगी।
-o का मानयह कर्नेल बिल्ड के दौरान make कमांड के लिए O= विकल्प को दिए गए फ़ोल्डर का पथ है।
सभी कर्नेल को अलग आउट पथ की आवश्यकता नहीं होती है। आप O विकल्प प्रदान न करके कर्नेल बना सकते हैं, ऐसी स्थिति में आपको run_all.py चलाते समय उस विकल्प के लिए मान प्रदान नहीं करना चाहिए।
clang का उपयोग करके बनाए गए कर्नेल के लिए, उपरोक्त विकल्पों के अतिरिक्त कृपया निम्नलिखित विकल्प निर्दिष्ट करें (मान लें कि आपने compile_commands.json का उपयोग किया है):
-isclang -clangp <कर्नेल बनाने के लिए उपयोग किए गए CLANG का पथ> -llvmlinkp <LLVM_LINK का पथ (clang के समान फ़ोल्डर में होगा)>
फ़ज़िंग शुरू करने से पहले हमें अपने बहुत ही शोध-गुणवत्ता वाले (क्षमा करें) पार्सर के साथ आउटपुट को थोड़ा संसाधित करने की आवश्यकता है।
ये यहाँ पाए जाते हैं। चलाने के लिए मुख्य स्क्रिप्ट run_all.py होगी:
$ python run_all.py --help
usage: run_all.py [-h] -f F -o O [-n {manual,auto,hybrid}] [-m M]
run_all options
optional arguments:
-h, --help show this help message and exit
-f F Filename of the ioctl analysis output OR the entire
output directory created by the system
-o O Output directory to store the results. If this
directory does not exist it will be created
-n {manual,auto,hybrid}
Specify devname options. You can choose manual
(specify every name manually), auto (skip anything that
we don't identify a name for), or hybrid (if we
detected a name, we use it, else we ask the user)
-m M Enable multi-device output most ioctls only have one
applicable device node, but some may have multiple. (0
to disable)
आप -f को ioctl विश्लेषण के आउटपुट निर्देशिका के रूप में पास करना चाहेंगे, उदाहरण के लिए ~/mediatek_kernel/ioctl_finder_out।
-o वह स्थान है जहाँ आप पोस्ट-प्रोसेस्ड परिणामों को संग्रहीत करना चाहते हैं। ये आसानी से पचने योग्य XML फ़ाइलें (jpits) होंगी।
-n सिस्टम को निर्दिष्ट करता है कि आप किस हद तक हमारे डिवाइस नाम पुनर्प्राप्ति पर भरोसा करना चाहते हैं।
यदि आप कोई काम/नाम खोज नहीं करना चाहते हैं, तो आप auto निर्दिष्ट कर सकते हैं।
बेशक यह उस डिवाइस को छोड़ने की कीमत पर आता है जिसके लिए हम नाम पुनर्प्राप्त नहीं करते हैं। यदि आप पागल होना चाहते हैं और हमारे किसी भी पुनर्प्राप्ति प्रयास पर भरोसा नहीं करना चाहते हैं (पूरी तरह से उचित) तो आप प्रत्येक डिवाइस को स्वयं नाम देने के लिए manual विकल्प का उपयोग कर सकते हैं।
hybrid तब दोनों का एक संयोजन है - हम आपके लिए डिवाइस का नाम देंगे जब हम कर सकते हैं, और जब हम असफल होते हैं तो आप पर वापस आ जाते हैं।
-m कभी-कभी ioctl एक से अधिक डिवाइस के अनुरूप हो सकते हैं (उदाहरण के लिए v4l2/subdev ioctls के साथ यह आम है)। इसके लिए समर्थन डिफ़ॉल्ट रूप से सक्षम है, लेकिन प्रत्येक डिवाइस के लिए उपकरणों की संख्या निर्दिष्ट करने के लिए उपयोगकर्ता इंटरैक्शन की आवश्यकता होती है। यदि यह आपके लिए बहुत कष्टप्रद है, तो आप -m 0 पास करके संकेत को अक्षम कर सकते हैं (हम प्रत्येक ioctl के लिए एक एकल डिवाइस मान लेंगे)।
चलाने के बाद, आपके पास, आपके आउट फ़ोल्डर में, प्रत्येक ioctl के लिए एक फ़ोल्डर होना चाहिए।
MangoFuzz हमारा सरल प्रोटोटाइप फ़ज़र है और यह Peach (विशेष रूप से MozPeach) पर आधारित है।
यह विशेष रूप से परिष्कृत फ़ज़र नहीं है लेकिन यह बग ढूंढता है। इसे आसानी से विस्तार योग्य बनाने के लिए भी बनाया गया था। इस फ़ज़र के 2 घटक हैं, फ़ज़ इंजन और निष्पादक। निष्पादक यहाँ पाया जा सकता है, और फ़ज़ इंजन यहाँ पाया जा सकता है।
निष्पादक फ़ोन पर चलता है, फ़ज़ इंजन द्वारा भेजे जाने वाले डेटा को सुनता है।
बस इसे अपने फ़ोन की आर्किटेक्चर के लिए संकलित करें, इसे adb push करके फ़ोन पर डालें, और उस पोर्ट के साथ निष्पादित करें जिस पर आप इसे सुनना चाहते हैं!
MangoFuzz के साथ इंटरफ़ेस करना काफी सरल है। आपको एक Engine ऑब्जेक्ट और एक Parser ऑब्जेक्ट की आवश्यकता होगी, जिसमें आप अपने इंजन को फ़ीड करेंगे।
यहाँ से, आप अपने Parser के साथ jpits को पार्स करते हैं, और फिर Engine चलाते हैं। आसान!
हमने आपको शुरू करने के लिए कुछ सरल रन स्क्रिप्ट प्रदान की हैं।
विशिष्ट ड्राइवरों के विरुद्ध चलाने के लिए आप आउटपुट निर्देशिका में ioctl फ़ोल्डरों में से किसी एक पर runner.py का उपयोग कर सकते हैं (हमारे पोस्ट प्रोसेसिंग स्क्रिप्ट द्वारा बनाई गई)।
उदाहरण के लिए ./runner.py -f honor8/out/chb -num 1000। यह MangoFuzz को chb ioctl/ड्राइवर से संबंधित सभी ioctl कमांड वैल्यू जोड़े के विरुद्ध 1000 पुनरावृत्तियों के लिए चलाने का निर्देश देता है।
यदि इसके बजाय हम पूरे डिवाइस (फ़ोन) के विरुद्ध चलाना चाहते हैं, तो आप dev_runner.py का उपयोग कर सकते हैं। उदाहरण के लिए ./dev_runner.py -f honor8/out -num 100।
यह ड्राइवर फ़ाइलों पर लूप करना जारी रखेगा, प्रत्येक 100 पुनरावृत्तियों के लिए उनके बीच यादृच्छिक रूप से स्विच करेगा।
ध्यान दें कि फ़ज़ इंजन फ़ोन के साथ संचार करने से पहले, आपको ADB का उपयोग करके पोर्ट फ़ॉरवर्डिंग सेट अप करने की आवश्यकता होगी, उदाहरण के लिए adb forward tcp:2022 tcp:2022।