이 문자 집합 손상은 무엇입니까? (ISO-2022?)

이 문자 집합 손상은 무엇입니까? (ISO-2022?)

손상된 문자가 포함된 레거시 소스의 텍스트 파일이 있습니다.

처음에 나는 그 손상이 단지 멍청한 것이라고 생각했지만 자세히 살펴보면 손상된 텍스트 중 일부가 아마도 재구성될 수 있는 것으로 나타났습니다.

노력에 집중하려면 원본을 완전히 재구성할 수는 없더라도 원본이 어떤 모습인지 이해하는 것이 도움이 될 것입니다.

불행하게도 이 문서는 제가 자유롭게 공유할 수 없는 컬렉션에서 가져온 것입니다. 여기에 일부 내용이 있습니다. 메시지가 UTF-8로 변환되었지만 어딘가에서 변환이 실패하여 대부분 읽을 수 없습니다. 체코어로 된 텍스트 조각이 표시됩니다. 여기서 악센트가 있는 체코어 문자는 키릴 문자로 대체되었습니다(변환 전에는 완전히 다른 문자였을 것임).

0001f80: 33d1 936e 6576 79d1 87d0 bd7a 656e d18c  3..nevy....zen..
0001f90: 6368 7e58 3833 d193 7e58 3945 d19b d0b1  ch~X83..~X9E....
0001fa0: 646f 7374 d0bd 7e58 3833 d193 6e61 7e58  dost..~X83..na~X
0001fb0: 3833 d193 7ad1 87d0 bd7a 656e 20d0 bd7e  83..z....zen ..~
0001fc0: 5838 33d1 936e 6562 6f7e 5838 33d1 9370  X83..nebo~X83..p
0001fd0: d187 656b 6cd0 b164 6b75 7e58 3833 d193  ..ekl..dku~X83..
0001fe0: 7465 6c65 666f 6e6e d0bd 7e58 3833 d193  telefonn..~X83..
0001ff0: 7374 616e 6963 657e 5838 33d1 9376 207e  stanice~X83..v ~
0002000: 5838 33d1 9372 6567 696f 6e75 7e58 3833  X83..regionu~X83
0002010: d193 5072 6168 617e 5838 33d1 9365 7669  ..Praha~X83..evi
0002020: 6475 6a65 7e58 3833 d193 5350 547e 5838  duje~X83..SPT~X8
0002030: 33d1 9354 656c 6563 6f6d 2e7e 5838 33d1  3..Telecom.~X83.
0002040: 934e 617e 5838 33d1 9364 6e65 7e58 2039  .Na~X83..dne~X 9
0002050: 41d1 996e d0bd 7e58 3833 d193 7469 736b  A..n..~X83..tisk
0002060: 6f76 d0b9 7e58 3833 d193 6b6f 6e66 6572  ov..~X83..konfer
0002070: 656e 6369 7e58 3833 d193 746f 7e58 3833  enci~X83..to~X83
0002080: d193 d187 656b 6c7e 5838 33d1 93d1 8765  ....ekl~X83....e

나는 인코딩이 다음과 관련이 있을 것이라고 막연하게 추측하고 있습니다.ISO-2022, 하지만 실제로 확신할 만큼 익숙하지 않습니다. 분명히 이렇게 되기 전에 적어도 하나의 깨진 필터(아마도 여러 개)를 거쳤을 것입니다.

첫 번째 줄을 보면 d1 93ѓ이며 변환 전 단일 8비트 바이트였을 것입니다. 일반적인 패턴 ~XFF뒤에는 신호 바이트가 오는 것 같습니다. 여기서 FF는 일반 ASCII의 16진수 시퀀스(여기서는 대부분 83이지만 일반적으로 전체 샘플에서는 80에서 9E까지)이며 마지막 바이트는 이제 UTF-8 문자입니다. . (물론 입력에 여러 바이트가 있을 수도 있습니다.) 이 시퀀스는 단어 사이(항상 ~X83ѓ?)에 나타나며 때로는 단어 내에 나타납니다.

이제 UTF-8로 렌더링되므로 텍스트와 동일한 조각이 있습니다.

3ѓnevyчнzenьch~X83ѓ~X9Eћбdostн~X83ѓna~X83ѓzчнzen н~X83ѓnebo
~X83ѓpчeklбdku~X83ѓtelefonnн~X83ѓstanice~X83ѓv ~X83ѓregionu
~X83ѓPraha~X83ѓeviduje~X83ѓSPT~X83ѓTelecom.~X83ѓNa~X83ѓdne~
X 9Aљnн~X83ѓtiskovй~X83ѓkonferenci~X83ѓto~X83ѓчekl~X83ѓчe

나는 다른 언어로 된 다른 샘플을 가지고 있기 때문에 체코어를 정리하는 것은 실제로 내 초점이 아닙니다. 이것은 아마도 극동 언어로 된 것의 시작 부분입니다.

 X1B%0 ~XD0^?~X98^?~XD0^?^?^?~X82^?~XD0^?~XB5^?^?~X80^?^?~X84^?~XD0^?~XB0^?~XD0
^?^?^?~X81^? ~XD0^?~XB1^?^?~X83^?~XD0^?^?~XD0^?~XB2^?~XD0^?~XB0^?~XD0^?^?^?~X8C
^?~XD0^?^?~XD0^?~XBE^? ~XD0^?~XB7^?~XD0^?~XB0^? ~XD0^?^?~XD0^?~XB5^?^?~X81^?~XD
0^?^?~XD0^?~XBE^?~XD0^?^?^?~X8C^?~XD0^?^?~XD0^?~XBE^? ~XD0^?^?~XD0^?~XB8^?~XD0^
?^?^?~X83^?^?~X82^? ~XD0^?~XB4^?~XD0^?~XBE^? ^?~X81^?~

( ^?:s는 리터럴 DEL 문자, ASCII 0x7F입니다.)

시작 부분의 물결표 위치에 있는 공백은 변환에서 무엇이 잘못되었는지에 대한 힌트일 수 있지만 이는 터무니없는 추측입니다.

ESC는 % 0"다른 코딩 시스템을 지정"하기 위한 ISO-2022 코드처럼 보이지만 0여기서는 무엇을 의미합니까? 추가 예제 없이 Wikipedia 기사를 이해하기에는 너무 밀도가 높을 수 있으며, 내가 찾을 수 있는 다른 모든 내용은 ISO-2022-JP와 같은 일부 하위 집합에 중점을 둔 것 같습니다.

지금까지의 분석이 이해가 되시나요? 무슨 일이 일어났는지 파악하는 데 도움을 주고 부패를 되돌리는 방법에 대한 조언도 제공해 주실 수 있나요?

나는 이 두 예제의 확장된 조각에 대한 16진 덤프를 게시했습니다.http://pastebin.com/ffn7CtdG

답변1

이 답변에서는 이러한 파일의 소스에 대한 내 생각을 자세히 설명합니다. 더 자세한 포렌식 분석을 위해서는 적어도 전체 파일의 일부 하위 집합에 대한 직접 액세스가 필요하기 때문에 이것은 완전한 대답은 아닙니다.

내가 본 단편에서 나를 놀라게 하는 몇 가지 사항은 다음과 같습니다.

  1. 단어는 체코어로 되어 있습니다.
  2. 단어를 구분하는 이상한 순서가 있고 많이 반복됩니다.
  3. 이러한 이상한 시퀀스는 UTF-8 문자로 구성되어 있으며 그 중 일부는 본질적으로 키릴 문자라는 점을 제외하면 전혀 의미가 없습니다.

내 결론은 이 파일이 원래 텍스트 파일이 아니었지만 키릴 문자가 포함된 코드 페이지를 사용하여 마치 텍스트인 것처럼 UTF-8로 잘못 변환되었다는 것입니다.

예를 들어, 의 편재적 순서는 d193키릴 문자입니다.작은 gje다른 코드 페이지 표현은 다음과 같습니다.

영상

이를 통해 원본 운영 체제에 따라 원본 파일의 가능한 인코딩 목록이 제공됩니다. Windows 컴퓨터에서 생성된 경우 원래 코드 페이지는 아마도 Windows-1251이었을 것입니다. 그러나 Mac에서는 아마도 Macintosh Cyrillic이었을 것입니다. 물론 UTF-8로의 변환이 잘못된 인코딩을 사용했을 수도 있습니다.

예를 들어 시퀀스를 찾습니다 SPT~X83..Telecom. "SPT Telecom"이라는 회사는 1993년에 설립된 체코 국영 통신 회사입니다. 이 회사가 Reuters 뉴스에 등장하는 것은 매우 논리적입니다. 그러나 두 단어 사이의 공백 옆에 ​​구분 기호가 있을 이유가 없습니다.

단어들 사이에서 반복되는 이 수수께끼 같은 문자열에 대한 나의 설명은 그것이 텍스트의 일부가 아니었고, 될 수도 없다는 것입니다. 나는 그 단어가 단어 사이에 배치된 이진 문자였음에 틀림없다고 생각하며, 이는 아마도 파일 형식과 관련이 있을 것입니다. 따라서 파일을 UTF-8로 변환한 변환 프로그램은 파일을 무의미한 UTF-8 문자로 맹목적으로 변환했습니다.

위 목록의 코드 페이지를 사용하여 이 시퀀스를 바이너리로 변환하려고 시도하더라도 의미 있는 시퀀스를 얻지 못합니다. 그러나 나는 표시할 목적이 아니라 표시를 제어하기 위한 목적으로 텍스트에 "보이지 않는" 문자를 배치한 일부 오래된 텍스트 편집기에서 가져온 텍스트 파일에 대한 경험이 있습니다.

나는 이것이 이 파일들에 대한 설명이라고 생각하지만, 나는 이 이상한 파일 형식을 모른다. 그것은 알려지지 않은 체코어 텍스트 편집기일 수도 있습니다(적어도 나에게는 알려지지 않았습니다). 파일에서 텍스트에 포함된 날짜를 검색할 수 있으면 가능성을 좁히는 데 도움이 될 수 있습니다.

나는 원본 파일이 잘 구성되고 인코딩되어 있다는 당신의 이론을 믿지 않습니다.ISO-2022, 이러한 이상한 시퀀스는 ISO-2022 제어 시퀀스가 ​​아닌 것 같기 때문입니다.

관련 정보