<bauen1>
and a lot of numbers pointing to the entry point trying to overwrite the return address on the stack
<bauen1>
then a little payload
<bauen1>
basically an oversized blob pretending to be toc0 by faking the first bytes
<bauen1>
not even piggy backing and not even a valid toc0 image
<apritzel>
bauen1: ah, I thought you had trouble running normal FEL mode
<bauen1>
smaeul: apritzel: i can provide you with the image if you want to test it (requires a pine h64 or a board that has an LED on PL7)
<bauen1>
pretty sure that's the dream of secure boot (without some tricks) going bye bye
<bauen1>
~128kb toc0 with just the first few magic bytes, a payload and then 0x20020 for the rest can hijack control flow by overwriting some return address on the stack
<bauen1>
oh no, it works
<bauen1>
actually, doing a binary search against what size breaks fel is probably a good idea
<bauen1>
i don't _want_ precautions :D
<bauen1>
apritzel: i'm trying to overwrite the stack of sbrom with an unathenticated image
<bauen1>
or deestablished secure boot by proofing it can be bypassed easily ...
<apritzel>
bauen1: I think once we have established the whole infrastructure around secure boot, we can think about that
<bauen1>
ah yes, having 20 people with "bricked" boards because they managed to enable secure boot by accident wouldn't be so fun
<bauen1>
apritzel: hm, i wasn't really looking forward to doing the writing by hand, but i guess for the 1-3 times i ever have to write to the sid that will do
<apritzel>
bauen1: and you can read arbitrary memory locations using "sunxi-fel read" and "sunxi-fel readl"
<apritzel>
bauen1: for reading the SID for hacking purposes, I would recommend U-Boot's md.l command
<apritzel>
bauen1: For the one time I burned an efuse, I just hacked it. Might have been in U-Boot (mw.l), or I injected some code into Trusted Firmware (since that always runs in secure world).
<bauen1>
KotCzarny: it (i think) is wired for both my boards
<bauen1>
and i still need a way of writing
<bauen1>
plaes: i figured out how to dump the values using linux, but doesn't `selinux-fel sid` only dump the firts ~32 bytes ?
<bauen1>
KotCzarny: sid is just a number of efuses
<bauen1>
smaeul: apritzel: what tool(s) do you use to read/write the sid ?
<smaeul>
bauen1: BSP code. I think that's where the original names in the wiki page came from as well
2020-11-17
<apritzel>
bauen1: ah right, I see it now, with tools-only_defconfig.
<bauen1>
tools/sunxi_egon.c:8:10: fatal error: asm/arch-sunxi/spl.h: No such file or directory
<bauen1>
not sure, the eGON version for sure
<apritzel>
bauen1: just the TOC0 version or the eGON one as well?
<bauen1>
smaeul: by the way mkimage doesn't compile with `make tools-only_defconfig tools-only` due to assuming that an allwinner SoC is already selected
<bauen1>
probably, currently i've started my B.Sc. in Informatics so i'm a bit strapped for time
<bauen1>
allwinner chips are a nice stepping stone until risc-v becomes a bit more affordable
<bauen1>
i'm just interested in hardware security / floss hardware
<bauen1>
*secret keys
<bauen1>
if at all possible i want to use the h64 as "root of trust", i.e. trusted computing platform to host keys and compile binaries for other boards
<bauen1>
lol
<asdf28>
bauen1, that's awesome
<bauen1>
anyway i think it's about time i flash my h64 to secure mode, i've already tested installing gentoo on it which should make kernel / tee development easier
<bauen1>
asdf28: tl lim send me a pine h64 and a pine64 for free
<asdf28>
bauen1 did you buy a single board computer?
<bauen1>
ideally there would be some nvram to store replay counters without the "high cost" of efuses
<bauen1>
megi: yes, but it just behaves like sram making it utterly useless
<megi>
bauen1: looks like it's mean for some nonce
<bauen1>
which i think is what microsofts fTPM on the surface tablets does
<bauen1>
or the replay protected block of an sd
<bauen1>
apritzel: i mean implementing replay protection using the sid efuses is possible ; but rather costly
<apritzel>
bauen1: probably short for "never mind" :-D
<bauen1>
but i don't think any allwinner SoCs have any
<bauen1>
probably Non Volatile Memory
<bauen1>
what does NVM stand for in this context
<bauen1>
there's also `The 2^32 monotonic counter does not need to be e-Fuses, but it does need to be fully secure. Using the SoC embedded NVM, or external secure element, or a trusted register, which is always on power. ` in the a64 manual
<bauen1>
tested on both the H6 (which doesn't even have R_TWDG documented, but allwinner is predictable lol) and the pine64 which has an a64
<bauen1>
but they're not backed by anything, a simple reset clears any value written to them, effectively making them SRAM
<bauen1>
it contains SST_NV_COUNTER_REG, SYN_DATA_COUNTER_REG{0..3} supposedly "Secure Storage NV-Counter Register" ; "Synchronize Data Counter Register {0..3}"
<bauen1>
i'm also really confused as to what allwinner did with their R_TWDG
<bauen1>
smaeul: nice work on the toc0 wiki page ; i'm interested, how did you find the meaning of TOC0_ITEMn_STATUS / TOC0_STATUS ?
2020-11-16
<bauen1>
but not possible anymore if using the method that includes the items / header in the signature since the run address varies between pre-H6 ; H6
<bauen1>
so it might be possible to generate toc0 that works for both H6 and pre-H6 ; you just need to figure out the correct rotpk hash
<bauen1>
smaeul: toc0 previous to H6 lacks the 0x10303 item (but should ignore it just fine) and compares the sha256 of the 0x10101 cert to the sid efuse rotpk hash
<bauen1>
smaeul: nice work
<smaeul>
bauen1 wants to rearrange the headers so that the firmware item actually starts before its item header, so the load address is also signed
<bauen1>
it also looks like the rtc actually has 0x30 bytes of usable registers, but only 0x20 bytes are officially documented as "general purpose"
<bauen1>
actually patching a single instruction in the sbrom code might be enough to make booting from smhc 0 safe, so copy the entire sbrom somewhere, patch the byte and call it (might as well patch out the monitor backdoor at that point too)
<bauen1>
actually, just moving the stack to a save location would be enough, but there is no memory below 0x20000
<bauen1>
but would cause the cpu to go into a reset loop if it ever looses power (not rtc power), so maybe the general purpose registers could be used to e.g. load an image of certain size from smhc 0 and then continue the normal validation path
<bauen1>
just writing the cpu0 hotplug register / entry to point to an infinite loop and then using the other words to store a secret would be enough to prevent this attack
<bauen1>
approximately 9, maybe 13 words of data to work with
<bauen1>
that just really leaves attaching an RTC battery and using the boot hotplug / general purpose registers to store a tiny bit of code and secrets
<bauen1>
so anyone with control over smhc 0 can probably bypass secure boot, nice
<bauen1>
smaeul: well that is bad news lol
<smaeul>
bauen1: indeed, I padded the TOC0 out to 0x00026a00 (154k) and I get no output and no FEL (even after I remove the SD card)
2020-11-14
<bauen1>
introduced by commit 905434e0b544ee220bcce6da16a6857c0274b8ba says that is related with dynamic voltage and frequency scaling
<bauen1>
the h6 dtsi in the linux kernel also has `cpu_speed_grade: cpu-speed-grade@1c { reg = <0x1c 0x4>; };`
<smaeul>
bauen1: I will prepare a table of H6 SBROM error codes
<bauen1>
right, but uart is easy to use
<bauen1>
i need to get my monitor working with linux again if i want to do test since my macbook air only has 2 usb ports with one taken by ethernet
<smaeul>
bauen1: 0x30000d0, the SRAM switch / error log register
<bauen1>
smaeul: not really, just bigger equal than SRAM A1 + SRAM C
<bauen1>
smaeul: from where do you have the 0x8904000b value
<bauen1>
it's like the idea to support 3072 bit keys was there but it was never tested
<bauen1>
yeah
<smaeul>
bauen1: right, I think that's the *only* part of the BROM that would not work with 3072 bit keys (for either key)
<bauen1>
smaeul: if you want to try, a toc0 of size ~152KiB, that just has a valid name, magic and length might be able to put the H6 into a reset loop
<bauen1>
in any case the sbrom forces the length of the key to be below < 0x201 and all buffers are >= that so there's no issues in part#
<bauen1>
in fact only BROM_CONFIG, VENDORID, ROTPK_HASH are used by the sbrom
<bauen1>
smaeul: there is no bit in the BROM_CONFIG that influences the RSA decryption function
<smaeul>
bauen1: I just tried 3072 bit RSA key and it dies with 0x8904000b (failure to check the key item against the ROTPK)
<bauen1>
i think it might be time to burn my h64s secure boot fuse
<bauen1>
i should read a bit more carefully before jumping to conclusions
<bauen1>
no it isn't 4 bytes -> 4GB
<bauen1>
so overwriting the stack shouldn't be possible
<bauen1>
wait, the toc0 size is limited to 64Kb
<bauen1>
smaeul: actually it moves the stack after deciding it should follow the "normal" boot sequence (i.e. before calling "main")
<smaeul>
bauen1: yes, I've booted a TOC0 with a 39KiB payload. SRAM C immediately follows SRAM A1 and is configured by the SBROM. SBROM moves its stack to the end of SRAM A2 in the middle of processing
<bauen1>
yes, the stack starts at 0x42e00
<bauen1>
or it isn't, but some sort of stack for something starts at 0x27ffc
<bauen1>
and at the end of SRAM A1 at 0x27ffc is the stack ...
<bauen1>
*even
<bauen1>
before processing eve
<bauen1>
from what i'm seeking in the sbrom the raw image is loaded to 0x00020000, which is the SRAM A1 that is limited to 32Kb
<bauen1>
smaeul: have you actually tried loading an toc0 that is >= ~28Kb ?
<bauen1>
so in theory that allows "bricking" FEL but still allows using the USB2.0 OTG port, e.g. from linux
<bauen1>
so there's definietly a chance that setting the BOOTROM_CONFIG.FEL_MAGIC flag in the SID could be used to "brick" fel
<bauen1>
hm, so writing 0x9 (FIQEn=1, En=1) to GICC_CTLR (0x03022000) from fel "breaks" fel
<smaeul>
bauen1: the earlier SPC is a BP147, which has groups of 3 registers, so each "SET" register is 0xc above the last. the new one has groups of 4 registers
2020-11-13
<bauen1>
*could be
<bauen1>
so in theory this could be a way of "bricking" FEL
<bauen1>
this is kind of assuming that FEL requires IRQs to work
<bauen1>
anyway, that probably requires bricking an actual board to test \o/
<bauen1>
the NBROM expects IRQs and would normally set GIC_CTLR=1 (FIQEn=0)
<bauen1>
which is done by the SBROM if a certain bit in the BROM_CONFIG is set
<bauen1>
and it just so happens that the SBROM sets GICC_CTLR.FIQEn=1 before jumping to the NBROM / FEL, and the NBROM can be made to skip the GIC init if 2 magic values are stored at a specific SRAM location
<bauen1>
at least that's what i would think
<bauen1>
so if 0x18 (fiq) is an infinite loop and the GIC has been configured with FIQEn=1 then the infinite loop will be executed instead of whatever is at 0x14 (irq)
<bauen1>
actually something better, with the GIC FIQEn=1 every interrupt to the GIC, e.g. a usb controller, would instead be run as FIQ (and using the FIQ handler instead of IRQ handler) ?
<bauen1>
nice, now i'm seriously confused what exactly sbrom / nbrom is doing
<apritzel>
bauen1: yes
<bauen1>
doesn't that mean that any IRQs would be handled by the monitor (located at MVBAR)
<bauen1>
it looks like the sbrom sets SCR.IRQ = 1 (p15,0x0,r3,cr1,cr1,0x0
<bauen1>
there's a small chance that this could be used to "disable" the FEL without burning pins
<bauen1>
it kind of looks like the FEL will skip initialising the GIC (Generic Interrupt Controller) if the magic is copied
<bauen1>
has anyone ever investigated what changes with the FEL if the magic is present at 0x22800, 0x22804 ?
<bauen1>
oh nevermind that was an off-by-one error
<bauen1>
also looks like bit 15 is both used to select software sha256 and booting images without 0x10303
<bauen1>
only ~8 bits, so you would just need ~256 boards to test it :D
<bauen1>
quite a lot of the bits in BROM_CONFIG seem to influence how the clocks are configured, i wonder if you can "brick" fel by messing with them
<bauen1>
also, can you like not write to the RTC using sunxi-fel ?
<bauen1>
hm, booby trapping your computer sounds fun, especially if you ever need to go through customs lmao
<KotCzarny>
bauen1: resin and explosives?
<bauen1>
power glitching would be another fun attack vector to explore
<bauen1>
KotCzarny: not against a local attacker with decent knowledge, e.g. desolder/solder components from the pcb, attach to traces but without the ability to decap the SoC (or use lasers to extract the secrets from efuses)
<apritzel>
which is exactly what bauen1 does NOT want ;-)
<bauen1>
true
<bauen1>
but allwinner is so damm cheap
<bauen1>
doesn't really solve the issue of disableing secure boot
<bauen1>
for something like the pine phone that might not actually be that much of an issue
<apritzel>
bauen1: across power-off's: yes
<bauen1>
it does require a battery, i think
<bauen1>
assuming that all of the values are retained on RTC power
<bauen1>
that would require a RTC battery though
<bauen1>
it also occured to me that if there is enough ("persistent") sram in the RTC you could store (parts of) the a secret in there along with hooking the super standby and hotplug vectors to prevent FEL from ever becoming active without "erasing" the secret
<bauen1>
smaeul: by the way you said that the SPC on the H6 has different registers, how did you determine that ?
<bauen1>
it's actually quite nice that they don't lie per se, they only lie by omission
<bauen1>
i mean if you cross reference enough user manuals from different allwinner chips you probably get a pretty good overview lol
<apritzel>
bauen1: that's admitting that reading Allwinner documentation takes its toll ;-)
<bauen1>
also not really sure what e.g. CRY_CONFIG_REG is for
<bauen1>
looking at the H6 docs, there's all kinds of registers from ~0x0100 to ~0x218 that kind of look like sram
<bauen1>
yes
<bauen1>
there's at least 4*8 + 4*3 bytes of it
<bauen1>
apritzel: part of the rtc reg space is probably just sram
<apritzel>
bauen1: are those really specific registers, or is it just some scratch SRAM on a separate power line?
<bauen1>
yeah, the RTC looks like a very important peripheral with lots of magic that is pretty much the same on all the chips
<apritzel>
bauen1: I am afraid it's a Wiki, so it would be up to you to enter it there :-D
<bauen1>
is there a wiki page with a bit more technical information about the registers than https://linux-sunxi.org/RTC ?
<bauen1>
lol
<bauen1>
so yeah same offsets into the RTC register space as the h6
<bauen1>
apritzel: write 0xFA50392F into 0x01f01dac, the entry address into 0x01f01da4
<apritzel>
bauen1: many thanks!
<bauen1>
let me look at the nbrom
<bauen1>
but yeah i don't see it there either
<bauen1>
apritzel: it's part of the RTC
<apritzel>
bauen1: a lot of CPUCFG is missing in the A64, that's why I am asking
<bauen1>
apritzel: it's the name of the register in the documentation, not sure how documented it is for A64 (if it exists), let me check
<apritzel>
bauen1: Is BOOT_CPU_HP_FLAG_REG documented? Do you know the equivalent for A64, for instance?
<apritzel>
bauen1: cool, thanks, that sounds promising
<bauen1>
would that work ?
<bauen1>
but at least the sbrom h6 checks if (MPIDR != 0) || (BOOT_CPU_HP_FLAG_REG == 0xFA50392F) -> jump(CPU_SOFT_ENT_REG0)
<bauen1>
i think so
<bauen1>
is that the core number ?
<bauen1>
apritzel: what is MPIDR ?
<apritzel>
bauen1: is that the "super-standby" resume? Or the MPIDR!=0 trick?
<bauen1>
apritzel: essentially faking a core 0+ reset i think
<bauen1>
apritzel: the nbrom should jump to your address before even messing with any hardware registers
<bauen1>
(looking at an h6 sbrom, but should be similiar to nbroms of similiar models): write 0xFA50392F into BOOT_CPU_HP_FLAG_REG and your desired address into CPU_SOFT_ENT_REG0
<bauen1>
apritzel: maybe, i think you could also trick the cpu 0 into thinking it's being started as not cpu0 by setting some bits in the rtc and resetting
<apritzel>
bauen1: you mean using this super-standby trick?
<bauen1>
apritzel: yeah, but you can make the early nbrom code jump to your fixup code (iirc even before the sp is setup)
<apritzel>
bauen1: the problem is: that fixup code is never called, because it goes to 0x0
<bauen1>
jernej: are you refering to the ~8 words ? or is there more undocumented scratch memory ?
<apritzel>
bauen1: that's what I am doing, yes
<bauen1>
apritzel: you could save the register information somewhere safe and setup a tiny routine that restores the registers and returns to fel
<bauen1>
megi: that's probably what i'm talking about
<apritzel>
bauen1: interesting, I remember that, might indeed be a way in
<apritzel>
bauen1: but yeah, I seem to be dropped to 0x0, where FEL restarts, throwing off sunxi-fel
<bauen1>
apritzel: the brom contains some logic for super standby and some other stuff that could be used to "subvert" the instruction flow before executing any actual boot code
<apritzel>
bauen1: so I need to branch to some custom AArch32 code to restore the registers
<apritzel>
bauen1: somewhat, but not even 0x20 would be enough, since I need to *return* to where FEL dropped me, initially
<bauen1>
apritzel: your problem is that resetting into aarch32 jumps to the brom at address 0x0000 when you want to land at address 0x0020 (enter_fel) ?
2020-11-12
<bauen1>
and it also means that to trigger a bug in the asn1 parse / verify logic for 0x10101 you now need a valid (vendor id match, valid signature) 0x10303
<bauen1>
combined with the usage of `bool` as return type (instead of int) in the "new" parts, it kind of looks bolted on
<bauen1>
i'm confused why that wasn't just put into the 0x10101 (or it eliminated)
<bauen1>
which also means you can use 2 different certificates, one as root that signs the 0x10303 blob, verifying the certificate used to sign the bootcode
<bauen1>
and cert_info also looks like it contains the sha256 of the rsa key used in 0x10101 instead of the efuse rotpk
<bauen1>
so that can be used to prevent roll backs, which is nice
<bauen1>
hm, so the new 0x10303 is also [vendor id][cert_info][cert_signature], where cert_signature = rsa([vendor_id .. cert_info]) and vendor id is checked to match the efuse value to permit boot
<bauen1>
also the functions that validate 0x10101 are slightly different between the "old" and "new" (0x10303) way
2020-11-11
<bauen1>
yeah but i'm interested about the situation on the pinephone since it seems to pull the usb through another chip before you can access it
<bauen1>
gnarface: insep_: have you actually tried accessing FEL (without writing a special image e.g. to the sd) ?
<gnarface>
bauen1: it was the same as android i thought
<gnarface>
bauen1: i thought you had to hold volume down while you power on or something?
<bauen1>
actually i don't have a pinephone and can't try if you can even access FEL (without hardware modifications), but it looks like the usb data wires go into an AXP803 chip so that could prevent access to FEL without opening the device
<bauen1>
insep_: but if you actually implement the touch screen as "secure peripheral" e.g. reserve the top 20px to secure mode (see link above) you can do a lot of fun stuff like storing your gpg keys in the secure mode
<bauen1>
iirc u-boot does some signature checking
<bauen1>
but if you control the bootloader you can implement it
<bauen1>
for UEFI Secure Boot that's already a thing
<bauen1>
insep_: what exactly reads the password, a full blown linux kernel, the bootloader ; doesn't matter too much at that point
<bauen1>
insep_: with secure boot you can have confidence that the code asking you for the decryption keys isn't malicious
<bauen1>
an efuse bit to disable FEL is the only thing needed, maybe on a future chip ...
<bauen1>
it's a bit of a bummer that the FEL provides a straight backdoor
<bauen1>
the pinephone is a very interesting target for doing trustzone and hardware security in general e.g. something like https://www.youtube.com/watch?v=voFV1W4yyY8 or a secure pin (encryption password) entry screen
<willmore>
bauen1, I assume the code in the efuse is meant to be programmed off board and the board would ground the pin preventing later modification.
<bauen1>
i suppose it can already be done by grounding the efuse ping, but that requires hardware modification
<bauen1>
since then you can ensure integrity (to some extend, but not confidentiality) of the code being executed even if fel is active
<bauen1>
willmore: i haven't actually booted my h6 yet so can't really answer that, but it would be lovely if there was a fuse that disables any further writes
<willmore>
bauen1, nice work you're doing. I have one question about the "and the first 4 bytes of the keyladder must match sid[0x5c] unless sid[0x5c] is 0" part. Isn't this memory 1 when blank and 0 when programmed? Wouldn't that make it possible to program these locations and bypass that check?
<bauen1>
pages that reference specific memory address / magic numbers also should mention which soc they respond to, but that's a dream far away
<apritzel>
smaeul: bauen1: in case you care, I put my U-Boot mkimage TOC0 skeleton patch here. That surely needs some rework now, but should provide some base: https://github.com/apritzel/u-boot/commits/mkimage
<bauen1>
why would you need another ethernet connector for a tv box ?
<bauen1>
but i also kind of doubt that is possible just in software
<bauen1>
it also occured to me that if i find a way to (persistently) breaks the fel in some way, e.g. by messing with timings that could be used as a way of disabling it while still allowing e.g. linux to use the usb
<bauen1>
smaeul: there should also be a SMC according to the BSP, see H6/Memory_Map
<smaeul>
bauen1: just to confirm, yes it will
<bauen1>
seems like the best way to make these chips secure is still to burn the otg usb data pins :/
<bauen1>
sorry i just read your text above again
<bauen1>
smaeul: the SMC backdoor would still work if you could care to craft up some code, upload it with fel and run it, right ?
<bauen1>
smaeul: is smch0 the sd card or emmc ?
2020-11-10
<bauen1>
i'm so annoyed that there isn't an easy way of disabling fel
<bauen1>
you can (probably) configure the SPC to prevent access to the RTC but you can't run (secure) code before the attacker if the attacker just goes to fel mode
<bauen1>
smaeul: didn't the smc trick work ?
<bauen1>
oh right
<bauen1>
e.g. 0x3448
<bauen1>
it also appears as if the brom will always try some smhc based boot method before doing the boot process (i.e. look at efuses / gpio and do "the way of try" or selected boot medium)
<bauen1>
looks just like the "normal" boot sequence but calls some functions that do "magic" checking against 'BT0.RRTB', '"BT0.DMTB', 'BT0.NTAB'
<bauen1>
takena a look at 0x341c yet ?
<bauen1>
wow you've been busy
<smaeul>
bauen1: I should send you my ghidra database; I've already gone through most of these. 0x2ff4 is 2-item TOC0, 0x1418 is 3-item TOC0
<bauen1>
that's probably BOOT_MODE[0]
<bauen1>
the 1. bit in the BROM_CONFIG mode also seems to switch between two different boot functions
<bauen1>
smaeul: i assume the "keyladder" term in toc0.log is from allwinner ?
<bauen1>
and that appears to be all that it's being used for ...
<bauen1>
which i think could be used as a sort of rollback prevention
<bauen1>
and the first 4 bytes of the keyladder must match sid[0x5c] unless sid[0x5c] is 0
<bauen1>
but i don't think that does anything problematic
<bauen1>
*0xFFFFFFFF, 0x00001
<bauen1>
hm, that length check can probably be made to overflow e.g. with length_modulus = 0xFFFF, length_public_exponent = 0x1
<bauen1>
not really sure what to make of that
<bauen1>
there are also some checks like: length(modulus) + length(public exponent) < 0x201
<bauen1>
doesn't look like anything weird, except that it's a custom format ?
<bauen1>
so from what i've gathered about the "keyladder" it's basically [some header information][modulus][public exponent][some more stuff ?][signature], where signature is the rsa signature of the sha256 [header - more stuff]
<bauen1>
which is a bit stupid since the buffers are 0xc00 (3072 / 8) bytes big ...
<bauen1>
so 0x10303 probably supports 3072 bits, but 0x10101 only supports (up to) 2048 bits
<bauen1>
i'm just stupid
<bauen1>
Oh
<bauen1>
looks kind of like a "copy in reverse and fill remaining with 0" or something like that
<bauen1>
i'm also really confused about what the function at 0x00001f68 does, it seems to be called with various arguments, including the sg src addr of the ce descriptor
<bauen1>
it could be that the h6 sbrom also supports 3072 bit rsa keys, at least judging by buffer size
<bauen1>
currently taking a dig at what ever verifies the "key ladder"
<bauen1>
i do have to give it to allwinner, they are checking buffer sizes in (almost) all places in the brom
<bauen1>
thanks
<Ixnus>
bauen1, smaeul, apritzel super reverse engineering, good luck.
<bauen1>
which would be most relevant to pre-H6 SBROMs that can't specify the boot order
<bauen1>
then you could also do some fun stuff like requiring that the image is booted e.g. from spi nor flash, since the sbrom overwrites the boot medium before verifying the signature
<bauen1>
assuming that the cert length and offset are already known i would just make the signed chunk start inside the toc0 header to cover as much as possible to avoid similiar surprises down the road
<bauen1>
adding another entry is easier, right
<bauen1>
but you can also (ab)use the bootcode entry
<bauen1>
right that would also be a way, i think
<bauen1>
e.g. you change item_offset / item_length to start at the reserved word in the header and fill that word with the branch to the actual bootcode
<bauen1>
and the first word of the signed data blob needs to be a branch instruction to the actual bootcode
<bauen1>
to avoid a mess, the run address is set to the exact address in memory where the data already resides, making the memcpy effectively a NOP operation
<bauen1>
now the run address and various other fields are part of the signature
<bauen1>
then you specify the offset/length to include the (header maybe) items, specifically the run_address and the bootcode