简介面向需要修改网卡物理地址、处理设备识别与网络环境适配问题的技术用户这份 MAC 地址硬刷工具包提供从原理说明到工具配置的较完整材料适合有一定动手能力、希望了解硬刷流程与风险边界的读者参考。压缩包共 197 个文件约 4.52MB包含 bin、c、mac、cfg、exe、txt、bat、map 等类型分别涉及固件与数据、源码、配置、执行程序、说明文本和批处理脚本并覆盖多类网卡芯片相关资源。已有 2556 人浏览学习说明该主题在设备调试与网络配置场景中具有一定关注度。包内还配有操作文档、参数配置与工具程序可帮助读者梳理硬刷思路、核对芯片适配信息并理解刷写前后的注意事项价值在于提供可查阅的资料集合与排错参考而非简单的单一工具。1. 同一批工控机撞地址mac 地址 硬刷 改的不是系统那一层整理一批退役工控机时碰到一个典型问题镜像克隆完之后好几台机器插到同一台交换机上ARP 表里翻来覆去就那两三个条目抓包能看到重复帧端口安全直接把它们全阻断了。用ip link set dev eth0 address改一下确实能通但重启失效换块硬盘进 PE 又变回老地址因为这个动作只动了操作系统内核里的一个字段。这套工具解决的是更靠下的那一层把 MAC 写进网卡自己的 EEPROM 或 NVM 区让固件在上电枚举阶段读到的就是新值。它适合做设备资产管理、兼容性测试、二手整机翻新、产线预配置的人如果你只是想临时换一次地址跑个脚本完全用不着动它风险也不对等。2. 三层地址的账MAC 在协议栈、驱动和 EEPROM 里各存了一份搞不清一块网卡上到底有几个地方存着 MAC后面所有操作都是盲写。实际排查下来同一个地址至少会在三个层面上出现而且它们的生效时机、谁能读到、重启后是否保留各不相同。把这三层的边界划清楚你才知道哪些场景软改够用、哪些必须硬刷也才知道刷完之后为什么有的地方显示新地址、有的地方还是旧的。2.1 软改能走多远协议栈层与驱动影子区最上层是协议栈。ip link set dev eth0 address改的是内核net_device结构里的dev_addr只在当前这次启动、当前这个网络命名空间里有效。Windows 上改注册表里的NetworkAddress属于同一层改完设备管理器显示新值但驱动一旦重载、或者系统进了一次快速启动值就回去了。这一层的好处是零风险、随时可逆坏处是它骗不过任何在操作系统之前运行的东西。中间层是驱动影子区这一层最容易被忽略。不少厂商驱动在 probe 阶段会把 NVM 里的 MAC 读进自己的适配器私有结构体之后收发队列、RSS 分流、带外管理都引用这份缓存。所以你可能会遇到一个很别扭的状态ip link show显示的是新地址ethtool -P读出来还是旧的UEFI 里的 PXE 启动更是完全不受影响。这不是工具没生效是你看的那一处不是真正被使用的那一处。判断方法很直接——冷启动一次断电再上电如果地址回退了说明你改的层没落到 NVM 上。最下层才是硬刷的目标网卡板载的串行 EEPROM或者 PCIe 卡上 SPI NOR 里划出来的 NVM 区。它在 PCI 枚举阶段被固件读出来随后操作系统 probe 时再读一次。这一层的特点是写进去就跟着卡走换系统、换硬盘、进 DOS、进 UEFI Shell读到的都是同一个值。代价是写错之后恢复成本高所以后面几章的重点全在备份、校验和回退上。注意只在自有或明确授权处置的硬件上做这类操作并且遵守所在网络的使用管理要求。批量改写设备标识会直接影响资产台账和端口安全策略动手前先跟管理这套网络的人对齐地址规划。还有一类特殊情况值得单独说板载 LOM 网卡的 MAC 常常不在网卡自己的 NVM 里。主板厂商在产线把 MAC 烧进 BIOS 的 SMBIOS 区域或者一块独立的 VPD 芯片POST 阶段再通过透传机制注入给网卡控制器。这类板子你把网卡 NVM 翻出来看前几个字往往是全FF或者全00这时候硬刷网卡完全没有意义要改的是 BIOS 那一侧。判断依据很简单——读出来的 NVM 前 6 个字节如果是全FF基本可以确定走的是注入路径。2.2 MAC 在 NVM 里的三种常见存法第一种是传统 EEPROM 的前三个字最常见于 PCIe 千兆卡。按 16 位字编址word 0 的低字节放 MAC[0]、高字节放 MAC[1]word 1 放 MAC[2] 和 MAC[3]word 2 放 MAC[4] 和 MAC[5]。校验和一般放在 word 0x3F算法是把 word 0x00 到 word 0x3E 累加再用0xBABA减去这个和取低 16 位。这个校验不是可选项——固件在加载 NVM 时会验它对不上就直接拒绝加载映像表现出来就是设备从lspci里消失。第二种是 PCI VPD 区。PCIe 设备在 NVM 里会保留一段 VPD 空间其中只读区以0x82大资源标签开头里面按关键字存着厂商名、部件号和MAC Address。这段内容独立于前一种布局两份值可以不一致。有些工具只更新主区的三个字VPD 里的副本原封不动结果就是操作系统看到新地址、某些带外管理工具读到旧地址。第三种是服务器网卡的 NVM 模块化布局。这类卡的 NVM 被切成 NVM、OROM、VPD、PXE 等多个模块每个物理端口在 NVM 里有一个 MAC 条目按端口索引存放另外还有一份 CRC。这种卡基本不能用「只改 6 个字节」的做法正确姿势是取出整个模块、改完条目、重算模块 CRC、再整块写回去。三种布局的关键差别在于副本数量和校验方式。改之前一定要先把整片 NVM 读出来对照着看这几个位置分别是什么值别照着某篇帖子里的偏移直接下手——同型号不同批次的卡偏移都可能不一样。# 从 sysfs 读 PCI VPD 原始内容避免 lspci 把长字段截断 BDF0000:03:00.0 sudo cat /sys/bus/pci/devices/$BDF/vpd | strings -n 4 | head -40 # 只读区里通常能看到 MAC Address 关键字后面跟 6 字节十六进制这段没有任何副作用纯读。strings -n 4是为了跳过 VPD 的二进制标签头只把可读关键字捞出来。如果vpd文件读出来是空的说明这张卡没实现 VPD或者内核没开CONFIG_PCI_VPD那就只能从 NVM 镜像里自己找。2.3 判断这块卡能不能硬刷三个判据第一个判据是写保护。SPI NOR 的写保护来自好几处Flash Descriptor 里 region 的读写权限位、BIOSSetup 里的 flash lock 选项、板上 WP 引脚的电平还有网卡固件自己对 NVM 写命令的拦截。有些卡能读出整片 NVM但写命令发下去返回成功、读回来没变——这就是被固件拦了。验证方法很土但有效写一个字节立刻读回比对。第二个判据是工具是否开放 MAC 字段。很多厂商工具只提供「整镜像更新」模式不给你单独改 MAC 的入口。这不是坏事整镜像更新会顺带重算所有副本和 CRC反而比手改 6 个字节安全。真正麻烦的是那种既不给整镜像、又不给单字段的工具只能靠自己打补丁。第三个判据是失败之后能不能救回来。有 SPI 编程器夹子、有双镜像golden image、有完整备份三者占一个就可以动手一个都没有就先别碰。设备类型MAC 实际来源硬刷可行性备注桌面级 PCIe 千兆卡NVM 前三个字 校验字可行必须同步重算 word 0x3F主板板载 LOM多为 BIOS/SMBIOS 注入网卡侧不可行NVM 里常为全 FF要改 BIOS 侧服务器万兆双口卡NVM 内按端口索引的 MAC 条目可行需整模块写入并重算 CRCUSB 网卡小容量 EEPROM多数不建议工具链零散校验规则不统一虚拟机 / 云主机无实体 NVM不可行由 hypervisor 配置决定这张表不是让你背是让你在拆机之前先花五分钟对一下自己的硬件落在哪一行。落在「不可行」和「不建议」两行的后面章节的操作全部不适用。3. 动手前的地基运行环境三选一与整片 NVM 备份真正把卡写坏的人绝大多数不是栽在改字节上是栽在没备份或者备份不完整。这一章全是准备工作看起来琐碎但每一步都在为后面可能的回退留后路。做过几次之后你会发现准备时间通常是写入时间的五到十倍这个比例是正常的。3.1 三种运行环境与各自的限制DOS 启动盘是兼容性最好的一种。厂商的刷写工具大多从 DOS 时代延续下来对各种老芯片的支持最全也不受操作系统驱动干扰。代价是需要一个能启动的 U 盘、要在 BIOS 里关掉 Secure Boot而且改完之后没法当场在同一个环境里做网络验证得重启进系统再看。UEFI Shell 是折中方案。把厂商的 EFI 版工具放到 FAT32 分区从 Shell 里直接执行改完可以立刻用ifconfig一类的命令看链路层地址省一次重启。限制是 Secure Boot 必须放开而且 Shell 下的文件系统路径写起来很啰嗦。Linux 用户态脚本化程度最高风险也最高。ethtool -E或者flashrom走 PCI BAR 直接发命令中间没有厂商工具那层版本检查和参数兜底。用这条路必须先确认驱动没占着设备需要手动 unbind# 确认设备被哪个驱动占用并解绑避免写入时驱动并发访问 NVM DEVeth0 BDF$(basename $(readlink -f /sys/class/net/$DEV/device)) DRV$(basename $(readlink -f /sys/class/net/$DEV/device/driver)) echo dev$DEV bdf$BDF driver$DRV sudo ip link set $DEV down echo $BDF | sudo tee /sys/bus/pci/drivers/$DRV/unbindreadlink -f顺着 sysfs 的符号链接拿到真实的 PCI 地址和驱动名比手敲lspci再肉眼对照可靠得多。ip link set down必须在 unbind 之前否则内核可能在解绑瞬间还在往队列里塞包。unbind 之后lspci还能看到设备但ip link里已经没有了这是正常状态别慌。3.2 备份整片 NVM 拉下来然后固化三份备份的原则是「宁多勿少」读整片不要只读前 512 字节。哪怕芯片只有 4K也按 4K 读满多读出来的部分就算是填充字节将来对照时也是有用的上下文。#!/bin/bash # 整片 NVM 备份分段读取以兼容老 ioctl 接口最后拼接并校验 set -euo pipefail DEV${1:-eth0} OUTbackup/nvm_${DEV}_$(date %Y%m%d%H%M%S).bin mkdir -p backup : $OUT # 老版本 ethtool 走 ioctl 时单次读取上限 0x200按 512 字节分段 for off in $(seq 0 512 7680); do printf -v hex 0x%x $off if ! sudo ethtool -e $DEV raw on offset $hex length 512 $OUT 2/dev/null; then echo 读取在 offset$hex 处结束镜像长度 $(stat -c%s $OUT) 字节 break fi done sha256sum $OUT | tee backup/sha256.txt cp $OUT /mnt/移动盘/ cp $OUT backup/nvm_golden.binraw on让工具输出原始二进制而不是 16 位字文本这一步很关键文本格式会丢字节序信息后面打补丁容易错位。offset和length都按字节算不要和字地址混。分段循环里那个break是有意留的读到芯片末尾时工具会报错此时镜像已经完整直接退出就行不要当成失败。最后三份副本——本地一份、外置介质一份、固定命名的 golden 一份——是给自己留的后悔药写坏了拿编程器回写 golden 就能救。3.3 写前基线六个必须记录的字段字段取值方式为什么必须记原始 MACip link show/ethtool -P回退目标和冲突排查的基准PCI 地址readlink -f /sys/class/net/$DEV/device多卡机器上避免刷错端口NVM 大小ethtool -e能读到的最长长度决定写入镜像的填充长度版本字镜像偏移 0x0A 附近或工具输出的 version工具做版本兼容检查时会用到原校验和按 2.2 的算法自己算一遍和工具读出的值对不上说明偏移判断错了备份文件 SHA256sha256sum回写前确认用的是不是当初那份第三行和第五行是新手最容易漏的。NVM 大小决定了写入时要不要补齐到整片长度——很多工具要求写入镜像长度和芯片容量严格相等短一个字节就报image size mismatch。原校验和自己算一遍的意义在于验证你对布局的判断如果自己按前三个字算出来的校验和跟镜像里 word 0x3F 的值对不上说明这张卡的布局不是你以为的那样赶紧停下来重新读。4. 打补丁到写入从 dump 到 flash 的可复现五步准备工作做完真正的写入其实只有几分钟。这一章把动作拆成五步每步之间都有一次比对任何一步对不上就退回上一步不要硬着头皮往下走。4.1 生成目标镜像改字节同时重算校验不要用十六进制编辑器手改。手改的问题不在改字节本身在于改完很容易忘记重算校验而校验错的表现是设备直接消失不是报错。用脚本改把校验计算和合法性检查一起做掉。#!/usr/bin/env python3 在备份的 NVM 镜像上替换 MAC 并重算 16 位校验和。 只适用“word0..word2 放 MAC、word 0x3F 放校验”的布局 其它布局必须先用读回结果确认偏移不要直接套用。 import sys import struct CHECKSUM_WORD 0x3F # 校验字所在字地址 CHECKSUM_BASE 0xBABA # 校验基数不同芯片可能不同 def patch(src: str, dst: str, mac: str) - None: data bytearray(open(src, rb).read()) m bytes(int(x, 16) for x in mac.replace(-, :).split(:)) assert len(m) 6, MAC 必须是 6 字节 assert not (m[0] 0x01), 首字节 bit0 为 1 是组播地址不能用作网卡地址 assert m[0] 0x02, 建议用本地管理地址首字节 bit1 置 1如 02/06/0A/0E 开头 # 小端每个 word 的低字节在前 struct.pack_into(BB, data, 0x00, m[0], m[1]) struct.pack_into(BB, data, 0x02, m[2], m[3]) struct.pack_into(BB, data, 0x04, m[4], m[5]) # 累加 word 0x00..word 0x3E即字节省 0x00..0x7D取低 16 位 end CHECKSUM_WORD * 2 total sum(struct.unpack_from(H, data, off)[0] for off in range(0, end, 2)) struct.pack_into(H, data, end, (CHECKSUM_BASE - total) 0xFFFF) open(dst, wb).write(data) print(fpatched {src} - {dst}, mac{mac}, size{len(data)}) if __name__ __main__: patch(sys.argv[1], sys.argv[2], sys.argv[3])三个assert是刻意的首字节 bit0 为 1 是组播地址写进去之后这块卡会收到一堆莫名其妙的多播流量bit1 为 1 才是本地管理地址也就是02、06、0A、0E这几种开头。用本地管理地址段最大的好处是不会和任何厂商 OUI 撞车资产台账上一眼就能看出这是人工规划的地址不是出厂值。CHECKSUM_BASE这个常量必须对着芯片手册确认。0xBABA是最常见的但也有用0xFFFF做模、或者干脆用 32 位 CRC 的。验证方式就是拿原始备份跑一遍计算看结果是否等于镜像里已有的校验字——相等说明常量和范围都对不等先别写。4.2 写入与冷复位一次写断电重启写入这一步有一个原则能用整镜像模式就别用单字段模式。整镜像模式内部会把所有副本和 CRC 一起更新单字段模式只管你指定的那 6 个字节VPD 副本、OROM 里的那份全都留着旧值。#!/bin/bash # 写入补丁后的整片镜像并强制冷启动使 NVM 重新加载 set -euo pipefail BDF${1:-0000:03:00.0} IMG${2:?用法: flash.sh BDF patched.bin} # 1) 确认设备处于解绑状态 ls /sys/bus/pci/devices/$BDF/driver 2/dev/null { echo 设备仍被驱动占用先执行 unbind; exit 1; } # 2) 整镜像写入-f 跳过版本检查的行为要清楚代价 sudo ./nvmupdate -nic 1 -i $IMG -log flash.log # 3) 立刻断电冷启动warm reboot 不足以让 NVM shadow 重新加载 sudo sync sudo shutdown -h now-nic 1在多口卡上指定端口序号写错端口是最常见的翻车方式多口卡一定要先用工具的输出确认端口和物理口的对应关系。-f强制跳过版本检查正常情况下不建议带——版本检查挂了通常意味着这个镜像不是给这张卡的强写进去校验和长度都可能不对。shutdown -h now而不是reboot是因为部分芯片的 NVM shadow 在 warm reset 时不重载必须真正掉电一次。4.3 常见写入工具的关键参数对照参数形态作用建议整镜像 / image 模式写入完整 NVM重算全部副本与 CRC首选除非工具不支持单字段 / mac 模式只改指定字节仅用于确认布局时的试写端口 / port index指定多口卡的物理端口必须与工具枚举输出核对强制 / force跳过版本与兼容性检查仅在确认镜像来源时使用保留 VPD写入时不动 VPD 区一般关闭让工具全量重算日志 / log输出每个模块的写入结果必须开失败时靠它定位日志这一项很多人嫌麻烦不开实际上写入失败时工具的控制台输出往往只有一行update failed具体是哪个模块、哪个偏移出的问题全在日志里。5. 避坑排查五个把网卡写成砖头的现场下面五条是按出现频率排的。前两条不涉及硬件损坏纯粹是「以为改对了其实没改」后三条是真的会丢设备动手前建议把这一章再看一遍。5.1 写完系统里还是旧地址现象工具日志显示写入成功退出码 0重启之后ip link show还是老 MAC。原因三种可能。一是只改了驱动影子区或者注册表压根没落到 NVM二是写到了另一个端口的 NVM 区多口卡上很常见三是 warm reboot 没有触发 NVM shadow 重载固件还在用启动时读到的那份缓存。解决先ethtool -P和ip link show对比两者不一致说明改的层不对再看工具枚举出来的端口序号和物理口是否对应最后强制断电冷启动一次。三步走完还是旧值就重新读回整片 NVM逐字节比对备份和当前内容看看到底哪个偏移真的变了。5.2 系统里是新地址PXE 启动还是旧的现象进系统后一切正常新 MAC 生效一改成网络启动DHCP 服务器上看到的还是旧地址。原因只更新了 NVM 主区的前三个字OROM 或者 VPD 里的副本没动。PXE 固件读的是 OROM 那一份操作系统驱动读的是主区那一份两条路径看到的值本来就可以不同。解决用整镜像模式重写一遍让工具把所有副本一起更新。写之前可以先读回整片镜像在偏移空间里搜一遍旧 MAC 的字节序列搜到几处就说明有几个副本。这个搜索动作很值得做成习惯——搜出来的位置数量就是你这次要改的位置数量。5.3 写完设备从 lspci 里消失了现象写入过程看似成功重启之后lspci完全看不到这张卡dmesg里也没有它的枚举记录。原因校验和算错或者镜像长度和芯片容量不匹配。固件加载 NVM 时校验失败直接放弃初始化这个 PCI function表现出来就是设备不存在。另一种可能是写入过程中断电NVM 只写了一半。解决如果之前有 SPI 编程器夹子和 golden 备份直接夹上去整片回写这是最快的路径。没有编程器的话部分服务器平台支持从 backup image 恢复进 BIOS 找 NVM recovery 相关选项桌面卡基本只能靠编程器。预防措施就是 3.2 那三份备份一份都不能省。5.4 板载网卡改完重启就失效现象写进去读回来都对冷启动之后又变回原来的 MAC反复几次都一样。原因这类板载 LOM 的 MAC 由 BIOS 在 POST 阶段注入网卡 NVM 里那 6 个字节要么是全FF要么根本没被使用。你写进去的值在注入阶段被覆盖掉了。解决改的方向错了要动的是 BIOS 的 SMBIOS 区域或者那块独立的 VPD 芯片。判断方法前面说过——读回 NVM 前 6 字节如果是全FF就不要再在网卡上折腾了。5.5 批量写完之后端口被交换机阻断现象一批机器刷完插上交换机端口起不来或者起来几分钟又被踢掉。原因两个层面。一是交换机端口安全配了 sticky MAC 或者静态绑定地址一变就触发 violation二是批量脚本把同一段地址写给了多台机器规划时没做去重。解决先看交换机侧的 violation 日志确认是哪种端口安全的话按流程更新绑定表地址重复的话重新规划用本地管理地址段按机位编号生成脚本里加一道全局去重检查再写入。批量场景下这一步比写入本身重要得多。6. 校验与回退把「三处读回」做成固定动作刷完之后只看一个地方的值是没有意义的。我现在的固定动作是三处读回ip link show看协议栈、ethtool -P看驱动读到的永久地址、再从 NVM 镜像里把前三个字抠出来看实体存储三者必须完全一致。任何一处对不上就说明还有副本没更新这时候不要急着重启进系统先把镜像重新读回来逐字节 diff。# 三处一致性校验任一不一致就阻断后续流程 DEVeth0 A$(ip link show $DEV | awk /link\/ether/{print $2}) B$(ethtool -P $DEV | awk {print $3}) C$(sudo ethtool -e $DEV raw on offset 0 length 6 | xxd -p | \ sed s/\(..\)\(..\)/\2\1/g | tr -d \n | sed s/../:/g;s/:$//) echo stack$A permanent$B nvm$C [ $A $B ] [ $B $C ] || { echo 不一致停止; exit 1; }中间那段sed是在做字节序交换——NVM 里每个 word 是低字节在前直接xxd出来顺序是反的不换过来比对必然失败。这个坑我踩过一次盯着两个明明相同的地址看了半小时。回退的触发条件我也写死了三条设备从lspci消失、校验和三处不一致且重写两次仍不收敛、链路起不来且排除了交换机侧配置。命中任意一条就直接上编程器回写 golden 镜像不在原地反复试。从那以后我每次刷完都强制走一遍「三处读回 断电冷启动 抓一次 DHCP」的流程宁可多花十分钟也不要在几十台机器的机房里靠猜。希望帮到你。本文还有配套的精品资源点击获取