Files with more than 11 partitions/sections

[armijnhemel]

There are firmware files where there are more than 11 partitions/sections. For example I am currently looking at IPC_528B174MP.1388_22100601.Reolink-Duo-WiFi.GC4653.4MP.WIFI1021.REOLINK.pak which has 13 partitions.

To find out how many partitions are needed you need to divide the offset found in the entry for the first section by (64 + 76)

[armijnhemel]

Also see: kaitai-io/kaitai_struct_formats#667

[hn]

Nice, I didn't know Kaitai Struct yet.

I pushed c5f043b to at least make the number of sections/partitions a bit more configurable. I need to find some time to implement it cleanly.

And I think one has to subtract 12 before dividing by 64 + 76 (doesn't change anything for ints).

[armijnhemel]

Nice, I didn't know Kaitai Struct yet.

I pushed c5f043b to at least make the number of sections/partitions a bit more configurable. I need to find some time to implement it cleanly.

And I think one has to subtract 12 before dividing by 64 + 76 (doesn't change anything for ints).

Ah yes, you are absolutely correct, the 12 bytes for the header should be subtracted.

[hn]

Off-topic: zennio-firmware and vallox-ventillation might be candidates for the Kaitai db ... in any case they are more or less based on the same perl-mishmash as the Reolink-unpacker :)

[AT0myks]

To find out how many partitions are needed you need to divide the offset found in the entry for the first section by (64 + 76)

This is true for all firmwares except the ones for the RLN36, their only device with 64-bit hardware as far as I know. They have 4 extra NULL bytes between the end of the last MTD and the start of the first section's content. They also happen to have different header and section sizes. You can get more details here.

[hn]

Closing this because pakler is more advanced and there is no point in putting more work into this tool.

[armijnhemel]

To find out how many partitions are needed you need to divide the offset found in the entry for the first section by (64 + 76)

This is true for all firmwares except the ones for the RLN36, their only device with 64-bit hardware as far as I know. They have 4 extra NULL bytes between the end of the last MTD and the start of the first section's content. They also happen to have different header and section sizes. You can get more details here.

Excellent. I have adapted the kaitai struct specification so these files can also be parsed.

[AT0myks]

@hn Thank you for adding a link to the archive and for your repo. It got me interested in digging into the firmwares to see what's inside. It's a great resource and I plan on using it in the future, maybe to make custom firmwares like others here have done.

@armijnhemel I see you're a former member of the gpl-violations.org core team, is this related to your interest in Reolink? Because it seems to me that they might not be complying with the GPL.

[armijnhemel]

@armijnhemel I see you're a former member of the gpl-violations.org core team, is this related to your interest in Reolink? Because it seems to me that they might not be complying with the GPL.

No, I am creating a generic firmware unpacker and for that I wanted to support this particular firmware format. See https://github.com/armijnhemel/binaryanalysis-ng/