简介HexEdit 是一个在 GitHub 上开源维护的十六进制编辑器能够以十六进制形式查看、搜索并修改二进制数据适合开发人员调试程序、逆向工程师分析恶意样本也适合普通用户手动修复损坏文件。这套资源正是该项目的完整源码包压缩后约 528KB却包含了涵盖 C/C 源码与头文件的两百多个文件同时附有位图、图标、工程配置、构建脚本和文档目录组织清晰便于按需查阅。通过阅读源码可以学习十六进制编辑界面的布局设计掌握查找替换、字节编辑等核心功能的实现逻辑并从中借鉴工具栏与界面资源的组织方式为后续开发同类工具或深入二进制安全研究提供代码级参考。目前已有 199 人浏览学习适合具备 C/C 基础、希望快速上手二进制编辑器二次开发的读者。1. HexEdit 是什么为什么二进制调试总是绕不开它如果你曾打开一个 .bin 文件看到满屏乱码却想定位某个配置字段你要用的就不是文本编辑器而是十六进制编辑器。HexEdit 正是这类工具里很有代表性的一个它把磁盘上的原始字节编排成一行行十六进制数字让你能直接查看、搜索、修改二进制内容。这篇文章从一线开发者的角度把 HexEdit 这类工具的落地实现拆开讲数据模型怎么建、编辑操作怎么建模、大文件为什么会卡以及我踩过的五个坑。适合两类读者手里有二进制文件想精准修改的以及想自己实现一个轻量 hex 工具的开发者。2. HexEdit 的数据模型从字节流到三栏视图的映射2.1 三栏视图的关键偏移、字节、ASCII 如何对齐几乎所有 hex 编辑器的主界面都是三栏最左侧是十六进制偏移地址中间是原始字节的十六进制表示右侧是对应字符的 ASCII 回退区。偏移列存在的意义是给每个字节一个绝对坐标否则在 GB 级文件里你根本说不清“在第几行”。中间栏每行通常显示 16 个字节称为一行宽度。右侧的 ASCII 区是一种辅助映射把 0x20-0x7E 之间的字节显示为可打印字符其余显示为点号用来快速辨别文本型数据和非文本型数据。我在自己写 HexEdit 时最先纠结的是行宽。宽度选 16 个字节界面紧凑换算方便——偏移每行增加 0x10正好和地址末位对齐。选 8 个字节每行地址变化更大适合窄屏选 32 字节能减少滚动但 ASCII 区会被压缩。下面的对比能看出差异行宽每行偏移增量适用场景常见工具默认值80x08窄屏调试、单看头部少数嵌入式工具160x10通用查看换算最直观多数编辑器320x20大区块浏览、磁盘镜像某些分析工具选择行宽不应该只凭喜好。偏移列宽度也要跟着行宽调整8 位偏移只适合文件小于 4GB0xFFFFFFFF超过 4GB 或需要定位到物理扇区时最好用 16 位十六进制补零否则排版会越看越别扭。这里还有一层容易忽略的选型理由十六进制天然对应 4 个比特也就是一个 nibble。一个字节的两个 hex 位刚好能覆盖 0x00-0xFF读两个字符比读 8 个二进制位快得多。二进制视图不是没有价值只是大多数人不愿意每天看一屏的 0/1所以 hex 视图是效率与可读性的平衡点。有些工具也支持十进制列其实十进制对字节掩码的观察反而不直观因为 0xA0 和 160 的位模式关系没法一眼看出。因此 HexEdit 的默认视图总是 hex其他进制只作为辅助。2.2 用 Python 写一个最小的 hex 预览读文件、格式化与分页先给一个能直接跑的最小实现。它读取整个文件按 16 字节一行输出偏移、十六进制字节和 ASCII 回退。虽然还不能编辑但足够验证你机器上的数据布局import sys def hex_dump(data, width16): lines [] for pos in range(0, len(data), width): chunk data[pos:pos width] hex_part .join(f{b:02x} for b in chunk) ascii_part .join(chr(b) if 32 b 126 else . for b in chunk) lines.append(f{pos:08x} {hex_part:{width * 3 - 1}} {ascii_part}) return \n.join(lines) if __name__ __main__: if len(sys.argv) ! 2: print(用法: python hex_dump.py 文件路径, filesys.stderr) sys.exit(1) with open(sys.argv[1], rb) as f: buf f.read() print(hex_dump(buf))逻辑说明hex_dump通过range(0, len(data), width)分页data[pos:pos width]切出当前行字节hex_part用f{b:02x}保证每个字节输出两字符避免0x0A显示成Aascii_part对 32-126 范围外的字节统一回退成点避免控制字符把终端搞乱。最后的格式化字符串里pos:08x是固定 8 位偏移如果文件超过 16MB0xFFFFFF这个宽度就不够了需要改成pos:0x或者pos:016x。参数调整建议行宽改成 8 时hex_part的宽度要同步改成width * 3 - 1否则列会对不齐这个-1是因为每 16 个字节的十六进制串内部会多出一个空格分隔符而format的宽度计算已经把空格算进去了。初次跑通后你会注意到 Python 的f.read()一次性加载整个文件——这个写法只能应付小文件后面第 4 章会讲 mmap 方案。选择 Python 做原型不是因为性能而是因为它处理字节流的库最直接open(path, rb)、mmap、bytearray都是内置功能两三屏代码就能验证想法。真要做到 HexEdit 那个量级我一般会把核心算法用 C 或 Rust 实现界面单独开一个进程但实现原理完全一致。你现在用 Python 把这个 dump 函数调通后面理解编辑和搜索就顺了。这也是我推荐新手起步时不急着碰大型代码库先拿 50 行脚本理解模型的原因。值得一提的还有偏移地址的“基址”概念。普通文件视图从 0 开始但如果你在调试一个加载到内存的固件镜像HexEdit 通常允许你设置一个基址让界面显示的虚地址等于文件偏移加基址。这一点在调试引导程序时特别有用——反汇编器给出的地址是 0x0800_0000而文件偏移只有 0x0000_0010没有基址换算你根本对不上。我在做模拟项目X 的启动镜像时就因为这个换算问题浪费了半个晚上。3. 把“能看”变成“能改”HexEdit 的编辑、搜索与撤销3.1 编辑操作为什么不能直接改文件补丁、事务与偏移漂移预览能跑通之后下一步就是编辑。编辑一个二进制文件看起来很简单——光标移到某个字节输入两个十六进制字符。一旦把“覆盖、插入、删除”三种操作全做上问题就来了插入和删除会改变后续所有字节的偏移如果你不做统一建模撤销、重做、搜索定位全会乱套。我的做法是把整个文件内容视为一个bytearray每次编辑都变成一次“补丁patch”记录操作位置、被覆盖的旧字节、以及新字节。覆盖操作的补丁长度不变插入补丁的旧字节长度为 0删除补丁的新字节长度为 0。撤销栈存的是逆补丁执行撤销时把旧字节原样写回再把新字节移除。下面这个简化类就是这个思路class ByteBuffer: def __init__(self, data: bytes): self.data bytearray(data) self.undo_stack [] def patch(self, offset: int, new_bytes: bytes) - bool: length len(new_bytes) if offset 0 or offset len(self.data): return False old_bytes bytes(self.data[offset:offset length]) self.data[offset:offset length] new_bytes self.undo_stack.append((offset, old_bytes, len(new_bytes))) return True def undo(self) - bool: if not self.undo_stack: return False offset, old_bytes, new_len self.undo_stack.pop() self.data[offset:offset new_len] old_bytes return True def insert(self, offset: int, new_bytes: bytes) - bool: if offset 0 or offset len(self.data): return False self.data[offset:offset] new_bytes # 长度为零的切片替换 self.undo_stack.append((offset, b, len(new_bytes))) return True def delete(self, offset: int, length: int) - bool: if offset 0 or offset length len(self.data): return False old_bytes bytes(self.data[offset:offset length]) self.data[offset:offset length] b self.undo_stack.append((offset, old_bytes, 0)) return True逻辑说明patch是核心方法它用切片赋值把new_bytes放到offset处因为切片赋值本身支持把较长或较短的序列赋进去覆盖、插入、删除都能统一走这一个方法。insert和delete只是给调用方更明确的语义。undo_stack里存的三元组分别记录起始偏移、被替换掉的旧字节、写入的新字节长度——撤销时只需要用旧字节原样覆盖新字节所在区域即可。这里有个细节如果插入发生在撤销栈里已有补丁的位置之后偏移已经漂移直接弹栈恢复会写错位置。解决方法是给每个补丁记录一个“操作序号”或者干脆把每次提交后的完整bytes快照存进撤销栈但快照方式对 GB 级文件是不可接受的折中做法是限制撤销步数或用差异化压缩。我先用这种简化版本后续要做大文件时再替换成反向补丁链。参数说明patch返回False表示偏移越界调用方必须把这种失败当成一次用户可见的错误而不是静默忽略insert里的self.data[offset:offset] new_bytes是 Python 切片插入的标准写法很多人第一次会写成self.data.insert(offset, new_bytes)但bytearray.insert一次只能插入一个整数不能插入一组字节。3.2 搜索十六进制串从暴力匹配到通配符支持编辑之前你首先得定位到目标位置。文本编辑器搜索的是字符串而 HexEdit 搜索的是十六进制序列比如48 65 6C 6C 6FHello 的 ASCII。更常见的是你只知道某些字节的掩码例如FF 0? 00其中0?表示“0 或任意字节”。我实现过两种匹配一种是针对固定串的 BMH 快速算法另一种是支持通配符??的逐字节暴力搜索。如果文件只有几 MB暴力搜索就够快如果固件镜像到几十 MB还带通配符就需要 BMH 的坏字符表来跳过大量比较。下面这个函数支持??通配符返回所有匹配位置。它按空格切分模式int(part, 16)把十六进制文本转成字节None代表任意值def find_pattern(data: bytes, pattern: str): tokens pattern.split() p [] for t in tokens: if t ??: p.append(None) else: p.append(int(t, 16)) if not p: raise ValueError(模式不能为空) n len(p) for i in range(len(data) - n 1): match True for j in range(n): pb p[j] if pb is not None and data[i j] ! pb: match False break if match: yield i这里要特别提醒int(t, 16)解析不了类似0?这种半通配符。如果模式里只有高位确定、低位任意最省事的写法是把它拆成两个具体字节去匹配或者在匹配层面对?做 nibble 级判断。我在做 HexEdit 时一开始图省事只用字节级??后来解析一个文件头时遇到“某个字节的 bit 3 是标志位”被迫加了 4-bit 掩码匹配。这个需求其实很常见但代码量会膨胀不少需要把模式的每个 token 都转换成(mask, value)对比如0?变成(0xF0, 0x00)。有一个常见误用是拿正则去搜二进制。Python 的正则表达式是基于文本的re默认会把字节串解码成字符遇到非 UTF-8 字节会直接抛错或匹配错位虽然能通过re.compile(b\\x48\\x65)匹配字节但逐字节十六进制处理更直观也方便加入??通配。我的经验是对于十六进制编辑器正则只适合在 ASCII 区域做辅助过滤核心搜索必须建立在自己的字节匹配层上。把搜索和编辑串起来你就能实现真正的“查找到→修改→撤销”闭环。闭环的逻辑是搜索返回偏移用户输入新十六进制字节patch修改缓冲区用户按撤销时恢复原字节。看似简单实战中问题都出在偏移管理上。例如你在文件开头插入了一个字节之前定位到的所有后续偏移都失效了界面需要立即刷新并重新计算映射。这也是下一章要重点处理的大文件问题的一部分。4. 大文件不卡死的关键HexEdit 的内存映射与增量渲染4.1 为什么大文件不能一次性读入内存、加载时间和撤销开销第 2 章的f.read()在文件只有几百 KB 时没毛病但你拿它打开一个 4GB 的磁盘镜像瞬间就会卡死甚至直接把内存打爆。这不是 Python 的问题凡是read()全部数据再构建界面的方案都有同样的隐患。我自己最初用open().read()打开一个 700MB 的安装包界面停了 8 秒才出来还吃了近 1GB 内存后来才改用内存映射。内存映射mmap的原理是把磁盘文件映射到进程的虚拟地址空间物理内存按页按需加载操作系统负责页缺失和回写。这样你就能像访问数组一样访问文件而不需要把整个文件复制进进程堆里。对 HexEdit 这种随机访问为主的工具mmap几乎是最优解。选型上的另一个选择是分块预读只维护最近访问的 64MB 窗口窗口以外重新读盘。这比 mmap 更省地址空间但代码复杂度高而且刷新频繁时容易顿挫。如果文件不超过 2GBmmap 足够用再大我建议先做分块再考虑 64 位偏移。4.2 用 mmap 实现随机读写参数、边界与报废陷阱下面这段代码展示了用 mmap 打开一个二进制文件并随机读写的基础操作。需要注意文件必须存在且不以只读方式打开mmap对象支持切片读写写入内容不会立刻刷到磁盘需要调用flush()。import mmap def open_file(path: str): with open(path, rb) as f: if f.seek(0, 2) 0: raise ValueError(文件大小为 0无法映射) m mmap.mmap(f.fileno(), 0, accessmmap.ACCESS_WRITE) return m # 注意with 退出后 f 关闭但 mmap 仍有效 def read_bytes(m, offset: int, length: int) - bytes: return m[offset:offset length] def write_bytes(m, offset: int, data: bytes) - None: m[offset:offset len(data)] data if __name__ __main__: m open_file(firmware.bin) head read_bytes(m, 0, 16) print(head.hex( )) write_bytes(m, 0, b\x00 * 4) m.flush()参数说明mmap.mmap(f.fileno(), 0, accessmmap.ACCESS_WRITE)的第二个参数0表示映射整个文件修改映射的内容是直接修改磁盘页面但页面回写时机由操作系统决定所以要调用flush()确保落盘。ACCESS_WRITE等价于读写如果要同时读取建议直接用它如果只想临时看看就用ACCESS_READ避免误改文件。另一个容易被忽略的边界是offset len(data)不能超过当前文件大小否则会抛IndexError。mmap对象和文件句柄的生命周期绑定代码里open_file用了with在 POSIX 系统上退出后映射依然可用Windows 上则不允许关闭映射源文件这一点要按平台处理。注意不要试图在 mmap 上做长度变化的插入删除这是碰不得的边界。这里隐藏着一个大坑mmap不能改变文件长度。也就是说你无法通过映射直接“插入”或“删除”字节那些操作必须回到普通文件 I/O用resize或者fallocate调整长度然后重建映射。我遇到过一个翻车场景在映射对象上尝试切片赋值一个更长的 bytes 块程序直接抛SystemError然后整个进程崩溃。正确做法是先把要扩展的尾部数据读出来调整文件大小再重新mmap或者严格限制只允许覆盖编辑即不允许用户插入删除。HexEdit 这类工具多数会提供插入删除模式因此它的编辑缓冲区必须建模为bytearray导出时再整体写回文件——这就是为什么很多 hex 编辑器编辑超大文件时会有一个“应用补丁”的确认步骤。另一个性能要点是增量渲染。无论如何映射你都不能把整个文件画到界面上。通常做法是只渲染可视区域根据滚动位置计算首尾偏移读取该范围的几百 KB 到临时 buffer格式化后更新表格。这样即使文件有 4GB滚动时的开销也只和视口大小相关和文件总大小无关。配合当前光标所在的偏移栏更新用户体验才跟得上。如果你在写命令行版 HexEdit增量渲染的简单实现是维护current_offset每次滚动事件发生时重新调用read_bytes读取一个新的窗口然后重新生成屏幕内容。一个可用的窗口大小是 64KB对应 4096 行按 16 字节宽。如果你用 curses 或文本终端一次刷新 4096 行并不慢但鼠标滚轮会触发大量连续滚动最好加一个 50ms 的合并定时器只在滚动停止后渲染一次。这个技巧能明显降低 CPU 占用避免滚动时“像幻灯片”。5. HexEdit 使用与实现的避坑指南五个高频翻车点5.1 行宽变化导致偏移错位与“对不上”的排查现象把默认行宽从 16 改成 8 之后文件里所有数据的偏移都显示成奇数个字符看起来像是每一行都偏移了几个字节甚至光标定位错误。原因行宽改变后偏移列、十六进制列和 ASCII 列之间的宽度没有同步调整。很多实现只在渲染时把字节分组变量改了但偏移列的格式化宽度沿用旧值导致列基线不一致。另外偏移地址是按字节计算的如果你把行宽改成 8但每行输出仍然以 16 个字节为单位去切片那每一行第二个“半行”会错位。解决维护一个统一的dump_line(data, offset, width)函数偏移列宽度根据文件大小动态计算例如文件 64MB 用08x否则用016x切片长度严格取width不要每隔 8 字节打一个换行符。我通常在每行末尾输出偏移的校验值比如pos width调试时一眼就能看出行步进是否正确。5.2 mmap 修改文件后不生效页面未 flush 与文件句柄生命周期现象在 mmap 上写了字节关闭程序后再打开文件改动丢失或者只写入了部分页面。原因没有调用flush()或者映射对象被垃圾回收但文件句柄已经提前关闭。Windows 上如果映射源文件句柄被close()映射对象会失效写入直接报错或静默丢失。解决使用with mmap.mmap(...) as m:生命周期管理修改后立即m.flush()退出前再os.fsync(fd)确认落盘。我习惯在每次保存操作时先flush()再os.fsync()速度会慢一些但能避免文件系统缓存导致的“保存后没改”的错觉。5.3 插入删除后撤销栈失效偏移漂移造成错误覆盖现象在一个文件中间插入 100 个字节然后对插入点后面某位置做替换再按撤销结果撤销不是恢复插入前的内容而是把旧数据覆盖到了错误位置。原因撤销栈里的补丁记录的是“文件原始偏移”插入操作之后的偏移都向右漂移了之前记录的位置现在指向了新数据。解决两种方案。一是为每个补丁追加版本号撤销时按版本号重放之前的补丁二是对编辑历史做“逆序撤销”也就是从最后一次操作开始往前撤销保证每次撤销时偏移都处于上一次操作后的状态。我在自己写 HexEdit 时选了第二种配合一个操作序列树用户即使不按顺序撤销也必须先撤销最近的操作才能回到更早的状态。5.4 搜索“0A”却搜不到任何内容ASCII / 十六进制输入混淆现象用户输入0A期望匹配一个换行字节但结果什么都搜不到输入0a则可以匹配或者说输入A0匹配到的却是文本字符 “A0” 的 ASCII。原因很多工具的搜索框默认是文本模式输入0A被当成两个字符0和A的 ASCII 码0x30 0x41而不是字节 0x0A。如果输入框同时支持文本和十六进制模式用户容易踩到模式切换的坑。解决把搜索和替换的输入分两栏十六进制输入框只接受0-9 A-F 空格字符输入时实时转成字节并给用户明确的提示0A表示一个字节 0x0A不是字符串“0A”。同时把通配符模式做成按钮比如??、0?减少手打格式导致误解析的机会。5.5 编辑后文件损坏备份与原子写现象用 HexEdit 改固件镜像保存后整个文件打不开甚至文件大小变成 0。原因程序把修改写回时直接打开原文件用write覆盖了一个“错误偏移”或者中途崩溃写到一半的文件破坏了原始内容。解决保存逻辑永远遵循“先写临时文件再原子替换”的流程先创建文件.tmp写入完整内容flushfsync最后用os.replace替换原文件。这样即使写坏原文件也不会受影响。我个人的习惯是任何批量修改前先用脚本做一次整个文件的备份哪怕只是加一个.bak后缀。你可以在 HexEdit 里把保存操作封装成一个函数检查同目录是否存在同名.bak文件不存在就自动创建一份副本。这个习惯救过我一次。6. HexEdit 的进阶玩法校验脚本、结构化解析与批量修改有了稳定可靠的编辑内核HexEdit 不只是手动点鼠标的工具还能做成批处理管线。最常见的是配合脚本做三件事校验和验证、结构字段解析、批量替换。以固件镜像为例你从十六进制视图里看到一个 4 字节字段它的偏移可能是 0x10但你不知道它是小端还是大端更不知道校验和算法。与其盯着屏幕心算不如让脚本输出字面值。下面是我常用的一段 crc16/modbus 校验代码专门用来在 HexEdit 里核对固件头校验def crc16_modbus(data: bytes) - int: crc 0xFFFF for b in data: crc ^ b for _ in range(8): if crc 1: crc (crc 1) ^ 0xA001 else: crc 1 return crc # 用法读取从偏移 0 到 0x1F 的 32 字节然后和偏移 0x20 处存的校验值比较 buf read_bytes(m, 0, 0x20) print(hex(crc16_modbus(buf)))参数说明0xA001是 CRC-16/MODBUS 的反向多项式适合大多数通信帧和固件头如果文件头是 CRC32就要换zlib.crc32。你可以把这个函数直接粘到 HexEdit 的脚本窗口输入目标偏移范围立即算出校验值不需要再开外部工具。我一般还会写一个小函数解析“小端 4 字节字段”def u32le(data: bytes, offset: int) - int: return int.from_bytes(data[offset:offset 4], little)批量修改的场景更实用。比如你要把某个配置区域的 magic number 从0xDEADBEEF改成0xC0FFEE01脚本只需定位到该偏移write_bytes(m, offset, b\x01\xEE\xFF\xC0)就可以在保存前自动完成。我建议把这类操作放到一个“修改脚本”里脚本执行前打印将要修改的偏移和旧值/新值确认后再写入。一次典型的对话流程是用 HexEdit 打开文件输入搜索模式定位再运行一小段 Python验证上下文确认后一次修改避免手动输入十六进制的笔误。最后分享一个我自己的习惯每次修改前先把从文件头开始的前 64 字节 dump 成带偏移的文本存到一个.log文件里。这个“修改前日志”看起来很简单但它记录了修改前的基线万一后来发现改动有问题可以直接对照日志恢复现场而不是靠记忆。我在处理某跨平台系统的启动参数时就是靠这招定位了一处错误的字节序。HexEdit 这个方向想做深还可以继续扩展把文件按结构模板解析成字段树给不同的字节区域上色甚至按处理器指令集高亮。你不需要一步到位从“看得见字节”开始逐步加上搜索、编辑、校验就能把它从一个小玩具变成每天离不开的调试武器。希望帮到你。本文还有配套的精品资源点击获取