पिछले भाग में, मैंने मोटे तौर पर वर्णन किया था कि आप एक ईएलएफ फ़ाइल से ईजीपीएफ कार्यों को कैसे लोड कर सकते हैं। अब फंतासी से सोवियत कार्टूनों में जाने का समय है, और बुद्धिमान सलाह का पालन करते हुए, एक बार एक निश्चित मात्रा में प्रयास करने के बाद, एक सार्वभौमिक साधन उपकरण बनाएं (या, संक्षेप में, UII !!!) । ऐसा करने में, मैं गोल्डन हैमर एंटीपैटर डिजाइन का लाभ उठाऊंगा और अपेक्षाकृत परिचित QEMU से एक उपकरण का निर्माण करूंगा। इसके लिए एक बोनस के रूप में, हमें क्रॉस-आर्किटेक्चरल इंस्ट्रूमेंटेशन, साथ ही पूरे वर्चुअल कंप्यूटर के स्तर पर इंस्ट्रूमेंटेशन मिलता है। इंस्ट्रूमेंटेशन "एक छोटा देशी सो-फाइल + एक छोटी .o- फाइल ईपीपीएफ के साथ" होगा। इस मामले में, अनुकूलन और कोड पीढ़ी से पहले QEMU के आंतरिक प्रतिनिधित्व के संबंधित निर्देशों से पहले eBPF फ़ंक्शन प्रतिस्थापित किया जाएगा।

नतीजतन, इंस्ट्रूमेंटेशन ही, जो कोड जेनरेशन के दौरान जोड़ा जाता है (यानी, सामान्य सिस्टम रनटाइम के कुछ किलोबाइट की गिनती नहीं), ऐसा दिखता है, और यह एक छद्म कोड नहीं है:

#include <stdint.h> extern uint8_t *__afl_area_ptr; extern uint64_t prev; void inst_qemu_brcond_i64(uint64_t tag, uint64_t x, uint64_t y, uint64_t z, uint64_t u) { __afl_area_ptr[((prev >> 1) ^ tag) & 0xFFFF] += 1; prev = tag; } void inst_qemu_brcond_i32(uint64_t tag, uint64_t x, uint64_t y, uint64_t z, uint64_t u) { __afl_area_ptr[((prev >> 1) ^ tag) & 0xFFFF] += 1; prev = tag; } 

खैर, यह हमारे योगिनी को मैट्रिक्स में लोड करने का समय है। खैर, डाउनलोड कैसे करें, बल्कि vmazat स्प्रे।

जैसा कि QEMU.js के बारे में लेख में पहले ही उल्लेख किया गया है, QEMU संचालन मोड में से एक अतिथि से मशीन कोड की जेआईटी पीढ़ी है (संभवतः, एक पूरी तरह से अलग वास्तुकला के लिए)। अगर पिछली बार मैंने अपनी कोड जनरेशन बैकएंड को लागू किया था, तो इस बार मैं ऑप्टिमाइज़र के सामने राइट वेजिंग करके आंतरिक प्रतिनिधित्व को प्रोसेस करने जा रहा हूं। क्या यह एक मनमाना फैसला है? नहीं। एक आशा है कि आशावादी अतिरिक्त कोनों को काट देगा, अनावश्यक चर बाहर फेंक देगा, आदि। जहां तक ​​मैं समझता हूं, वह, वास्तव में, सरल और जल्दी से करने योग्य चीजें करता है: स्थिरांक को धक्का देना, "x: = x + 0" जैसे भावों को बाहर फेंकना और अगम्य कोड को हटाना। और हम इसे एक सभ्य राशि प्राप्त कर सकते हैं।

विधानसभा स्क्रिप्ट विन्यास

सबसे पहले, आइए हमारी स्रोत फाइलें जोड़ें: tcg/bpf-loader.c और tcg/instrument.c Makefiles में। सामान्यतया, किसी दिन इसे ऊपर की ओर धकेलने की इच्छा होती है, इसलिए आपको इसे अंत में समझदारी से करने की आवश्यकता होगी, लेकिन अब मैं बस बिना शर्त इन फाइलों को विधानसभा में जोड़ दूंगा। और मैं AFL की सबसे अच्छी परंपराओं में पैरामीटर ले जाऊंगा - पर्यावरण चर के माध्यम से। वैसे, मैं एएफएल के लिए इंस्ट्रूमेंटेशन पर फिर से इसका परीक्षण करूंगा।

बस "पड़ोसी" के उल्लेख के लिए देखें - optimize.c grep -R साथ फ़ाइल और हमें कुछ भी नहीं मिलेगा। क्योंकि यह optimize.o करने के लिए खोजना आवश्यक था।

 --- a/Makefile.target +++ b/Makefile.target @@ -110,7 +110,7 @@ obj-y += trace/ obj-y += exec.o obj-y += accel/ obj-$(CONFIG_TCG) += tcg/tcg.o tcg/tcg-op.o tcg/tcg-op-vec.o tcg/tcg-op-gvec.o -obj-$(CONFIG_TCG) += tcg/tcg-common.o tcg/optimize.o +obj-$(CONFIG_TCG) += tcg/tcg-common.o tcg/optimize.o tcg/instrument.o tcg/bpf-loader.o obj-$(CONFIG_TCG_INTERPRETER) += tcg/tci.o obj-$(CONFIG_TCG_INTERPRETER) += disas/tci.o obj-$(CONFIG_TCG) += fpu/softfloat.o 

तो यहाँ आप कर रहे हैं, सी में metaprogramming ...

सबसे पहले, पिछली श्रृंखला के bpf-loader.c को कोड के साथ जोड़ते हैं जो QEMU परिचालनों के अनुरूप प्रवेश बिंदु खींचती है। और रहस्यमय tcg-opc.h फ़ाइल हमें इसमें मदद करेगी। यह इस तरह दिखता है:

 /* * DEF(name, oargs, iargs, cargs, flags) */ /* predefined ops */ DEF(discard, 1, 0, 0, TCG_OPF_NOT_PRESENT) DEF(set_label, 0, 0, 1, TCG_OPF_BB_END | TCG_OPF_NOT_PRESENT) /* variable number of parameters */ DEF(call, 0, 0, 3, TCG_OPF_CALL_CLOBBER | TCG_OPF_NOT_PRESENT) DEF(br, 0, 0, 1, TCG_OPF_BB_END) // ... 

क्या बकवास है? और बात बस यह है कि यह स्रोत हेडर में जुड़ा नहीं है - आपको DEF मैक्रो को परिभाषित करने की आवश्यकता है, इस फाइल को शामिल करें, और तुरंत मैक्रो को हटा दें। देखिए, उसके पास गार्ड भी नहीं है।

 static const char *inst_function_names[] = { #define DEF(name, a, b, c, d) stringify(inst_qemu_##name), #include "tcg-opc.h" #undef DEF NULL }; 

नतीजतन, हमें ओपकोड द्वारा अनुक्रमित और NULL के साथ समाप्त होने वाले लक्ष्य फ़ंक्शन नामों का एक साफ़ सरणी मिलता है, जिसे हम फ़ाइल में प्रत्येक वर्ण के लिए चला सकते हैं। मैं समझता हूं कि यह प्रभावी नहीं है। लेकिन यह सरल है, जो महत्वपूर्ण है, इस ऑपरेशन की एकमुश्त प्रकृति को देखते हुए। अगला, हम सिर्फ सभी वर्णों को छोड़ते हैं जिसके लिए

 ELF64_ST_BIND(sym->st_info) == STB_LOCAL || ELF64_ST_TYPE(sym->st_info) != STT_FUNC 

बाकी सूची के खिलाफ जाँच की है।

हम निष्पादन के प्रवाह से जुड़े हैं

अब आपको कोड पीढ़ी तंत्र के प्रवाह पर कहीं उठने की जरूरत है, और जब तक ब्याज का निर्देश पारित नहीं होता तब तक प्रतीक्षा करें। लेकिन सबसे पहले आपको tcg/tcg.h में अपने instrumentation_init , tcg_instrument और instrumentation_shutdown फ़ंक्शन को परिभाषित करना tcg_instrument और उनकी कॉल को लिखना होगा: आरंभीकरण - बैकएंड के आरंभ होने के बाद, इंस्ट्रूमेंटेशन - tcg_optimize कॉल से ठीक पहले। ऐसा लगेगा कि instrumentation_shutdown को instrumentation_shutdown जा सकता है। मैंने ऐसा भी सोचा था, और सबसे अधिक संभावना है कि यह पूर्ण सिस्टम इम्यूलेशन मोड में काम करेगा, लेकिन exit_group इम्यूलेशन मोड में QEMU, exit_group सिस्टम कॉल्स का अनुवाद करता है और कभी-कभी _exit फंक्शन कॉल में exit जाता है, जो इन सभी _exit -हैंडलर को अनदेखा करता है, इसलिए, हम linux-user/syscall.c में इसे linux-user/syscall.c और इसके सामने हमारे कोड पर कॉल linux-user/syscall.c ।

बिटरटेक की व्याख्या करना

इसलिए यह पढ़ने का समय है कि हमारे लिए संकलक क्या उत्पन्न करता है। यह आसानी से -x विकल्प, या बेहतर, तुरंत -d -t -r साथ llvm-objdump का उपयोग करके किया जाता है।

 $ ./compile-bpf.sh test-bpf.o: file format ELF64-BPF Disassembly of section .text: 0000000000000000 inst_brcond_i64: 0: 18 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r2 = 0 ll 0000000000000000: R_BPF_64_64 prev 2: 79 23 00 00 00 00 00 00 r3 = *(u64 *)(r2 + 0) 3: 77 03 00 00 01 00 00 00 r3 >>= 1 4: 7b 32 00 00 00 00 00 00 *(u64 *)(r2 + 0) = r3 5: af 13 00 00 00 00 00 00 r3 ^= r1 6: 57 03 00 00 ff ff 00 00 r3 &= 65535 7: 18 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r4 = 0 ll 0000000000000038: R_BPF_64_64 __afl_area_ptr 9: 79 44 00 00 00 00 00 00 r4 = *(u64 *)(r4 + 0) 10: 0f 34 00 00 00 00 00 00 r4 += r3 11: 71 43 00 00 00 00 00 00 r3 = *(u8 *)(r4 + 0) 12: 07 03 00 00 01 00 00 00 r3 += 1 13: 73 34 00 00 00 00 00 00 *(u8 *)(r4 + 0) = r3 14: 7b 12 00 00 00 00 00 00 *(u64 *)(r2 + 0) = r1 15: 95 00 00 00 00 00 00 00 exit 0000000000000080 inst_brcond_i32: 16: 18 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r2 = 0 ll 0000000000000080: R_BPF_64_64 prev 18: 79 23 00 00 00 00 00 00 r3 = *(u64 *)(r2 + 0) 19: 77 03 00 00 01 00 00 00 r3 >>= 1 20: 7b 32 00 00 00 00 00 00 *(u64 *)(r2 + 0) = r3 21: af 13 00 00 00 00 00 00 r3 ^= r1 22: 57 03 00 00 ff ff 00 00 r3 &= 65535 23: 18 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r4 = 0 ll 00000000000000b8: R_BPF_64_64 __afl_area_ptr 25: 79 44 00 00 00 00 00 00 r4 = *(u64 *)(r4 + 0) 26: 0f 34 00 00 00 00 00 00 r4 += r3 27: 71 43 00 00 00 00 00 00 r3 = *(u8 *)(r4 + 0) 28: 07 03 00 00 01 00 00 00 r3 += 1 29: 73 34 00 00 00 00 00 00 *(u8 *)(r4 + 0) = r3 30: 7b 12 00 00 00 00 00 00 *(u64 *)(r2 + 0) = r1 31: 95 00 00 00 00 00 00 00 exit SYMBOL TABLE: 0000000000000000 l df *ABS* 00000000 test-bpf.c 0000000000000000 ld .text 00000000 .text 0000000000000000 *UND* 00000000 __afl_area_ptr 0000000000000080 g F .text 00000080 inst_brcond_i32 0000000000000000 g F .text 00000080 inst_brcond_i64 0000000000000008 g O *COM* 00000008 prev 

यदि आप eBPF ऑपकोड के विवरण को देखने की कोशिश करते हैं, तो यह पता चला है कि स्पष्ट स्थानों (लिनक्स कर्नेल के स्रोत और मैन-पेज) में इसका उपयोग करने, कैसे संकलित करने, आदि का वर्णन है। फिर आप एक सुविधाजनक अनौपचारिक eBPF संदर्भ के साथ iovisor टूल टीम पेज पर आते हैं।

निर्देश एक 64-बिट शब्द (कुछ दो) पर कब्जा कर लेता है और इसका रूप होता है

 struct { uint8_t opcode; uint8_t dst:4; uint8_t src:4; uint16_t offset; uint32_t imm; }; 

जो लोग दो शब्दों पर कब्जा कर लेते हैं, उनमें सभी तर्क के साथ पहला निर्देश होता है और तत्काल मूल्य के 32 और बिट्स के साथ एक "ट्रेलर" होता है और objdump disassembler पर बहुत स्पष्ट रूप से दिखाई देता है।

स्वयं ऑपकोड में भी एक नियमित संरचना होती है: निचले तीन बिट्स ऑपरेशन क्लास होते हैं: 32-बिट ALU, 64-बिट ALU, लोड / स्टोर, सशर्त शाखा। इसलिए, उन्हें QEMU की सर्वश्रेष्ठ परंपराओं में मैक्रोज़ पर लागू करना बहुत सुविधाजनक है। मैं कोड आधार पर विस्तृत निर्देश का संचालन नहीं करूंगा हम कोड की समीक्षा पर नहीं हैं मैं आपको नुकसान के बारे में बेहतर बताता हूं।

मेरी पहली समस्या यह थी कि मैंने QEMU- local_temp के रूप में एक आलसी ईजीपीएफ रजिस्टर आवंटनकर्ता local_temp , और इस फ़ंक्शन के कॉल को मैक्रो में जानबूझकर स्थानांतरित करना शुरू कर दिया। यह एक प्रसिद्ध मेम की तरह निकला: "हमने एक अमूर्त में एक अमूर्त डाला ताकि आप एक अनुदेश उत्पन्न करते समय एक निर्देश उत्पन्न कर सकें।" तथ्य के बाद, मैं पहले से ही अच्छी तरह से समझ नहीं पाया कि तब क्या टूट गया था, लेकिन कुछ अजीब रूप से उत्पन्न निर्देशों के आदेश के साथ स्पष्ट रूप से हो रहा था। उसके बाद, मैंने tcg_gen_... फ़ंक्शन के बीच में नए निर्देशों को आगे बढ़ाने के लिए फ़ंक्शन के तर्कों के रूप में ऑपरेंड ले रहे हैं, और स्वचालित रूप से जैसा कि यह होना चाहिए (चूंकि कॉल से पहले तर्क पूरी तरह से गणना की जाती है) के रूप में क्रम बन गया।

दूसरी समस्या बर्खास्तगी के निर्देश के रूप में TCG कास्ट को धक्का देने की कोशिश कर रही थी जब eBPF में तत्काल ऑपरेंड को देखते हुए। पहले से ही उल्लेख किए गए tcg-opc.h , ऑपरेशन की तर्क सूची की संरचना सख्ती से तय की गई है: n इनपुट तर्क, m आउटपुट और k स्थिरांक। वैसे, इस तरह के कोड को डीबग करते समय, यह QEMU को कमांड लाइन तर्क -d op,op_opt या even -d op,op_opt,out_asm पास करने में मदद करता है।

 $ ./x86_64-linux-user/qemu-x86_64 -d help Log items (comma separated): out_asm show generated host assembly code for each compiled TB in_asm show target assembly code for each compiled TB op show micro ops for each compiled TB op_opt show micro ops after optimization op_ind show micro ops before indirect lowering int show interrupts/exceptions in short format exec show trace before each executed TB (lots of logs) cpu show CPU registers before entering a TB (lots of logs) fpu include FPU registers in the 'cpu' logging mmu log MMU-related activities pcall x86 only: show protected mode far calls/returns/exceptions cpu_reset show CPU state before CPU resets unimp log unimplemented functionality guest_errors log when the guest OS does something invalid (eg accessing a non-existent register) page dump pages at beginning of user mode emulation nochain do not chain compiled TBs so that "exec" and "cpu" show complete traces trace:PATTERN enable trace events Use "-d trace:help" to get a list of trace events. 

ठीक है, मेरी गलतियों को न दोहराएं: आंतरिक निर्देश add_i64 loc15,loc15,$554412123213 काफी उन्नत है, और यदि आप इसमें कुछ भी add_i64 loc15,loc15,$554412123213 जैसे देखते हैं, तो डॉलर के संकेत के बाद यह बात कोई सूचक नहीं है। अधिक सटीक रूप से, यह, निश्चित रूप से, एक सूचक है, लेकिन शायद झंडे के साथ लटका दिया गया है और ऑपरेटर के शाब्दिक मूल्य की भूमिका में है, और सूचक नहीं। यह सब निश्चित रूप से लागू होता है, यदि आप जानते हैं कि कुछ विशिष्ट संख्या होनी चाहिए, जैसे $0 या $ff , तो आपको पॉइंटर्स से बिल्कुल भी डरना नहीं चाहिए। :) इससे कैसे movi - आपको बस एक फंक्शन बनाने की ज़रूरत है जो एक ताजा temp रिटर्न देता है, जिसमें movi माध्यम से movi वांछित स्थिरांक रखता है।

वैसे, यदि आप tcg/tcg.c #define USE_TCG_OPTIMIZATIONS में #define USE_TCG_OPTIMIZATIONS टिप्पणी करते हैं, तो, अचानक, अनुकूलन बंद हो जाएगा और कोड परिवर्तनों का विश्लेषण करना आसान हो जाएगा।

सिम के लिए, मैं QEMU को प्रलेखन में रुचि रखने वाले एक पाठक को भेजूंगा, यहां तक ​​कि आधिकारिक एक भी! बाकी के लिए, मैं AFL के लिए वादा किए गए इंस्ट्रूमेंटेशन का प्रदर्शन करूंगा।

वही और खरगोश

रनटाइम के पूरे पाठ के लिए, मैं, फिर से, पाठक को रिपॉजिटरी में भेजूंगा, क्योंकि यह (पाठ) कलात्मक मूल्य का नहीं है और ईमानदारी से AFL डिलीवरी से qemu_mode से कठोर है, और सामान्य तौर पर, सी कोड का एक नियमित टुकड़ा है। लेकिन यहां बताया गया है कि इंस्ट्रूमेंटेशन कैसे दिखता है। :

 #include <stdint.h> extern uint8_t *__afl_area_ptr; extern uint64_t prev; void inst_qemu_brcond_i64(uint64_t tag, uint64_t x, uint64_t y, uint64_t z, uint64_t u) { __afl_area_ptr[((prev >> 1) ^ tag) & 0xFFFF] += 1; prev = tag; } void inst_qemu_brcond_i32(uint64_t tag, uint64_t x, uint64_t y, uint64_t z, uint64_t u) { __afl_area_ptr[((prev >> 1) ^ tag) & 0xFFFF] += 1; prev = tag; } 

यह महत्वपूर्ण है कि हुक कार्यों में इसी QEMU ऑपरेशन के लिए iargs रूप में कई तर्क हैं। हेडर में दो extern को स्थानांतरण प्रक्रिया के दौरान रनटाइम से जोड़ा जाएगा। सिद्धांत रूप में, prev को यहीं परिभाषित किया जा सकता है, लेकिन तब इसे static रूप में परिभाषित करने की आवश्यकता होती है, अन्यथा यह COMMON सेक्शन में गिर जाएगा जिसका मैं समर्थन नहीं करता। दरअसल, हम, वास्तव में, प्रलेखन से छद्म कोड को फिर से लिखते हैं, लेकिन यहाँ यह मशीन-पठनीय है!

जाँच करने के लिए, bug.c फ़ाइल बनाएँ:

 #include <stdio.h> #include <unistd.h> #include <stdlib.h> int main(int argc, char *argv[]) { char buf[16]; int res = read(0, buf, 4); if (buf[0] == 'T' && buf[1] == 'E' && buf[2] == 'S' && buf[3] == 'T') abort(); return res * 0; } 

और यह भी - forksrv फ़ाइल, जो AFL को खिलाने के लिए सुविधाजनक है:

 #!/bin/bash export NATIVE_INST=./instrumentation-examples/afl/afl-native.so export BPF_INST=./instrumentation-examples/afl/afl-bpf.co exec ./x86_64-linux-user/qemu-x86_64 ./instrumentation-examples/afl/bug 

और फ़ज़िंग चलाएं:

 AFL_SKIP_BIN_CHECK=1 afl-fuzz -i ../input -o ../output -m none -- ./forksrv 

 1234 T234 TE34 TES4 TEST <-     crashes,    2200   

अब तक, गति इतनी गर्म नहीं है, लेकिन एक बहाने के रूप में मैं कहूंगा कि यहां (अभी के लिए) मूल qemu_mode की एक महत्वपूर्ण विशेषता का उपयोग नहीं किया गया है: कांटा सर्वर को निष्पादन योग्य कोड के पते भेजना। लेकिन अब क्यूईएमयू कोडबेस में एएफएल कुछ भी नहीं है, और उम्मीद है कि किसी दिन यह सामान्यीकृत इंस्ट्रूमेंटेशन अपस्ट्रीम में चरमरा जाएगा।

गिटहब परियोजना