Hex Editor

The Cyber Forensics Academy reference captures the role of hex editors in technical work: “Hex editors are the scalpels of the digital forensic world. While large automated suites are the heavy machinery, hex editors allow for the precision work required to solve the most difficult cases. Whether it is WinHex for its robust disk imaging, HxD for its speed, or 010 Editor for its parsing capabilities, having a hex editor in your toolkit is non-negotiable.”¹

The fundamental concept

A hex editor reveals what files and disks actually contain at the byte level:

• Text editor: shows characters; hides byte representations.
• Word processor: shows formatted text; hides everything except the visible content.
• Image viewer: shows pixels; hides the underlying file structure.
• File manager: shows file names and metadata; hides the actual bytes entirely.
• Hex editor: shows the raw bytes underneath all of those abstractions.

The Norton Disk Editor heritage

Hex editors trace their lineage to mainframe hex dump utilities and 1980s PC tools:

• 1960s-1970s: mainframe hex dump utilities for examining program memory and tape contents.
• 1985: Norton Utilities released DiskEdit by Peter Norton; the canonical 1980s/1990s PC hex/disk editor.
• 1990s: WinHex by X-Ways established as the forensic-grade hex editor on Windows.
• 2003: HxD by Mael Horz released; became the standard free Windows hex editor.
• Mid-2000s: 010 Editor introduced Binary Templates for structured parsing.
• 2010s-2020s: Cross-platform tools (ImHex, wxHexEditor) and online tools (HexEd.it) emerged.
• Present: hex editors remain essential tools for forensics, reverse engineering, and recovery.

Who uses hex editors

Hex editors serve diverse professional needs:

• Software developers: debugging binary file formats, inspecting compiled outputs, examining process memory.
• Reverse engineers: analyzing executable files, malware samples, proprietary binary formats.
• Security researchers: examining suspicious files, identifying malware signatures, analyzing exploits.
• Forensic examiners: recovering deleted files, examining metadata, verifying chain of custody.
• Data recovery practitioners: manually inspecting damaged headers, examining partition tables, analyzing recovery results.
• Game modders: editing save files, modifying assets, applying binary patches.
• Embedded systems engineers: programming firmware images, analyzing protocol dumps.
• Chip-tuning specialists: editing ECU firmware images for engine performance modifications.

Why “hex” specifically

The hexadecimal display format is the de facto standard for several practical reasons:

• Compactness: two hex digits represent one byte (8 bits); base-10 would need three digits per byte.
• Bit alignment: each hex digit corresponds to exactly 4 bits, making bit-level analysis straightforward.
• Historical convention: hardware documentation, memory dumps, and machine code references all use hex.
• Pattern recognition: common values like 0xFF (all bits set), 0x00 (zero), 0x80 (sign bit) are easily recognizable.
• Round multiples: 16-byte rows align cleanly with cache lines, sectors (512 bytes = 32 rows), and pages.

The standard hex editor display has been remarkably stable for decades. Understanding the layout is the first step to using any hex editor effectively.

The three-column layout

Every modern hex editor uses essentially the same three-column layout:

• Left column (offset): shows the byte position in the file or disk; typically displayed in hexadecimal (00000000, 00000010, 00000020 for rows starting at bytes 0, 16, 32).
• Middle column (hex bytes): shows the actual byte values as pairs of hex digits separated by spaces; typically 16 bytes per row.
• Right column (ASCII): shows printable characters or dots/placeholders for non-printable bytes.
• Optional middle separator: some editors split the hex column at byte 8 with extra spacing for readability.
• Cursor/highlighting: the same byte position is highlighted in both hex and ASCII columns.

A practical example

Opening a Windows executable in a hex editor shows characteristic patterns at the start:

Offset	Hex Bytes	ASCII
00000000	4D 5A 90 00 03 00 00 00 04 00 00 00 FF FF 00 00	MZ…………..
00000010	B8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00	……..@…….
00000020	00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00	…………….
00000030	00 00 00 00 00 00 00 00 00 00 00 00 80 00 00 00	…………….
00000040	0E 1F BA 0E 00 B4 09 CD 21 B8 01 4C CD 21 54 68	……..!..L.!Th
00000050	69 73 20 70 72 6F 67 72 61 6D 20 63 61 6E 6E 6F	is program canno
00000060	74 20 62 65 20 72 75 6E 20 69 6E 20 44 4F 53 20	t be run in DOS

The 4D 5A at offset 0 is the “MZ” signature identifying a Windows PE executable; the message “This program cannot be run in DOS mode” appears at offset 0x4E.

Display modes and grouping

Modern hex editors offer several display modes for the byte values:

• Byte view (8-bit): default mode; each byte shown as two hex digits.
• Word view (16-bit): bytes grouped in pairs; useful for examining 16-bit integer values.
• Dword view (32-bit): bytes grouped in fours; common for 32-bit integers and pointers.
• Qword view (64-bit): bytes grouped in eights; useful for 64-bit values.
• Endianness: little-endian or big-endian interpretation; affects how multi-byte values are displayed.
• Address base: offset can be displayed in hex (default), decimal, or octal.

The data inspector panel

Modern hex editors include a data inspector that shows the same bytes interpreted multiple ways:

• int8 / uint8: single byte as signed/unsigned 8-bit integer.
• int16 / uint16: two bytes as signed/unsigned 16-bit integer; little-endian and big-endian variants.
• int32 / uint32: four bytes as signed/unsigned 32-bit integer.
• int64 / uint64: eight bytes as signed/unsigned 64-bit integer.
• float / double: 32-bit and 64-bit IEEE 754 floating-point numbers.
• LEB128: variable-length integer used in Android DEX files and WebAssembly.
• Time formats: Unix timestamp, Windows FILETIME, GUID interpretations.
• Strings: ASCII, UTF-8, UTF-16 (LE/BE) interpretations of the byte sequence.

Insert vs overwrite modes

Hex editors typically support two editing modes with critical implications:

• Overwrite mode: typing replaces existing bytes without changing file size; the default for most hex editors.
• Insert mode: typing inserts new bytes, expanding the file size; behaves like a text editor.
• Why this matters: binary file formats often have offsets and lengths that depend on file structure; insert mode breaks these references.
• Default safety: overwrite mode is safer for binary files because it preserves file structure.
• Visual indication: most editors show INS or OVR in the status bar.

Color highlighting and bookmarks

Advanced hex editors provide visual aids for navigating large files:

• Bookmarks: mark specific offsets for quick return; named with descriptions.
• Color coding: different colors for different byte ranges or value types.
• Selection highlighting: selected ranges shown in distinctive colors.
• Difference highlighting: when comparing two files, differences highlighted automatically.
• Pattern highlighting: matched search patterns highlighted across the file.
• Template highlighting: 010 Editor and ImHex highlight bytes according to applied templates (header, payload, footer).

The hex editor landscape includes free and commercial tools across all major platforms. Choosing the right tool depends on use case, platform, and feature requirements.

HxD (Windows free standard)

The HxD official documentation describes its capabilities: “HxD is a carefully designed and fast hex editor which, additionally to raw disk editing and modifying of main memory (RAM), handles files of any size. The easy to use interface offers features such as searching and replacing, exporting, checksums/digests, insertion of byte patterns, a file shredder, concatenation or splitting of files, statistics and much more.”² Key HxD properties:

• Developer: Mael Horz; first released 2003; current version 2.5.0.0.
• Platform: Windows only (NT 4.0+); no macOS or Linux build.
• License: freeware (not open source); free for personal and commercial use.
• File size limit: up to 8 EB (essentially unlimited).
• Disk editing: raw access to physical drives; requires Administrator privileges.
• Memory editing: read and write running process memory.
• Export formats: can export selections as C, Java, Pascal source code arrays.
• Single edition: no Lite/Pro split; all features in the free version.

010 Editor (commercial cross-platform)

010 Editor is the leading commercial hex editor with a unique structured-parsing capability:

• Developer: SweetScape Software; current pricing $49.95 single license.
• Platforms: Windows, macOS, Linux.
• Binary Templates: 300+ predefined templates parse file formats into structured hierarchical views.
• Scripting: C-style scripting engine for automating analysis tasks.
• Process memory: can edit running process memory.
• Disk editing: raw disk access on all platforms.
• File comparison: sophisticated diff with synchronized scrolling.
• Use cases: reverse engineering, malware analysis, forensic examination, structured binary analysis.

Hex Fiend (macOS native)

Hex Fiend is the standard macOS hex editor:

• Platform: macOS only (native Cocoa application).
• License: free, open source (BSD-style).
• Strengths: handles very large files efficiently with smooth scrolling.
• Features: file comparison, search, basic editing, multiple files in tabs.
• Limitations: no scripting or templates like 010 Editor.
• Distribution: available via Mac App Store and direct download.

Linux options: Bless, GHex, wxHexEditor

Several free hex editors target Linux users:

• Bless: GTK-based GUI hex editor; multi-threaded; user-friendly.
• GHex: GNOME hex editor; simple interface; basic feature set.
• wxHexEditor: cross-platform; particularly strong with very large files; works on Windows, macOS, Linux.
• Okteta: KDE hex editor; integrates with KDE Plasma desktop.
• HexEd.it: browser-based; no installation required; good for quick edits.

ImHex (modern open-source)

ImHex represents the modern open-source approach with features comparable to 010 Editor:

• Platform: Windows, macOS, Linux (cross-platform).
• License: free, open source (GPL-2.0).
• Pattern language: custom scripting language for binary analysis (similar to 010 Editor templates).
• Features: data processor (visual node-based analysis), bookmarks, search, hash calculator.
• Active development: regular releases; community-driven feature additions.
• Use cases: reverse engineering, CTF challenges, forensic analysis, binary research.

Forensic-specific: WinHex

WinHex by X-Ways Software is the industry-standard forensic hex editor:

• Developer: X-Ways Software Technology AG.
• Platform: Windows only.
• License: commercial (multiple tiers from professional to forensic).
• Forensic features: evidence-grade disk imaging, hash verification, write blocking integration.
• Disk capabilities: RAID reconstruction, partition recovery, slack space examination.
• X-Ways Forensics: the premium forensic suite built on WinHex foundation.
• Use cases: law enforcement, e-discovery, professional incident response.

Command-line alternatives

Unix-style CLI tools provide hex editing capabilities without GUI:

Tool	Source	Capability	Use case
xxd	Bundled with Vim	Hex dump and reverse	Quick file inspection in scripts
hexdump	BSD utilities	Formatted hex output	Standard CLI hex viewing
od	POSIX coreutils	Octal/hex/decimal dump	Text/binary file inspection
bvi	Separate package	vi-style binary editor	Vi users editing binary files
dhex	Separate package	ncurses hex editor	Terminal-based editing with diff
hexyl	Modern Rust	Pretty-printed hex viewer	Read-only colorized inspection

Hex editors support a consistent set of operations across tools. Understanding these operations is essential for using any hex editor effectively.

File signature inspection

Identifying file types from byte signatures is one of the most-common hex editor tasks. The Cyber Forensics Academy reference describes signatures: “A sequence of bytes at the beginning of a file that identifies its format, visible using a hex editor.”³ Common file signatures (magic numbers):

File Type	Hex Signature	ASCII	Notes
Windows PE / EXE / DLL	4D 5A	MZ	Named after Mark Zbikowski
JPEG image	FF D8 FF	…	Followed by E0/E1/etc.
PNG image	89 50 4E 47 0D 0A 1A 0A	.PNG….	8-byte signature
GIF image	47 49 46 38	GIF8	Followed by 7a or 9a
BMP image	42 4D	BM	Bitmap
PDF document	25 50 44 46	%PDF	Followed by version
ZIP archive	50 4B 03 04	PK..	PK = Phil Katz, ZIP creator
RAR archive	52 61 72 21 1A 07	Rar!..	WinRAR signature
GZIP archive	1F 8B	..	2-byte signature
ELF Linux executable	7F 45 4C 46	.ELF	Executable and Linkable Format
Mach-O macOS executable	CE FA ED FE / CF FA ED FE	….	32-bit / 64-bit variants
RIFF / WAV audio	52 49 46 46	RIFF	Container format
MP3 audio	49 44 33 / FF FB	ID3 / ..	ID3 tag or raw frame
SQLite database	53 51 4C 69 74 65 20 66 6F 72 6D 61 74 20 33 00	SQLite format 3.	16-byte signature

Searching

Hex editors provide multiple search modes for finding patterns:

• Hex search: find specific byte sequences (e.g., “FF D8 FF E0” for JPEG header).
• ASCII search: find text strings; case-sensitive or case-insensitive options.
• Unicode search: find UTF-8, UTF-16 LE, or UTF-16 BE strings (important for Windows file paths).
• Regex search: advanced editors support regular expressions for pattern matching.
• Wildcard search: “??” or similar wildcards within hex patterns.
• Find next/previous: navigate through multiple matches.
• Highlight all: mark every match in the file simultaneously.

File comparison and diff

Comparing two files at the byte level is essential for many analytical tasks:

• Synchronous scrolling: two files displayed side-by-side; scrolling one moves both.
• Difference highlighting: bytes that differ between the two files highlighted in distinctive colors.
• Difference map: visual overview showing density of differences across the entire file.
• Use cases: comparing original vs modified file, identifying patches, analyzing file format variations.
• Tools with strong diff: 010 Editor, FlexHEX, WinHex; HxD has basic comparison only.

Hash calculation and checksums

Most hex editors include integrated hash and checksum calculation:

• Common hashes: MD5, SHA-1, SHA-256, SHA-512.
• CRC variants: CRC-16, CRC-32, CRC-64 with various polynomials.
• Live calculation: hash updates automatically as the file changes.
• Selection hashing: calculate hash of selected byte range only.
• Use cases: verifying file integrity, identifying known files, forensic chain of custody.

Byte patching and editing

Beyond viewing, hex editors enable direct byte modification:

• Direct typing: click on a byte and type the new hex value.
• ASCII editing: click in the ASCII column to type characters that map to bytes.
• Fill region: set a range of bytes to a specific value (e.g., zero out a region).
• Pattern fill: repeat a hex pattern across a range.
• Cut/copy/paste: standard clipboard operations on byte ranges.
• Undo/redo: reversible editing with multiple undo levels.
• Save/save as: persist changes to original or new file.
• Read-only mode: protect against accidental modification during analysis.

Templates and structured analysis

The most-distinguishing feature of advanced hex editors is structured analysis via templates:

• 010 Editor Binary Templates: C-like syntax describes file format structure; applied template highlights and labels bytes (header, payload, footer).
• ImHex pattern language: similar concept; pattern files map bytes to named structures.
• WinHex template editor: XML-based templates for forensic file format analysis.
• Use cases: understanding unfamiliar file formats, identifying corrupted fields, extracting embedded data.
• Pre-built libraries: hundreds of templates available for common formats (PNG, JPEG, ZIP, PE, ELF, PDF, registry hives).

Hex editors play several specific roles in data recovery scenarios where automated tools cannot complete the job alone.

Why manual hex editing matters

The Cyber Forensics Academy reference describes the importance of manual analysis: “In an age of automated forensic tools, one might ask why manual hex editing is necessary. The answer lies in verification and precision. Automated tools rely on known signatures and parsers; if an attacker uses a custom packer or slightly modifies a file header, automated tools may fail to recognize the evidence. A hex editor allows an analyst to manually verify the file structure. Furthermore, hex editors are essential for data recovery.”⁴ Specific recovery applications:

• Automated tools fail when signatures are damaged or non-standard.
• Custom or obscure file formats may not have automated parsers.
• Verification of automated tool output requires manual inspection.
• Manual reconstruction enables recovery from drives that automated tools mark as unrecoverable.

FOUND.000 / .CHK file identification

One of the most-common recovery use cases involves identifying file types from chkdsk‘s FOUND.000 directory:

1. Open a FILE0001.CHK file in a hex editor.
2. Examine the first 16-32 bytes for a magic number signature.
3. Cross-reference against known file signatures (using the table above or signature databases).
4. Rename the file with the correct extension based on the identified type.
5. Open the renamed file in the appropriate application to verify recovery.

Partition table examination

Hex editors enable direct inspection of partition tables for recovery purposes:

• MBR examination: open the disk in a hex editor and navigate to offset 0x1BE; the next 64 bytes contain four 16-byte partition entries.
• MBR signature: bytes at offset 0x1FE-0x1FF should be 55 AA; missing or wrong signature indicates corruption.
• GPT header: at LBA 1 (offset 0x200) for 512-byte sector drives; signature is “EFI PART” (45 46 49 20 50 41 52 54).
• GPT entries: begin at LBA 2 (offset 0x400); each entry is 128 bytes by default.
• Backup GPT: at the end of the disk; useful when primary GPT is corrupted.
• Manual repair: with knowledge of partition layout, hex editor can repair corrupted MBR/GPT directly.

MFT and filesystem structure analysis

NTFS and other filesystems can be examined directly via hex editor:

• NTFS boot sector: at offset 0 of the partition; signature “NTFS” at offset 3.
• MFT location: the boot sector specifies the MFT cluster offset.
• MFT records: each is 1024 bytes by default; signature “FILE” at start.
• FAT examination: FAT12/16/32 boot sector at partition offset 0; FAT tables follow.
• ext4 superblock: at offset 0x400 of the partition; magic number 0xEF53 at offset 0x456.
• Use case: when automated recovery tools fail, manual MFT/FAT analysis can locate file fragments.

Manual file header repair

Damaged file headers can sometimes be repaired manually with a hex editor:

1. Open the damaged file in one hex editor pane.
2. Open a known-good file of the same type in another pane.
3. Compare the headers byte-by-byte to identify which bytes differ.
4. Determine which differences are normal variations and which represent damage.
5. Copy correct bytes from the known-good file to the damaged file.
6. Save and test if the file can be opened normally.
7. Common scenarios: ZIP archives with corrupted central directory, JPEG files with damaged EXIF, PDF files with corrupted xref tables.

File carving boundary identification

For files recovered from unallocated space, hex editors help identify proper boundaries:

• Start identification: magic number marks the beginning of a file.
• End identification: end-of-file markers vary by format (FF D9 for JPEG, %%EOF for PDF, IEND chunk for PNG).
• Length headers: some formats include explicit length in the header (e.g., RIFF chunks).
• Manual extraction: select bytes from start to end signature, save as new file with appropriate extension.
• Use cases: recovering files that PhotoRec or similar tools missed due to unusual structure.

Recovery tool output verification

After running automated recovery tools, hex editors help verify the results:

• Compare recovered files against the source disk image at the byte level.
• Identify any bytes that were misrecovered or replaced with placeholders.
• Check for valid file structure (correct magic numbers, valid length fields, proper terminators).
• Detect when automated tools have stitched fragments incorrectly.
• Confirm that critical data (specific records, identifiable strings) is present in recovered output.

When hex editors are essential vs convenient

Hex editors are essential rather than optional in specific scenarios:

• Essential: identifying unknown file types, repairing damaged headers, examining partition tables, verifying forensic chain of custody.
• Essential: custom or proprietary file format analysis, malware reverse engineering.
• Convenient: verifying automated tool output, learning file format internals.
• Convenient: teaching binary file structure, understanding endianness and encoding.
• Not necessary: routine file recovery where automated tools succeed; standard backup and restore workflows.