ความเสียหายที่ชุดอักขระนี้คืออะไร (ISO-2022?)


4

ฉันมีไฟล์ข้อความจากแหล่งดั้งเดิมที่มีอักขระที่เสียหาย

ตอนแรกฉันคิดว่าการทุจริตเป็นแค่ gobbledygook แต่มันปรากฏขึ้นเมื่อตรวจสอบอย่างใกล้ชิดว่าข้อความที่เสียหายบางส่วนอาจถูกสร้างขึ้นใหม่

เพื่อที่จะมุ่งเน้นความพยายามของฉันมันจะเป็นประโยชน์ในการเข้าใจสิ่งที่ดูเหมือนต้นฉบับแม้ว่าฉันจะไม่สามารถสร้างใหม่ได้อย่างเต็มที่

น่าเสียดายที่เอกสารมาจากคอลเล็กชันที่ฉันไม่สามารถแชร์ได้อย่างอิสระ แต่นี่เป็นตัวอย่าง ข้อความถูกแปลงเป็น 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 ธรรมดา (ส่วนใหญ่ 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

ฉันมีตัวอย่างอื่น ๆ ในภาษาอื่น ๆ เพื่อให้การแยกเช็กไม่ได้เป็นจุดสนใจของฉัน นี่คือจุดเริ่มต้นของหนึ่งในฉันไม่รู้ภาษา Far Eastern อาจบ้างไหม

 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

การวิเคราะห์ของฉันทำให้คุณสมเหตุสมผลหรือไม่? คุณช่วยฉันคิดดูว่าเกิดอะไรขึ้นและอาจเสนอคำแนะนำเกี่ยวกับวิธีการคืนความเสียหาย

ฉันได้โพสต์ทิ้งเศษหกเหลี่ยมของชิ้นส่วนเพิ่มเติมของตัวอย่างทั้งสองนี้ที่ http://pastebin.com/ffn7CtdG


2
มันจะช่วยในงานนิติวิทยาศาสตร์ถ้าคุณสามารถแยกส่วนดังกล่าวข้างต้นโดยใช้ตัวแก้ไขฐานสิบหกเก็บไว้เป็นไฟล์ไบนารีและโพสต์ไว้ที่ไหนสักแห่ง ทำให้แฟรกเมนต์มีขนาดใหญ่เท่าที่คุณสามารถและเริ่มต้นได้ถ้าคุณทำได้จากไบต์แรกของไฟล์ คุณรู้ภายใต้ระบบปฏิบัติการที่ไฟล์ถูกสร้างขึ้น?
harrymc

ไม่ฉันไม่ทราบว่าระบบนี้ใช้งานได้ในลักษณะใด
tripleee

ขอบคุณสำหรับความคิดเห็น! เพิ่มลิงค์ Pastebin ลงในตัวอย่างเพิ่มเติม
tripleee

ขอบคุณ แต่ฉันหมายถึงจุดเริ่มต้นทั้งหมดของไฟล์อย่างแท้จริงและไม่ใช่ผลลัพธ์มาจาก xxd ที่ฉันไม่สามารถใช้ในโปรแกรมแก้ไข hex ของฉัน อย่างไรก็ตามสิ่งหนึ่งที่เห็นได้ชัดจากตัวอย่างของคุณคือส่วน "~ X83 .. " ควรจะว่างเปล่า ตัวอย่างเช่น "SPT Telecom" เป็นที่รู้จักกันดีในสาธารณรัฐเช็ก ข้อมูลเพิ่มเติมใด ๆ ที่คุณมีเกี่ยวกับที่มาของไฟล์เหล่านี้จะช่วยได้
harrymc

ด้วยเหตุผลด้านลิขสิทธิ์ฉันไม่แน่ใจว่าฉันจะโพสต์ไฟล์ทั้งหมดได้หรือไม่ คุณสามารถเปลี่ยนเศษเล็กเศษน้อยเป็นไบนารีได้อย่างง่ายดาย perl -lne '@s = m/: ((\X\X ?){16})/; $s = join ("", @s); $s =~ s/ //g; print pack("H*", $s)'
tripleee

คำตอบ:


1

ในคำตอบนี้ฉันอธิบายรายละเอียดเกี่ยวกับแหล่งที่มาของไฟล์เหล่านี้ นี่ไม่ใช่คำตอบที่สมบูรณ์เนื่องจากต้องการการวิเคราะห์ทางนิติวิทยาศาสตร์อย่างละเอียดยิ่งขึ้น การลงมือปฏิบัติเพื่อเข้าถึงไฟล์ที่สมบูรณ์อย่างน้อยบางส่วน

บางจุดที่ทำให้ฉันแตกเป็นชิ้นที่ฉันเห็น:

  1. คำที่อยู่ในสาธารณรัฐเช็ก
  2. มีลำดับที่แปลกแยกคำและพวกเขาทำซ้ำมาก
  3. ลำดับที่แปลกประหลาดเหล่านี้ประกอบด้วยตัวอักษร UTF-8 ซึ่งไม่เข้าท่าเลย ยกเว้นว่าบางคนเป็นซีริลลิกในธรรมชาติ

ข้อสรุปของฉันคือไฟล์เหล่านี้ไม่ได้เป็นไฟล์ข้อความ แต่แรกเริ่มผิดพลาด แปลงเป็น UTF-8 ราวกับว่าเป็นข้อความโดยใช้โค้ดเพจที่มีอักขระซิริลลิก

ตัวอย่างเช่นลำดับทุกหนทุกแห่งของ d193 เป็นอักษรซีริลลิก gje ขนาดเล็ก การแทนค่าโค้ดเพจที่ต่างกันคือ:

image

นี่ทำให้เรามีรายการของการเข้ารหัสที่เป็นไปได้ของไฟล์ต้นฉบับซึ่งขึ้นอยู่กับ บนระบบปฏิบัติการดั้งเดิม หากพวกเขาถูกสร้างขึ้นบนคอมพิวเตอร์ Windows หน้ารหัสดั้งเดิมของพวกเขาน่าจะเป็น Windows-1251 แต่สำหรับ Mac พวกเขาน่าจะเป็น ใน Macintosh Cyrillic แน่นอนมันเป็นไปได้ทั้งหมดที่แปลไป UTF-8 ใช้การเข้ารหัสผิด

ตัวอย่างเช่นเราค้นหาลำดับ SPT~X83..Telecom. บริษัท "SPT Telecom" ไม่เป็นอย่างอื่น บริษัท โทรคมนาคมแห่งชาติเช็กก่อตั้งขึ้นในปี 1993 ที่มีอยู่ในข้อความรอยเตอร์ newswire ค่อนข้างสมเหตุสมผล อย่างไรก็ตามไม่มีเหตุผลสำหรับตัวคั่นใด ๆ ข้างช่องว่าง ระหว่างคำทั้งสอง

คำอธิบายของฉันต่อสตริงที่ทำให้งงเหล่านี้ที่ทำซ้ำระหว่างคำเหล่านี้คือพวกเขา ไม่ได้และไม่สามารถเป็นส่วนหนึ่งของข้อความ ฉันเชื่อว่าพวกเขาจะต้องเป็นแล้ว อักขระไบนารีวางอยู่ระหว่างคำซึ่งอาจมีการเชื่อมต่อบางส่วน เพื่อจัดรูปแบบของไฟล์ โปรแกรมแปลงไฟล์ที่แปลงไฟล์ เป็น UTF-8 ดังนั้นจึงแปลงเป็นอักขระ UTF-8 แบบสุ่มโดยไม่มีเหตุผล

แม้แต่พยายามแปลงลำดับนี้เป็นไบนารี่โดยใช้โค้ดเพจใด ๆ ใน รายการด้านบนฉันไม่ได้รับลำดับที่มีความหมายใด ๆ อย่างไรก็ตามฉันมีประสบการณ์กับข้อความ ไฟล์ที่มาจากตัวแก้ไขข้อความเก่าที่วางอักขระ "มองไม่เห็น" ในข้อความที่ไม่มีจุดประสงค์ที่จะแสดง แต่แทนที่จะควบคุมการแสดงผล

ฉันเชื่อว่านี่เป็นคำอธิบายของไฟล์เหล่านี้ แต่ฉันไม่รู้ว่ามันแปลก รูปแบบไฟล์. มันน่าจะเป็นโปรแกรมแก้ไขข้อความเช็กที่ไม่รู้จัก (อย่างน้อยก็ไม่ทราบสำหรับฉัน) หากไฟล์สามารถสแกนตามวันที่ที่อยู่ในข้อความ สิ่งนี้อาจช่วย จำกัด ความเป็นไปได้ให้แคบลง

ฉันไม่เชื่อในทฤษฎีของคุณเกี่ยวกับไฟล์ต้นฉบับที่สร้างขึ้นมาอย่างดี และเข้ารหัสใน ISO-2022 เนื่องจากลำดับแปลก ๆ เหล่านี้ดูเหมือนจะไม่เป็น (หรือเคยมีมา) ลำดับการควบคุม ISO-2022


ขออภัยฉันไม่สามารถให้คำตอบที่มีสิทธิ์ หากสิ่งนี้ไม่ได้นำไปสู่การแก้ปัญหาโปรดอย่ามอบรางวัลให้ฉัน ฉันพยายามกำหนดความคิดของฉันอย่างชัดเจน
harrymc

ขออภัยที่จะเห็นค่าหัวที่หมดอายุก่อนที่คุณจะมีเงินรางวัลมากพอที่จะได้รับ ฉันจะพยายามกู้คืนตัวแทนเพียงพอที่จะโพสต์เงินรางวัลอีกในที่สุด
tripleee

ไม่ต้องกังวลกับมัน
harrymc
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.