바이너리 Hex 에디터 | 파일을 16진수로 보고 편집하기
파일을 드래그 앤 드롭하면 내용을 바이트 단위 16진수(hex dump)로 확인할 수 있습니다. 매직 바이트로 파일의 실제 형식을 확인하고, 바이트를 직접 편집한 뒤 다운로드할 수 있습니다. 파일은 서버로 전송되지 않습니다.
자주 사용되는 파일 시그니처(매직 넘버) 목록
| 형식 | 시작 바이트(16진수) | 오프셋 | 비고 |
|---|---|---|---|
| PNG | 89 50 4E 47 0D 0A 1A 0A | 0 | 이미지 파일. 8바이트가 모두 일치하면 PNG로 거의 확실하게 판정 가능 |
| JPEG | FF D8 FF | 0 | 이미지 파일. 4번째 바이트는 JFIF/Exif 등 변형에 따라 달라짐 |
| GIF | 47 49 46 38 39 61 / 47 49 46 38 37 61 | 0 | ASCII 문자열 "GIF89a" 또는 "GIF87a" |
| 25 50 44 46 2D | 0 | ASCII 문자열 "%PDF-" 뒤에 버전 번호가 이어짐 | |
| ZIP / docx / xlsx / jar | 50 4B 03 04 | 0 | ZIP 형식. Office Open XML 계열 및 여러 압축·아카이브 형식이 내부적으로 ZIP을 사용 |
| Windows 실행 파일(EXE/DLL) | 4D 5A | 0 | ASCII 문자열 "MZ". PE 형식에 남아 있는 MS-DOS 실행 파일 헤더의 흔적 |
| ELF 실행 파일 | 7F 45 4C 46 | 0 | Linux 등에서 사용되는 실행 파일·공유 라이브러리 형식 |
Hex 에디터 활용 팁
- 확장자가 바뀐 파일의 정체를 알고 싶다면 파일 앞부분 몇 바이트(매직 바이트)를 위 목록과 대조해 보세요. 확장자는 단순한 자기 신고에 불과하지만, 매직 바이트는 파일 형식 자체에서 비롯되므로 위조하기가 훨씬 어렵습니다.
- 16진수 직접 입력 모드에서는 다른 도구에서 복사한 바이트열(공백 구분·줄바꿈 구분 모두 가능)을 그대로 붙여넣어 불러올 수 있습니다.
- 편집 중 잘못된 셀을 클릭했다면 Esc 키를 눌러 해당 셀의 편집을 취소할 수 있으며, 바이트 값은 변경되지 않습니다.
- 바이너리 프로토콜을 디버깅할 때는 예상되는 바이트열과 실제로 주고받은 바이트열을 이 도구에서 나란히 비교하면 어긋난 부분을 쉽게 찾을 수 있습니다.
자주 묻는 질문
FF D8 FF로 시작한다면 확장자와 무관하게 JPEG 이미지일 가능성이 큽니다.
여담이지만 ― 파일의 진짜 정체는 확장자가 아니라 바이트에 담겨 있다
Windows의 파일 확장자는 운영체제에 "이 파일을 어떤 앱으로 열 것인가"를 알려주는 힌트일 뿐, 파일의 실제 내용과는 독립된 문자열입니다. 그래서 `사진.jpg`를 `메모.txt`로 바꾼다고 해서 텍스트가 되지는 않으며, 반대로 진짜 이미지 파일의 확장자를 지워도 데이터 자체는 여전히 이미지로 남아 있습니다. 이처럼 확장자가 본질적으로 "자기 신고"에 불과하다는 점을 악용해, 실행 파일을 이미지나 문서로 위장하는 악성코드 수법은 오래전부터 알려져 있습니다.
이에 대응하기 위해 대부분의 파일 형식은 앞부분 몇 바이트에 고유 식별자(매직 바이트, 매직 넘버라고도 함)를 심어 두는 방식으로 설계되어 있습니다. 예를 들어 PNG는 사양에 따라 항상 `89 50 4E 47 0D 0A 1A 0A`라는 정확한 8바이트로 시작합니다. 즉 운영체제나 애플리케이션은 파일 이름이 아니라 실제 내용을 확인해야만 비로소 "이것이 정말 PNG인가"를 판단할 수 있습니다. 유닉스 계열의 `file` 명령어나 브라우저의 MIME 타입 판정 역시 확장자가 아니라 이러한 매직 바이트 대조를 주된 근거로 삼습니다.
매직 바이트의 설계에는 역사적인 재치도 엿보입니다. 예를 들어 PNG의 8바이트에는 의도적으로 줄바꿈 코드(0D 0A)가 포함되어 있는데, 이는 텍스트 모드로 파일이 전송될 때 줄바꿈 코드가 변환되어 손상되지는 않았는지 감지하기 위한 장치입니다. 단순한 식별자에 그치지 않고 전송 과정의 손상 감지까지 겸하도록 설계된 점에서 바이너리 포맷 설계의 깊이를 엿볼 수 있습니다.