Signature did not verify

[huanglei3]

you did it?
i find codeverf ,codecheck and syscheck binary,but when i patch those binary ,i still got an erro :Signature did not verify...
and then i use qemu , it tells me “codeverf :one or more .... “ because i dont give rootfs.img .so i think the kernel should have somrthing code verify rootfs.do you have a solution?help me,thanks

[amnemonic]

Hello @huanglei3, unfortunately I didn't found the solution for issue yet, however this is how I think it works:
Somewhere in init ram disk or even in kernel itself there are hardcoded verification routines for following files

• /bin/codeverf
• /etc/codesign-public.pem

You can reproduce error Signature did not verify in following way

• extract file M400_M500.hda3 from firmware upgrade package (firebox_M270_M370_M470_M570_M670_*.zip)
• mount image in directory of choice (./hda3/ in my example) sudo mount -o loop ./M400_M500.hda3 ./hda3/
• run: sudo chroot ./hda3/ /bin/codeverf /etc/codesign-public.pem /etc/code-signed /etc/code-signature

Normally you should get no output in stdout and exit code=0, but if you modify any file listed in code-sha1sums.txt then you will get error Signature did not verify and exit code=1

So, the conclusions are as follows

• to replace /etc/lickey.pem we need to update checksum for that file in code-sha1sums.txt
• then update /etc/code-signature using our own key
• therefore we need to replace /etc/codesign-public.pem with our own
• to replace that key we need to convince kernel that this is legit key

It would be cool to follow that path and "fix" newer versions of firmware. Maybe above give you some ideas?

[huanglei3]

你好@huanglei3不幸的是，我还没有找到问题的解决方案，但我认为它的工作原理是这样的： 在 init ram 磁盘的某个地方，甚至在内核本身中，都有针对以下文件的硬编码验证例程

• /bin/codeverf
• /etc/codesign-公共.pem

Signature did not verify您可以按照以下方式重现错误

• 从固件升级包中提取文件M400_M500.hda3（firebox_M270_M370_M470_M570_M670_*.zip）
• 在选择的目录中安装映像（在我的示例中为 ./hda3/）sudo mount -o loop ./M400_M500.hda3 ./hda3/
• 跑步：sudo chroot ./hda3/ /bin/codeverf /etc/codesign-public.pem /etc/code-signed /etc/code-signature

正常情况下，您不应该在 stdout 中获得任何输出并且退出代码=0，但是如果您修改列出的任何文件code-sha1sums.txt，那么您将收到错误Signature did not verify并且退出代码=1

因此，结论如下

• 要替换，/etc/lickey.pem我们需要更新该文件的校验和code-sha1sums.txt
• 然后/etc/code-signature使用我们自己的密钥进行更新
• 因此我们需要/etc/codesign-public.pem用我们自己的
• 要替换该密钥，我们需要让内核相信这是合法的密钥

按照这个方法“修复”新版本的固件会很酷。也许上面的内容能给你一些想法？

yes,i try to find verification in kernel,but failed.and you give me another idea,thanks ,i try it

[hackyannick]

The routine must be in the kernel, I had already experimented with it myself. If you use the kernel of 10.7.2 U1 to start the 10.12 image, this works in virtual machines. Unfortunately, this did not work on ARM-based devices like my T40.

[hackyannick]

The Reason why there is a Check Routine has to be like with the Cyclops Blink CVE. Before 12.7.2 U2 there was not an Checksum Check.

[apssian]

The routine must be in the kernel, I had already experimented with it myself. If you use the kernel of 10.7.2 U1 to start the 10.12 image, this works in virtual machines. Unfortunately, this did not work on ARM-based devices like my T40.

The last working version is 12.7.2 U1. Is is possible to use the kernel of this version and boot the latest Watchguard OS?

[hackyannick]

Yes i testet this allready, if you are on x86 and changes the Kernels the newest Release is booting successfully.

[apssian]

Yes i testet this allready, if you are on x86 and changes the Kernels the newest Release is booting successfully.

Which is the kernel file?

[hackyannick]

These Files on a seperate Partition. I will look the Files later. Am 25.05.2025 um 16:42 schrieb apssian ***@***.***>:apssian left a comment (amnemonic/wg_firebox#3) Yes i testet this allready, if you are on x86 and changes the Kernels the newest Release is booting successfully. Which is the kernel file? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[apssian]

Is it the bzImage file?

[apssian]

Did you test it for FireboxV?

[willmav5000]

It looks like the signature check is handled in the kernel. A cpio archive is embedded in the kernel, which loads at boot and runs the checks before the rest of the system. You could patch the init or codeverf binaries inside, then rebuild the kernel, which should allow the checks to be bypassed. I have not tested this myself, but it should work.

[willmav5000]

Update:
I have now tested this method on my T55 and patching the kernel does work. By using a modified codeverf that always passes the verification checks, you can alter the filesystem, replace the lickey.pem, and generate your own licences once more.

It looks like the signature check is handled in the kernel. A cpio archive is embedded in the kernel, which loads at boot and runs the checks before the rest of the system. You could patch the init or codeverf binaries inside, then rebuild the kernel, which should allow the checks to be bypassed. I have not tested this myself, but it should work.

[hackyannick]

Can you send me the Code you used to Patch it. I would it Test on the T40-W.

[dustynet]

Hi,
I would also like to test this on a t30-w if that helps.
I would also be curious about learning more about this, did you use any reference materials during your research, or was it purely reverse engineering, something I think would be outside my skill set ☺️

[willmav5000]

It was mostly a manual process of decompressing, extracting, patching, and then rebuilding, but I will try to build a script if I get some time over the next few days.

I used binwalk to decompress the bzImage and pull out the parts that were needed.

The changes made to the codeverf binary were as follows, in case anyone wants to try it themselves:

Original values:
ff 25 82 2f 00 00 68 0a 00 00 00 e9 40 ff ff ff
ff 25 72 2f 00 00 68 0c 00 00 00 e9 20 ff ff ff
ff 25 02 2f 00 00 68 1a 00 00 00 e9 40 fe ff ff

Patched with:
B8 01 00 00 00 C3 90 90 90 90 90 90 90 90 90 90