CRC 체크섬을 사용하여 손상된 아카이브를 검사하는 기능을 작성했습니다.
그것을 테스트하기 위해 방금 아카이브를 열고 16 진 편집기로 내용을 스크램블했습니다. 문제는 이것이 손상된 파일을 생성하는 올바른 방법이라고 믿지 않는다는 것입니다.
“제어 된 손상”을 생성하는 다른 방법이 있습니까? 따라서 완전히 무작위 적이지는 않지만 실제 손상된 아카이브에서 발생하는 상황을 시뮬레이션 할 수 있습니까? 나는 의도적으로 무언가를 손상시키지 않았으므로 파일에서 무작위로 데이터를 스크램블링하는 것 외에 어떻게 그렇게하는지 확실하지 않습니다.
답변
나는 퍼즈 테스트 를 많이하지 않았지만 다음 두 가지 아이디어가 있습니다.
파일 중간에 0을 씁니다. 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시나리오 와 일치합니다 . (구문 파일 또는 사전 할당 된 범위는 아직 작성되지 않은 곳에서는 0으로 읽습니다.)
불량 RAM (파일을 다운로드 한 시스템에서)은 손상을 일으킬 수 있으며 광 드라이브는 파일을 손상시킬 수도 있습니다 (ECC가 긁힘이나 염료의 퇴색을 완벽하게 복구 할만큼 강하지는 않습니다).
DVD 섹터 (ECC 블록)는 2048B 이지만 단일 바이트 또는 단일 비트 오류가 발생할 수 있습니다. 일부 드라이브는 특히 원시 모드에서 읽거나 호출되는 경우 섹터에 대한 읽기 오류 대신 수정 불가능한 잘못된 데이터를 제공 할 수 있습니다.
답변
다른 답변은 대부분 하드웨어 오류와 관련이 있습니다. 소프트웨어로 인해 발생한 손상을 나열하겠습니다.
- LF는 CRLF로 대체되었습니다.
- CR이 제거되었습니다. (LF 뒤에 오지 않더라도)
- 여분의 널 바이트가 삽입되었습니다.
- 추가 유니 코드 “바이트 순서 표시”가 삽입되었습니다.
- 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(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.
답변
암시:
아카이브에 쓰기를 시작하고 쓰기가 끝나기 전에 쓰기를 중단하십시오. 전원 차단 및 기타 시나리오 중에 발생할 수 있습니다.
실제 시나리오 :
나는 매체에 맞는 것보다 더 많은 데이터를 복사하려고 시도하여 zip 파일을 손상시켰다. Windows (안전 모드 ftr의 Windows 7)는 충분한 공간이 있는지 확인하기 전에 작업을 완료하려고했지만 파일이 완전히 완성되어 손상되었음을 확인했습니다. 나는 그들이 이후 버전의 Windows에서 그 문제를 해결했거나 안전 모드 일이기를 바랍니다.
답변
또 다른 일반적인 유형의 손상은 비트 트위들 링입니다. 여기서 단일 비트 (또는 여러 비트)가 데이터 스트림에서 토글됩니다.
바이트 그렇게 1111 0000될 수도, 말 1111 0010또는 1011 0000또는 1110 1100또는 무엇 이건.
패리티 및 카운트-온-원 체크섬 시스템은 1110 1000동일한 수의 세트와 세트가있는 곳 과 같은 문제가 있는데, 이는 패리티와 개수가 동일하게 유지되기 때문입니다.
따라서 임의의 문자의 모든 인스턴스를 0x57 ~ 0x75 ( ‘9’~ ‘K’)로 바꾸거나 그 반대로 감지 할 수 없습니다. mysql이있는 시스템의 경우 “replace”명령은 이러한 목적으로 만 존재합니다.
replace K 9 < goodInputFile > corruptedOutputFile
또한 K와 9 문자를 바꿔보십시오. 둘 다 파일에 같은 횟수로 나타나는 경우 특히 좋은 테스트입니다.
replace K 9 9 K < goodInputFile > corruptedOutputFile
man replace자세한 정보를 위해 사용하십시오 .
답변
테스트를 다시 실행하기 위해 샘플을 재현 할 수 없으므로 손상된 테스트 데이터를 임의로 변경하는 것은 좋은 방법이 아닙니다.
첫 바이트, 마지막 바이트 및 중간 바이트에서 1 비트 만 변경하는 3 개의 샘플 만 있으면 좋을 것입니다. 그러나 전체 바이트가 아닌 1 비트입니다.
그러나 최상의 테스트 샘플은 파일의 각 1 비트를 첫 번째 바이트에서 마지막 바이트로 변경하는 샘플을 생성 할 수있는 샘플입니다. 이것은 보통 도구로 얻을 수 없으며, 도구를 만들어야합니다 (추측).
이 방법을 사용하면 알고리즘이 한 종류의 엔디안을 기반으로하는 경우 엔디안을 포함한 많은 가능성을 격리 할 수 있습니다. 반면에 큰 샘플은 처리하는 데 많은 시간이 소요될 수 있습니다.
마지막으로 일부 샘플이 잘 리거나 바이트를 추가하면 테스트가 완료됩니다.