This fixes a couple of issues when cross-compiling for windows:
- lib builds (i.e. mks5lboot) were overriding the cross CC/CXX with the
native CC, producing incompatible binaries.
- Qt made the accessibility plugin part of the core library, so we no
longer need to import it.
Change-Id: I9d884aee62dfa51d3624a3fa9b99c23b3b375f20
The current implementation was custom and super slow. Since we use Crypto++
anyway, we might as well get use a good implementation.
Change-Id: I761ad7401653471e54000e1c2bc3d9882378112f
Instead of having our own copy of the AES code, use a good library to do that.
Crypto++ is well-maintained, supports a lot of ciphers, works on many OSes, and
is optimized for many architectures.
Change-Id: I7d7d24b47993206d7338c5f9bac8bbdd3915a667
It was a mess, a mix of crypto_* and cbc_mac calls. I made everything call crypto
functions, and also separate key setup from cryptographic operations, this will
be useful to speed up the code in the upcoming commits. Drop support for "usbotp"
key, since the crypto code for that was never mainlined and we can always get the
keys from a device as long as we have code execution (using the DCP debug registers).
Change-Id: I7aa24d12207ffb744225d1b9cc7cb1dc7281dd22
The overriding of the IV and real key should be the exception, there is no
need to manually set them to false.
Change-Id: Id66754f20a79aa5c1a991839345d1242e0aa587d
The old code had some annoying way of dealing with padding by adding explicit
instructions to the stream, which is 1) ugly 2) not in par with freescale
tools. The trick, which this new version implements, is to put the useful length
of the section in the section header, and the actual (with padding) length in
the boot tag. This way the tools can just ignore padding instruction by
reading the section header, and the bootloader can still load the image because
it uses the boot tags.
Also correctly handle the case where the first section does not start right
after the header (there is a bug in freescale tools for this case by the way).
There is an ambiguity in the way the padding instructions should be encrypted:
the bootloader should logically treat them as regular instruction of the section
stream, but it appears the freescale tools do not generate them as part of the
stream and instead encrypt them like boot tags, which is stupid because there
is no way the bootloader could decrypt them, and anyway we don't care because
the bootloader doesn't decrypt them at all.
Change-Id: Iabdc1d1f9f82d374779bf03efb75c2c3998f5b5d
Although this does bug is never triggered because we never decrypt and use the
resulting CBC-MAC, it's a major overlook.
Change-Id: I3c5d318e6428d528483bf888ea284e9ded3889f0
cppcheck reported:
[rockbox/utils/imxtools/sbtools/sb1.c:440]: (warning) Comparison of a boolean expression with an integer other than 0 or 1.
Thanks to Thomas Jarosch
Change-Id: I0078232706d4014a1f2acea310a7a0d0edf7788b
A older commit removed this ability but it tends to be a problem since the HID
driver can prevent probing of transfer size which then needs to be entered
by hand on the command line.
Change-Id: Ie5a556ffdcc2adec0e1c984810983e19136b6473
Some older versions of the ROM (TA3 for example), use a 64 byte report size
instead of 1024, so hardcoding 1024 is just a bad idea.
Change-Id: I720c4465cfe2f519bffa307175614bba58766dce
Now always generate a "make.db" file which aims at being the exact
representation of the file, ie running sbtoelf and elftosb using
the generated command file should produce the exact same file
(except for the random paddings). We still miss the support
for some option parsing to achieve that though.
Change-Id: Ib7d6b241f7855fd35225df8ab8e0711f69d9ee5a
Remove the hackish elf_translate_addresses which should not have
existed in the first place, on write always compute the physical
address of a section using elf_translate_virtual_address which
makes it possible to specify any virtual to physical mapping and
fail nicely if there is none.
Change-Id: I4f436945e90280a6fd9430de6c642dbeb8e23d40
The tool can now load sb1 and sb files to devices. Detection has
been improved and the tool can infer the packet size for the HID
description as well. The command line interface has been vastly
improved too, this breaks the old one.
Change-Id: I01a0ff8f8a007514aa81c56f114c0f0a86e3303c
After some reverse engineering, it appears that the keys of the
sb1 format are very weak: the 128 bytes are generated from the
laserfuse words 4,5 and 6 but in a weird manner: 4 and 5 are
simply ORed and 6 is only half used (somehow), making it "only" a
48 bit word to find.
Change-Id: I40702e19d0924ef51c01894efce3cb65bd664456
