大家好，
我一直在研究海康威视K41 NVR固件修改，想分享我的研究成果，回馈一下社区。这篇文章主要介绍了四个K41固件版本的解压、修改、重新分配和验证过程。我还回复了一些之前对我帮助很大的帖子。
学术研究声明：本文所述的对海康威视K41 NVR加固的解包、修改和重新定位仅用于学术研究和教育目的。目标是遵守嵌入式加固结构、启动流程和静态完整性验证方法。此项工作不涉及、支持或鼓励任何其他安全威胁，包括默认授权的访问、攻击、绕过任何安全机制、接入后门或非法使用。未进行任何物理刷写操作操作，也未尝试绕过数字签名验证。测试目标仅限于K41 NVR；未测试DVR设备和其他平台。
固件：hikvision_3.4.87.dav、hikvision_3.5.30.dav、hikvision_3.5.35.dav、hikvision_4.1.50.dav
平台：K41系列网络录像机
工具：hikpack 2.5（带-t k41参数）、mkcramfs、mount -tcramfs-oloop、Python 3.10
环境：WSL2上的Ubuntu 22.04 LTS
我发现：两种不同的硬件结构
K41固件根据版本不同有两种布局：
结构 A — 多文件 (4.1.50)：解压后，将获得单独的文件：uImage、start.sh、sys_app.tar.lzma、gui_res.tar.gz、webs.tar.lzma、TX1_Version.bin 等。start.sh 是纯文本，可以直接编辑。
结构B —cramfs镜像（3.4.87、3.5.30、3.5.35）：解压后，你会得到cramfs.img、new_10.bin和new_20.bin。你需要挂载cramfs镜像才能访问根文件系统中的start.sh文件。
cramfs 提取——挂载与 binwalk 的区别
我首先尝试使用 binwalk，但在 WSL2 下遇到了权限错误。可靠的方法是使用 Linux 手动挂载：
狂欢
mkdir -p /mnt/cramfs_tmp 根文件系统
sudo mount -t cramfs -o loop cramfs.img /mnt/cramfs_tmp
sudo cp -a /mnt/cramfs_tmp/* rootfs/
sudo umount /mnt/cramfs_tmp
修改rootfs/目录下的文件后，使用以下命令重新分配：
狂欢
mkcramfs rootfs new_cramfs.img
主要发现：hikpack会自动处理校验和。
这是我最重要的发现。我对比了重新压缩备份的 new_10.bin 文件，确认 hikpack 在压缩过程中会重新生成所有校验和数据——包括文件 CRC、new_10.bin、new_20.bin 以及文件头 CRC。您需要手动更新任何 CRC 或 MD5 值。
pack 命令很简单：
狂欢
./hikpack -t k41 -p modified_firmware.dav -o firmware_extracted
审批以下人员：
狂欢
./hikpack -t k41 -i modified_firmware.dav
开发类必须保留
.dav 文件头中的 devclass 字段是硬件平台标识符。我从原始固件中自动提取了该字段，并在重新备份过程中保持不变。如果您更改了该字段，设备可能无法识别该固件。
我注射的
我在 start.sh 文件的添加了一个简单的命令：
狂欢
echo "脚本脚本正在运行" > /tmp/custom.log
这不会改变任何现有逻辑——它只是在启动脚本中添加了一行。
结果
固件开发类结构状态
3.4.87 0x44 jamfs 重新分配 + 已验证
3.5.30 0x5Acramfs 重新分配 + 已验证
3.5.35 0x5A jamfs 重新分配 + 已验证
4.1.50 0x3D 多文件重新分配 + 已验证
所有四个修改后的固件文件都通过了 hikpack -i 头部 CRC 校验。我重新解压了每个文件，并确认注入的命令出现在 start.sh 文件的构成中。
结构验证（无物理提示）
我没有将这些文件刷入设备。相反，我构建了一个静态验证方法，我称之为 SIS（结构完整性签名），该方法比较修改反向启动关键元数据：
cramfs：块超级魔法+大小+版本
u图片：magic + 加载地址 + 入口点 + 图片CRC
start.sh：sh -n 语法检查
对于所有四个固件版本，修改前后 SIS 都一个。
对现有主题的回复
@montecrypto 的 hikpack 帖子（2016 年）——您的工具在我的 K41 目标设备上完美运行。您内置的自动校验和重生成功能为我节省了很多 CRC 校验的工作。我不确定最新的固件版本，但在 3.4.87 到 4.1.50 版本上，hikpack 2.5 -t k41 命令可以正常工作。
“如何提取 .dav 固件文件”（2023）——文中提到较新的固件可能会阻止 hikpack 运行，这一点表示。我没有测试过最新版本，所以无法证实或否认。关于cramfs 文件的提取，我想补充一点，在 WSL2 上，使用
“海康威视DVR固件逆向工程”（2017）——你的工作流程仍然适用。我的测试目标是K41 NVR，而不是DVR，因此设备类型不同，但方法仍然具有参考价值。我将结构检测（多文件与cramfs）并重新分配流程自动化到一个Python脚本中，该脚本可以透明地处理两种布局。
“海康威视巩固工具”（2015）——早期的工具奠定了基础。在我的K41设备上，3.x版本使用cramfs文件系统，而4.1.50版本则切换到了多文件布局。hikpack -t k41命令可以处理这两种文件系统。
我尚未审核的内容
为了说清楚，避免错误任何人：
我没有将这些修改过的固件文件实际刷入任何设备。
我还没有测试最新的海康威视固件是否会阻止hikpack。
我没有尝试绕过数字签名验证。
修改后我尚未验证系统功能（硬盘、网络、Web用户界面等）。
仅在K41 NVR上进行了测试——未在DVR、K51、R0、R1或其他平台上进行测试。
希望这对某些人有用。如果您在其他 K41 版本或其他平台上尝试过类似的批发，我很想听听您的结果。
再次声明：本实验中的解包、修改和重新分配操作仅用于纯粹的学术研究，不涉及任何其他安全威胁或非法目的。它们不用于未经授权的访问、攻击、绕过安全机制、入口后门或任何非法用途。
干杯
我一直在研究海康威视K41 NVR固件修改，想分享我的研究成果，回馈一下社区。这篇文章主要介绍了四个K41固件版本的解压、修改、重新分配和验证过程。我还回复了一些之前对我帮助很大的帖子。
学术研究声明：本文所述的对海康威视K41 NVR加固的解包、修改和重新定位仅用于学术研究和教育目的。目标是遵守嵌入式加固结构、启动流程和静态完整性验证方法。此项工作不涉及、支持或鼓励任何其他安全威胁，包括默认授权的访问、攻击、绕过任何安全机制、接入后门或非法使用。未进行任何物理刷写操作操作，也未尝试绕过数字签名验证。测试目标仅限于K41 NVR；未测试DVR设备和其他平台。
固件：hikvision_3.4.87.dav、hikvision_3.5.30.dav、hikvision_3.5.35.dav、hikvision_4.1.50.dav
平台：K41系列网络录像机
工具：hikpack 2.5（带-t k41参数）、mkcramfs、mount -tcramfs-oloop、Python 3.10
环境：WSL2上的Ubuntu 22.04 LTS
我发现：两种不同的硬件结构
K41固件根据版本不同有两种布局：
结构 A — 多文件 (4.1.50)：解压后，将获得单独的文件：uImage、start.sh、sys_app.tar.lzma、gui_res.tar.gz、webs.tar.lzma、TX1_Version.bin 等。start.sh 是纯文本，可以直接编辑。
结构B —cramfs镜像（3.4.87、3.5.30、3.5.35）：解压后，你会得到cramfs.img、new_10.bin和new_20.bin。你需要挂载cramfs镜像才能访问根文件系统中的start.sh文件。
cramfs 提取——挂载与 binwalk 的区别
我首先尝试使用 binwalk，但在 WSL2 下遇到了权限错误。可靠的方法是使用 Linux 手动挂载：
狂欢
mkdir -p /mnt/cramfs_tmp 根文件系统
sudo mount -t cramfs -o loop cramfs.img /mnt/cramfs_tmp
sudo cp -a /mnt/cramfs_tmp/* rootfs/
sudo umount /mnt/cramfs_tmp
修改rootfs/目录下的文件后，使用以下命令重新分配：
狂欢
mkcramfs rootfs new_cramfs.img
主要发现：hikpack会自动处理校验和。
这是我最重要的发现。我对比了重新压缩备份的 new_10.bin 文件，确认 hikpack 在压缩过程中会重新生成所有校验和数据——包括文件 CRC、new_10.bin、new_20.bin 以及文件头 CRC。您需要手动更新任何 CRC 或 MD5 值。
pack 命令很简单：
狂欢
./hikpack -t k41 -p modified_firmware.dav -o firmware_extracted
审批以下人员：
狂欢
./hikpack -t k41 -i modified_firmware.dav
开发类必须保留
.dav 文件头中的 devclass 字段是硬件平台标识符。我从原始固件中自动提取了该字段，并在重新备份过程中保持不变。如果您更改了该字段，设备可能无法识别该固件。
我注射的
我在 start.sh 文件的添加了一个简单的命令：
狂欢
echo "脚本脚本正在运行" > /tmp/custom.log
这不会改变任何现有逻辑——它只是在启动脚本中添加了一行。
结果
固件开发类结构状态
3.4.87 0x44 jamfs 重新分配 + 已验证
3.5.30 0x5Acramfs 重新分配 + 已验证
3.5.35 0x5A jamfs 重新分配 + 已验证
4.1.50 0x3D 多文件重新分配 + 已验证
所有四个修改后的固件文件都通过了 hikpack -i 头部 CRC 校验。我重新解压了每个文件，并确认注入的命令出现在 start.sh 文件的构成中。
结构验证（无物理提示）
我没有将这些文件刷入设备。相反，我构建了一个静态验证方法，我称之为 SIS（结构完整性签名），该方法比较修改反向启动关键元数据：
cramfs：块超级魔法+大小+版本
u图片：magic + 加载地址 + 入口点 + 图片CRC
start.sh：sh -n 语法检查
对于所有四个固件版本，修改前后 SIS 都一个。
对现有主题的回复
@montecrypto 的 hikpack 帖子（2016 年）——您的工具在我的 K41 目标设备上完美运行。您内置的自动校验和重生成功能为我节省了很多 CRC 校验的工作。我不确定最新的固件版本，但在 3.4.87 到 4.1.50 版本上，hikpack 2.5 -t k41 命令可以正常工作。
“如何提取 .dav 固件文件”（2023）——文中提到较新的固件可能会阻止 hikpack 运行，这一点表示。我没有测试过最新版本，所以无法证实或否认。关于cramfs 文件的提取，我想补充一点，在 WSL2 上，使用
mount -o loop命令比binwalk更可靠。“海康威视DVR固件逆向工程”（2017）——你的工作流程仍然适用。我的测试目标是K41 NVR，而不是DVR，因此设备类型不同，但方法仍然具有参考价值。我将结构检测（多文件与cramfs）并重新分配流程自动化到一个Python脚本中，该脚本可以透明地处理两种布局。
“海康威视巩固工具”（2015）——早期的工具奠定了基础。在我的K41设备上，3.x版本使用cramfs文件系统，而4.1.50版本则切换到了多文件布局。hikpack -t k41命令可以处理这两种文件系统。
我尚未审核的内容
为了说清楚，避免错误任何人：
我没有将这些修改过的固件文件实际刷入任何设备。
我还没有测试最新的海康威视固件是否会阻止hikpack。
我没有尝试绕过数字签名验证。
修改后我尚未验证系统功能（硬盘、网络、Web用户界面等）。
仅在K41 NVR上进行了测试——未在DVR、K51、R0、R1或其他平台上进行测试。
希望这对某些人有用。如果您在其他 K41 版本或其他平台上尝试过类似的批发，我很想听听您的结果。
再次声明：本实验中的解包、修改和重新分配操作仅用于纯粹的学术研究，不涉及任何其他安全威胁或非法目的。它们不用于未经授权的访问、攻击、绕过安全机制、入口后门或任何非法用途。
干杯
Last edited:
