
Schneider Electric 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 का उपयोग करता हूं, और यह जानने में दिलचस्पी थी कि वे अधिक मौलिक स्तर पर कैसे काम करते हैं (या नहीं करते)। यह पता चला कि यह जांच मुझे मनोरंजित रखने के लिए पर्याप्त जटिल थी (शायद जैसे सामान्य लोगों के लिए वर्ग पहेली हल करना), और मैं इस उपकरण के साथ समाप्त हुआ।
यह उपकरण अपनी पूरी क्षमता से उन फ़ाइलों को निकालने और पुनः जोड़ने का प्रयास करता है जिनके साथ यह काम करता है। हालाँकि, उपयोगकर्ता को पता होना चाहिए कि यह उपकरण निम्नलिखित के साथ विकसित किया गया था:
वास्तविक PLC पर पुनः जोड़ी गई फ़ाइलों का उपयोग करने से समस्याएँ हो सकती हैं, खासकर यदि आपने सेक्शन या मेटाडेटा को संशोधित किया है। यह संभव है कि यह PLC को ब्रिक (brick) कर सकता है। इसलिए संशोधित संग्रह फ़ाइलों को PLC पर अपने जोखिम पर अपलोड करें।
यह उपकरण पायथन इंटरप्रेटर के साथ कमांड लाइन से उपयोग किया जाता है:
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" निर्देशिका में निकालने के लिए, आप उपयोग करेंगे:
python apxutil.py -F archive.sta -E extracted
Station.apx की सामग्री को "contents" निर्देशिका में निकालने के लिए, आप उपयोग करेंगे:
python apxutil.py -f extracted/BinAppli/Station.apx -e contents -d
"-d" विकल्प का अर्थ है कि संपीड़ित सेक्शन डीकंप्रेस किए जाएंगे, लेकिन यदि (सभी) कच्चा सेक्शन डेटा चाहिए तो इसे छोड़ा जा सकता है।
Station.apx को पुनः जोड़ने के लिए, आप उपयोग करेंगे:
python apxutil.py -f extracted/BinAppli/Station.apx -a contents
यह contents निर्देशिका में पाए गए apx_manifest.ini के आधार पर Station.apx को जोड़ेगा, यदि सेक्शन डेटा पहले डीकंप्रेस किया गया था तो उसे संपीड़ित करेगा। सेक्शन आकार और CRC का पुनर्गणना किया जाएगा, और apx_manifest.ini से नहीं पढ़ा जाएगा।
.sta फ़ाइल को पुनः जोड़ने के लिए, आप उपयोग करेंगे:
python apxutil.py -F modified-archive.sta -A extracted
यह डिफ़ॉल्ट रूप से Station.apd फ़ाइल को छोड़ देगा (जो मुख्य रूप से Station.apx फ़ाइल हेडर के लिए एक अखंडता जांच प्रतीत होती है)। यदि आप चाहते हैं कि इसे शामिल किया जाए, तो "-B" विकल्प जोड़ें। लेकिन इसका मतलब यह हो सकता है कि Control Expert Classic प्रोजेक्ट संग्रह फ़ाइल को खोलने में विफल हो जाए।
Station.apx फ़ाइल की सामग्री को सीधे "देखने" के लिए, निम्न कमांड का उपयोग किया जा सकता है:
python apxutil.py -F modified-archive.sta -x
यह Station.apx फ़ाइल का "canonical hexdump" आउटपुट करेगा, जिसका अर्थ है कि आप ऑफसेट, हेक्स डेटा और ASCII डेटा, एक बार में 16 बाइट्स, मेटाडेटा सहित देखेंगे। "-d" विकल्प का उपयोग संपीड़ित सेक्शन को डीकंप्रेस करने के लिए किया जा सकता है (लेकिन सावधान रहें कि उस स्थिति में ऑफसेट का कोई खास मतलब नहीं होता)। "-r" विकल्प का उपयोग प्रत्येक सेक्शन के लिए ऑफसेट को 0 पर पुनः आरंभ करने के लिए किया जा सकता है। यह उपयोगी है यदि आपने परिवर्तन किए हैं और उन्हें बिना ऑफसेट के "diff" करने में सक्षम होना चाहते हैं।
यदि आप APX फ़ाइल प्रारूप को समझना चाहते हैं (मेरे और इस उपकरण के स्तर तक), तो सबसे अच्छा तरीका वास्तव में apxutil.py के स्रोत कोड को देखना है। कोड को थोड़े प्रोग्रामिंग अनुभव के साथ भी पढ़ना बहुत कठिन नहीं होना चाहिए। लेकिन यह वास्तविक प्रोग्रामर को मिचली दे सकता है। किसी भी स्थिति में, फ़ाइल प्रारूप का एक उच्च-स्तरीय अवलोकन यहां दिया गया है। APX फ़ाइल 32 बाइट लंबे फ़ाइल हेडर से शुरू होती है। फ़ाइल का शेष भाग विभिन्न सेक्शनों में विभाजित है, प्रत्येक की समान संरचना है। प्रत्येक सेक्शन एक सेक्शन हेडर से शुरू होता है, जिसकी लंबाई सेक्शन प्रकार पर निर्भर करती है (हेडर की शुरुआत में परिभाषित)। सेक्शन हेडर के बाद एक RTE (हेडर) आता है। RTE के बाद सेक्शन डेटा आता है (यदि ऐसा मौजूद है)। और सेक्शन डेटा के बाद अगला सेक्शन (हेडर) शुरू होता है। ऐसा प्रतीत होता है कि सेक्शन हेडर Station.apx प्रारूप से अधिक संबंधित है और RTE निष्पादन वातावरण (RunTime Environment या RealTime Environment शायद?) से अधिक संबंधित है, लेकिन यह एक स्पष्ट अंतर नहीं है।
APX फ़ाइल हेडर 32 बाइट लंबा होता है और ASCII टेक्स्ट "APX" से शुरू होता है, उसके बाद कुछ मेटाडेटा होता है। शायद सबसे महत्वपूर्ण बात, यह उपयोग किए गए RTE के प्रकार और आकार को परिभाषित करता है। टाइप 0x02 वह है जो मैंने देखा है। यह संभावना लगती है कि टाइप 0x01 16-बिट एड्रेस स्पेस के लिए है और टाइप 0x02 32-बिट एड्रेस स्पेस के लिए है, लेकिन यह निश्चित से बहुत दूर है। कुछ अज्ञात हैं जिनका संभवतः कुछ महत्व है। कुछ 32-बिट मान और एक 16-बिट मान सेक्शन "SD" 0x0001 में "दोहराए" जाते हैं, लेकिन उनका अर्थ अज्ञात है। अंतिम 11 बाइट हमेशा शून्य प्रतीत होते हैं। नीचे एक उदाहरण है (canonical hexdump प्रारूप में, मेटाडेटा के साथ):
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 सेक्शन हेडर इसके प्रकार को परिभाषित करने वाले 16-बिट मान से शुरू होता है। प्रकार 0x0001 - 0x0004 मान्य प्रतीत होते हैं, लेकिन मैंने केवल प्रकार 0x0000, 0x0001 और 0x0002 देखे हैं। सेक्शन हेडर की लंबाई प्रकार पर निर्भर करती है। 0x0000 के लिए लंबाई 8 बाइट है, 0x0001 - 0x0002 के लिए यह 16 बाइट है और प्रकार 0x0003 - 0x0004 के लिए यह 24 बाइट होनी चाहिए। सेक्शन संख्या बाइट ऑफसेट 4 पर 16-बिट मान द्वारा दी गई है। सेक्शन प्रकार 0x0000 और 0x0001 के लिए, मैं बस इतना जानता हूं, और उनके पास कोई सेक्शन डेटा नहीं है। सेक्शन प्रकार 0x0002 के लिए, बाइट ऑफसेट 10 पर 32-बिट मान Station.apx फ़ाइल में मौजूद सेक्शन डेटा का आकार निर्दिष्ट करता है।
सेक्शन हेडर के बाद आने वाला RTE हेडर 16 बाइट लंबा होता है (कम से कम प्रकार 0x02 के लिए)। पहले 32-बिट मान का अर्थ अज्ञात है (लेकिन यहां "block_count" नाम दिया गया है)। ऑफसेट 4 से शुरू होने वाला 32-बिट मान सेक्शन डेटा आकार (सेक्शन हेडर से) घटा 1 है, यदि सेक्शन में डेटा है। यदि सेक्शन में डेटा नहीं है, तो अर्थ अज्ञात है (और सेक्शन 0x0011 इस नियम को तोड़ता है)। बाइट ऑफसेट 8 से शुरू होने वाला 32-बिट मान विशेषताएँ/फ़्लैग हैं, जिनमें से अधिकांश का अर्थ अज्ञात है। कुछ विचार apxutil.py के अंत में सूचीबद्ध हैं। बाइट ऑफसेट 12 से शुरू होने वाला 16-बिट मान सेक्शन डेटा का CRC16/Kermit चेकसम है (और फिर से, सेक्शन 0x0011 इस नियम को तोड़ता है)। बाइट 14 के 3 उच्च बिट मेमोरी क्षेत्र को परिभाषित करते हैं और निम्न 5 बिट मेमोरी फोलियो को। अंतिम बाइट 15 संभवतः अप्रयुक्त है।
सेक्शन डेटा सामान्य रूप से "कच्चा" डेटा होता है, जिसमें निष्पादन योग्य कोड, प्रोजेक्ट जानकारी, संपीड़ित डेटा आदि शामिल हो सकते हैं। ऐसा प्रतीत होता है कि यदि RTE विशेषताओं में बिट 13 सेट है, तो सेक्शन डेटा संपीड़ित है। देखे गए संपीड़न प्रकार zip/"pk", गैर-मानक हेडर के साथ zlib और "raw deflate" हैं।
जबकि सभी सेक्शनों का अपना अर्थ होता है, ऐसा प्रतीत होता है कि सेक्शन 0x0001 "RT" और 0x0011 "SD" बाकी की तुलना में मौलिक हैं। वे RTE और PLC निष्पादन वातावरण के वास्तविक मेमोरी लेआउट से संबंधित प्रतीत होते हैं। इन सेक्शनों का आंशिक डिकोडिंग apxutil.py के अंत की ओर शामिल है, लेकिन वर्तमान में उपकरण द्वारा स्वयं उपयोग नहीं किया जाता है।
यदि कोई जांच करना चाहता है तो बहुत सारे "आसानी से तोड़े जाने वाले" (low hanging) फल हैं। कुछ खुले प्रश्न: