finngineering/apxutilUma ferramenta para manipular arquivos de arquivo de PLC da Schneider Electric
Esta ferramenta pode extrair e remontar arquivos de "archive" de CLPs, usados por vários CLPs Schneider Electric, incluindo pelo menos M580, M340 e Quantum. Os arquivos de archive com extensão .sta são na verdade um arquivo zip contendo alguns arquivos. Dentro do archive, o arquivo verdadeiramente importante é chamado Station.apx. O conteúdo desse arquivo é o que é transferido para/de dentro do CLP durante um download/upload (completo) de programa. Naturalmente, ele contém o código executável real do programa do CLP. Mas também contém todas as informações necessárias para editar o programa do CLP no Control Expert Classic (ou Unity Pro). O formato do arquivo .apx é proprietário, e pouca informação sobre ele está disponível. Um pouco de informação está disponível em Liras en la red e Team82, mas este trabalho vai mais fundo do que o que eles publicaram. Com esta ferramenta, as diferentes "seções" do Station.apx podem ser extraídas (e descomprimidas, se necessário) para exame. A ferramenta também pode remontar o Station.apx a partir de dados e metadados de seções previamente extraídos - e talvez modificados. E este arquivo remontado abrirá sem erros no Control Expert Classic / Unity Pro, desde que as alterações feitas não quebrem a "lógica das seções".
Nunca houve um grande plano com este projeto. Uso CLPs Schneider Electric de vez em quando e estava interessado em como eles funcionam (ou não) em um nível mais fundamental. Acabou que essa investigação foi adequadamente complexa para me manter entretido (provavelmente como resolver palavras-cruzadas é para pessoas normais), e acabei com esta ferramenta.
A ferramenta faz o seu melhor para extrair e remontar os arquivos com os quais trabalha. No entanto, o usuário deve estar ciente de que a ferramenta foi desenvolvida com:
Usar arquivos remontados em um CLP real pode causar problemas, especialmente se você tiver modificado as seções ou metadados. É até possível que possa danificar permanentemente o CLP. Portanto, faça upload de arquivos de archive modificados para o CLP por sua própria conta e risco.
A ferramenta é usada a partir da linha de comando com o interpretador 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]
Ferramenta para manipular arquivos .sta e .apx da Schneider Electric
opções:
-h, --help mostrar esta mensagem de ajuda e sair
-f, --apxfile filaname-apx
arquivo .apx para ler ou escrever
-F, --stafile filaname-sta
arquivo .sta para ler ou escrever
-e, --extract-apx dir
extrair o conteúdo do arquivo Station.apx
-E, --extract-sta dir
extrair o conteúdo do arquivo .sta
-a, --assemble-apx manifestpath
criar arquivo Station.apx baseado em apx_manifest.ini
-A, --assemble-sta manifestpath
criar um arquivo .sta a partir de arquivos em sta_manifest.ini
-d, --decompress descomprimir seções do Station.apx que estão comprimidas
-x, --hexdump imprimir hexdump do Station.apx com informações de cabeçalho
-B, --include-apd incluir Station.apd ao criar archive .sta
-r, --restart-offsets
reiniciar offsets em 0 para cada seção na impressão do hexdump (útil para diff)
A ajuda deve ser bastante autoexplicativa. Geralmente, opções abreviadas com letras maiúsculas funcionam em arquivos .sta, e letras minúsculas funcionam em arquivos .apx. Alguns exemplos de uso são fornecidos abaixo.
Para extrair o conteúdo de um arquivo .sta para o diretório "extracted", você usaria:
python apxutil.py -F archive.sta -E extracted
Para extrair o conteúdo do Station.apx para o diretório "contents", você usaria:
python apxutil.py -f extracted/BinAppli/Station.apx -e contents -d
A opção "-d" significa que as seções comprimidas serão descomprimidas, mas pode ser omitida se os dados brutos da seção (todos) forem desejados.
Para remontar o Station.apx, você usaria:
python apxutil.py -f extracted/BinAppli/Station.apx -a contents
Isto irá montar o Station.apx com base no apx_manifest.ini encontrado no diretório contents, comprimindo os dados da seção se eles foram previamente descomprimidos. Os tamanhos das seções e CRCs serão recalculados, e não lidos do apx_manifest.ini.
Para remontar um arquivo .sta, você usaria:
python apxutil.py -F modified-archive.sta -A extracted
Por padrão, isso irá omitir o arquivo Station.apd (que parece ser principalmente uma verificação de integridade para o cabeçalho do arquivo Station.apx). Se você quiser que ele seja incluído, adicione a opção "-B". Mas isso pode muito bem significar que o Control Expert Classic falhará ao abrir o arquivo de projeto do archive.
Para "visualizar" diretamente o conteúdo do arquivo Station.apx, o seguinte comando pode ser usado:
python apxutil.py -F modified-archive.sta -x
Isso irá gerar um "hexdump canônico" do arquivo Station.apx, ou seja, você vê os offsets, dados hexadecimais e dados ASCII, 16 bytes por vez, incluindo os metadados. A opção "-d" pode ser usada para descomprimir seções comprimidas (mas cuidado: os offsets fazem pouco sentido nesse caso). A opção "-r" pode ser usada para reiniciar o offset em 0 para cada seção. Isso é útil se você fez alterações e deseja poder fazer "diff" delas sem offsets.
Se você quiser entender o formato de arquivo APX (no nível de mim mesmo e desta ferramenta), a melhor maneira é realmente olhar o código-fonte do apxutil.py. O código não deve ser muito difícil de ler mesmo com pouca experiência em programação. Mas pode deixar programadores de verdade enjoados. De qualquer forma, uma visão geral de alto nível do formato de arquivo é fornecida aqui. O arquivo APX começa com um cabeçalho de arquivo de 32 bytes. O resto do arquivo é dividido em diferentes seções, cada uma com uma estrutura semelhante. Cada seção começa com um cabeçalho de seção, cujo comprimento depende do tipo de seção (definido no início do cabeçalho). O cabeçalho de seção é seguido por um RTE (cabeçalho). Após o RTE, vêm os dados da seção (se presentes). E após os dados da seção, começa a próxima seção (cabeçalho). Parece que o cabeçalho de seção está mais relacionado ao formato Station.apx e o RTE está mais relacionado ao ambiente de execução (RunTime Environment ou RealTime Environment talvez?), mas não é uma distinção clara.
O cabeçalho do arquivo APX tem 32 bytes de comprimento e começa com o texto ASCII "APX", seguido por alguns metadados. Talvez o mais importante, ele define o tipo e o tamanho do RTE usado. O tipo 0x02 é o que vi. Parece provável que o tipo 0x01 seja para espaço de endereçamento de 16 bits e o tipo 0x02 para espaço de endereçamento de 32 bits, mas isso está longe de ser certo. Existem algumas incógnitas que provavelmente têm algum significado. Um par de valores de 32 bits e um valor de 16 bits são "repetidos" na seção "SD" 0x0001, mas seu significado é desconhecido. Os últimos 11 bytes parecem ser sempre zeros. Um exemplo abaixo (em formato de hexdump canônico, com metadados):
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...............|
O cabeçalho de seção APX começa com um valor de 16 bits que define seu tipo. Os tipos 0x0001 - 0x0004 parecem ser válidos, mas só vi tipos 0x0000, 0x0001 e 0x0002. O comprimento do cabeçalho de seção depende do tipo. Para 0x0000, o comprimento é de 8 bytes, para 0x0001 - 0x0002 é de 16 bytes e para tipos 0x0003 - 0x0004 deve ser de 24 bytes. O número da seção é dado por um valor de 16 bits no deslocamento de byte 4. Para tipos de seção 0x0000 e 0x0001, isso é tudo que sei, e eles não têm dados de seção. Para o tipo de seção 0x0002, o valor de 32 bits no deslocamento de byte 10 especifica o tamanho dos dados da seção, conforme presente no arquivo Station.apx.
O cabeçalho RTE que segue o cabeçalho de seção tem 16 bytes de comprimento (pelo menos para o tipo 0x02). O significado do primeiro valor de 32 bits é desconhecido (mas aqui chamado de "block_count"). O valor de 32 bits começando no deslocamento 4 é o tamanho dos dados da seção (do cabeçalho da seção) menos 1, caso a seção tenha dados. Se a seção não tiver dados, o significado é desconhecido (e a seção 0x0011 quebra esta regra). O valor de 32 bits começando no deslocamento de byte 8 são atributos/flags, cujo significado é em grande parte desconhecido. Alguns pensamentos estão listados no final do apxutil.py. O valor de 16 bits começando no deslocamento de byte 12 é a soma de verificação CRC16/Kermit dos dados da seção (e novamente, a seção 0x0011 quebra esta regra). Os 3 bits altos do byte 14 definem a área de memória e os 5 bits baixos definem o fólio de memória. O último byte 15 provavelmente não é usado.
Os dados da seção são geralmente dados "brutos", que podem conter código executável, informações do projeto, dados comprimidos, etc. Parece que se o bit 13 nos atributos RTE estiver definido, então os dados da seção estão comprimidos. Os tipos de compressão vistos são zip/"pk", zlib com cabeçalho não padrão e "raw deflate".
Embora todas as seções tenham seu próprio significado, parece que as seções 0x0001 "RT" e 0x0011 "SD" são mais fundamentais que as outras. Elas parecem estar relacionadas aos RTEs e à disposição real da memória do ambiente de execução do CLP. Uma decodificação parcial dessas seções está incluída no final do apxutil.py, mas atualmente não é usada pela própria ferramenta.
Há muitas "frutas baixas" caso alguém queira investigar. Algumas perguntas em aberto: