CONCLUSION

같은 13바이트 payload를 같은 zip -X 옵션으로 묶었지만 내부 수정 시각을 바꾸자 두 ZIP은 모두 133바이트이면서 SHA-256은 달랐습니다. 재현 가능한 배포물에는 시간 정규화가 필요합니다.

확인 방법

  1. 내용이 same payload와 줄바꿈인 13바이트 payload.txt를 만들었습니다.
  2. 수정 시각을 2026-01-01 01:01과 2026-10-01 18:01로 바꾼 뒤 각각 zip -X로 압축했습니다.
  3. 두 ZIP의 크기, SHA-256과 서로 다른 바이트 위치를 비교했습니다.

크기는 같고 해시는 달랐다

early.zip과 late.zip은 모두 133바이트였습니다. SHA-256은 각각 07ff8c0a…94cd2와 a57832f3…0a46으로 달랐습니다.

바이트 비교에서는 로컬 파일 헤더와 중앙 디렉터리 영역의 시간 필드 위치가 달랐습니다. payload의 내용 변경이나 압축률 차이가 없어도 아카이브 컨테이너는 다른 파일이 될 수 있습니다.

수정 시각만 다른 ZIP 두 개의 결과
표본내부 파일 수정 시각ZIP 크기SHA-256 앞 8자리
early.zip2026-01-01 01:01133 B07ff8c0a
late.zip2026-10-01 18:01133 Ba57832f3

ZIP은 파일 내용 외의 항목도 저장한다

ZIP 헤더에는 파일명, 압축 방식, CRC, 크기와 수정 시각 같은 정보가 들어갈 수 있습니다. 같은 폴더를 다시 압축할 때 운영체제·도구·파일 순서·추가 속성이 달라져 결과 해시가 바뀔 수 있습니다.

재현 가능한 압축물이 필요할 때

빌드 결과 해시를 여러 환경에서 맞춰야 한다면 내부 파일의 수정 시각과 순서, 권한, 압축기 버전을 고정해야 합니다. 단순 백업이라면 ZIP 해시뿐 아니라 압축 해제 후 개별 파일 해시도 함께 비교하는 편이 원인을 찾기 쉽습니다.

  • 입력 파일 순서 고정
  • 수정 시각 정규화
  • 압축 도구와 버전 기록
  • 아카이브와 내부 파일 해시를 구분

확인한 1차 자료

작성·검수

파일 처리 실험을 직접 재현하고, 측정값과 해석의 경계를 검수합니다. 전문 감정이나 법률 판단을 대신하지 않습니다.