Image Verification Failed
Shawana Kallhoff
My 128gb microsd card always shows that the verification failed after flashing the jetson nano dev kit ( -nano-sd-card-image). I am using balenaetcher 1.5.109 on Windows 10, using Samsung EVO Plus UHS3 128gb.
I have tried on all my 4 128gb cards, and all of them have the same error. When I turn on the Nano, it only shows the Nvidia logo, and stays there. Definitely not a power issue as I am using a 5V/4A power, and the green light on my nano is a stable solid green.
You can see that signature verification fails with the artifact-verify-key.pem which is present on the device but looking into both the public.key file and artifact-verify-key.pem file they are exactly the same (besides file formats). And from what I understand, the artifact-verify-key.pem is all that is used to verify firmware images on the device.
These files are supposed to copies of each other, in other words identical. If the artifact-verify-key.pem is a different format, then a mistake has been made along the way. You should be able to simply copy public.key to artifact-verify-key.pem.
The flashing portion completes with no errors. Validation completes - all the way, 100% - with no errors, but Etcher says that validation failed. The image has a small FAT32 boot partition and a larger EXT4 partition. Per one of your previous forum posts, I do see where Windows has created a System Volume Information folder in the FAT32 partition - is this why validation is failing? Is there a way to keep Windows from doing this, if so?
The resulting image on the USB card fails to boot on the Raspberry PI. Is Etcher writing something to the drive after validation, and the lack of this is causing problems? I would have thought that everything would have been written during the flashing portion and validation was just checking to see if everything had been written successfully.
The verification failing sometimes is just a misleading message towards the user. (The verification is OK just the message display encounters some error while displaying the message and says verification failed instead of displaying the message failed)
But this case the device should boot.
To have a closer look you can open the devtools by pressing Ctrl + Alt + i , and examine the logs on the console tab.
If you can copy them and attach it here we could have a look too.
The Russian model firmware contains a telnet server that can be enabled. I used it to dump all of the /dev/mtdX devices onto a USB flash drive. I also checked the flash layout and it matched the layout described on the DIR-882 A1 page:
I gambled and tried using this tool to install the OpenWRT factory image to "Linux" (mtd6). My new brick now only boots into the dlink recovery GUI. The recovery GUI is not the same as the US recovery GUI, and refuses to take any images with the error message "ERROR - the image you uploaded failed to pass verification.", regardless of if it is from the official site ( -882/Firmware/), the US D-Link site, or any openwrt firmware.
I have contacted D-Link for the source code of their bootloader, as well as firmware images. I am wondering if I can reverse engineering the bootloader verification to understand how it determines whether the images are valid to unbrick my router. The bootloader image (mtd1) contains this string and many more. Is there any guide available as to how to go about starting to disassemble it? binwalk indicates it is based on U-Boot 1.1.3, and it has strings that indicate that it contains the uIP networking TCP/IP stack.
I know I also can solder a serial cable onto the hardware pins to get the router into TFTP recovery mode, but I have more MIPS experience than soldering experience and I'd rather avoid definitively voiding the warranty (if I haven't already yet). I also know this is probably what I'll end up having to do.
the Russian version has a different boot loader header size & partition layout
you will find there is a extra config 64K partition on the A1 models after the factory 64K partition
they are shown on the A1 openwrt versions as a 128K Factory partition
if you wish make your own image I can give you a start
I have installed the Russian boot loader & firmware on my A1 model
but as I don't have a real R1 Model I can't really test as an R1
I ran binwalk on the binary dlink gave me, and noticed there were an extra 56 bytes after the end of the squashfs partition, with two obvious magic numbers - 0x00c0ffee. I also noticed a similar 51 bytes after the end of the squashfs image on the mtd dump that I took with the same two magic numbers. When I truncated my dump that the second magic coffee, my image loaded just fine in the recovery GUI.
It seems that the first part of the trailing bytes seems to be some sort of variable width ascii printable information (perhaps versioning) following by 16 bytes of data and then 0x00c0ffee. The second part of the tail seems to be 16 bytes of data followed by 0x00c0ffee.
I think these byte are just the end of the d-link firmware files
the only firmware magic is the start 27051956
the R1 used the same basic header is as others
the A1 had a custom bigger header with an extra 96 bytes
I loaded the factory image with the fw_updater binary on the router, and OpenWRT booted. By any chance might you be able to share the build configuration exactly so I can make a 19.4 build for my router?
I'm interested in getting a copy of the U-Boot-env info for that unit
if i load the Russian firmware it has an error about WPS button location
I think it may be in there
but yes remove any info you think is personal
mine has the following by default
I don't have a serial console to the router. I only have the image of the boot loader partition. Perhaps I can e-mail it or private message it in base64 (it's less than 64 kB compressed with xz). Is there a way I can get the information you're asking for from the OpenWRT logs?
I realize that in other versions of the router that no other checks are done for firmware image validation. But these checks definitely are done on the bootloader that came with my router. Changing the bytes near the 0x00c0ffee tail causes it to reject the firmware image.
This is Lucky's image where I only changed the header to match the factory one you use (with a correct CRC). If you want to give it a go and try and load it from the recovery. I did not touch anything else by the way.
I am not certain the signature is at the end, but it certainly looks this way. None of the US firmware images that I checked have any trailing bytes after the squash fs image, but the Russian ones do:
Notice that the extra bytes end with a magic hex character 0x00c0ffee, and putting the bootloader image into Ghidra produces this magic number in code that is connected to the HTTP server. This is enough for me to believe that there is some sort of signature at the end.
As I managed to flash my device, I don't see any urgency in reverse engineering how exactly it is calculated, but I may try to do this in the future, as it makes recovery flashing significantly easier. I do not have significant experience reverse engineering low level code so if somebody with more experience would like to guide me, I might have more luck.
Thank you once again for your work on this - this build works perfectly. I even built in again on my own laptop for got measure and it works great! Please let me know if I can help get this into the mainline.
Hi,
I am hoping that the way to the solution is simple (but I have currently no clue) because the issue is simple: If I want to upload an image (jpg, just 300kB), I get an error (without further details). I tried on different pages. Xwiki version is 13.1.
How can I locate the reason of the issue?
Hi,
in the log I see the following warning:
WARN o.x.c.i.DefaultCSRFToken - CSRFToken: Secret token verification failed, token: "null", stored token: ...
I tried to find some hints in the forum and old tickets but did not find a solution.
I am using xwiki with a proxy. I tried already to access directly but the issue was still there.
OK very strange then. When you upload an attachment through the UI a special token is sent along with the attachment content to avoid CSRF attacks (where something would use you to upload stuff without you noticing). In seems in your case the token is not sent or not received but hard to tell why without a way to reproduce.
Based on the detailed attempts of @heinoh I observed the network tab of the inspector for the wysiwyg editor: The xredirect and form_token parameters are passed at the URL. This, probably, allows an upload form recipient to check the validity of the the CSRF token before starting to swallow the attachment which is, otherwise, as part of the big stream of attachments.
However on every other run the command fails with a "Write verify failed". It works on the first time but running it again will trigger the error (and the firmware is not run even after a reset). After getting the error, running the command again works fine (and I can see the chip booting our firmware normally).
nrfjprog -f nrf52 --program firmware.hex --chiperase --verify --reset --log
Parsing image file.
Verifying programming.
ERROR: [ nRF52] - Data does not match in address range [0x00001000-0x00018fec] (Flash)
ERROR: [ nRF52] - Expected byte value 0x00 but read 0xff at address 0x000122b8.
ERROR: [ nRF52] - Flash verification failed.
ERROR: [ nRF52] - Failed while verifying file firmware.hex.
ERROR: Write verify failed.