👇🏻 ⌚️ 🌰 सिस्टम कॉल हैंडलर स्पूफिंग 🚣🏾 👩🏾‍🤝‍👩🏼 🐀

सभी को शुभ दिन! मैं एक तकनीकी विश्वविद्यालय का एक परिशिष्ट हूं। कुछ महीने पहले पाठ्यक्रम परियोजना के लिए एक विषय चुनने का समय था। कैलकुलेटर जैसे विषय मुझे सूट नहीं करते थे। इसलिए मैंने पूछा कि क्या कुछ और दिलचस्प था, और एक सकारात्मक जवाब मिला। "सिस्टम कॉल हैंडलर का प्रतिस्थापन" मेरा विषय है।

परिचय

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

क्यों?

मुख्य लक्ष्य, शायद, नेत्रहीन कार्य प्रणाली पर यह देखना है कि यह कैसे काम करता है, और शुष्क सिद्धांत को "काटने" के लिए नहीं। खैर, या पहले की तरह, प्रोग्रामर ने टाइमर इवेंट हैंडलर को ओवरराइड करके डॉस में "मल्टीटास्किंग" करने की कोशिश की।

32-बिट हैंडलर

कैसे संपर्क करें
इंटरनेट पर थोड़ी खोज की ( यह पोस्ट विशेष रूप से उपयोगी थी) और लिनक्स आर्किटेक्चर मैनुअल को "स्मोक्ड" किया, मैंने सी के लिए 32-बिट इंटरप्ट को प्रतिस्थापित करने का एक कार्यान्वयन पाया। सब कुछ मेरे विचार से आसान हो गया।

हम क्रम में विश्लेषण करेंगे।
सिस्टम कॉल (Eng। सिस्टम कॉल) - एप्लिकेशन किसी भी ऑपरेशन (विकी) को करने के लिए ऑपरेटिंग सिस्टम के कर्नेल को कॉल करता है। सिस्टम कॉल हैंडलर के पते सिस्टम कॉल टेबल (sys_call_table) में कर्नेल द्वारा संग्रहीत किए जाते हैं। इन पतों में से एक पर स्थित एक हैंडलर को हर बार कॉल किया जाता है, जब कोई प्रोग्राम 80x को कॉल करता है, जो ईरेक्स रजिस्टर में एक सिस्टम कॉल की संख्या के साथ होता है (उदाहरण के लिए, eax = 4 उस लिखने वाले सिस्टम कॉल के लिए जो फ़ाइल या आउटपुट डिवाइस पर लिखता है) । इस तालिका का पता और आपके द्वारा आवश्यक कॉल की संख्या को जानने के बाद, आप इसके हैंडलर को अपने कोड से बदल सकते हैं।

तो, एक 32-बिट बाधा के साथ पता लगा।

व्यवधान प्रतिस्थापन एल्गोरिथ्म अत्यंत सरल है:

सिस्टम कॉल टेबल (sys_call_table) के पते की तलाश करें
उस सिस्टम कॉल का पता देखें जिसकी हमें इसमें आवश्यकता है
इस पते के बजाय हमारे हैंडलर का पता लिखें

इस तरह के जोड़तोड़ के बाद, जब हम उस रुकावट को बुलाते हैं जिसे हमने बदल दिया है, तो हमारे हैंडलर को बुलाया जाएगा।
इसे लागू करने के लिए, हम एक कर्नेल मॉड्यूल लिखते हैं। मॉड्यूल क्यों? हां, सब कुछ सरल है, एक मॉड्यूल एक प्रोग्राम कोड है जिसे आवश्यकतानुसार मेमोरी से लोड या अनलोड किया जा सकता है। इस प्रकार, हम सिस्टम को रिबूट करने की आवश्यकता के बिना कर्नेल की कार्यक्षमता का विस्तार करेंगे। मॉड्यूल C में लिखा जाएगा।

कर्नेल मॉड्यूल का कंकाल:

static int init(void) { } static void exit(void) { } module_init(init); module_exit(exit);

मॉड्यूल, जैसा कि ऊपर से देखा जा सकता है, में कम से कम 2 फ़ंक्शन होने चाहिए - मेमोरी में मॉड्यूल इनिशियलाइज़ेशन फ़ंक्शन (जिसे मॉड्यूल को मेमोरी में लोड किया जाता है) और शटडाउन फ़ंक्शन (क्रमशः, जब मॉड्यूल अनलोड होता है)।
मुख्य कार्य जिसे हैंडलर को बदलने के लिए हल करने की आवश्यकता है, वह रैम में सिस्टम कॉल टेबल के स्थान का पता लगाना है। तालिका का पता "System.map-version_kernel" फ़ाइल में पाया जा सकता है। संकलित मॉड्यूल में पाया गया पता जोड़ें। पता खोजने के लिए, निम्नलिखित कमांड का उपयोग करें:

grep sys_call_table /boot/System.map-$(uname -r) |awk '{print $1}'

उदाहरण के लिए कमांड पाया गया पता दिखाता है:

c05d3180

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

महत्वपूर्ण विवरण! हैंडलर को प्रतिस्थापित करते समय, बाधित वैक्टर के क्षेत्र के लिए लेखन सुरक्षा को बायपास करना आवश्यक है। हम CR0 सिस्टम रजिस्टर के WP बिट को रीसेट करके ऐसा करते हैं। यह बिट हार्डवेयर स्तर पर कार्य करता है, अनुमति देता है (पर्याप्त विशेषाधिकार के साथ कोड के लिए) स्मृति पृष्ठों में संशोधन, भले ही वे उन्हें लिखने की अनुमति दें या नहीं। CR0 रजिस्टर को write_cr0 () और read_cr0 () मैक्रोज़ द्वारा एक्सेस किया जाता है।

मॉड्यूल सारांश कोड

 #include <linux/init.h> #include <linux/module.h> #include <linux/kernel.h> #include <linux/errno.h> #include <linux/types.h> #include <linux/unistd.h> #include <asm/cacheflush.h> #include <asm/page.h> #include <asm/current.h> #include <linux/sched.h> #include <linux/kallsyms.h> unsigned long *syscall_table = (unsigned long *)0xTABLE; // TABLE -     (    c05d3180) asmlinkage int (*original_write)(unsigned int, const char __user *, size_t); asmlinkage int new_write(unsigned int fd, const char __user *buf, size_t count) { //   write printk(KERN_ALERT "It works!\n"); return (*original_write)(fd, buf, count); } static int init(void) { printk(KERN_ALERT "Module init\n"); write_cr0 (read_cr0 () & (~ 0x10000)); //  WP  original_write = (void *)syscall_table[__NR_write];//     syscall_table[__NR_write] = new_write; //    write_cr0 (read_cr0 () | 0x10000); //  WP   return 0; } static void exit(void) { write_cr0 (read_cr0 () & (~ 0x10000)); //  WP  syscall_table[__NR_write] = original_write; //      write_cr0 (read_cr0 () | 0x10000); //  WP   printk(KERN_ALERT "Module exit\n"); return; } module_init(init); module_exit(exit);

64-बिट हैंडलर

पहला अंतर जो मैंने देखा, जब कमांड दर्ज कर रहा था

grep sys_call_table /boot/System.map-$(uname -r) |awk '{print $1}'

दो पते काटे गए:

ffffffff81801300
ffffffff81805260

टीम को थोड़ा बदलने के बाद, मुझे ऐसा परिणाम मिला

grep sys_call_table /boot/System.map-$(uname -r)

ffffffff81801300 R sys_call_table
ffffffff81805260 R ia32_sys_call_table

सब कुछ तुरंत स्पष्ट हो गया। 64-बिट आर्किटेक्चर में, 32-बिट एक के साथ संगतता के लिए, दो सिस्टम कॉल टेबल हैं। जैसा कि आप देख सकते हैं, एक 64-बिट कॉल के लिए है, और दूसरा 32-बिट कॉल के लिए है।
32-बिट आर्किटेक्चर में, __NR_write 4 था (जो समझ में आता है, राइट सिस्टम कॉल 4 नंबर पर है), और x64 में यह 1. है क्योंकि जब मैंने पहले 64-बिट असेंबलर के साथ काम नहीं किया था, तो मुझे तुरंत समझ नहीं आया कि क्या हो रहा है,। लेकिन तब उसे पता चला कि 64-बिट आर्किटेक्चर में sys_write नंबर 1 है।
वास्तव में, इस सारे अंतर पर, जो 64-बिट और 32-बिट लिखने में बाधा हैंडलर के बीच मेरी रुचि थी, मेरे लिए समाप्त हो गया।
चूंकि TK में कोडांतरक का उपयोग शामिल है, हम C में कर्नेल मॉड्यूल लिखेंगे, और कोडांतरक में इसके सभी कार्य।

शैल लिपि

 #!/bin/bash TABLE=$(grep ' sys_call_table' /boot/System.map-$(uname -r) |awk '{print $1}') echo $TABLE sed -is/TABLE/$TABLE/g module.c

कर्नेल मॉड्यूल

 #include <linux/init.h> #include <linux/module.h> unsigned long *syscall_table = (unsigned long *)0xTABLE; extern void change(unsigned long *temp); extern void unchange(unsigned long *temp); static int init(void) { printk(KERN_ALERT "\nModule init\n"); change(syscall_table); return 0; } static void cleanup(void) { unchange(syscall_table); printk(KERN_ALERT "Module exit\n"); } module_init(init); module_exit(cleanup);

सहायक मॉड्यूल

 global unlockWP global lockWP global change global unchange extern printk SECTION .text newwrite: mov rax, original ; original_write mov rax, QWORD[rax] ;  rdi - 4  fd call far rax ;  rsi - 8  buf ;  rdx - 8  count ;    push rax ;     xor rax, rax ;  rax mov rdi, work ;   "It works" call printk ;   printk pop rax ;   rax ,     ret change: call unlockWP ;   ; rdi -  add rdi, 8 ; rdi - syscall_table + __NR_write mov rax, QWORD [rdi] ; rax - syscall_table[__NR_write] mov rbx , original mov QWORD [rbx], rax ;     mov rax, newwrite ;       mov QWORD [rdi], rax ;    call lockWP ;   ret unchange: call unlockWP ;   ; rdi -  add rdi, 8 ; rdi - syscall_table + __NR_write mov rbx, original ;  rbx    mov rax, QWORD [rbx] ; rax - syscall_table[__NR_write] mov QWORD [rdi],rax ;      call lockWP ;   ret unlockWP: mov rax, cr0 and rax, 0xfffffffffffeffff mov cr0, rax ret lockWP: mov rax, cr0 xor rax, 0x0000000000001000 mov cr0, rax ret SECTION .data original: DQ 0,0 work: DB "It works!",10,0

makefile

 obj-m += kmod.o kmod-objs := module.o main.o KDIR := /lib/modules/$(shell uname -r)/build PWD := $(shell pwd) module: nasm -f elf64 -o main.o main.asm make -C $(KDIR) SUBDIRS=$(PWD) modules make clean clean: rm -f *.o *mod.c *.symvers *.order

यदि सब कुछ ठीक रहा, तो स्रोत निर्देशिका में हमें kmod.ko फ़ाइल मिलती है। यह हमारा कर्नेल मॉड्यूल है। इसके संचालन की जांच करने के लिए, आपको इसे मेमोरी में लोड करने की आवश्यकता है। यह insmod _. का उपयोग करके किया insmod _. मॉड्यूल को अनलोड करने के लिए, कमांड rmmod _. निष्पादित करें rmmod _. मॉड्यूल के संचालन की जांच करने के लिए, dmesg निष्पादित करें, जिससे कर्नेल संदेश बफर को मानक आउटपुट स्ट्रीम में आउटपुट किया जा सके।

आपका ध्यान देने के लिए धन्यवाद।

पुनश्च:

स्क्रीनशॉट की एक जोड़ी।

स्क्रिप्ट रन