🤞🏿 🐃 👡 .Wasm फ़ाइल के अंदर क्या है? प्रस्तुत था wasm-decompile 🉐 👩🏾‍🤝‍👨🏼 🎄

हमारे पास .wasm फ़ाइलों को बनाने और काम करने के लिए हमारे निपटान में कई कंपाइलर और अन्य उपकरण हैं। इन उपकरणों की संख्या लगातार बढ़ रही है। कभी-कभी आपको .wasm फ़ाइल को देखने और यह पता लगाने की आवश्यकता होती है कि इसके अंदर क्या है। हो सकता है कि आप किसी एक वासम टूल के डेवलपर हों, या हो सकता है कि आप एक प्रोग्रामर हों, जो कोड को वास में परिवर्तित करने के लिए डिज़ाइन किया गया हो और यह इस बात में रुचि रखता हो कि यह कैसे दिखता है कि उसका कोड क्या होगा। इस तरह के ब्याज को ट्रिगर किया जा सकता है, उदाहरण के लिए, प्रदर्शन के विचार से।

समस्या यह है कि .wasm फ़ाइलों में निम्न स्तर का कोड होता है जो वास्तविक कोडांतरक कोड जैसा दिखता है। विशेष रूप से, इसके विपरीत, उदाहरण के लिए, जेवीएम, सभी डेटा संरचनाओं को लोड / स्टोर संचालन के सेट में संकलित किया जाता है, न कि ऐसी किसी चीज़ में, जिसमें स्पष्ट वर्ग और फ़ील्ड नाम हों। कंपाइलर, एलएलवीएम की तरह, इनपुट कोड को इस तरह से बदल सकते हैं कि उन्हें जो मिलता है वह उसके करीब नहीं दिखता है।

जो चाहता है, उसके बारे में .wasm फ़ाइल लेने के बारे में, यह पता लगाने के लिए कि उसमें क्या हो रहा है?

विघटित या ... विघटित?

आप .m2wat फ़ाइलों का उपयोग कर सकते हैं .wasm फ़ाइलों को .mat कोड के एक मानक पाठ प्रतिनिधित्व युक्त फ़ाइलों के लिए उपयोग करें (यह WABT टूलकिट का हिस्सा है )। इस रूपांतरण के परिणाम बहुत सटीक हैं, लेकिन परिणामी कोड पढ़ना विशेष रूप से सुविधाजनक नहीं है।

यहाँ, उदाहरण के लिए, C में लिखा गया एक सरल कार्य है:

typedef struct { float x, y, z; } vec3;

float dot(const vec3 *a, const vec3 *b) {
    return a->x * b->x +
           a->y * b->y +
           a->z * b->z;
}

कोड एक फ़ाइल में संग्रहीत किया जाता है dot.c।

हम निम्नलिखित कमांड का उपयोग करते हैं:

clang dot.c -c -target wasm32 -O2

अगला, .wat फ़ाइल का क्या हुआ, इसे बदलने के लिए, हम निम्नलिखित कमांड लागू करते हैं:

wasm2wat -f dot.o

यहाँ यह है कि यह हमें क्या देगा:

(func $dot (type 0) (param i32 i32) (result f32)
  (f32.add
    (f32.add
      (f32.mul
        (f32.load
          (local.get 0))
        (f32.load
          (local.get 1)))
      (f32.mul
        (f32.load offset=4
          (local.get 0))
        (f32.load offset=4
          (local.get 1))))
    (f32.mul
      (f32.load offset=8
        (local.get 0))
      (f32.load offset=8
        (local.get 1))))))

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

आइए, wasm2wat का उपयोग करने के बजाय, निम्न कमांड चलाएँ:

wasm-decompile dot.o

यहाँ वह हमें क्या देगा:

function dot(a:{ a:float, b:float, c:float },
             b:{ a:float, b:float, c:float }):float {
  return a.a * b.a + a.b * b.b + a.c * b.c
}

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

जैसा कि आप देख सकते हैं, विघटन के परिणामों की तुलना में विघटन के परिणाम अधिक समझ में आते हैं।

डिकम्पाइलर द्वारा लिखे गए कोड को किस भाषा में लिखा जाता है?

Wasm-decompile टूल कोड को आउटपुट करता है, इस कोड को "औसत" प्रोग्रामिंग भाषा के कुछ प्रकार की तरह बनाने की कोशिश करता है। उसी समय, यह उपकरण वॉसम से बहुत दूर नहीं जाने की कोशिश करता है।

Wasm-decompiler का पहला लक्ष्य पठनीय कोड बनाना था। वह है - ऐसा कोड जो अपने पाठक को आसानी से समझने की अनुमति देगा कि विघटित .wasm फ़ाइल में क्या हो रहा है। इस उपकरण का दूसरा उद्देश्य .wasm फ़ाइल का सबसे सटीक प्रतिनिधित्व प्रदान करना है, कोड उत्पन्न करके जो पूरी तरह से स्रोत फ़ाइल में हो रहा है का प्रतिनिधित्व करता है। जाहिर है, ये लक्ष्य एक-दूसरे के साथ अच्छे समझौते से हमेशा दूर हैं।

मूल रूप से डिकमपाइलर आउटपुट क्या था, मूल रूप से कुछ वास्तविक प्रोग्रामिंग भाषा का प्रतिनिधित्व करने वाले कोड के रूप में कल्पना नहीं की गई थी। इस कोड को Wasm में संकलित करने का फिलहाल कोई तरीका नहीं है।

डेटा लोड करने और सहेजने के लिए आदेश देता है

जैसा कि ऊपर दिखाया गया है, wasm-decompile किसी विशेष पॉइंटर से जुड़े कमांड को लोड करने और सहेजने के लिए देखता है। यदि ये आदेश एक निरंतर अनुक्रम बनाते हैं, तो डिकम्पॉइलर एक "अंतर्निहित" डेटा संरचना घोषणाओं को प्रदर्शित करता है।

यदि सभी "फ़ील्ड्स" एक्सेस नहीं किए गए थे, तो डिकंपाइलर मज़बूती से काम करने के साथ संचालन के एक निश्चित अनुक्रम से संरचना को मज़बूती से अलग नहीं कर सकता है। इस मामले में, wasm-decompile सरल प्रकार का उपयोग करके फ़ॉलबैक विकल्प का उपयोग करता है, float_ptr(यदि प्रकार समान हैं), या, सबसे खराब स्थिति में, कोड उत्पन्न करता है जो दिखाता है कि सरणी के साथ कैसे काम किया जाए, जैसे o[2]:int। ऐसा कोड हमें बताता है कि यह oप्रकार के तत्वों को इंगित करता है int, और हम तीसरे ऐसे तत्व की ओर मुड़ते हैं।

यह अंतिम स्थिति आपके द्वारा सोचने की तुलना में बहुत अधिक बार उठती है, क्योंकि स्थानीय वास कार्यों को चर के बजाय रजिस्टरों का उपयोग करने पर अधिक ध्यान केंद्रित किया जाता है। परिणामस्वरूप, अनुकूलित कोड में, एक ही पॉइंटर का उपयोग पूरी तरह से असंबंधित वस्तुओं के साथ काम करने के लिए किया जा सकता है।

डीकोम्पाइलर अनुक्रमण के लिए एक बुद्धिमान दृष्टिकोण चाहता है और जैसे पैटर्न की पहचान करने में सक्षम है (base + (index << 2))[0]:int। ऐसे पैटर्न का स्रोत सी के लिए सामान्य अनुक्रमण संचालन है, जैसे base[index]कि यह base4-बाइट प्रकार को इंगित करता है। यह कोड में बहुत आम है, क्योंकि वॉसम, डेटा कमांड को लोड और सेव करता है, केवल स्थिरांक के रूप में परिभाषित ऑफसेट का समर्थन करता है। Wasm-decompile द्वारा उत्पन्न कोड में, ऐसे निर्माण प्रकार में परिवर्तित हो जाते हैं base[index]:int।

इसके अलावा, डीकॉम्पेलर जानता है कि जब पूर्ण पते एक डेटा अनुभाग को इंगित करते हैं।

कार्यक्रम प्रवाह नियंत्रण

अगर हम नियंत्रण निर्माणों के बारे में बात करते हैं, तो उनमें से सबसे प्रसिद्ध है अगर-तत्कालीन Wasm निर्माण, जो if (cond) { A } else { B }कि इस तथ्य के अतिरिक्त के साथ बदल जाता है कि Wasm में ऐसा निर्माण एक मूल्य वापस कर सकता है, इसलिए यह एक टर्नरी ऑपरेटर का भी प्रतिनिधित्व कर सकता है, जैसे cond ? A : B, जो कुछ में है भाषाओं।

अन्य Wasm नियंत्रण संरचनाओं ब्लॉक आधारित हैं blockऔर loop, साथ ही संक्रमण br, br_ifऔर br_table। डिकम्पॉइलर संभव के रूप में इन संरचनाओं के करीब रहने की कोशिश करता है। वह निर्माण / निर्माण / स्विच को फिर से बनाने की कोशिश नहीं करता है, जो उनके लिए आधार के रूप में काम कर सकता है। तथ्य यह है कि अनुकूलित कोड को संसाधित करते समय यह दृष्टिकोण खुद को बेहतर दिखाता है। उदाहरण के लिए, एक पारंपरिक डिजाइनloop इस तरह से wasm-decompile द्वारा लौटाए गए कोड में देख सकते हैं:

loop A {
  //    .
  if (cond) continue A;
}

यहां Aएक लेबल है जो आपको एक दूसरे में नेस्टेड संरचनाओं का निर्माण करने की अनुमति देता है loop। तथ्य यह है कि आज्ञाएं हैं ifऔर continueचक्र को नियंत्रित करने के लिए उपयोग किया जाता है, जबकि छोरों के लिए कुछ अलग लग सकता है, लेकिन वे वास-निर्माण के अनुरूप हैं br_if।

ब्लॉक एक समान तरीके से तैयार किए जाते हैं, लेकिन यहां स्थितियां शुरुआत में हैं, और अंत में नहीं:

block {
  if (cond) break;
  //    .
}

यदि तत्कालीन निर्माण को विघटित करने का परिणाम यहां दिखाया गया है। डिकम्पाइलर के भविष्य के संस्करणों में, शायद, ऐसे कोड के बजाय, जहां संभव हो, एक अधिक परिचित अगर-तब निर्माण होगा।

किसी प्रोग्राम के प्रवाह को नियंत्रित करने के लिए उपयोग किया जाने वाला सबसे असामान्य वासम उपकरण है br_table। यह टूल एक तरह का स्विच स्टेटमेंट है, सिवाय इसके कि यह इनलाइन ब्लॉक का उपयोग करता है। यह सब कोड के पढ़ने को जटिल बनाता है। डिकम्पॉइलर ऐसी संरचनाओं की संरचना को सरल करता है, जो उनकी धारणा को थोड़ा आसान बनाने का प्रयास करता है:

br_table[A, B, C, ..D](a);
label A:
return 0;
label B:
return 1;
label C:
return 2;
label D:

यह डिफ़ॉल्ट विकल्प है जब switchविश्लेषण के लिए उपयोग की याद ताजा करती aहै D।

अन्य रोचक विशेषताएं

यहाँ wasm-decompile की कुछ और विशेषताएं हैं:

, . C++-.
, , , . . , .
.
Wasm-, . , wasm-decompile , , , .
, ( , C- ).

Decompiling Wasm कोड एक ऐसा कार्य है जो उदाहरण के लिए, JVM बाइट कोड को डिकंपाइल करने की तुलना में बहुत अधिक जटिल है।

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

JVM bytecode के विपरीत, .wasm फ़ाइलों में आने वाला कोड LLVM द्वारा अत्यधिक अनुकूलित है। नतीजतन, ऐसा कोड अक्सर अपनी मूल संरचना को खो देता है। आउटपुट कोड प्रोग्रामर जो लिखेगा उससे बहुत अलग है। यह परिणाम के आउटपुट के साथ Wasm कोड को डिकम्पोज करने के कार्य को बहुत जटिल करता है जो प्रोग्रामर को वास्तविक लाभ पहुंचा सकता है। हालांकि, इसका मतलब यह नहीं है कि हमें इस समस्या को हल करने का प्रयास नहीं करना चाहिए!

सारांश

यदि आप वास कोड डिकम्पोजिशन के विषय में रुचि रखते हैं, तो शायद इस विषय को समझने का सबसे अच्छा तरीका है कि आप अपना स्वयं का .wasm प्रोजेक्ट लें और डिकम्पाइल करें! इसके अलावा, यहां आप wasm-decompile पर अधिक विस्तृत मार्गदर्शन पा सकते हैं। इस रिपॉजिटरी की फाइलों में डिकंपाइलर कोड पाया जा सकता है, जिसके नाम से शुरू होता है decompile(यदि आप चाहें, तो डिकॉम्पेलर पर काम में शामिल हों)। यहाँ आप .wat फ़ाइलों और विघटन परिणामों के बीच अंतर के अतिरिक्त उदाहरण दिखाते हुए परीक्षण पा सकते हैं।

और आप किन उपकरणों के साथ शोध करते हैं।

, , iPhone. , .