Skip to content

Latest commit

 

History

History
190 lines (133 loc) · 6.15 KB

README.md

File metadata and controls

190 lines (133 loc) · 6.15 KB
Raw

meson-tools

meson-tools is a collection of tools for use with the Amlogic Meson family of ARM based SoCs.

Name-wise it was inspired by sunxi-tools.

amlbootsig

Usage:

 amlbootsig boot_new.bin u-boot.img

This tool is supposed to provide equivalent output to:

 aml_encrypt_gxb --bootsig --input boot_new.bin --output u-boot.img

with the tool version distributed by Hardkernel for their Odroid-C2 board (S905 / Meson GXBaby).

How to compare output

 hexdump -C a/u-boot.img > a/u-boot.img.hex
 hexdump -C b/u-boot.img > b/u-boot.img.hex
 diff -u a/u-boot.img.hex b/u-boot.img.hex | less

This should result in a diff with only the following differences:

  • First 16 bytes will be random in original.
  • The header for each FIP TOC entry will contain 4 bytes of random data.
  • Due to FIP TOC entry headers differing, the SHA256 hash in the header will differ as well.

For testing identity of output files, modify the code to use the random bytes from the file you are testing against.

Known limitations

  • Correctness: Since amlbootsig was designed to binary-match previously created output files, it may still have some numbers hard-coded or may do calculations in a way that happened to match tested input/output but may break for other input files. Please report such cases as GitHub issues.
  • Endianness: Only Little Endian byte order has been considered. Running it on Big Endian hosts may misinterpret file input and/or result in wrong output and/or other misbehavior. The solution would be byte swaps, but those depend on the field width, which is guessed only and thus may change as the format is being better understood.
  • Security: The tool was not designed to defend against invalid or evil file input.

unamlbootsig

Usage:

unamlbootsig u-boot.img boot_new.bin

This tool is supposed to do the reverse of amlbootsig, i.e. drop the boot signature.

The output may differ from the original aml_encrypt_gxb --bootsig/amlbootsig input from 0xb000 to 0xbfff as well as in FIP TOC entry size 16-byte alignment.

Known limitations

See amlbootsig.

amlbootsig-gxl

Usage:

 amlbootsig-gxl bl2_new.bin bl2_new.bin.sig

This tool is supposed to provide equivalent output to:

 aml_encrypt_gxl --bl2sig --input bl2_new.bin --output bl2_new.bin.sig

with the tool version distributed by Amlogic in their 2018-07-06 Buildroot tarball.

How to compare output

 hexdump -C a/bl2_new.bin.sig > a/bl2_new.bin.sig.hex
 hexdump -C b/bl2_new.bin.sig > b/bl2_new.bin.sig.hex
 diff -u a/bl2_new.bin.sig.hex b/bl2_new.bin.sig.hex | less

This should result in a diff with only the following differences:

  • First 16 bytes will be random in original.
  • Due to padding contents differing, the SHA256 hash in the header will differ as well.

For testing identity of output files, modify the code to use the random bytes from the file you are testing against.

Known limitations

Specifically tailored to BL2.

Otherwise see amlbootsig.

amlbootenc-gxl

Usage:

 amlbootenc-gxl u-boot.bin u-boot.bin.enc

This tool is supposed to provide equivalent output to:

 aml_encrypt_gxl --bl3enc --input u-boot.bin --output u-boot.bin.enc

with the tool versions distributed by Amlogic in their 2018-07-06 Buildroot tarball.

How to compare output

 hexdump -C a/u-boot.bin.enc > a/u-boot.bin.enc.hex
 hexdump -C b/u-boot.bin.enc > b/u-boot.bin.enc.hex
 diff -u a/u-boot.bin.enc.hex b/u-boot.bin.enc.hex | less

This should result in a diff with the following differences:

  • Symmetric AES CBC encryption key (32 bytes) and initialization vector (16 bytes) are random.
  • Therefore the whole encrypted contents will differ.
  • Due to differing encryption the SHA256 hash (32 bytes) in the header will differ as well.

For testing identity of output files, modify the code to use the key/IV bytes from the file you are testing against.

Known limitations

Specifically tailored to BL3x.

Otherwise see amlbootsig.

amlbootimg-gxl

Usage:

 fiptool --align 0x4000 --scp-fw bl30_new.bin.enc --soc-fw bl31.img.enc --nt-fw u-boot.bin.enc fip.bin
 amlbootenc-gxl fip.bin fip.bin.enc
 dd if=fip.bin.enc of=fip.enc.bin bs=512 count=31
 amlbootimg-gxl bl2_new.bin.sig fip.enc.bin bl30_new.bin.enc bl31.img.enc u-boot.bin.enc u-boot.img

This tool is supposed to provide equivalent output to:

 aml_encrypt_gxl --bootmk --bl2 bl2_new.bin.sig --bl30 bl30_new.bin.enc --bl31 bl31.img.enc --bl33 u-boot.bin.enc --output u-boot.img
 dd if=u-boot.img.sd.bin of=/dev/XXX bs=512 skip=1 seek=1

with the tool versions distributed by Amlogic in their 2018-07-06 Buildroot tarball.

To deploy the file to SD card:

 dd if=u-boot.img of=/dev/XXX bs=512 seek=1

How to compare output

 hexdump -C a/u-boot.img > a/u-boot.img.hex
 hexdump -C b/u-boot.img > b/u-boot.img.hex
 diff -u a/u-boot.img.hex b/u-boot.img.hex | less

This should result in a diff with the following differences:

  • Symmetric AES CBC encryption key (32 bytes) and initialization vector (16 bytes) are random.
  • Therefore the whole encrypted contents will differ.
  • Due to differing encryption the SHA256 hash (32 bytes) in the header will differ as well.
  • Random padding bytes between the FIP images.

Known limitations

  • Hardcodes file offsets matching the current binary blobs. May break with upstream BL31 or newer/older blobs.

Otherwise see amlbootsig.

amlinfo

Usage:

 amlinfo u-boot.img

This tool dumps info about an existing image file.

It supports the following inputs:

  • amlbootsig output
  • aml_encrypt_gxb --bootsig output, except when using --amluserkey or --efuse
  • dd if=u-boot.img bs=512 skip=96 output for either of them (FIP TOC with headered entries)
  • dd if=u-boot.img bs=1 skip=16 output, i.e. raw @AML header, of at least 64 bytes
  • amlbootsig-gxl output
  • aml_encrypt_gxl --bl2sig output

Known limitations

  • Correctness: Since there seems to be no public documentation for the @AML headers, any field names printed are guesses and may need to be revised once their meaning becomes clearer.
  • Endianness: Only Little Endian byte order has been considered, see above.
  • Security: See above.