finngineering/apxutil슈나이더 일렉트릭 PLC 아카이브 파일을 조작하기 위한 도구
이 도구는 슈나이더 일렉트릭의 여러 PLC(최소한 M580, M340, Quantum)에서 사용되는 PLC "아카이브" 파일을 추출하고 재조립할 수 있습니다. .sta 확장자를 가진 아카이브 파일은 실제로 몇 개의 파일이 포함된 ZIP 아카이브입니다. 아카이브 내에서 진정으로 중요한 파일은 Station.apx라는 이름의 파일입니다. 이 파일의 내용은 (전체) 프로그램 다운로드/업로드 중 PLC로/로부터 전송되는 내용입니다. 당연히 PLC 프로그램의 실제 실행 코드가 포함되어 있습니다. 또한 Control Expert Classic(또는 Unity Pro)에서 PLC 프로그램을 편집하는 데 필요한 모든 정보도 포함되어 있습니다. .apx 파일 형식은 독점적이며 이에 대한 정보는 거의 없습니다. Liras en la red 및 Team82에서 약간의 정보를 얻을 수 있지만, 이 작업은 그들이 발표한 것보다 더 깊이 들어갑니다. 이 도구를 사용하면 Station.apx의 다양한 "섹션"을 추출하여(필요한 경우 압축 해제) 검사할 수 있습니다. 또한 이전에 추출되었거나 수정된 섹션 데이터 및 메타데이터에서 Station.apx를 재조립할 수 있습니다. 그리고 이 재조립된 파일은 변경 사항이 "섹션 로직"을 깨뜨리지 않는 한 Control Expert Classic / Unity Pro에서 오류 없이 열립니다.
이 프로젝트에는 거창한 계획이 전혀 없었습니다. 저는 가끔 슈나이더 일렉트릭 PLC를 사용하며, 더 근본적인 수준에서 PLC가 어떻게 작동하는지(또는 작동하지 않는지)에 관심이 있었습니다. 알고 보니 이 조사는 저를 지루하지 않게 하기에 적절히 복잡했고(아마도 일반인에게 크로스워드 푸는 것과 비슷할 것입니다), 결국 이 도구를 만들게 되었습니다.
이 도구는 작업하는 파일을 최선을 다해 추출하고 재조립합니다. 그러나 사용자는 이 도구가 다음 조건에서 개발되었음을 인지해야 합니다:
실제 PLC에서 재조립된 파일을 사용하면 문제가 발생할 수 있으며, 특히 섹션이나 메타데이터를 수정한 경우 더욱 그렇습니다. PLC를 벽돌로 만들 가능성도 있습니다. 따라서 수정된 아카이브 파일을 PLC에 업로드하는 것은 사용자 본인의 책임입니다.
이 도구는 명령줄에서 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)
도움말은 꽤 자명할 것입니다. 일반적으로 대문자 단축 옵션은 .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 파일의 "정규 16진 덤프"를 출력합니다. 즉, 오프셋, 16진 데이터, 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바이트는 항상 0인 것으로 보입니다. 아래 예시(정규 16진 덤프 형식, 메타데이터 포함):
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의 끝 부분에 포함되어 있지만, 현재 도구 자체에서는 사용되지 않습니다.
누군가 조사하고 싶어할 만한 "쉬운" 과제가 많이 있습니다. 몇 가지 열린 질문: