1. 项目概述为什么我们需要hexdump在Linux世界里我们每天都在和各种文件打交道文本文件、配置文件、日志文件这些用cat、less就能轻松查看。但当你面对一个二进制文件时比如一个编译好的可执行程序、一张图片的原始数据、一段网络抓包的数据流或者一个损坏了但你想看看它“肚子里”到底装了什么的文件常规的文本查看器就彻底“抓瞎”了。它们要么显示一堆乱码要么直接报错。这时候你就需要一个能“透视”文件底层数据的工具而hexdump正是这样一把瑞士军刀。简单来说hexdump是一个命令行工具它能以十六进制以及可选的ASCII字符格式逐字节地显示文件内容。这就像给文件做了一次“X光扫描”让你能看清它的每一个字节byte到底是什么。十六进制之所以成为标准是因为它比二进制表示更紧凑一个字节正好用两个十六进制数字表示如0xFF又比十进制更直观地对应到内存地址和位操作。我最初接触hexdump是在调试一个网络协议时。客户端发送过来的数据包在程序里解析总是出错。用hexdump把接收到的原始数据“dump”出来和协议文档一比对立刻发现是某个字段的字节序Endianness搞反了。这种“眼见为实”的排查方式比在代码里打无数个printf要高效得多。对于系统管理员、安全研究员、嵌入式开发者和逆向工程爱好者来说hexdump是一个不可或缺的基础工具它能帮你分析文件格式、排查数据损坏、验证加密或编码结果甚至是进行简单的二进制文件编辑配合其他工具。2. hexdump命令的核心语法与模式解析hexdump的命令行语法看似简单但其格式控制选项非常灵活这也是它功能强大的地方。其基本形式如下hexdump [选项] [文件...]如果不指定文件或者文件名为-它会从标准输入读取数据。这意味着你可以用管道将其他命令的输出直接交给hexdump分析例如cat binary.bin | hexdump。它的核心魔力在于-C这个最常用的选项以及更底层的-e格式字符串。我们先从最常用的开始。2.1 经典布局-C 选项Canonical HexASCII Display对于大多数日常使用-C选项是你的首选。它提供了一个规整的、信息丰富的经典显示布局。hexdump -C filename.bin执行后你会看到类似这样的输出00000000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 |.ELF............| 00000010 02 00 3e 00 01 00 00 00 c0 55 40 00 00 00 00 00 |........U.....| 00000020 40 00 00 00 00 00 00 00 10 2e 00 00 00 00 00 00 |...............| 00000030 00 00 00 00 40 00 38 00 09 00 40 00 1c 00 1b 00 |.....8........|我们来拆解这个布局第一列如00000000偏移量Offset。表示当前行显示的16个字节数据在文件中的起始位置以十六进制表示。这对于定位特定数据块至关重要。中间部分8组双字节十六进制数据区。每两个字符代表一个字节8位的数据。注意它通常以每8个字节为一个单元进行分组中间用空格隔开这主要是为了视觉上的对齐符合很多系统内存地址的显示习惯。例如7f 45 4c 46就是文件最开始的4个字节。最后一列在|之间ASCII表示区。hexdump会尝试将同一行的16个字节解释为ASCII字符。如果是可打印字符字母、数字、标点就显示出来如果是控制字符或不可打印字符则显示为一个点.。这让你能快速识别文件中嵌入的文本字符串。比如第一行的.ELF就明确告诉你这是一个ELF格式的可执行文件。注意-C选项显示的字节顺序是文件的物理存储顺序。在分析涉及多字节整数如int, short的文件格式时你需要自己判断字节序大端序Big-Endian还是小端序Little-Endian。例如一个16位的值0x1234在文件中存储为34 12那么它就是小端序。2.2 自由定制-e 格式字符串Format String当你需要更特定的输出格式时-e选项提供了终极的灵活性。它的功能强大到可以模拟-C的效果也能实现各种自定义布局。格式字符串的基本单位是“格式单元”用引号括起来。一个简单的例子是只显示十六进制hexdump -e ‘“%07.7_ax: ” 8/1 “%02x ” “\n”’ filename.bin%07.7_ax 格式化输出偏移量。07.7指定输出至少7位宽度_a表示以十六进制地址格式输出x是格式类型。整体效果是输出类似0000000的7位十六进制偏移量后跟一个冒号和空格。8/1 “%02x ” 这是数据迭代部分。8/1表示“循环8次每次处理1个字节”。在每次循环中使用“%02x ”格式来打印当前字节即用两位十六进制数表示不足两位前面补零后面跟一个空格。“\n” 每处理完8个字节后换行。这会产生类似-C的十六进制部分但没有分组和ASCII栏。你可以通过组合多个格式单元来实现复杂效果。例如下面这个命令几乎完全复现了-C的布局hexdump -e ‘“%07.7_ax ” 8/1 “%02x ” “ ” 8/1 “%02x ” “ |”’ -e ‘16/1 “%_p” “|\n”’ filename.bin这里用了两个-e格式字符串。第一个处理偏移量和两段8字节的十六进制数据第二个处理同一行的16个字节的ASCII表示。为什么需要-e举个例子如果你在分析一个全是32位整数4字节的数据文件你可能希望每行显示4个整数并以十进制形式展示。使用-e就可以轻松实现hexdump -e ‘4/4 “%10d ” “\n”’ data.bin。这种定制能力在解析特定二进制协议或数据格式时非常有用。2.3 其他实用选项速览除了-C和-ehexdump还有其他一些有用的选项-n length 仅转储文件的前length个字节。这在查看文件头或只想快速瞥一眼文件开头时非常方便。例如hexdump -C -n 64 myfile只查看前64字节。-s offset 跳过文件开头的offset个字节从指定位置开始显示。例如hexdump -C -s 1024 myfile从文件的第1024字节开始显示。-v 强制显示所有数据。默认情况下hexdump如果发现连续多行内容完全相同会用一行*来代替以节省输出空间。这在看全零区域时很常见。但有时你需要确认每一行的具体内容这时-v选项就禁止了这种缩写。3. 实战演练hexdump在多种场景下的应用理解了基本语法我们来看看hexdump在实际工作中如何大显身手。我会通过几个具体场景展示从基础到进阶的用法。3.1 场景一识别未知文件类型文件“指纹”分析你从网上或同事那里拿到一个没有扩展名的文件mystery_filefile命令可能因为信息不全也无法准确判断。这时查看文件头是最直接的方法。hexdump -C -n 64 mystery_file通过头几个字节你就能做出判断89 50 4e 47 0d 0a 1a 0a 这是PNG图片的魔数Magic NumberASCII对应是.PNG....。ff d8 ff e0 这是JPEG/JFIF图片的开头。25 50 44 46 这是PDF文件的开头%PDF。7f 45 4c 46 这是Linux可执行文件ELF的开头.ELF。50 4b 03 04或50 4b 05 06 这是ZIP压缩包或JAR、DOCX等的开头PK..。实操心得记住一些常见文件的魔数能让你在缺乏其他工具时快速定位问题。对于更复杂的格式结合hexdump和格式文档如分析一个WAV音频文件头你可以手动验证采样率、声道数等信息是否与预期一致。3.2 场景二分析文本文件中的隐藏字符与编码文本文件看起来简单但有时行为诡异比如在Windows上编辑的脚本到Linux下执行报错“\rcommand not found”或者某些行尾多出了奇怪的字符。创建一个测试文件echo -e “hello\x00world\nline2\r\n” test.txt这个文件包含了空字符\x00和混合的换行符\n和\r\n。用cat -A可以看一些但用hexdump更底层hexdump -C test.txt输出00000000 68 65 6c 6c 6f 00 77 6f 72 6c 64 0a 6c 69 6e 65 |hello.world.line| 00000010 32 0d 0a |2..| 00000013一目了然第5个字节是00空字符这在C语言字符串中是结束符可能导致某些文本处理工具提前截断。“world”后的0a是换行符\nLF。“line2”后的0d 0a是回车换行符\r\nCRLF。排查技巧如果你在调试一个配置文件解析错误或者脚本执行异常用hexdump检查文件内容往往能立刻发现是因为BOM字节顺序标记如UTF-8的ef bb bf或者行尾符不一致导致的问题。3.3 场景三调试网络数据与二进制协议这是hexdump的黄金应用场景。假设你正在开发一个TCP服务端客户端连接发送数据但你的解析逻辑有问题。你可以在接收数据的代码处将原始的字节缓冲区byte buffer写入一个临时文件然后用hexdump分析。更常见的用法是结合网络工具。例如用ncnetcat监听端口并保存原始数据nc -l -p 12345 raw_data.bin客户端连接并发送数据后用hexdump分析raw_data.bin。或者直接使用管道进行实时分析# 假设有个工具myclient会发送二进制数据 myclient | hexdump -C案例解析假设你收到一个4字节的整数hexdump显示为78 56 34 12。如果你的系统是小端序x86架构常见那么这4个字节代表的整数值是0x12345678从后往前读。如果你错误地按大端序解析0x78563412就会得到一个完全不同的数字。hexdump帮你看到了最原始的数据结合你对协议的了解协议规范通常会规定字节序就能验证解析逻辑是否正确。3.4 场景四逆向工程与安全分析初步在安全领域分析恶意软件或漏洞利用样本Exploit时hexdump是第一步。你可以快速查看样本中是否包含明文字符串比如硬编码的IP地址、URL、命令或函数名。# 结合strings命令先提取可读字符串再用hexdump精确定位 strings -t x malware.bin | head -20 # -t x 显示字符串在文件中的十六进制偏移量 # 假设发现可疑字符串“evil.com”在偏移量0x400处 hexdump -C -s 0x400 -n 64 malware.bin这样你就能看到evil.com这个字符串在二进制文件中的上下文前后可能还有其他的配置信息或代码。注意事项高级的恶意软件会混淆字符串可能不会直接显示。但hexdump仍然可以用来分析文件结构比如查看PEWindows可执行文件头、节Section表或者寻找特定的字节模式Pattern这些可能是解密例程或Shellcode的特征。3.5 场景五与其他命令行工具协作hexdump的威力在于它能无缝嵌入Unix的管道哲学。过滤特定内容 你可以用grep搜索十六进制输出中的模式但要注意grep处理的是文本行。更强大的工具是xxd另一个十六进制转储工具它支持反向操作-r或者用awk、sed处理hexdump的输出。# 查找文件中是否包含0xdeadbeef这个魔数 hexdump -v -e ‘1/4 “%08x\n”’ file.bin | grep -i deadbeef这个命令用-e将文件每4个字节格式化为一个8位十六进制数一个32位字然后通过grep搜索。对比二进制差异 虽然diff用于文本但我们可以用hexdump将二进制文件“文本化”后再比较。diff (hexdump -C file1.bin) (hexdump -C file2.bin)或者使用专门的二进制比较工具如cmp -l但hexdump的方式能提供更直观的上下文。生成数据或简单编辑 虽然hexdump本身不用于编辑但你可以将它的输出尤其是规范格式-C保存下来人工修改右侧的ASCII栏这没有实际效果或者作为参考然后使用xxd -r将修改后的十六进制文本转换回二进制文件。注意这是一个危险操作需要极其小心务必先备份原文件。4. 进阶技巧与深度原理解析掌握了基本应用后我们深入一些细节和原理这能帮助你更精准地使用hexdump并理解其输出背后的含义。4.1 字节序Endianness问题与手动解析这是分析二进制文件格式时最大的坑之一。hexdump -C忠实地按字节在文件中的物理顺序显示。但一个多字节数据如32位整数0x12345678在内存或文件中的存储方式有两种大端序Big-Endian 高位字节在前。存储为12 34 56 78。网络字节序通常是大端序。小端序Little-Endian 低位字节在前。存储为78 56 34 12。x86/x64架构采用小端序。如何判断没有捷径必须依据文件格式的规范。例如PNG文件 大端序。文件头的长度字段如IHDR块长度就是大端存储。BMP文件Windows位图 小端序。文件头的数据偏移等字段是小端存储。TCP/IP协议头 大端序网络字节序。手动解析示例 假设你用hexdump -C看到一个PNG文件的IHDR块数据开始于偏移量0x08内容是00000008 00 00 00 0d 49 48 44 52 00 00 02 80 00 00 01 e0 |....IHDR........|根据PNG规范49 48 44 52是“IHDR”标识。它前面的4个字节00 00 00 0d是IHDR数据块的长度大端序。将其转换为十进制0x0d 13。这意味着接下来的13个字节从49开始后的13字节是IHDR数据。IHDR数据的前4个字节是宽度00 00 02 80大端序解析为0x280即640像素。接着4个字节是高度00 00 01 e0即480像素。4.2 格式字符串-e的详细语法与高级用法-e格式字符串的完整语法很强大其核心是“迭代次数/字节数 格式字符串”迭代次数 重复执行后面格式字符串的次数。字节数 每次迭代从输入中消耗的字节数。hexdump内部有一个指针按照这个字节数向后移动。格式字符串 类似C语言printf的格式但有自己的专用转换字符。常用转换字符%_ax 输出当前地址偏移量默认十六进制。%_ao 输出当前地址八进制。%_adu 输出当前地址十进制。%_p 以字符形式输出。不可打印字符显示为.。%_c 以字符形式输出。不可打印字符可能显示为控制字符或乱码。%x,%o,%u,%d 分别以十六进制、八进制、无符号十进制、有符号十进制输出。它们默认处理4个字节32位但可以通过前缀修饰。%2x 输出2个字节的十六进制。%1x 输出1个字节的十六进制等同于%02x常用于单字节。%4.4x 输出4字节宽度至少4位。高级示例 解析一个自定义二进制数据文件该文件由重复的“记录”组成每个记录结构为1字节类型Type2字节小端序长度Length然后是可变数据。# 假设我们想漂亮地打印每个记录的头信息 hexdump -e ‘“Offset: %06_ax | Type: %01x | Length: ” 1/2 “%04x (LE) - ” 1/2 “%04x (BE)\n”’ -e ‘“ Data (first 16B): ” 16/1 “%02x ” “\n\n”’ data.bin这个复杂的格式字符串做了两件事第一个-e打印偏移量6位十六进制然后读取1个字节作为Type%01x接着读取2个字节但按小端序解释1/2 “%04x”会读取2字节并格式化为4位十六进制数但hexdump默认按大端序解释读取的多字节数据这里有个关键点。实际上hexdump的%x等格式对于大于1字节的数据总是按当前系统的字节序通常是主机字节序来解释从文件中读取的字节流。所以如果文件是小端序而你的系统是大端序直接用%2x会出错。对于非主机字节序的数据更安全的做法是读取单字节1/1然后手动计算或者使用其他工具如od八进制转储它提供了-I32位十进制、-i32位十六进制等明确指定字节序的选项。这引出了hexdump的一个局限性它对多字节整数的格式化依赖于主机字节序。因此对于严格的跨平台二进制数据分析如果涉及多字节整数并且文件字节序与主机不同建议使用od命令它支持-t x1单字节十六进制避免字节序问题或者用-t x2等并注意其说明。用hexdump -C获取原始字节流然后手动或编写脚本进行解析。这才是最可靠的方式。4.3 hexdump与od、xxd的对比与选型Linux下还有其他二进制查看工具最常用的是odoctal dump历史原因命名和xxdVim编辑器自带。特性hexdumpod(GNU)xxd主要特点功能均衡格式灵活系统自带历史最悠久选项繁多字节序控制强输出规整自带反汇编-r反向操作是其特色经典视图hexdump -Cod -Ax -tx1z或od -t x1 -A xxxd或xxd -g 1字节序控制弱格式化多字节数依赖主机序强-I大端32位、-i小端32位等弱类似hexdump反向操作不支持有限支持-i等支持xxd -r可将十六进制文本转回二进制自定义格式强大-e格式字符串非常强大-t指定类型较弱学习曲线中等较高选项复杂较低选型建议日常快速查看hexdump -C或xxd。xxd的默认输出分组更紧凑。需要精确控制多字节整数解析尤其是非主机字节序 首选od。例如od -t u4 -A d file以十进制查看32位无符号整数主机序od -I -A d file以大端序查看32位十进制整数。需要将十六进制输出转换回二进制 首选xxd -r。编写脚本或需要复杂自定义输出hexdump -e或od -t各有千秋取决于你对格式控制的熟悉度。5. 常见问题排查与操作避坑指南即使掌握了命令在实际使用中还是会遇到各种问题。下面是我总结的一些典型场景和解决方案。5.1 输出看起来全是零或重复星号*现象 使用hexdump -C查看一个大文件中间出现大量连续的*号。... 00000200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00001000 48 65 6c 6c 6f 20 57 6f 72 6c 64 0a 00 00 00 00 |Hello World.....|原因与解决 这是hexdump的默认行为当检测到连续两行或更多行内容完全相同时它会用一行*代替以节省输出空间。这常见于全零区域或未初始化的数据段。如果你需要查看所有这些重复行的具体内容请加上-vverbose选项hexdump -C -v file.bin。5.2 解析多字节数据如int, float时结果不对现象 你用hexdump -e ‘1/4 “%d\n”’想读取一个32位整数但得到的值完全错误。原因 这几乎肯定是字节序问题。hexdump的%d、%u、%x等格式符在处理大于1字节的数据类型时是按照你当前CPU的字节序来解释输入字节流的。如果你的文件数据是大端序如网络数据、某些文件格式而你的CPU是小端序常见于x86那么直接使用%d就会得到错误的值。解决方案最可靠的方法 使用hexdump -C查看原始字节序列然后根据文件格式规范手动计算。例如看到字节12 34 56 78若规范为大端序则值为0x12345678若为小端序则值为0x78563412。使用od命令od提供了明确的字节序选项。例如以大端序解释32位有符号整数od -t dI -A n file.bin-t dI表示十进制、4字节、使用“整型”大小和主机字节序注意od的-I才是大端32位十进制。更准确的用法是od -t x4 -A x file.bin 以主机序查看4字节十六进制。要指定字节序可能需要结合其他工具或脚本因为od的-t选项的字节序有时也依赖系统。最保险的还是方法1。实操心得 在分析任何二进制文件前第一件事就是确认其字节序。查看格式规范RFC、官方文档或者通过已知的魔数、固定值来推断。不要假设。5.3 如何精确提取文件中的某一段数据需求 你从hexdump输出中发现从偏移量0x400到0x4ff的数据是你需要的想单独保存出来。解决方案 使用dd命令它是二进制数据操作的“手术刀”。dd iforiginal.bin ofextracted.bin bs1 skip$((0x400)) count$((0x4ff - 0x400 1))if 输入文件。of 输出文件。bs1 块大小设为1字节便于精确控制。skip 跳过输入文件开头的字节数。这里用Shell算术$((0x400))将十六进制转换为十进制。count 要拷贝的块数因为bs1所以就是字节数。计算长度是结束偏移 - 开始偏移 1。更便捷的方式 结合hexdump和dd。先用hexdump -C找到范围再用dd提取。5.4 处理非常大的二进制文件问题 文件有几个GB直接用hexdump -C会刷屏很久甚至可能耗尽内存。策略只查看头部/尾部hexdump -C -n 4096 hugefile.bin # 只看前4KB tail -c 4096 hugefile.bin | hexdump -C # 查看最后4KB需要先跳过前面部分查看特定偏移区域hexdump -C -s 0x100000 -n 2048 hugefile.bin # 从1MB偏移处开始看2KB结合less分页查看hexdump -C hugefile.bin | less在less中你可以用/搜索特定的十六进制或ASCII模式。使用strings快速检索可读内容 如果只是想找文件里的字符串strings hugefile.bin | less效率高得多。5.5 常见错误与注意事项速查表问题/现象可能原因解决方案命令未找到系统未安装hexdump极少数最小化安装使用xxd或od替代或安装bsdmainutils包Debian/Ubuntu输出乱码/换行错乱终端编码问题或文件包含特殊控制字符确保终端UTF-8编码。使用hexdump -C其ASCII栏会将控制字符显示为.想查看的偏移量不对计算错误或文件本身有特殊结构如分区表使用-s跳过指定字节时确认偏移量是十进制还是十六进制。在Shell中$((0x400))表示十六进制400需要编辑二进制文件hexdump本身不具备编辑功能使用专门的十六进制编辑器如bless,ghex,hexedit或使用xxd生成文本编辑后用xxd -r转回高风险需备份管道输入时格式不对输入数据可能不是纯二进制或者包含终端控制序列确保数据源是原始的。对于命令输出有时需要21重定向标准错误或使用cat读取最后记住hexdump是一个查看工具。对于复杂的二进制文件解析、编辑或修补应当使用更专业的工具如010 Editor、Bless或编程语言如Python的struct模块、binascii。但无论如何hexdump作为第一步的“侦察兵”其快速、直接、无处不在的特性使其在命令行工具箱中的地位始终不可动摇。下次当你面对一个“黑盒”般的二进制文件时别犹豫先用hexdump -C给它照个X光吧。