The ZyXEL NR7101 prepend an additional header to U-Boot images. This
header use the TRX magic 0x30524448 (HDR0), but is incompatible with
TRX images.
This code is reverse-engineered based on matching 32 bit numbers
found in the header with lengths and different checksum
calculations of the vendor images found on the device. The result
was matched against the validation output produced by the
bootloader to name the associated header fields.
Example bootloader validation output:
Zyxel TRX Image 1 --> Found! Header Checksum OK
============ZyXEL header information==================
chipId : MT7621A
boardId : NR7101
modelId : 07 01 00 01
kernel_len : (14177560)
kernelChksum : (0x8DD31F69)
swVersionInt : 1.00(ABUV.0)D1
swVersionExt : 1.00(ABUV.0)D1
Zyxel TRX Image 2 --> Found! Header Checksum OK
============ZyXEL header information==================
chipId : MT7621A
boardId : NR7101
modelId : 07 01 00 01
kernel_len : (14176660)
kernelChksum : (0x951A7637)
swVersionInt : 1.00(ABUV.0)D0
swVersionExt : 1.00(ABUV.0)D0
=================================================
Check image validation:
Image1 Header Magic Number --> OK
Image2 Header Magic Number --> OK
Image1 Header Checksum --> OK
Image2 Header Checksum --> OK
Image1 Data Checksum --> OK
Image2 Data Checksum --> OK
Image1 Stable Flag --> Stable
Image1 Try Counter --> 0
Image1: OK
Image2: OK
The coverage and algorithm for the kernelChksum field is unknown.
This field is not validated by the bootloader or the OEM firmware
upgrade tool. It is therefore set to a static value for now.
The swVersion fields contain free form string values. The OEM firmware
use ZyXEL structured version numbers as shown above. The strings are
not interpreted or validated on boot, so they can be repurposed for
anything we want the bootloader to display to the user. But the OEM
web GUI fails to flash images with freeform strings.
The purpose of the other strings in the header is not known. The
values appear to be static. We assume they are fixed for now, until
we have other examples. One of these strings is the platform name,
which is taken as an input parameter for support other members of
the device family.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: Tianling Shen <cnsztl@immortalwrt.org>
bcm4908img is a tool managing BCM4908 platform images. It's used for
creating them as well as checking, modifying and extracting data from.
It's required by both: host (for building firmware images) and target
(for sysupgrade purposes). Make it a host/target package.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Asus looks for an extra data at the end of BCM4908 image, right before
the BCM4908 tail. It needs to be properly filled to make Asus accept
firmware image.
This tool constructs such a tail, writes it and updates CRC32 in BCM4908
tail accordingly.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Flashing image with BCM4908 CFE bootloader requires specific firmware
format. It needs 20 extra bytes with magic numbers and CRC32 appended.
This tools allows appending such a tail to the specified image and also
verifying CRC32 of existing BCM4908 image.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
BCM4908 CFE bootloader requires kernel to be prepended with a custom
header. This simple tool implements support for such headers.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Some Russian d-link routers require that their firmware be signed with a
salted md5 checksum followed by the bytes 0x00 0xc0 0xff 0xee. This tool
signs factory images the OEM's firmware accepts them.
Signed-off-by: Andrew Pikler <andrew.pikler@gmail.com>
Because some padding values in the TP-Link safeloader image generation
were hardcoded, different values were sometimes used throughout a
factory image. TP-Link's upgrade images use the same value everywhere,
so let's do the same here.
Although a lot of TP-Link's safeloader images have padded partition
payloads, images for the EAP-series of AC devices don't. This padding is
therefore also made optional.
By replacing the type of the padding value byte with a wider datatype,
new values outside of the previously valid range become available. Use
these new values to denote that padding should not be performed.
Because char might be signed, also replace the char literals by a
numeric literal. Otherwise '\xff' might be sign extended to 0xffff.
This results in factory images differing by 1 byte for:
* C2600
* ARCHER-C5-V2
* ARCHERC9
* TLWA850REV2
* TLWA855REV1
* TL-WPA8630P-V2-EU
* TL-WPA8630P-V2-INT
* TL-WPA8630P-V2.1-EU
* TLWR1043NDV4
* TL-WR902AC-V1
* TLWR942NV1
* RE200-V2
* RE200-V3
* RE220-V2
* RE305-V1
* RE350-V1
* RE350K-V1
* RE355
* RE450
* RE450-V2
* RE450-V3
* RE500-V1
* RE650-V1
The following factory images no longer have padding, shrinking the
factory images by a few bytes for:
* EAP225-OUTDOOR-V1
* EAP225-V3
* EAP225-WALL-V2
* EAP245-V1
* EAP245-V3
Signed-off-by: Sander Vanheule <sander@svanheule.net>
TP-Link safeloader firmware images contain a number of (small)
partitions with information about the device. These consist of:
* The data length as a 32-bit integer
* A 32-bit zero padding
* The partition data, with its length set in the first field
The OpenWrt factory image partitions that follow this structure are
soft-version, support-list, and extra-para. Refactor the code to put all
common logic into one allocation call, and let the rest of the data be
filled in by the original functions.
Due to the extra-para changes, this patch results in factory images that
change by 2 bytes (not counting the checksum) for three devices:
* ARCHER-A7-V5
* ARCHER-C7-V4
* ARCHER-C7-V5
These were the devices where the extra-para blob didn't match the common
format. The hardcoded data also didn't correspond to TP-Link's (recent)
upgrade images, which actually matches the meta-partition format.
A padding byte is also added to the extra-para partition for EAP245-V3.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
this patch fixes/improves follows:
- PATTERN_LEN is defined as a macro but unused
- redundant logic in count-up for "ptn"
Signed-off-by: INAGAKI Hiroshi <musashino.open@gmail.com>
By using localtime() to determine the timestamp that goes into factory
images, the resulting image depends on the timezone of the build system.
Use gmtime() instead, which results in more reproducible images.
Signed-off-by: Sander Vanheule <sander@svanheule.net>
There is no versioning information in the firmware-utils code nor the
Makefile. Consider it as first release by adding PKG_RELEASE.
Motivation is the tracking of changes in the buildsystem, which requires
versioning of packages.
Also update copyright.
Signed-off-by: Paul Spooren <mail@aparcar.org>
