halpomeranz/lmgलिनक्स मेमोरी कैप्चर और विश्लेषण को स्वचालित करने के लिए स्क्रिप्ट
लिनक्स मेमोरी ग्रैबर लिनक्स मेमोरी डंप करने और Volatility(TM) प्रोफाइल बनाने के लिए एक स्क्रिप्ट। Hal Pomeranz ([email protected]), 2020-02-01
"अगर मैंने आगे देखा है तो यह दिग्गजों के कंधों पर खड़े होकर।" ~ आइज़ैक न्यूटन
बहुत से लोग हैं जो इस सरल छोटे उपकरण को संभव बनाने के लिए धन्यवाद के पात्र हैं:
-- AVML उपलब्ध कराने के लिए Microsoft के अच्छे लोग
-- LiME पर अपने काम के लिए Joe Sylve
-- Volatility(TM) विकास टीम को उनके निरंतर काम के लिए। मैं विशेष रूप से Andrew Case को पहचानना चाहूंगा जिन्होंने मेरे उपकरण के विकास के दौरान मेरे कई परेशान करने वाले प्रश्नों का उत्तर दिया।
-- libdwarf और dwarfdump के निरंतर समर्थन के लिए David Anderson
-- MoonSols से Matt Suiche। जब मैं अपना उपकरण बना रहा था, तो मेरा डिज़ाइन लक्ष्य था "इसे DumpIt जितना आसान बनाएं" (यदि आपको विंडोज मेमोरी कैप्चर करने की आवश्यकता है, तो मैं इससे आसान किसी उपकरण को नहीं जानता)। तो प्रेरणा के लिए धन्यवाद, Matt!
-- वे लोग जिन्होंने उपकरण को बेहतर बनाने के लिए विचार और कोड प्रदान किए हैं:
Julien -- वैकल्पिक आउटपुट/बिल्ड निर्देशिकाएं और केस ID लेबल, रूट के रूप में नहीं चलने पर रोकें
Jonathon Poling -- Julien के समान विचार
Jeff Bryner -- प्रत्येक कैप्चर के लिए volatilityrc फाइलें बनाना
इन सभी प्रयासों से समुदाय बेहतर है। मैंने अपने उपकरण को Creative Commons 'Attribution' License (CC BY) के तहत उपलब्ध कराने का विकल्प चुना है, ताकि इसे यथासंभव व्यापक रूप से उपलब्ध कराया जा सके।
लिनक्स मेमोरी का विश्लेषण करने के लिए, पहले आपको लिनक्स मेमोरी कैप्चर करने में सक्षम होना होगा। AVML बहुत अच्छा काम करता है, लेकिन यदि आपके सिस्टम में /proc/kcore या /dev/crash नहीं है तो आपको Joe Sylve के Linux Memory Extractor (LiME) की आवश्यकता होगी। लेकिन आपके पास उस सिस्टम के कर्नेल के लिए संकलित एक LiME मॉड्यूल होना चाहिए जहां आप RAM लेना चाहते हैं।
Volatility(TM) लिनक्स मेमोरी इमेज का विश्लेषण करने में बहुत अच्छा है। लेकिन इसे एक प्रोफाइल की आवश्यकता है जो उस सिस्टम से मेल खाती हो जहां मेमोरी कैप्चर की गई थी। प्रोफाइल बनाने का मतलब है उपयुक्त सिस्टम पर एक C प्रोग्राम संकलित करना और महत्वपूर्ण कर्नेल डेटा संरचनाओं के पतों को प्राप्त करने के लिए dwarfdump का उपयोग करना। आपको /boot निर्देशिका से System.map फ़ाइल की एक प्रति की भी आवश्यकता है।
अब यदि आपके पास अपने लक्ष्य सिस्टम की डुप्लिकेट है, तो आप क्लोन पर Volatility(TM) प्रोफाइल बना सकते हैं और यदि आवश्यक हो तो लक्ष्य से मेमोरी कैप्चर और विश्लेषण करने के लिए LiME बना सकते हैं। लेकिन ऐसी कई स्थितियां हैं जहां आपके लक्ष्य सिस्टम की डुप्लिकेट उपलब्ध नहीं है। इसलिए आपको अपने लक्ष्य मशीन पर अपना Volatility(TM) प्रोफाइल और LiME बनाना पड़ सकता है।
और यह कमजोर दिल वालों के लिए नहीं है। इसमें कई कदम शामिल हैं, और कुछ काफी निम्न-स्तरीय लिनक्स कमांड शामिल हैं। मेरा लक्ष्य एक ऐसा पैकेज बनाना था जिसे (एक विशेषज्ञ द्वारा) थंब ड्राइव पर स्थापित किया जा सके और फील्ड में एजेंटों को वितरित किया जा सके। थंब ड्राइव के उपयोगकर्ता को थंब ड्राइव में प्लग करने, एक कमांड चलाने, और सफलतापूर्वक लक्ष्य मशीन की मेमोरी इमेज और एक कार्यशील Volatility(TM) प्रोफाइल प्राप्त करने में सक्षम होना चाहिए। परिणाम मेरी lmg (Linux Memory Grabber) स्क्रिप्ट है।
यदि आप फोरेंसिक शुद्धता पर जोर देते हैं, तो यह संभवतः आपके लिए उपकरण नहीं है। आइए उन तरीकों पर चर्चा करें जिनसे मेरा उपकरण लक्ष्य सिस्टम के साथ बातचीत करता है:
हटाने योग्य मीडिया -- उपकरण को पोर्टेबल USB उपकरण जैसे थंब ड्राइव से चलाने के लिए डिज़ाइन किया गया है। आप अपने लक्ष्य सिस्टम में एक लिखने योग्य उपकरण प्लग करने जा रहे हैं, जहां यह संभावित रूप से दुर्भावनापूर्ण उपयोगकर्ताओं या सिस्टम पर मैलवेयर द्वारा लक्षित किया जा सकता है। उपकरण को सिस्टम में प्लग करने की क्रिया मशीन की स्थिति को बदलने वाली है (जैसे, लॉग प्रविष्टियां, mtab प्रविष्टियां आदि बनाना)। यदि उपकरण ऑपरेटिंग सिस्टम द्वारा स्वचालित रूप से माउंट नहीं किया जाता है, तो उपयोगकर्ता को रूट शेल के माध्यम से मैन्युअल रूप से उपकरण माउंट करना होगा।
संकलन -- Volatility(TM) प्रोफाइल बनाने में लक्ष्य मशीन पर कोड संकलित करना शामिल है। ऐसा ही AVML के काम न करने पर LiME बनाने में भी होता है। तो gcc निष्पादित किया जाएगा, हेडर फ़ाइलें पढ़ी जाएंगी, लाइब्रेरी लिंक की जाएंगी, आदि। lmg TMPDIR को USB उपकरण की निर्देशिका पर सेट करके लक्ष्य मशीन के फ़ाइल सिस्टम पर प्रभाव को कम करने का प्रयास करता है जहां से lmg चलता है। इसका मतलब है कि संकलक द्वारा बनाई गई मध्यवर्ती फ़ाइलें लक्ष्य मशीन के स्थानीय फ़ाइल सिस्टम के बजाय थंब ड्राइव पर लिखी जाएंगी।
निर्भरताएं -- लिनक्स पर कर्नेल कोड संकलित करने के लिए, लक्ष्य मशीन को gcc, make आदि के साथ एक कार्यशील विकास वातावरण और सभी उपयुक्त इन्क्लूड फ़ाइलें और साझा लाइब्रेरी की आवश्यकता होती है। और विशेष रूप से, कर्नेल हेडर फ़ाइलें स्थानीय मशीन पर मौजूद होनी चाहिए। ये निर्भरताएं लक्ष्य पर मौजूद नहीं हो सकती हैं। इस मामले में, उपयोगकर्ता के पास उपयुक्त निर्भरताओं को स्थापित करने (यदि संभव हो) या सिस्टम के लिए Volatility(TM) प्रोफाइल बनाने में असमर्थ होने का विकल्प है।
मैलवेयर -- lmg लक्ष्य मशीन से /bin/bash, gcc, zip, और कई अन्य प्रोग्रामों का उपयोग करता है। यदि सिस्टम से समझौता किया गया है, तो lmg द्वारा उपयोग किए जाने वाले एप्लिकेशन भरोसेमंद नहीं हो सकते हैं। एक अधिक पूर्ण समाधान पोर्टेबल USB उपकरण पर lmg के लिए एक सुरक्षित निष्पादन वातावरण बनाना होगा, लेकिन यह इस प्रारंभिक अवधारणा प्रमाण के दायरे से बाहर था।
मेमोरी -- चलाए जा रहे सभी कमांड लक्ष्य सिस्टम की मेमोरी को बदलने का कारण बनेंगे। RAM कैप्चर करने की क्रिया हमेशा कलाकृतियां बनाएगी, लेकिन इस मामले में RAM डंपर चलाने के अलावा व्यापक संकलन, फ़ाइल सिस्टम एक्सेस आदि भी हैं।
यह सब कहने के बाद, lmg कम कुशल एजेंटों को लक्ष्य सिस्टम से उपयोगी मेमोरी विश्लेषण डेटा कैप्चर करने की अनुमति देने के लिए एक बहुत ही सुविधाजनक उपकरण है।
ध्यान दें कि यदि AVML विफल होता है, तो lmg USB उपकरण पर पहले से मौजूद LiME मॉड्यूल की तलाश करेगा जो लक्ष्य मशीन के कर्नेल संस्करण और प्रोसेसर आर्किटेक्चर से मेल खाता हो। यदि मिल गया, तो lmg पुनर्संकलन की जहमत नहीं उठाएगा। इसी तरह, आप लक्ष्य सिस्टम पर प्रभाव को कम करने के लिए lmg को Volatility(TM) प्रोफाइल नहीं बनाने का विकल्प चुन सकते हैं।
lmg gcc और zip जैसे प्रोग्रामों को लागू करते समय सापेक्ष पथ नामों का उपयोग करता है। इसलिए यदि आप इन प्रोग्रामों को वैकल्पिक मीडिया से चलाना चाहते हैं, तो lmg चलाने से पहले $PATH को उचित रूप से अपडेट करें।
पहले, lmg के साथ प्रदान किए गए INSTALL दस्तावेज़ में दिए गए निर्देशों के अनुसार एक थंब ड्राइव तैयार करें।
जब आप RAM अधिग्रहण करना चाहते हैं, तो थंब ड्राइव को अपने लक्ष्य सिस्टम में प्लग करें। अधिकांश लिनक्स सिस्टम पर, नए USB उपकरण स्वचालित रूप से /media के तहत माउंट हो जाएंगे। मान लें कि आपका /media/LMG के अंतर्गत आता है।
अब, रूट के रूप में, "/media/LMG/lmg" चलाएँ। यह इंटरेक्टिव मोड है और lmg द्वारा सिस्टम के लिए LiME मॉड्यूल बनाने और/या Volatility(TM) प्रोफाइल बनाने से पहले उपयोगकर्ता से पुष्टि के लिए संकेत दिया जाएगा। यदि आप संकेत नहीं चाहते हैं, तो "/media/LMG/lmg -y" का उपयोग करें।
बाकी सब कुछ स्वचालित है। स्क्रिप्ट चलने के बाद, आपके पास थंब ड्राइव पर एक नई निर्देशिका होगी जिसका नाम है:
".../capture/-YYYY-MM-DD_hh.mm.ss"
lmg एक -c विकल्प का समर्थन करता है जो डिफ़ॉल्ट "-YYYY-MM-DD_hh.mm.ss" निर्देशिका के बजाय उपयोग किए जाने वाले केस ID निर्देशिका नाम को निर्दिष्ट करने के लिए है।
जो भी निर्देशिका नाम उपयोग किया जाता है, उस निर्देशिका में शामिल होगा:
-YYYY-MM-DD_hh.mm.ss-memory.lime -- RAM कैप्चर -YYYY-MM-DD_hh.mm.ss-profile.zip -- Volatility(TM) प्रोफाइल -YYYY-MM-DD_hh.mm.ss-bash -- लक्ष्य के /bin/bash की प्रति volatilityrc -- प्रोटोटाइप Volatility कॉन्फ़िग फ़ाइल
volatilityrc फ़ाइल कैप्चर की गई मेमोरी और प्लगइन के लिए उपयुक्त स्थानों को परिभाषित करती है। इस फ़ाइल का उपयोग कैसे करें, इसके लिए नीचे USAGE EXAMPLE देखें।
/bin/bash की प्रति मेमोरी कैप्चर में bash प्रक्रियाओं की मेमोरी में शेल इतिहास डेटा संरचना का पता निर्धारित करने में सहायक है। इस निष्पादन योग्य का उपयोग करने के तरीके के बारे में अधिक जानकारी के लिए https://github.com/volatilityfoundation/volatility/wiki/Linux-Command-Reference#linux_bash देखें (या नीचे USAGE EXAMPLE देखें)।
ध्यान दें कि ऐसे समय हो सकते हैं जब आप उस मीडिया पर डेटा नहीं लिखना चाहते जिससे आप lmg चला रहे हैं—उदाहरण के लिए यदि lmg उपकरण DVD-ROM जैसे केवल-पढ़ने योग्य मीडिया पर हैं। lmg एक -d विकल्प का समर्थन करता है जो एक अलग आउटपुट निर्देशिका निर्दिष्ट करता है। डिफ़ॉल्ट रूप से, सभी संकलन लक्ष्य निर्देशिका में होंगे, लेकिन उपयोगकर्ता -B के साथ एक वैकल्पिक संकलन निर्देशिका निर्दिष्ट कर सकता है।
यहाँ lmg उपकरण का उपयोग करने का एक उदाहरण है, जिसमें कैप्चर की गई इमेज का विश्लेषण करने के लिए सीधे थंब ड्राइव से Volatility(TM) का उपयोग करना शामिल है। मेरी परीक्षण मशीन पर, थंब ड्राइव /dev/sdb पर था और मेरे ऑपरेटिंग सिस्टम द्वारा ऑटो-माउंट नहीं किया गया था। इसलिए मैंने सब कुछ मैन्युअल रूप से किया।
[root@localhost ~]$ sudo -s [sudo] password for lab: [root@localhost lab]# mkdir -p /mnt/usb [root@localhost lab]# mount /dev/sdb1 /mnt/usb
[root@localhost lab]# /mnt/usb/lmg -y AVML is /mnt/usb/avml/avml-x86_64 Dumping memory in "lime" format to /mnt/usb/capture/localhost.localdomain-2020-02-01_08.16.55 This could take a while...Done! Grabbing a copy of /bin/bash...Done! Writing volatilityrc to /mnt/usb/capture/localhost.localdomain-2020-02-01_08.16.55...Done! make -C //lib/modules/4.18.0-147.3.1.el8_1.x86_64/build M="/mnt/usb/volatility-master/tools/linux" clean make[1]: Entering directory '/usr/src/kernels/4.18.0-147.3.1.el8_1.x86_64' make[1]: Leaving directory '/usr/src/kernels/4.18.0-147.3.1.el8_1.x86_64' rm -f module.dwarf make -C //lib/modules/4.18.0-147.3.1.el8_1.x86_64/build CONFIG_DEBUG_INFO=y M="/mnt/usb/volatility-master/tools/linux" modules make[1]: Entering directory '/usr/src/kernels/4.18.0-147.3.1.el8_1.x86_64' CC [M] /mnt/usb/volatility-master/tools/linux/module.o Building modules, stage 2. MODPOST 1 modules WARNING: modpost: missing MODULE_LICENSE() in /mnt/usb/volatility-master/tools/linux/module.o see include/linux/module.h for more information CC /mnt/usb/volatility-master/tools/linux/module.mod.o LD [M] /mnt/usb/volatility-master/tools/linux/module.ko make[1]: Leaving directory '/usr/src/kernels/4.18.0-147.3.1.el8_1.x86_64' dwarfdump -di module.ko > module.dwarf make -C //lib/modules/4.18.0-147.3.1.el8_1.x86_64/build M="/mnt/usb/volatility-master/tools/linux" clean make[1]: Entering directory '/usr/src/kernels/4.18.0-147.3.1.el8_1.x86_64' CLEAN /mnt/usb/volatility-master/tools/linux/.tmp_versions CLEAN /mnt/usb/volatility-master/tools/linux/Module.symvers make[1]: Leaving directory '/usr/src/kernels/4.18.0-147.3.1.el8_1.x86_64' adding: module.dwarf (deflated 90%) adding: boot/System.map-4.18.0-147.3.1.el8_1.x86_64 (deflated 79%)
[root@localhost lab]# cd /mnt/usb/capture/localhost.localdomain-2020-02-01_08.16.55 [root@localhost localhost.localdomain-2020-02-01_08.16.55]# ls localhost.localdomain-2020-02-01_08.16.55-bash localhost.localdomain-2020-02-01_08.16.55-memory.lime localhost.localdomain-2020-02-01_08.16.55-profile.zip volatilityrc [root@localhost localhost.localdomain-2020-02-01_08.16.55]# ../../volatility-master/vol.py --conf-file=volatilityrc linux_banner Volatility Foundation Volatility Framework 2.6.1 Linux version 4.18.0-147.3.1.el8_1.x86_64 ([email protected]) (gcc version 8.3.1 20190507 (Red Hat 8.3.1-4) (GCC)) #1 SMP Fri Jan 3 23:55:26 UTC 2020
[root@localhost localhost.localdomain-2020-02-01_08.16.55]# gdb localhost.localdomain-2020-02-01_08.16.55-bash GNU gdb (GDB) Red Hat Enterprise Linux 8.2-6.el8_0 Copyright (C) 2018 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-redhat-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from localhost.localdomain-2020-02-01_08.16.55-bash...Missing separate debuginfo for /mnt/usb/capture/localhost.localdomain-2020-02-01_08.16.55/localhost.localdomain-2020-02-01_08.16.55-bash
Try: dnf --enablerepo='debug' install /usr/lib/debug/.build-id/b6/858d77c486b7b596f22956149bbc9f8058d98d.debug
Reading symbols from .gnu_debugdata for /mnt/usb/capture/localhost.localdomain-2020-02-01_08.16.55/localhost.localdomain-2020-02-01_08.16.55-bash...(no debugging symbols found)...done.
(no debugging symbols found)...done.
(gdb) disass history_list
Dump of assembler code for function history_list:
0x00000000000ccea0 <+0>: endbr64
0x00000000000ccea4 <+4>: mov 0x24b09d(%rip),%rax # 0x317f48
0x00000000000cceab <+11>: retq
End of assembler dump.
(gdb) quit
[root@localhost localhost.localdomain-2020-02-01_08.16.55]# ../../volatility-master/vol.py --conf-file=volatilityrc linux_bash -H 0x317f48
Volatility Foundation Volatility Framework 2.6.1
Pid Name Command Time Command
13822 bash 2020-01-30 20:25:39 UTC+0000 uname -a 13822 bash 2020-01-30 20:25:39 UTC+0000 ls 13822 bash 2020-01-30 20:25:39 UTC+0000 sudo -s 13822 bash 2020-01-30 20:25:39 UTC+0000 fg [... more output not shown ...]