วิธีเสียหายไฟล์เก็บถาวรในทางที่ควบคุม?

ฉันเขียนฟังก์ชันที่ตรวจสอบไฟล์เก็บถาวรที่เสียหายโดยใช้การตรวจสอบ CRC

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

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

ฉันไม่ได้ทำการทดสอบฟัซซี่มากนักแต่ต่อไปนี้เป็นแนวคิดสองข้อ:

เขียนเลขศูนย์ลงในไฟล์ ใช้กับdd conv=notruncนี่เขียนไบต์เดียว (block-size = 1 count = 1):

dd if=/dev/zero of=file_to_fuzz.zip bs=1 count=1 seek=N conv=notrunc

การใช้/dev/urandomเป็นแหล่งที่มาก็เป็นตัวเลือกเช่นกัน

ผลัดกันชกหลายของ 4k fallocate --punch-holeหลุมด้วย คุณสามารถfallocate --collapse-rangeตัดออกหน้าโดยไม่ต้องออกจากหลุมที่เต็มไปด้วยศูนย์ (สิ่งนี้จะเปลี่ยนขนาดไฟล์)

การดาวน์โหลดต่อในตำแหน่งที่ไม่ถูกต้องจะตรงกับ--collapse-rangeสถานการณ์ ฝนตกหนักไม่สมบูรณ์จะตรงกับpunch-holeสถานการณ์ (ไฟล์กระจัดกระจายหรือส่วนขยายที่จัดสรรล่วงหน้าไม่ว่าจะอ่านเป็นศูนย์ทุกที่ที่ยังไม่ได้เขียน)

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

ส่วนของดีวีดี (บล็อก ECC) คือ 2048Bแต่อาจเกิดข้อผิดพลาดไบต์เดียวหรือแม้แต่ข้อผิดพลาดบิตเดียว ไดรฟ์บางตัวอาจให้ข้อมูลที่ไม่สามารถแก้ไขได้ไม่ถูกต้องแทนการอ่านข้อผิดพลาดสำหรับภาคโดยเฉพาะอย่างยิ่งถ้าคุณอ่านในโหมด raw หรือเรียกว่า w / e

คำตอบอื่น ๆ ส่วนใหญ่เกี่ยวข้องกับข้อผิดพลาดของฮาร์ดแวร์ ให้ฉันแสดงรายการความเสียหายที่เกิดจากซอฟต์แวร์:

• LF ถูกแทนที่ด้วย CRLF
• ลบ CR แล้ว (แม้ว่าจะไม่ได้ตามด้วย LF)
• แทรก Null พิเศษไบต์
• แทรก Unicode พิเศษ "เครื่องหมายคำสั่งซื้อ Byte"
• ชุดอักขระแปลงจาก UTF-8 เป็น Latin-1 หรือในทางกลับกัน
• ลบตัวอักขระ DOS EOF (# 1A) แม้ว่าจะไม่อยู่ที่ท้ายไฟล์

สิ่งเหล่านี้ค่อนข้างไม่เป็นอันตรายเมื่อเกิดขึ้นกับไฟล์ข้อความ แต่โดยทั่วไปแล้วเมื่อนำไปใช้กับไฟล์ไบนารี

ใช้ddเพื่อตัดทอนไฟล์หรือลองใช้โปรแกรมแก้ไขแบบไบนารีhexerเพื่อแก้ไขและแนะนำความเสียหายบางอย่าง

ตัวอย่างของการตัดทอนไฟล์โดยใช้ dd

สร้างไฟล์ 5MB

# dd if=/dev/zero of=foo bs=1M count=5
5+0 records in
5+0 records out
5242880 bytes (5.2 MB) copied, 0.0243189 s, 216 MB/s
# ls -l foo
-rw-r--r-- 1 root root 5242880 Aug 12 20:13 foo
#

ตัดส่วนที่เหลือออก 10 ไบต์

# dd if=foo of=foo-corrupted bs=1 count=5242870
5242870+0 records in
5242870+0 records out
5242870 bytes (5.2 MB) copied, 23.7826 s, 220 kB/s
# ls -l foo foo-corrupted
-rw-r--r-- 1 root root 5242880 Aug 12 20:13 foo
-rw-r--r-- 1 root root 5242870 Aug 12 20:14 foo-corrupted
#

หน้าคน Hexer

HEXER(1)                              General Commands Manual                             HEXER(1)

NAME
   hexer - binary file editor

SYNOPSIS
   hexer [options] [file [...]]

DESCRIPTION
   hexer  is  a  multi-buffer  editor  for  viewing  and  manipulating binary files.  It can't
   (shouldn't) be used for editing block devices, because it tries to load the whole file into
   a  buffer (it should work for diskettes).  The most important features of hexer are:  multi
   buffers, multi level undo, command line editing with completion, binary regular expressions
   (see  below).   The  user  interface  is  kept similar to vi, so if you know how to use vi,
   you'll get started easily.

คำแนะนำ:

เริ่มเขียนไปยังที่เก็บถาวรและหยุดสิ่งที่ทำเขียนก่อนที่จะเสร็จสิ้น สิ่งนี้สามารถเกิดขึ้นได้ในระหว่างการตัดไฟและสถานการณ์อื่น ๆ

สถานการณ์ในชีวิตจริง:

ฉันเคยเสียหายไฟล์ซิปโดยพยายามที่จะคัดลอกข้อมูลลงไปมากกว่าที่จะพอดีกับสื่อ Windows (นี่คือ Windows 7 ในเซฟโหมด ftr) พยายามดำเนินการให้เสร็จก่อนที่จะคิดออกว่ามีพื้นที่เพียงพอหรือไม่และเมื่อถึงเวลาที่คิดว่าไฟล์ดังกล่าวเสร็จสมบูรณ์แล้วครึ่งหนึ่ง ฉันหวังว่าพวกเขาจะแก้ไขปัญหานั้นใน Windows รุ่นที่ใหม่กว่าหรือเป็นเพียงแค่สิ่งที่ปลอดภัยในโหมด

ประเภทของความเสียหายที่พบโดยทั่วไปอีกอย่างหนึ่งคือการบิดสองบิต: โดยที่บิตเดียว (หรือหลายบิต) ถูกสลับในสตรีม

ดังนั้นไบต์1111 0000อาจกลายเป็นพูด1111 0010หรือ1011 0000หรือ1110 1100หรืออะไรก็ตาม

ความเท่าเทียมกันและระบบตรวจนับรวมมีปัญหากับสิ่งต่าง ๆ เช่น1110 1000ที่มีจำนวนชุดและ unsets เท่ากันเนื่องจากทั้งพาริตีและจำนวนยังคงเหมือนเดิม

ดังนั้นการแทนที่อินสแตนซ์ทั้งหมดของตัวอักษรแบบสุ่มด้วยผกผันของมันให้บอกว่า 0x57 ถึง 0x75 ('9' เป็น 'K') หรือในทางกลับกันอาจตรวจไม่พบ สำหรับระบบที่มี mysql คำสั่ง "replace" มีอยู่เพื่อจุดประสงค์ดังกล่าว:

replace K 9 < goodInputFile > corruptedOutputFile

คุณสามารถลองสลับตัวอักษร K และ 9 รอบ ๆ ซึ่งเป็นการทดสอบที่ดีโดยเฉพาะหากพวกเขาทั้งคู่ปรากฏจำนวนครั้งเท่ากันในไฟล์:

replace K 9 9 K < goodInputFile > corruptedOutputFile

ใช้man replaceสำหรับข้อมูลเพิ่มเติม

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

ฉันจะมีความสุขกับ 3 ตัวอย่างเท่านั้นเปลี่ยนเพียง 1 บิตในไบต์แรกในไบต์สุดท้ายและในไบต์กลางใด ๆ แต่เพียง 1 บิตไม่ใช่ไบต์ทั้งหมด

แต่ตัวอย่างการทดสอบที่ดีที่สุดจะเป็นที่ที่คุณสามารถสร้างตัวอย่างที่เปลี่ยนแต่ละบิตของไฟล์จากไบต์แรกถึงสุดท้าย สิ่งนี้ไม่สามารถ (โดยปกติ) ได้ด้วยเครื่องมือปกติคุณต้องสร้าง (ฉันเดา)

ด้วยวิธีการนี้คุณสามารถแยกความเป็นไปได้มากมายรวมถึง endianess หากอัลกอริทึมของคุณอยู่ในประเภท endianess ในขณะที่ตัวอย่างขนาดใหญ่สามารถใช้เวลาในการประมวลผลมาก

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