제어 된 방식으로 보관 파일을 손상시키는 방법은 무엇입니까?


23

CRC 체크섬을 사용하여 손상된 아카이브를 검사하는 기능을 작성했습니다.

그것을 테스트하기 위해 방금 아카이브를 열고 16 진 편집기로 내용을 스크램블했습니다. 문제는 이것이 손상된 파일을 생성하는 올바른 방법이라고 믿지 않는다는 것입니다.

"제어 된 손상"을 생성하는 다른 방법이 있습니까? 따라서 완전히 무작위 적이지는 않지만 실제 손상된 아카이브에서 발생하는 상황을 시뮬레이션 할 수 있습니까? 나는 의도적으로 무언가를 손상시키지 않았으므로 파일에서 무작위로 데이터를 스크램블링하는 것 외에 어떻게 그렇게하는지 확실하지 않습니다.


아카이브에있는 파일 중 하나 또는 아카이브 자체의 내용을 의미하기 위해 "아카이브"하기 위해 어떤 도구를 사용하고 있습니까?
Drav Sloan

아카이브 형식으로 tar를 사용하고 있습니다. 파일의 내용 만 손상시키고 싶습니다. 따라서 아카이브 자체는 여전히 tar 파일로 인식됩니다. 내 기능은 파일을 추출합니다. 파일이 손상된 경우가 있지만 아카이브 내부의 파일이 손상되면 어떻게되는지 확인하고 싶습니다.
rataplan

답변:


22

나는 퍼즈 테스트 를 많이하지 않았지만 다음 두 가지 아이디어가 있습니다.

파일 중간에 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 이지만 단일 바이트 또는 단일 비트 오류가 발생할 수 있습니다. 일부 드라이브는 특히 원시 모드에서 읽거나 호출되는 경우 섹터에 대한 읽기 오류 대신 수정 불가능한 잘못된 데이터를 제공 할 수 있습니다.


1
하드 드라이브 작동 방식으로 인해 4K로 정렬 된 4K 블록 또는 512 바이트로 정렬 된 512 바이트 블록에서 제로 채우기가 가장 현실적입니다.
Mark

@Mark : 오, HD에 의한 손상에 대해 생각하고 있다면, 그렇습니다. 누군가의 컴퓨터에있는 나쁜 RAM은 파일 중간에 약간 뒤집힐 수 있습니다. 마찬가지로, 불량 광 디스크를 왕복하는 왕복은 작은 청크를 제로화 할 수 있습니다 (DVD ECC 코드는 다른 청크 크기에서 작동 함).
Peter Cordes

10

다른 답변은 대부분 하드웨어 오류와 관련이 있습니다. 소프트웨어로 인해 발생한 손상을 나열하겠습니다.

  • LF는 CRLF로 대체되었습니다.
  • CR이 제거되었습니다. (LF 뒤에 오지 않더라도)
  • 여분의 널 바이트가 삽입되었습니다.
  • 추가 유니 코드 "바이트 순서 표시"가 삽입되었습니다.
  • UTF-8에서 Latin-1로 또는 그 반대로 변환 된 문자 세트.
  • 파일 끝이 아니더라도 DOS EOF 문자 (# 1A)가 삭제되었습니다.

이러한 것은 텍스트 파일에 발생할 때 상당히 무해하지만 일반적으로 이진 파일에 적용될 때는 치명적입니다.


오, 좋은 것들! 물론 다른 방법으로도 변환. PNG 헤더에는 이러한 상황에 대한 체크인 오류가 있습니다. w3.org/TR/PNG-Rationale.html#R.PNG-file-signature
Dewi Morgan

7

사용하여 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.

고마워 스티브 실제 시나리오에서 발생하는 상황을 시뮬레이션합니까? 네트워크에서 아카이브를 복사하는 중이고 손상 되었습니까? 파일을 자르기 위해 실패한 다운로드를 dd로 시뮬레이션 할 수 있다고 생각합니다. 정확합니까?
rataplan

2
예,를 사용하여 파일을 자르면 파일의 dd일부만 생성되는 실제 시나리오를 시뮬레이션합니다. 또한 hexer 가짜 콘텐츠를 도입하기 위해 편집하면 다른 유형의 손상이 시뮬레이션됩니다. 따로 md5sum살펴볼 가치가 있지만 파일의 md5 체크섬을 계산합니다.
스티브

1
@newbiez, 잘라내 기는 무작위로 네트워크 오류를 시뮬레이트하는 반면 4KB 또는 512 바이트 경계에서 잘라 내면 디스크 오류를 시뮬레이트합니다.
Mark

실제로 파일을 dd어떻게 자르 나요?
에드워드 토발즈

@ edward torvalds-dd truncate 예제 추가
steve

2

암시:

아카이브에 쓰기를 시작하고 쓰기가 끝나기 전에 쓰기를 중단하십시오. 전원 차단 및 기타 시나리오 중에 발생할 수 있습니다.

실제 시나리오 :

나는 매체에 맞는 것보다 더 많은 데이터를 복사하려고 시도하여 zip 파일을 손상시켰다. Windows (안전 모드 ftr의 Windows 7)는 충분한 공간이 있는지 확인하기 전에 작업을 완료하려고했지만 파일이 완전히 완성되어 손상되었음을 확인했습니다. 나는 그들이 이후 버전의 Windows에서 그 문제를 해결했거나 안전 모드 일이기를 바랍니다.


2

또 다른 일반적인 유형의 손상은 비트 트위들 링입니다. 여기서 단일 비트 (또는 여러 비트)가 데이터 스트림에서 토글됩니다.

바이트 그렇게 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자세한 정보를 위해 사용하십시오 .


0

테스트를 다시 실행하기 위해 샘플을 재현 할 수 없으므로 손상된 테스트 데이터를 임의로 변경하는 것은 좋은 방법이 아닙니다.

첫 바이트, 마지막 바이트 및 중간 바이트에서 1 비트 만 변경하는 3 개의 샘플 만 있으면 좋을 것입니다. 그러나 전체 바이트가 아닌 1 비트입니다.

그러나 최상의 테스트 샘플은 파일의 각 1 비트를 첫 번째 바이트에서 마지막 바이트로 변경하는 샘플을 생성 할 수있는 샘플입니다. 이것은 보통 도구로 얻을 수 없으며, 도구를 만들어야합니다 (추측).

이 방법을 사용하면 알고리즘이 한 종류의 엔디안을 기반으로하는 경우 엔디안을 포함한 많은 가능성을 격리 할 수 ​​있습니다. 반면에 큰 샘플은 처리하는 데 많은 시간이 소요될 수 있습니다.

마지막으로 일부 샘플이 잘 리거나 바이트를 추가하면 테스트가 완료됩니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.