finngineering/apxutilUno strumento per manipolare i file di archivio dei PLC Schneider Electric
Questo strumento può estrarre e riassemblare file di "archivio" PLC, utilizzati da diversi PLC Schneider Electric, tra cui almeno M580, M340 e Quantum. I file di archivio con estensione .sta sono in realtà un archivio zip contenente alcuni file. All'interno dell'archivio, il file veramente importante si chiama Station.apx. Il contenuto di quel file è ciò che viene trasferito da/al PLC durante un download/upload completo del programma. Naturalmente, contiene il codice eseguibile effettivo del programma PLC. Ma contiene anche tutte le informazioni necessarie per modificare il programma PLC in Control Expert Classic (o Unity Pro). Il formato del file .apx è proprietario e sono disponibili poche informazioni al riguardo. Un po' di informazioni sono disponibili da Liras en la red e Team82, ma questo lavoro va più a fondo di quanto pubblicato da loro. Con questo strumento, le diverse "sezioni" dello Station.apx possono essere estratte (e decompresse se necessario) per l'esame. Lo strumento può anche riassemblare lo Station.apx da dati e metadati delle sezioni precedentemente estratti - e forse modificati. E questo file riassemblato si aprirà senza errori in Control Expert Classic / Unity Pro, a condizione che le modifiche apportate non rompano la "logica delle sezioni".
Non c'è mai stato un grande piano con questo progetto. Utilizzo PLC Schneider Electric di tanto in tanto e mi interessava capire come funzionano (o non funzionano) a un livello più fondamentale. Si è scoperto che questa indagine era abbastanza complessa da tenermi intrattenuto (probabilmente come risolvere cruciverba per persone normali), e ho finito per creare questo strumento.
Lo strumento fa del suo meglio per estrarre e riassemblare i file con cui lavora. Tuttavia, l'utente dovrebbe essere consapevole che lo strumento è stato sviluppato con:
L'utilizzo di file riassemblati su un PLC reale può causare problemi, specialmente se sono state modificate le sezioni o i metadati. È anche possibile che possa danneggiare il PLC. Quindi caricate file di archivio modificati sul PLC a vostro rischio.
Lo strumento viene utilizzato dalla riga di comando con l'interprete Python:
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)
L'aiuto dovrebbe essere abbastanza auto-esplicativo. In generale, le opzioni abbreviate con lettere maiuscole lavorano sui file .sta, e le lettere minuscole lavorano sui file .apx. Di seguito vengono forniti alcuni esempi di utilizzo.
Per estrarre il contenuto di un file .sta nella directory "extracted", si userà:
python apxutil.py -F archive.sta -E extracted
Per estrarre il contenuto di Station.apx nella directory "contents", si userà:
python apxutil.py -f extracted/BinAppli/Station.apx -e contents -d
L'opzione "-d" significa che le sezioni compresse verranno decompresse, ma può essere omessa se si desiderano i dati grezzi (tutte) della sezione.
Per riassemblare Station.apx, si userà:
python apxutil.py -f extracted/BinAppli/Station.apx -a contents
Questo assemblerà Station.apx basato sul file apx_manifest.ini trovato nella directory contents, comprimendo i dati delle sezioni se precedentemente decompressi. Le dimensioni delle sezioni e i CRC verranno ricalcolati e non letti da apx_manifest.ini.
Per riassemblare un file .sta, si userà:
python apxutil.py -F modified-archive.sta -A extracted
Questo ometterà per impostazione predefinita il file Station.apd (che sembra essere principalmente un controllo di integrità per l'intestazione del file Station.apx). Se si desidera includerlo, aggiungere l'opzione "-B". Ma ciò potrebbe significare che Control Expert Classic non riuscirà ad aprire il file di archivio del progetto.
Per "visualizzare" direttamente il contenuto del file Station.apx, si può usare il seguente comando:
python apxutil.py -F modified-archive.sta -x
Questo produrrà un "canonico hexdump" del file Station.apx, nel senso che si vedono gli offset, i dati esadecimali e i dati ASCII, 16 byte alla volta, inclusi i metadati. L'opzione "-d" può essere usata per decomprimere le sezioni compresse (ma attenzione: gli offset hanno poco senso in quel caso). L'opzione "-r" può essere usata per riavviare l'offset a 0 per ogni sezione. Questo è utile se sono state apportate modifiche e si desidera poterle confrontare senza offset.
Se si vuole capire il formato del file APX (al livello mio e di questo strumento), il modo migliore è davvero guardare il codice sorgente di apxutil.py. Il codice non dovrebbe essere troppo difficile da leggere anche con poca esperienza di programmazione. Ma potrebbe far venire la nausea ai veri programmatori. In ogni caso, qui viene fornita una panoramica ad alto livello del formato file. Il file APX inizia con un'intestazione file di 32 byte. Il resto del file è diviso in diverse sezioni, ciascuna con una struttura simile. Ogni sezione inizia con un'intestazione di sezione, la cui lunghezza dipende dal tipo di sezione (definito all'inizio dell'intestazione). L'intestazione di sezione è seguita da un RTE (intestazione). Dopo l'RTE vengono i dati della sezione (se presenti). E dopo i dati della sezione inizia la sezione (intestazione) successiva. Sembra che l'intestazione di sezione sia più legata al formato Station.apx e l'RTE sia più legato all'ambiente di esecuzione (Runtime Environment o Real-Time Environment?), ma non è una distinzione chiara.
L'intestazione del file APX è lunga 32 byte e inizia con il testo ASCII "APX", seguito da alcuni metadati. Forse la cosa più importante è che definisce il tipo e la dimensione dell'RTE utilizzato. Ho visto il tipo 0x02. Sembra probabile che il tipo 0x01 sia per spazio di indirizzi a 16 bit e il tipo 0x02 per spazio a 32 bit, ma questo è lungi dall'essere certo. Ci sono alcuni sconosciuti che probabilmente hanno un significato. Un paio di valori a 32 bit e un valore a 16 bit sono "ripetuti" nella sezione "SD" 0x0001, ma il loro significato è sconosciuto. Gli ultimi 11 byte sembrano essere sempre zero. Un esempio di seguito (in formato hexdump canonico, con metadati):
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...............|
L'intestazione della sezione APX inizia con un valore a 16 bit che ne definisce il tipo. I tipi da 0x0001 a 0x0004 sembrano essere validi, ma ho visto solo i tipi 0x0000, 0x0001 e 0x0002. La lunghezza dell'intestazione della sezione dipende dal tipo. Per 0x0000 la lunghezza è di 8 byte, per 0x0001 - 0x0002 è di 16 byte e per i tipi 0x0003 - 0x0004 dovrebbe essere di 24 byte. Il numero di sezione è dato da un valore a 16 bit all'offset di byte 4. Per i tipi di sezione 0x0000 e 0x0001, questo è tutto ciò che so, e non hanno dati di sezione. Per il tipo di sezione 0x0002, il valore a 32 bit all'offset di byte 10 specifica la dimensione dei dati della sezione, come presenti nel file Station.apx.
L'intestazione RTE che segue l'intestazione della sezione è lunga 16 byte (almeno per il tipo 0x02). Il significato del primo valore a 32 bit è sconosciuto (ma qui chiamato "block_count"). Il valore a 32 bit che inizia all'offset 4 è la dimensione dei dati della sezione (dall'intestazione della sezione) meno 1, nel caso in cui la sezione abbia dati. Se la sezione non ha dati, il significato è sconosciuto (e la sezione 0x0011 viola questa regola). Il valore a 32 bit che inizia all'offset di byte 8 sono attributi/flags, la maggior parte dei quali hanno significato sconosciuto. Alcune riflessioni sono elencate alla fine di apxutil.py. Il valore a 16 bit che inizia all'offset di byte 12 è il checksum CRC16/Kermit dei dati della sezione (e ancora, la sezione 0x0011 viola questa regola). I 3 bit più alti del byte 14 definiscono l'area di memoria e i 5 bit più bassi il folio di memoria. L'ultimo byte 15 è probabilmente inutilizzato.
I dati della sezione sono in generale dati "grezzi", che possono contenere codice eseguibile, informazioni di progetto, dati compressi, ecc. Sembra che se il bit 13 negli attributi RTE è impostato, allora i dati della sezione sono compressi. I tipi di compressione visti sono zip/"pk", zlib con intestazione non standard e "raw deflate".
Sebbene tutte le sezioni abbiano il proprio significato, sembra che le sezioni 0x0001 "RT" e 0x0011 "SD" siano più fondamentali delle altre. Sembrano essere correlate agli RTE e all'effettivo layout di memoria dell'ambiente di esecuzione del PLC. Una decodifica parziale di queste sezioni è inclusa verso la fine di apxutil.py, ma attualmente non è utilizzata dallo strumento stesso.
C'è molta "frutta a portata di mano" nel caso qualcuno voglia investigare. Alcune domande aperte: