Làm thế nào để làm hỏng tệp lưu trữ theo cách được kiểm soát?

Tôi đã viết một hàm kiểm tra kho lưu trữ bị hỏng bằng tổng kiểm tra CRC.

Để kiểm tra nó, tôi chỉ cần mở kho lưu trữ và xáo trộn nội dung với trình soạn thảo hex. Vấn đề là tôi không tin rằng đây là cách chính xác để tạo một tệp bị hỏng.

Có cách nào khác để tạo ra một "tham nhũng được kiểm soát", vì vậy nó sẽ không hoàn toàn ngẫu nhiên nhưng có thể mô phỏng những gì xảy ra với tài liệu lưu trữ bị hỏng thực sự? Tôi không bao giờ phải làm hỏng một cái gì đó trên mục đích vì vậy tôi không thực sự chắc chắn làm thế nào để làm điều đó, bên cạnh việc xáo trộn dữ liệu ngẫu nhiên trong một tập tin.

Tôi cũng chưa thực hiện nhiều thử nghiệm fuzz , nhưng đây là hai ý tưởng:

Viết một số số không vào giữa tệp. Sử dụng ddvới conv=notrunc. Điều này ghi một byte đơn (block-size = 1 Count = 1):

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

Sử dụng /dev/urandomnhư một nguồn cũng là một lựa chọn.

Ngoài ra, đục lỗ nhiều trong 4k với fallocate --punch-hole. Bạn thậm chí có thể fallocate --collapse-rangecắt ra một trang mà không để lại một lỗ trống. (Điều này sẽ thay đổi kích thước tập tin).

Một bản tải xuống được tiếp tục ở sai vị trí sẽ phù hợp với --collapse-rangekịch bản. Một torrent không đầy đủ sẽ phù hợp với punch-holekịch bản. (Tệp thưa thớt hoặc phạm vi được phân bổ trước, được đọc là 0 ở bất kỳ nơi nào chưa được viết.)

RAM xấu (trong hệ thống bạn đã tải xuống tệp từ đó) có thể gây ra hỏng hóc và ổ đĩa quang cũng có thể làm hỏng các tệp (ECC của chúng không đủ mạnh để phục hồi hoàn hảo sau các vết trầy xước hoặc phai màu của thuốc nhuộm).

Các lĩnh vực DVD (khối ECC) là 2048B , nhưng các lỗi đơn byte hoặc thậm chí một bit có thể xảy ra. Một số ổ đĩa có thể sẽ cung cấp cho bạn dữ liệu không chính xác xấu thay vì lỗi đọc cho khu vực đó, đặc biệt nếu bạn đọc ở chế độ thô hoặc gọi nó là.

Các câu trả lời khác có vẻ chủ yếu liên quan đến lỗi phần cứng. Hãy để tôi liệt kê một số lỗi do phần mềm gây ra:

• Thay thế bằng CRLF.
• CR loại bỏ. (Ngay cả khi không được theo sau bởi LF)
• Thêm byte Null được chèn.
• Thêm Unicode "Dấu thứ tự byte" được chèn vào.
• Bộ ký tự được chuyển đổi từ UTF-8 sang Latin-1 hoặc ngược lại.
• DOS EOF-character (# 1A) đã bị xóa, ngay cả khi không ở End Of File.

Những điều này khá vô hại khi xảy ra với các tệp văn bản, nhưng thường gây chết người khi áp dụng cho các tệp nhị phân.

Sử dụng ddđể cắt bớt tệp hoặc thử trình hexerchỉnh sửa nhị phân như chỉnh sửa và giới thiệu một số lỗi.

Ví dụ về cắt ngắn tệp bằng dd

Tạo tập tin 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
#

Cắt bớt 10 byte cuối

# 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
#

Trang người đàn ông

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.

Gợi ý:

Bắt đầu viết vào một kho lưu trữ và dừng việc viết trước khi nó kết thúc. Điều này có thể xảy ra trong quá trình cắt điện và các kịch bản khác.

Kịch bản đời thực:

Tôi đã từng làm hỏng một tệp zip bằng cách cố gắng sao chép nhiều dữ liệu vào nó hơn là vừa với phương tiện. Windows (đây là Windows 7 ở chế độ an toàn ftr) đã cố gắng hoàn thành hành động trước khi tìm ra liệu có đủ dung lượng hay không, và đến lúc nó phát hiện ra thì tệp đã hoàn thành một nửa và do đó bị hỏng. Tôi hy vọng họ đã khắc phục sự cố đó trong các phiên bản sau của windows hoặc đó chỉ là một chế độ an toàn.

Một loại tham nhũng phổ biến khác là vặn vẹo bit: trong đó một bit đơn (hoặc nhiều bit) được chuyển đổi trong kho dữ liệu.

Vì vậy, một byte 1111 0000có thể trở thành, nói, 1111 0010hoặc 1011 0000hoặc 1110 1100hoặc bất cứ điều gì.

Các hệ thống kiểm tra chẵn lẻ và đếm số có vấn đề với những thứ như 1110 1000có số lượng tập hợp và số chưa đặt bằng nhau, vì cả hai số chẵn lẻ và số lượng vẫn giữ nguyên.

Vì vậy, thay thế tất cả các trường hợp của một ký tự ngẫu nhiên bằng nghịch đảo của nó, giả sử 0x57 thành 0x75 ('9' thành 'K') hoặc ngược lại có thể không phát hiện được. Đối với các hệ thống có mysql, lệnh "thay thế" tồn tại cho mục đích như vậy:

replace K 9 < goodInputFile > corruptedOutputFile

Bạn cũng có thể thử hoán đổi chữ K và 9 xung quanh, đây sẽ là một thử nghiệm đặc biệt tốt nếu cả hai đều xuất hiện cùng một số lần trong tệp:

replace K 9 9 K < goodInputFile > corruptedOutputFile

Sử dụng man replaceđể biết thêm.

Thay đổi ngẫu nhiên đối với dữ liệu thử nghiệm bị hỏng không phải là một cách tiếp cận tốt, vì bạn không thể sao chép mẫu để chạy lại các thử nghiệm.

Tôi sẽ rất vui khi chỉ có 3 mẫu, chỉ thay đổi 1 bit ở byte đầu tiên, ở byte cuối cùng và ở bất kỳ byte giữa nào. Nhưng chỉ cần 1 bit chứ không phải toàn bộ byte.

Nhưng mẫu thử nghiệm tốt nhất sẽ là một trong đó bạn có thể tạo các mẫu thay đổi từng bit của tệp từ byte đầu tiên sang byte cuối cùng. Điều này không thể (thường) có được với các công cụ thông thường, bạn cần phải xây dựng một (tôi đoán).

Với cách tiếp cận này, bạn cô lập rất nhiều khả năng bao gồm cả endianess nếu thuật toán của bạn dựa trên một loại endianess. Mặt khác, mẫu lớn có thể tiêu tốn rất nhiều thời gian để xử lý.

Cuối cùng, một số mẫu cắt ngắn hoặc thêm byte sẽ hoàn thành các bài kiểm tra của bạn.