<bauen1>
then i kind of need to figure out what to do with that
<bauen1>
so that involves actually buying an h6 board, figuring out how get secure boot to work and writing a bootloader that fits in the limited space provided by the sbrom and implements proper secure boot
<bauen1>
so basically storing a private key in the "secure" efuses of the h6 and using secure boot to ensure that only trusted code can access the secrets
<bauen1>
the end goal is to build a (cheap) proof of concept of a trusted soc that is tamper proof against evil maid attacks (or at least once with a small budget)
<bauen1>
asdf28: if you want to i can talk about secure boot, trustzone, my future plans with a h6 sbc, and my recent reverse engineering of the h5 sbrom, interested ? lol
<bauen1>
so what i said earlier about strncpy is actually wrong, they too are limited (correctly) to the buffer length
<bauen1>
i'm not sure if that is even exploitable
<bauen1>
and later when verifying the certificate there are a number to strncpy calls that just take the parsed length and don't do any limiting on the length
<bauen1>
the parser result is stored on the stack and the parser itself seems to verify the length of buffers before copying, but in case the supplied length is higher than the buffer less is copied (good) and the length is saved anyway (bad length > buffer size)
<bauen1>
i wouldn't be terribly surprised if the asn.1 parser and verification logic contains a buffer overflow or more
2020-10-03
<bauen1>
but it is probably limited to triggering read access to above where the asn.1 data is located
<bauen1>
hm, so the function that "parses" the asn.1 data structre gets passed the pointer to the data and the length, but it doesn't actually seem to _ever_ validate the length of asn.1 elements against the total length
<bauen1>
it also reads the ROTPK hash and NV1 values from SID and writes them to ~0x10000 before executing fel, but i'm not really sure what for
<bauen1>
oh nevermind i found it
<bauen1>
the code that switches to secure mode is still there for sure (0x000081d8 - $+0x2) but now i can't really find the code that actually loads the secure monitor vector table (0x000081a4)
<bauen1>
yeah that's not so nice
<bauen1>
did you observe this just with the h3 or also with the h5 ?
<bauen1>
yeah so not exactly how it should be
<bauen1>
and if the sbrom can switch to the nbrom at runtime it might also be possible to switch to sbrom without blowing any fuses (and maybe that could be applied to the h6)
<bauen1>
if it does have a TZASC or SPC that would be awesome
<bauen1>
smaeul: where did you find the info that there is mmio space reserved on the h6 ?
<bauen1>
smaeul: i was thinking about the 'smc #0' call to enter secure mode from fel without any signature check
<bauen1>
smaeul: thanks, i'll take a look and reverse engineer it a bit
<smaeul>
bauen1: I pushed the real H5 SBROM. I can do H6 too, though I'd like to add TOC0 support to binman before blowing more fuses
<smaeul>
bauen1: what about h3 do you consider a backdoor?
<smaeul>
bauen1: oops, sorry. I dumped the BROM from FEL, but FEL is implemented in the NBROM only, so the SBROM switches the mux to NBROM before entering FEL
<bauen1>
it kind of looks like all trustzone implementation in allwinner SoCs are handi-capped in some way or another (backkdoor in h3, probably a lack of SPC / SMC on the h6)
<bauen1>
guess i just have to buy a board to dump the firmware and figure out if there are any undocumented features
<bauen1>
however not being able to mark peripherals as secure also makes it less useful
<bauen1>
that would actually be quite decent
<bauen1>
it also appears that all the R_.*, RTC and SRAM A2 are attached on the same bus, so it could be possible that their all marked as secure
<bauen1>
so the h6 has a trusted watchdog, which is nice i guess, and according to the arm trusted firmware SRAM A2 is marked as secure, but still no trace of anything that would allow marking peripherals as secure
<bauen1>
anyhow i'm tending towards buying a h6 device
<bauen1>
smaeul: the sbrom you uploaded is just the nbrom but twice
<bauen1>
MoeIcenowy: in what way ?
<bauen1>
smaeul: thanks
<smaeul>
bauen1: correct. I never bothered to install Ruby (gentoo...) to generate a TOC0 image, so I never burnt the fuse.
<MoeIcenowy>
bauen1: don't worry, the H5 one is severely broken, at least when secure boot is not used
2020-10-02
<bauen1>
don't you also need some place to put the secure code that isn't writable by non secure code ?
<bauen1>
only access to the SID or keysram requires secure mode
<bauen1>
or at least it isn't in the manual
<bauen1>
it also looks like the h6 is lacking the secure peripheral controller the h5 has
<bauen1>
actually i might as well go for a board with an h6 since the user manual has a few more details and you can configure the boot sequences to some extend
<bauen1>
MoeIcenowy: is it also possible to dump from u-boot ?
<bauen1>
i do hope that behavior is also present on the h5 (or the h6)
<MoeIcenowy>
bauen1: I had a H2+ board that is burnt to be secure boot (but it's not bricked because I never write any keys into it -- when no key is present in eFUSE any signed BL is accepted)
<bauen1>
MoeIcenowy: Thanks, I actually disassembled part of the h3 sbrom to verify that behavior
<MoeIcenowy>
bauen1: no idea
<bauen1>
ironically only a "bricked" board or the sbrom dump can tell if there are any backdoors to the secure boot
<bauen1>
so you could boot some code that writes a 1, then dumps the memory, but as soon as you poweroff the board you have a brick
<bauen1>
as far as i understand it, the rom mapped at 0x0000 - 0xFFFF is selected by the secure bit of the lcjs efuse
<bauen1>
nvm i found a dump of both in this channel
<bauen1>
if someone could send me a dump of the N-BROM and S-BROM (first 64kb) or any documentation about the R_CPUCFG memory area that would be very nice
<bauen1>
according to the manual it should support some form of it