🥇आईबीडी फ़ाइल के बाइट-बाय-बाइट विश्लेषण का उपयोग करके संरचना फ़ाइल के बिना XtraDB तालिकाओं से डेटा पुनर्प्राप्ति

पृष्ठभूमि

ऐसा हुआ कि सर्वर पर एक रैंसमवेयर वायरस द्वारा हमला किया गया था, जिसने एक "भाग्यशाली दुर्घटना" के कारण .ibd फ़ाइलों (innodb तालिकाओं की कच्ची डेटा फ़ाइलें) को आंशिक रूप से अछूता छोड़ दिया, लेकिन साथ ही .fpm फ़ाइलों को पूरी तरह से एन्क्रिप्ट कर दिया। संरचना फ़ाइलें)। इस मामले में, .idb को इसमें विभाजित किया जा सकता है:

मानक उपकरणों और गाइडों के माध्यम से बहाली के अधीन। ऐसे मामलों के लिए, एक उत्कृष्ट है बनना;
आंशिक रूप से एन्क्रिप्टेड टेबल. अधिकतर ये बड़ी तालिकाएँ होती हैं, जिनके लिए (जैसा कि मैं समझता हूँ) हमलावरों के पास पूर्ण एन्क्रिप्शन के लिए पर्याप्त रैम नहीं थी;
खैर, पूरी तरह से एन्क्रिप्टेड टेबल जिन्हें पुनर्स्थापित नहीं किया जा सकता है।

वांछित एन्कोडिंग (मेरे मामले में यह UTF8 है) के तहत किसी भी टेक्स्ट एडिटर में इसे खोलकर और केवल टेक्स्ट फ़ील्ड की उपस्थिति के लिए फ़ाइल को देखकर यह निर्धारित करना संभव था कि टेबल किस विकल्प से संबंधित हैं, उदाहरण के लिए:

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

मेरे मामले में, हमलावरों ने प्रत्येक एन्क्रिप्टेड फ़ाइल के अंत में 4-बाइट स्ट्रिंग (1, 0, 0, 0) छोड़ दी, जिससे कार्य सरल हो गया। असंक्रमित फ़ाइलों की खोज के लिए, स्क्रिप्ट पर्याप्त थी:

def opened(path):
    files = os.listdir(path)
    for f in files:
        if os.path.isfile(path + f):
            yield path + f

for full_path in opened("C:somepath"):
    file = open(full_path, "rb")
    last_string = ""
    for line in file:
        last_string = line
        file.close()
    if (last_string[len(last_string) -4:len(last_string)]) != (1, 0, 0, 0):
        print(full_path)

इस प्रकार, यह पहले प्रकार से संबंधित फ़ाइलों को खोजने में सफल रहा। दूसरे में बहुत सारा मैन्युअल काम शामिल है, लेकिन जो मिला वह पहले से ही पर्याप्त था। सब कुछ ठीक हो जाएगा, लेकिन आपको जानना जरूरी है बिल्कुल सटीक संरचना और (बेशक) एक मामला सामने आया कि मुझे बार-बार बदलती हुई टेबल के साथ काम करना पड़ा। किसी को याद नहीं आया कि फ़ील्ड का प्रकार बदला गया था या कोई नया कॉलम जोड़ा गया था।

दुर्भाग्य से, वाइल्ड्स सिटी ऐसे मामले में मदद नहीं कर सका, यही कारण है कि यह लेख लिखा जा रहा है।

मुद्दे पे आईये

3 महीने पहले की एक तालिका की संरचना है जो वर्तमान तालिका (संभवतः एक फ़ील्ड, और संभवतः अधिक) से मेल नहीं खाती है। तालिका संरचना:

CREATE TABLE `table_1` (
    `id` INT (11),
    `date` DATETIME ,
    `description` TEXT ,
    `id_point` INT (11),
    `id_user` INT (11),
    `date_start` DATETIME ,
    `date_finish` DATETIME ,
    `photo` INT (1),
    `id_client` INT (11),
    `status` INT (1),
    `lead__time` TIME ,
    `sendstatus` TINYINT (4)
);

इस मामले में, आपको निकालने की आवश्यकता है:

id_point int(11);
id_user int(11);
date_start दिनांक समय;
date_finish दिनांक समय।

पुनर्प्राप्ति के लिए, .ibd फ़ाइल का बाइट-बाय-बाइट विश्लेषण का उपयोग किया जाता है, इसके बाद उन्हें अधिक पठनीय रूप में परिवर्तित किया जाता है। चूँकि हमें जो चाहिए उसे खोजने के लिए, हमें केवल int और datatime जैसे डेटा प्रकारों का विश्लेषण करने की आवश्यकता है, लेख केवल उनका वर्णन करेगा, लेकिन कभी-कभी हम अन्य डेटा प्रकारों का भी उल्लेख करेंगे, जो अन्य समान घटनाओं में मदद कर सकते हैं।

1 समस्या: DATETIME और TEXT प्रकार वाले फ़ील्ड में NULL मान थे, और उन्हें बस फ़ाइल में छोड़ दिया गया है, इस वजह से, मेरे मामले में पुनर्स्थापित करने के लिए संरचना निर्धारित करना संभव नहीं था। नए कॉलम में, डिफ़ॉल्ट मान शून्य था, और सेटिंग innodb_flush_log_at_trx_commit = 0 के कारण लेनदेन का हिस्सा खो सकता था, इसलिए संरचना निर्धारित करने के लिए अतिरिक्त समय खर्च करना होगा।

2 समस्या: यह ध्यान में रखा जाना चाहिए कि DELETE के माध्यम से हटाई गई सभी पंक्तियाँ ibd फ़ाइल में होंगी, लेकिन ALTER TABLE के साथ उनकी संरचना अपडेट नहीं की जाएगी। परिणामस्वरूप, डेटा संरचना फ़ाइल की शुरुआत से अंत तक भिन्न हो सकती है। यदि आप अक्सर ऑप्टिमाइज़ टेबल का उपयोग करते हैं, तो आपको ऐसी समस्या का सामना करने की संभावना नहीं है।

ध्यान दें, DBMS संस्करण डेटा संग्रहीत करने के तरीके को प्रभावित करता है, और यह उदाहरण अन्य प्रमुख संस्करणों के लिए काम नहीं कर सकता है। मेरे मामले में, mariadb 10.1.24 के विंडोज़ संस्करण का उपयोग किया गया था। इसके अलावा, हालांकि mariadb में आप InnoDB तालिकाओं के साथ काम करते हैं, वास्तव में वे हैं एक्स्ट्राडीबी, जो InnoDB mysql के साथ विधि की प्रयोज्यता को बाहर करता है।

फाइल विश्लेषण

पायथन में, डेटा प्रकार बाइट्स() संख्याओं के नियमित सेट के स्थान पर यूनिकोड डेटा प्रदर्शित करता है। हालाँकि आप फ़ाइल को इस रूप में देख सकते हैं, सुविधा के लिए आप बाइट सरणी को एक नियमित सरणी (सूची (उदाहरण_बाइट_एरे)) में परिवर्तित करके बाइट्स को संख्यात्मक रूप में परिवर्तित कर सकते हैं। किसी भी स्थिति में, दोनों विधियाँ विश्लेषण के लिए उपयुक्त हैं।

कई आईबीडी फाइलों को देखने के बाद, आप निम्नलिखित पा सकते हैं:

इसके अलावा, यदि आप फ़ाइल को इन कीवर्ड से विभाजित करते हैं, तो आपको डेटा के अधिकतर समान ब्लॉक मिलेंगे। हम विभाजक के रूप में इन्फ़िमम का उपयोग करेंगे।

table = table.split("infimum".encode())

एक दिलचस्प अवलोकन: थोड़ी मात्रा में डेटा वाली तालिकाओं के लिए, इन्फ़िमम और सुप्रीमम के बीच ब्लॉक में पंक्तियों की संख्या के लिए एक संकेतक होता है।

- पहली पंक्ति के साथ परीक्षण तालिका

- 2 पंक्तियों वाली परीक्षण तालिका

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

ये एक स्ट्रिंग में संग्रहीत int मान हैं। पहला बाइट बताता है कि संख्या सकारात्मक है या नकारात्मक। मेरे मामले में, सभी संख्याएँ सकारात्मक हैं। शेष 3 बाइट्स से, आप निम्नलिखित फ़ंक्शन का उपयोग करके संख्या निर्धारित कर सकते हैं। लिखी हुई कहानी:

def find_int(val: str):  # example '128, 1, 2, 3'
    val = [int(v) for v in  val.split(", ")]
    result_int = val[1]*256**2 + val[2]*256*1 + val[3]
    return result_int

उदाहरण के लिए, 128, 0, 0, 1 = 1या 128, 0, 75, 108 = 19308.
तालिका में स्वतः-वृद्धि के साथ एक प्राथमिक कुंजी थी, और इसे यहां भी पाया जा सकता है

परीक्षण तालिकाओं से डेटा की तुलना करने पर, यह पता चला कि DATETIME ऑब्जेक्ट में 5 बाइट्स होते हैं और 153 से शुरू होते हैं (संभवतः वार्षिक अंतराल का संकेत)। चूँकि DATTIME रेंज '1000-01-01' से '9999-12-31' है, मुझे लगता है कि बाइट्स की संख्या भिन्न हो सकती है, लेकिन मेरे मामले में, डेटा 2016 से 2019 की अवधि में आता है, इसलिए हम मान लेंगे वह 5 बाइट्स पर्याप्त हैं.

बिना सेकंड के समय निर्धारित करने के लिए निम्नलिखित फ़ंक्शन लिखे गए। लिखी हुई कहानी:

day_ = lambda x: x % 64 // 2  # {x,x,X,x,x }

def hour_(x1, x2):  # {x,x,X1,X2,x}
    if x1 % 2 == 0:
        return x2 // 16
    elif x1 % 2 == 1:
        return x2 // 16 + 16
    else:
        raise ValueError

min_ = lambda x1, x2: (x1 % 16) * 4 + (x2 // 64)  # {x,x,x,X1,X2}

साल और महीने के लिए एक कार्यात्मक फ़ंक्शन लिखना संभव नहीं था, इसलिए मुझे इसे हैक करना पड़ा। लिखी हुई कहानी:

ym_list = {'2016, 1': '153, 152, 64', '2016, 2': '153, 152, 128', 
           '2016, 3': '153, 152, 192', '2016, 4': '153, 153, 0',
           '2016, 5': '153, 153, 64', '2016, 6': '153, 153, 128', 
           '2016, 7': '153, 153, 192', '2016, 8': '153, 154, 0', 
           '2016, 9': '153, 154, 64', '2016, 10': '153, 154, 128', 
           '2016, 11': '153, 154, 192', '2016, 12': '153, 155, 0',
           '2017, 1': '153, 155, 128', '2017, 2': '153, 155, 192', 
           '2017, 3': '153, 156, 0', '2017, 4': '153, 156, 64',
           '2017, 5': '153, 156, 128', '2017, 6': '153, 156, 192',
           '2017, 7': '153, 157, 0', '2017, 8': '153, 157, 64',
           '2017, 9': '153, 157, 128', '2017, 10': '153, 157, 192', 
           '2017, 11': '153, 158, 0', '2017, 12': '153, 158, 64', 
           '2018, 1': '153, 158, 192', '2018, 2': '153, 159, 0',
           '2018, 3': '153, 159, 64', '2018, 4': '153, 159, 128', 
           '2018, 5': '153, 159, 192', '2018, 6': '153, 160, 0',
           '2018, 7': '153, 160, 64', '2018, 8': '153, 160, 128',
           '2018, 9': '153, 160, 192', '2018, 10': '153, 161, 0', 
           '2018, 11': '153, 161, 64', '2018, 12': '153, 161, 128',
           '2019, 1': '153, 162, 0', '2019, 2': '153, 162, 64', 
           '2019, 3': '153, 162, 128', '2019, 4': '153, 162, 192', 
           '2019, 5': '153, 163, 0', '2019, 6': '153, 163, 64',
           '2019, 7': '153, 163, 128', '2019, 8': '153, 163, 192',
           '2019, 9': '153, 164, 0', '2019, 10': '153, 164, 64', 
           '2019, 11': '153, 164, 128', '2019, 12': '153, 164, 192',
           '2020, 1': '153, 165, 64', '2020, 2': '153, 165, 128',
           '2020, 3': '153, 165, 192','2020, 4': '153, 166, 0', 
           '2020, 5': '153, 166, 64', '2020, 6': '153, 1, 128',
           '2020, 7': '153, 166, 192', '2020, 8': '153, 167, 0', 
           '2020, 9': '153, 167, 64','2020, 10': '153, 167, 128',
           '2020, 11': '153, 167, 192', '2020, 12': '153, 168, 0'}

def year_month(x1, x2):  # {x,X,X,x,x }

    for key, value in ym_list.items():
        key = [int(k) for k in key.replace("'", "").split(", ")]
        value = [int(v) for v in value.split(", ")]
        if x1 == value[1] and x2 // 64 == value[2] // 64:
            return key
    return 0, 0

मुझे यकीन है कि यदि आप पर्याप्त समय खर्च करें तो इस गलतफहमी को सुधारा जा सकता है।
अगला, एक फ़ंक्शन जो एक स्ट्रिंग से डेटाटाइम ऑब्जेक्ट लौटाता है। लिखी हुई कहानी:

def find_data_time(val:str):
    val = [int(v) for v in val.split(", ")]
    day = day_(val[2])
    hour = hour_(val[2], val[3])
    minutes = min_(val[3], val[4])
    year, month = year_month(val[1], val[2])
    return datetime(year, month, day, hour, minutes)

Int, int, datetime, datetime से बार-बार दोहराए गए मानों का पता लगाने में कामयाब , ऐसा लगता है कि आपको यही चाहिए। इसके अलावा, ऐसा क्रम प्रति पंक्ति दो बार दोहराया नहीं जाता है।

रेगुलर एक्सप्रेशन का उपयोग करते हुए, हमें आवश्यक डेटा मिलता है:

fined = re.findall(r'128, d*, d*, d*, 128, d*, d*, d*, 153, 1[6,5,4,3]d, d*, d*, d*, 153, 1[6,5,4,3]d, d*, d*, d*', int_array)

कृपया ध्यान दें कि इस अभिव्यक्ति का उपयोग करके खोज करते समय, आवश्यक फ़ील्ड में NULL मान निर्धारित करना संभव नहीं होगा, लेकिन मेरे मामले में यह महत्वपूर्ण नहीं है। फिर हम एक लूप में जो मिला उसे देखते हैं। लिखी हुई कहानी:

result = []
for val in fined:
    pre_result = []
    bd_int  = re.findall(r"128, d*, d*, d*", val)
    bd_date= re.findall(r"(153, 1[6,5,4,3]d, d*, d*, d*)", val)
    for it in bd_int:
        pre_result.append(find_int(bd_int[it]))
    for bd in bd_date:
        pre_result.append(find_data_time(bd))
    result.append(pre_result)

वास्तव में, बस इतना ही, परिणाम सरणी का डेटा वह डेटा है जिसकी हमें आवश्यकता है। ###पीएस.###
मैं समझता हूं कि यह विधि सभी के लिए उपयुक्त नहीं है, लेकिन लेख का मुख्य लक्ष्य आपकी सभी समस्याओं का समाधान करने के बजाय त्वरित कार्रवाई करना है। मुझे लगता है कि सबसे सही समाधान यह होगा कि आप स्वयं स्रोत कोड का अध्ययन शुरू कर दें MariaDB, लेकिन सीमित समय के कारण, वर्तमान पद्धति सबसे तेज़ प्रतीत होती है।

कुछ मामलों में, फ़ाइल का विश्लेषण करने के बाद, आप अनुमानित संरचना निर्धारित करने और उपरोक्त लिंक से मानक तरीकों में से एक का उपयोग करके इसे पुनर्स्थापित करने में सक्षम होंगे। यह अधिक सही होगा और कम समस्याएँ पैदा करेगा।

स्रोत: www.habr.com

आईबीडी फ़ाइल के बाइट-बाय-बाइट विश्लेषण का उपयोग करके संरचना फ़ाइल के बिना XtraDB तालिकाओं से डेटा पुनर्प्राप्त करना

पृष्ठभूमि

मुद्दे पे आईये

फाइल विश्लेषण

एक टिप्पणी जोड़ें उत्तर रद्द