Skip to content
KitploitKITPLOIT
उपकरणब्लॉग
जमा करें
उपकरणब्लॉग
जमा करें

हैकिंग, पेनटेस्ट और साइबर सुरक्षा उपकरण आपके सुरक्षा शस्त्रागार के लिए!

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

··फ़ीड·संपर्क·गोपनीयता·© 2026 Kitploit

टूल निर्देशिका

श्रेणियाँ

सभी श्रेणियाँ देखें
Loading categories
apxutil — Schneider Electric PLC संग्रह फ़ाइलों में हेरफेर करने के लिए एक उपकरण | Kitploit
उपकरण/GitHubGitHub/finngineering/apxutil
एम्बेडेड सिस्टम सुरक्षाभेद्यता विश्लेषणशोषणरिवर्स इंजीनियरिंगSCADA/ICS सुरक्षाहार्डवेयर सुरक्षाबाइनरी विश्लेषणफर्मवेयर विश्लेषण
GitHubfinngineering/apxutil

apxutil

Schneider Electric PLC संग्रह फ़ाइलों में हेरफेर करने के लिए एक उपकरण

रिपॉजिटरी देखें
1056 महीने पहलेअभी तक समीक्षित नहीं

सबसे लोकप्रिय

सभी देखें →

हमारे समुदाय द्वारा सबसे अधिक उपयोग किए जाने वाले उपकरण खोजें।

सभी उपकरण खोजें

हमारे उपकरणों का संग्रह ब्राउज़ करें

सभी उपकरण देखें →
साझा करें

श्नाइडर इलेक्ट्रिक PLC संग्रह फ़ाइलों में हेरफेर करने के लिए एक उपकरण

यह उपकरण PLC "archive" फ़ाइलों को निकाल और पुनः जोड़ सकता है, जिनका उपयोग कई श्नाइडर इलेक्ट्रिक PLC द्वारा किया जाता है, जिनमें कम से कम M580, M340 और Quantum शामिल हैं। .sta एक्सटेंशन वाली संग्रह फ़ाइलें वास्तव में एक zip संग्रह होती हैं जिनमें कुछ फ़ाइलें होती हैं। संग्रह के अंदर, वास्तव में महत्वपूर्ण फ़ाइल का नाम Station.apx है। उस फ़ाइल की सामग्री वही है जो (पूर्ण) प्रोग्राम डाउनलोड/अपलोड के दौरान PLC से/को स्थानांतरित की जाती है। स्वाभाविक रूप से, इसमें PLC प्रोग्राम के लिए वास्तविक निष्पादन योग्य कोड होता है। लेकिन इसमें Control Expert Classic (या Unity Pro) में PLC प्रोग्राम को संपादित करने के लिए आवश्यक सभी जानकारी भी होती है। .apx फ़ाइल प्रारूप स्वामित्व वाला (proprietary) है, और इसके बारे में बहुत कम जानकारी उपलब्ध है। कुछ जानकारी Liras en la red और Team82 से उपलब्ध है, लेकिन यह कार्य उनके प्रकाशन से अधिक गहराई तक जाता है। इस उपकरण के साथ, Station.apx के विभिन्न "सेक्शन" (sections) को जांच के लिए निकाला (और यदि आवश्यक हो तो डीकंप्रेस) जा सकता है। यह उपकरण पहले से निकाले गए - और संभवतः संशोधित - सेक्शन डेटा और मेटाडेटा से Station.apx को पुनः जोड़ भी सकता है। और यह पुनः जोड़ा गया फ़ाइल Control Expert Classic / Unity Pro में बिना किसी त्रुटि के खुलेगा, बशर्ते कि किए गए परिवर्तन "सेक्शन लॉजिक" को न तोड़ें।

प्रेरणा

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

चेतावनी

यह उपकरण अपनी पूरी क्षमता से उन फ़ाइलों को निकालने और पुनः जोड़ने का प्रयास करता है जिनके साथ यह काम करता है। हालाँकि, उपयोगकर्ता को पता होना चाहिए कि यह उपकरण निम्नलिखित के साथ विकसित किया गया था:

  • .apx (और .sta) फ़ाइल प्रारूप की सीमित समझ
  • सीमित इनपुट सत्यापन, जिसका अर्थ है कि यह कोशिश किए बिना हार मानने के बजाय क्रैश होगा या कुछ गलत करेगा
  • पिछली फ़ाइलों को बिना पूछे अधिलेखित (overwrite) कर देता है
  • विभिन्न PLC और प्रोग्रामिंग सॉफ़्टवेयर संस्करणों का सीमित परीक्षण
  • कोड कार्यक्षमता का सीमित परीक्षण

वास्तविक PLC पर पुनः जोड़ी गई फ़ाइलों का उपयोग करने से समस्याएँ हो सकती हैं, खासकर यदि आपने सेक्शन या मेटाडेटा को संशोधित किया है। यह संभव है कि यह PLC को ब्रिक (brick) कर सकता है। इसलिए संशोधित संग्रह फ़ाइलों को PLC पर अपने जोखिम पर अपलोड करें।

उपयोग

यह उपकरण पायथन इंटरप्रेटर के साथ कमांड लाइन से उपयोग किया जाता है:

root@kitploit:~
python apxutil.py -h

usage: apxutil.py [-h] [-f filaname-apx] [-F filaname-sta] [-e dir] [-E dir] [-a manifestpath] [-A manifestpath] [-d]
                  [-x] [-B] [-r]

Tool to manipulate Schneider Electric .sta and .apx files

options:
  -h, --help            show this help message and exit
  -f, --apxfile filaname-apx
                        .apx file to read or write
  -F, --stafile filaname-sta
                        .sta file to read or write
  -e, --extract-apx dir
                        extract contents of the Station.apx file
  -E, --extract-sta dir
                        extract contents of the .sta file
  -a, --assemble-apx manifestpath
                        create Station.apx file based on apx_manifest.ini
  -A, --assemble-sta manifestpath
                        create a .sta file from files in sta_manifest.ini
  -d, --decompress      decompress Station.apx sections that are compressed
  -x, --hexdump         print hexdump of Station.apx with header information
  -B, --include-apd     include Station.apd when creating .sta archive
  -r, --restart-offsets
                        restart offsets at 0 for each section in hexdump print (useful for diffing)

सहायता काफी हद तक स्व-व्याख्यात्मक होनी चाहिए। सामान्य तौर पर, बड़े अक्षरों वाले संक्षिप्त विकल्प .sta फ़ाइलों पर काम करते हैं, और छोटे अक्षरों वाले विकल्प .apx फ़ाइलों पर काम करते हैं। उपयोग के कुछ उदाहरण नीचे दिए गए हैं।

.sta फ़ाइल की सामग्री को "extracted" निर्देशिका में निकालने के लिए, आप उपयोग करेंगे:

root@kitploit:~
python apxutil.py -F archive.sta -E extracted

Station.apx की सामग्री को "contents" निर्देशिका में निकालने के लिए, आप उपयोग करेंगे:

root@kitploit:~
python apxutil.py -f extracted/BinAppli/Station.apx -e contents -d

"-d" विकल्प का अर्थ है कि संपीड़ित सेक्शन डीकंप्रेस किए जाएंगे, लेकिन यदि (सभी) कच्चा सेक्शन डेटा चाहिए तो इसे छोड़ा जा सकता है।

Station.apx को पुनः जोड़ने के लिए, आप उपयोग करेंगे:

root@kitploit:~
python apxutil.py -f extracted/BinAppli/Station.apx -a contents

यह contents निर्देशिका में पाए गए apx_manifest.ini के आधार पर Station.apx को जोड़ेगा, यदि सेक्शन डेटा पहले डीकंप्रेस किया गया था तो उसे संपीड़ित करेगा। सेक्शन आकार और CRC का पुनर्गणना किया जाएगा, और apx_manifest.ini से नहीं पढ़ा जाएगा।

.sta फ़ाइल को पुनः जोड़ने के लिए, आप उपयोग करेंगे:

root@kitploit:~
python apxutil.py -F modified-archive.sta -A extracted

यह डिफ़ॉल्ट रूप से Station.apd फ़ाइल को छोड़ देगा (जो मुख्य रूप से Station.apx फ़ाइल हेडर के लिए एक अखंडता जांच प्रतीत होती है)। यदि आप चाहते हैं कि इसे शामिल किया जाए, तो "-B" विकल्प जोड़ें। लेकिन इसका मतलब यह हो सकता है कि Control Expert Classic प्रोजेक्ट संग्रह फ़ाइल को खोलने में विफल हो जाए।

Station.apx फ़ाइल की सामग्री को सीधे "देखने" के लिए, निम्न कमांड का उपयोग किया जा सकता है:

root@kitploit:~
python apxutil.py -F modified-archive.sta -x

यह Station.apx फ़ाइल का "canonical hexdump" आउटपुट करेगा, जिसका अर्थ है कि आप ऑफसेट, हेक्स डेटा और ASCII डेटा, एक बार में 16 बाइट्स, मेटाडेटा सहित देखेंगे। "-d" विकल्प का उपयोग संपीड़ित सेक्शन को डीकंप्रेस करने के लिए किया जा सकता है (लेकिन सावधान रहें कि उस स्थिति में ऑफसेट का कोई खास मतलब नहीं होता)। "-r" विकल्प का उपयोग प्रत्येक सेक्शन के लिए ऑफसेट को 0 पर पुनः आरंभ करने के लिए किया जा सकता है। यह उपयोगी है यदि आपने परिवर्तन किए हैं और उन्हें बिना ऑफसेट के "diff" करने में सक्षम होना चाहते हैं।

APX फ़ाइल प्रारूप संरचना

यदि आप APX फ़ाइल प्रारूप को समझना चाहते हैं (मेरे और इस उपकरण के स्तर तक), तो सबसे अच्छा तरीका वास्तव में apxutil.py के स्रोत कोड को देखना है। कोड को थोड़े प्रोग्रामिंग अनुभव के साथ भी पढ़ना बहुत कठिन नहीं होना चाहिए। लेकिन यह वास्तविक प्रोग्रामर को मिचली दे सकता है। किसी भी स्थिति में, फ़ाइल प्रारूप का एक उच्च-स्तरीय अवलोकन यहां दिया गया है। APX फ़ाइल 32 बाइट लंबे फ़ाइल हेडर से शुरू होती है। फ़ाइल का शेष भाग विभिन्न सेक्शनों में विभाजित है, प्रत्येक की समान संरचना है। प्रत्येक सेक्शन एक सेक्शन हेडर से शुरू होता है, जिसकी लंबाई सेक्शन प्रकार पर निर्भर करती है (हेडर की शुरुआत में परिभाषित)। सेक्शन हेडर के बाद एक RTE (हेडर) आता है। RTE के बाद सेक्शन डेटा आता है (यदि ऐसा मौजूद है)। और सेक्शन डेटा के बाद अगला सेक्शन (हेडर) शुरू होता है। ऐसा प्रतीत होता है कि सेक्शन हेडर Station.apx प्रारूप से अधिक संबंधित है और RTE निष्पादन वातावरण (RunTime Environment या RealTime Environment शायद?) से अधिक संबंधित है, लेकिन यह एक स्पष्ट अंतर नहीं है।

APX फ़ाइल हेडर

APX फ़ाइल हेडर 32 बाइट लंबा होता है और ASCII टेक्स्ट "APX" से शुरू होता है, उसके बाद कुछ मेटाडेटा होता है। शायद सबसे महत्वपूर्ण बात, यह उपयोग किए गए RTE के प्रकार और आकार को परिभाषित करता है। टाइप 0x02 वह है जो मैंने देखा है। यह संभावना लगती है कि टाइप 0x01 16-बिट एड्रेस स्पेस के लिए है और टाइप 0x02 32-बिट एड्रेस स्पेस के लिए है, लेकिन यह निश्चित से बहुत दूर है। कुछ अज्ञात हैं जिनका संभवतः कुछ महत्व है। कुछ 32-बिट मान और एक 16-बिट मान सेक्शन "SD" 0x0001 में "दोहराए" जाते हैं, लेकिन उनका अर्थ अज्ञात है। अंतिम 11 बाइट हमेशा शून्य प्रतीत होते हैं। नीचे एक उदाहरण है (canonical hexdump प्रारूप में, मेटाडेटा के साथ):

root@kitploit:~
00000000  41 50 58 00 00 01 02 01 10 01 10 60 f6 c3 30 00  |APX........`..0.| ApxFileHeader(magic=0x00585041, version_maybe=0x0100, rte_type=0x02, header_count_maybe=0x01, sdsection_total_size=0x0110, rte_size=0x10, sdsection_39_4=0x30c3f660, sdsection_35_4=0x0b926500, sesection_8_2=0x0106, zero_pad_21_11=0000000000000000000000)
00000010  65 92 0b 06 01 00 00 00 00 00 00 00 00 00 00 00  |e...............|

APX सेक्शन हेडर

APX सेक्शन हेडर इसके प्रकार को परिभाषित करने वाले 16-बिट मान से शुरू होता है। प्रकार 0x0001 - 0x0004 मान्य प्रतीत होते हैं, लेकिन मैंने केवल प्रकार 0x0000, 0x0001 और 0x0002 देखे हैं। सेक्शन हेडर की लंबाई प्रकार पर निर्भर करती है। 0x0000 के लिए लंबाई 8 बाइट है, 0x0001 - 0x0002 के लिए यह 16 बाइट है और प्रकार 0x0003 - 0x0004 के लिए यह 24 बाइट होनी चाहिए। सेक्शन संख्या बाइट ऑफसेट 4 पर 16-बिट मान द्वारा दी गई है। सेक्शन प्रकार 0x0000 और 0x0001 के लिए, मैं बस इतना जानता हूं, और उनके पास कोई सेक्शन डेटा नहीं है। सेक्शन प्रकार 0x0002 के लिए, बाइट ऑफसेट 10 पर 32-बिट मान Station.apx फ़ाइल में मौजूद सेक्शन डेटा का आकार निर्दिष्ट करता है।

APX RTE

सेक्शन हेडर के बाद आने वाला RTE हेडर 16 बाइट लंबा होता है (कम से कम प्रकार 0x02 के लिए)। पहले 32-बिट मान का अर्थ अज्ञात है (लेकिन यहां "block_count" नाम दिया गया है)। ऑफसेट 4 से शुरू होने वाला 32-बिट मान सेक्शन डेटा आकार (सेक्शन हेडर से) घटा 1 है, यदि सेक्शन में डेटा है। यदि सेक्शन में डेटा नहीं है, तो अर्थ अज्ञात है (और सेक्शन 0x0011 इस नियम को तोड़ता है)। बाइट ऑफसेट 8 से शुरू होने वाला 32-बिट मान विशेषताएँ/फ़्लैग हैं, जिनमें से अधिकांश का अर्थ अज्ञात है। कुछ विचार apxutil.py के अंत में सूचीबद्ध हैं। बाइट ऑफसेट 12 से शुरू होने वाला 16-बिट मान सेक्शन डेटा का CRC16/Kermit चेकसम है (और फिर से, सेक्शन 0x0011 इस नियम को तोड़ता है)। बाइट 14 के 3 उच्च बिट मेमोरी क्षेत्र को परिभाषित करते हैं और निम्न 5 बिट मेमोरी फोलियो को। अंतिम बाइट 15 संभवतः अप्रयुक्त है।

APX सेक्शन डेटा

सेक्शन डेटा सामान्य रूप से "कच्चा" डेटा होता है, जिसमें निष्पादन योग्य कोड, प्रोजेक्ट जानकारी, संपीड़ित डेटा आदि शामिल हो सकते हैं। ऐसा प्रतीत होता है कि यदि RTE विशेषताओं में बिट 13 सेट है, तो सेक्शन डेटा संपीड़ित है। देखे गए संपीड़न प्रकार zip/"pk", गैर-मानक हेडर के साथ zlib और "raw deflate" हैं।

उल्लेखनीय सेक्शन

जबकि सभी सेक्शनों का अपना अर्थ होता है, ऐसा प्रतीत होता है कि सेक्शन 0x0001 "RT" और 0x0011 "SD" बाकी की तुलना में मौलिक हैं। वे RTE और PLC निष्पादन वातावरण के वास्तविक मेमोरी लेआउट से संबंधित प्रतीत होते हैं। इन सेक्शनों का आंशिक डिकोडिंग apxutil.py के अंत की ओर शामिल है, लेकिन वर्तमान में उपकरण द्वारा स्वयं उपयोग नहीं किया जाता है।

शेष रहस्य

यदि कोई जांच करना चाहता है तो बहुत सारे "आसानी से तोड़े जाने वाले" (low hanging) फल हैं। कुछ खुले प्रश्न:

  • निष्पादन योग्य डेटा कहाँ संग्रहीत है? एक सेक्शन में या कई में?
  • पासवर्ड कहाँ संग्रहीत हैं, और पासवर्ड सुरक्षा/एन्क्रिप्शन कैसे काम करता है?
  • APX सेक्शन हेडर और RTE फ़ील्ड के अधिक अपारदर्शी भागों का विस्तृत अर्थ क्या है?
  • विभिन्न सेक्शनों में कौन सा डेटा निहित है?
  • सेक्शन संख्या का क्या अर्थ है? ऐसा प्रतीत होता है कि कुछ संख्याएँ "हार्ड-कोडेड" हैं जबकि अन्य गतिशील हैं। यदि आप इस पर काम करने में रुचि रखते हैं, तो बेझिझक रिपो को फोर्क करें और जारी रखें, या शायद एक PR सबमिट करें।
टूल डाउनलोड करें