How to read the application version from a DFU zip file in iOS/Android

[mrono]

Hello.

We have a working DFU system using Nordic's Secure Buttonless DFU bootloader. The bootloader correctly checks if the incoming DFU package has the correct 'init packet' data. It checks that the hardware version matches, the softdevice requirement matches, and that the application version is not lower than the currently installed one.

But I don't want the app to prompt the user to do DFU, and have the bootloader tell him that one of the above conditions is not met. So how can the iOS/Android app read the version information from the supplied DFU zip file? On a PC I can use nrfutil to display said version info, but what is the equivalent on iOS/Andriod?

Added 8.11.:

It seems the manifest file in the DFU zip has had this information earlier (see this and this question), but apparently it has been removed. Can I still generate DFU packages with this information? This would be the perfect solution in my opinion.

[Edvin]

Hello,

The manifest.json file doesn't tell you this information anymore. However, you can retrieve all the information from the .dat file in the DFU image.

Below is a comparison of two dat files created with the same .hex file, but different settings. The one to the left is generated with:
nrfutil pkg generate --application buttonless.hex --application-version 1 --hw-version 52 --sd-req 0xAF --key-file keys\private.key test_dfu_pkg.zip

And the one to the right is generated with:

nrfutil pkg generate --application buttonless.hex --application-version 3 --hw-version 51 --sd-req 0xAE --key-file keys\private.key test_dfu_pkg.zip

If you want to compare in a text editor, the first file says:

12 84 01 0a 3e 08 01 12 3a 08 01 10 34 1a 02 af
01 20 00 28 00 30 00 38 d4 8e 03 42 24 08 03 12
20 33 1d 48 ba 51 8b 77 fa ee ce 12 f4 35 5f 5d
63 5f 84 b6 2f 56 cf ca f1 a9 5a 3c 53 91 4e bb
96 48 00 10 00 1a 40 3b aa 30 6e ed d0 9d 9c 73
d6 17 ba 55 6e 35 e0 3e 8e d8 eb 70 a9 17 f9 ff
4f 30 c8 b8 ea e6 8c 04 31 ee 37 54 a0 95 db 85
df a0 05 c1 dd 30 7d 88 01 b9 7b dc 53 b5 a9 ed
73 77 d2 f6 1a 98 f1

And the second one says:

12 84 01 0a 3e 08 01 12 3a 08 03 10 35 1a 02 ae
01 20 00 28 00 30 00 38 d4 8e 03 42 24 08 03 12
20 33 1d 48 ba 51 8b 77 fa ee ce 12 f4 35 5f 5d
63 5f 84 b6 2f 56 cf ca f1 a9 5a 3c 53 91 4e bb
96 48 00 10 00 1a 40 7b e8 42 67 ea 0b bf 33 11
c7 88 36 1a 3b 3f 41 a6 f9 9e 4a 3c a2 bf a8 af
50 6f a8 e7 fe fd 97 a5 5c 7b 59 f6 34 25 f5 ea
f5 b2 a9 f9 0e 19 b9 da 0c 95 0f ed 0f eb 47 a2
b7 69 df 5d 6d 49 86

The two settings that I changed:

--application-version 1 vs --application-version 3,

--hw-version 52 vs --hw-version 51,

--sd-req 0xAF vs --sd-req 0xAE

I know that --hw-version 51 and --sd-req 0xAE doesn't make sense, but I just wanted to check where these values are stored.

As you can see, the 10th byte changes from 01 to 03, so this is the application version. 

The 12th byte changes from 34 to 33, so this is the --hw-version (0x34 = 52, 0x33 = 51)

The 15th byte changes from af to ae, so this is the --sd-req.

You can do these experiments to check where the different fields are stored. 

Alternatively, you can look at the source code for nrfutil, which you can find here.

As mentioned in one of the links you provided, you can use nrfutil pkg display <dfu_img path> to display all the information from a computer. See if you can find out where and how in the nrfutil source code this is done.

Best regards,

Edvin

[mrono]

Well yes, I knew that parsing the binary dat file was a possibility. But is that really the way this is expected to be done? What I'm trying to do is determine if the software in a DFU package is newer than the one currently on the device. Surely this is a common scenario?

If there really is no 'supported' way to do this then easier for me is to add another text or json file that has this information. Since I am the one generating the DFU package, I do know the values. It just seems redundant and error-prone to add the same information manually, especially since the tool (nrfutil) seemingly has previously done this.

[mrono]

Thinking about where to add the version numbers. I came across this question that says it is safe to add entries to the manifest.json file. This is probably the way I'm going to do this.

[Edvin]

Hello,

Yes. That seems like a viable solution. I really don't think that the json file is used for much anymore, now that the secure bootloader handles the version checks and so on. 

I am not sure whether nRF Connect for Android and iOS actually uses the json file when performing a DFU. It should be easy to find out, by trying to remove it and test. If it doesn't, then you can modify it however you want. 

If it turns out it is used, you can of course still modify it, since you create the mobile app, and you read the json file. As for the bootloader itself, it only uses the .bin and .dat files.

Best regards,

Edvin

[mrono]

nRF Connect for PC at least reads the json file, as its contents are displayed during the DFU process. The update seems to be working fine with a modified file as well.

For now I am creating another json file for the version info, mainly because creating a new file was easier to script than unzip-modify-rezip.