같은 바이트인지 확인할 때는 cmp를 사용합니다
cmp -- first.bin second.bin
status=$?
printf 'cmp status=%s\n' "$status"0이면 두 파일의 내용이 같습니다. 1이면 다르며, 그 밖의 값은 읽기 실패 등 오류입니다. 파일 이름이나 수정 시간이 같다는 이유로 내용까지 같다고 볼 수 없습니다. 비교 중 다른 프로세스가 파일을 바꿀 수 있다면 먼저 변경되지 않는 사본을 확보해야 합니다.
- cmp두 파일의 실제 바이트를 비교합니다.
- sha256sum파일에서 계산한 해시를 기준 해시와 비교합니다.
- strings표시 가능한 문자열 조각을 찾아봅니다.
상자는 용도의 비교이며 실행 순서를 뜻하지 않습니다. strings 출력이 같아도 원본 파일이 같다는 뜻은 아닙니다.
체크섬 파일의 출처도 확인합니다
sha256sum -- firmware.bin > firmware.sha256
sha256sum --check firmware.sha256첫 명령은 현재 파일의 SHA-256과 파일명을 기록하고, 둘째 명령은 그 기록을 기준으로 다시 검사합니다. 전달 과정의 변경을 확인하는 데 쓸 수 있지만 공격자가 파일과 체크섬을 함께 바꾼 상황까지 인증하지는 못합니다. 배포자 확인에는 신뢰한 서명이나 별도 경로로 받은 기준값이 필요합니다.
MD5는 128비트이며 16진수로는 32자리입니다. 충돌이 가능하고 보안상 약점도 알려져 있으므로 파일의 진위를 보증하는 값으로 사용하지 않습니다. 기존 MD5 목록을 검사하는 것과 새 배포 절차에 MD5를 선택하는 것은 다른 판단입니다.
분할 순서와 복원 결과를 확인합니다
mkdir chunks
split -b 4M -d -a 4 -- firmware.bin chunks/part-
cat chunks/part-[0-9][0-9][0-9][0-9] > restored.bin
cmp -- firmware.bin restored.bin새 디렉터리에 일정 길이의 숫자 접미사를 사용합니다. part-0000부터 이름순으로 연결하며, 오래된 조각이 섞이거나 조각이 빠지면 마지막 비교에서 실패합니다. 실제 자동화에서는 각 명령의 종료 상태를 확인하고, 배포 시에는 예상 조각 목록과 전체 파일의 해시도 함께 보관합니다.
strings는 일부 바이트를 문자열처럼 보여 줍니다
strings -a -t x -- firmware.bin-a는 파일 전체를 대상으로 검사하고 -t x는 발견 위치를 16진수 파일 offset으로 표시합니다. 이 위치는 실행 중의 가상 주소가 아닙니다. 문자열의 인코딩, 압축 여부, 최소 길이에 따라 보이지 않는 내용이 있으므로 문자열이 없다는 결과만으로 해당 기능이 없다고 결론 내리지 않습니다.