<smaeul>
bauen1: the bit that switches between TOC0 with and without the extra item is bit 15 of the OEM_PROGRAM fuse
<smaeul>
I didn't want to program it
<smaeul>
the SPL at the link above is 48k, and expects U-Boot concatenated on the end. The ATF -> U-Boot handoff hangs, so that will need further debugging
JohnDoe_71Rus has joined #linux-sunxi
<smaeul>
I will start posting code/documentation later in the week after I can sanitize it
AneoX has quit [Ping timeout: 260 seconds]
AneoX has joined #linux-sunxi
kaspter has quit [Ping timeout: 256 seconds]
kaspter has joined #linux-sunxi
lurchi_ has joined #linux-sunxi
lurchi__ has quit [Ping timeout: 240 seconds]
AneoX has quit [Ping timeout: 260 seconds]
AneoX has joined #linux-sunxi
asdf28 has joined #linux-sunxi
reinforce has joined #linux-sunxi
lkcl has quit [Ping timeout: 260 seconds]
AneoX has quit [Ping timeout: 246 seconds]
AneoX has joined #linux-sunxi
lkcl has joined #linux-sunxi
AneoX has quit [Ping timeout: 272 seconds]
AneoX has joined #linux-sunxi
daregap has joined #linux-sunxi
apritzel has joined #linux-sunxi
gendevbot has quit [Remote host closed the connection]
AneoX has quit [Ping timeout: 260 seconds]
AneoX has joined #linux-sunxi
apritzel has quit [Ping timeout: 272 seconds]
mcf has quit [Ping timeout: 260 seconds]
lkcl has quit [Ping timeout: 260 seconds]
AneoX has quit [Ping timeout: 246 seconds]
eduardas has joined #linux-sunxi
AneoX has joined #linux-sunxi
Kwiboo- has quit [Ping timeout: 240 seconds]
AneoX has quit [Ping timeout: 260 seconds]
lkcl has joined #linux-sunxi
AneoX has joined #linux-sunxi
lkcl has quit [Ping timeout: 246 seconds]
AneoX has quit [Ping timeout: 260 seconds]
AneoX has joined #linux-sunxi
AneoX_ has joined #linux-sunxi
AneoX has quit [Ping timeout: 258 seconds]
lkcl has joined #linux-sunxi
camus1 has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
camus1 is now known as kaspter
AneoX_ has quit [Ping timeout: 264 seconds]
<bauen1>
very nice
<bauen1>
i'll have to give ghidara another look
AneoX has joined #linux-sunxi
ldevulder_ is now known as ldevulder
cmeerw has joined #linux-sunxi
lkcl has quit [Ping timeout: 272 seconds]
lkcl has joined #linux-sunxi
AneoX has quit [Ping timeout: 272 seconds]
AneoX has joined #linux-sunxi
AneoX_ has joined #linux-sunxi
AneoX has quit [Ping timeout: 260 seconds]
eduardas has quit [Quit: Konversation terminated!]
eduardas has joined #linux-sunxi
<bauen1>
interestingly there is a "sid_write_rotpk_hash_buf" function present in the sbrom (but unused) 0x37a0
apritzel has joined #linux-sunxi
camus1 has joined #linux-sunxi
kaspter has quit [Remote host closed the connection]
camus1 is now known as kaspter
<bauen1>
smaeul: i haven't found yet where in the sbrom the oem_program fuse is read, all i've found is reads against BROM_CONFIG
florian_kc has joined #linux-sunxi
<bauen1>
maybe it would be possible to (completely) disassemble some functions and save that representation with the binary form so it can be matched against other (s/n) brom dumps
matthias_bgg has joined #linux-sunxi
mcf has joined #linux-sunxi
florian_kc is now known as florian
chewitt has joined #linux-sunxi
steev has quit [Ping timeout: 244 seconds]
victhor has joined #linux-sunxi
narmstrong has quit [Ping timeout: 260 seconds]
steev has joined #linux-sunxi
narmstrong has joined #linux-sunxi
matthias_bgg has quit [Ping timeout: 264 seconds]
matthias_bgg has joined #linux-sunxi
matthias_bgg has quit [Quit: Leaving]
matthias_bgg has joined #linux-sunxi
gaston1980 has joined #linux-sunxi
shailangsa has joined #linux-sunxi
\\Mr_C\\ has quit [Quit: (Read error: Connection reset by beer)]
cnxsoft has joined #linux-sunxi
cnxsoft1 has quit [Read error: Connection reset by peer]
\\Mr_C\\ has joined #linux-sunxi
<bauen1>
i'm also not really sure what 0x00002f64 does, it looks like it reads a 4 byte value from 0x80000 + (x << 0x8), but there is nothing there
<bauen1>
perhaps some way of debugging where the brom is by observing memory access ?
netlynx has joined #linux-sunxi
netlynx has joined #linux-sunxi
netlynx has quit [Changing host]
Mangy_Dog has joined #linux-sunxi
AneoX_ has quit [Ping timeout: 246 seconds]
lucascastro has quit [Remote host closed the connection]
<smaeul>
bauen1: OEM_PROGRAM is read and cached in SRAM A2 at 0x768. yes, there are several debugging functions (0x354 is another, also present in NBROM)
<bauen1>
smaeul: that is BROM_CONFIG you're refering to
<smaeul>
ghidra has a "version tracking" tool that correlates functions/objects between binaries and lets you copy name/type/comment info between them
<bauen1>
also at least the spi nor boot code doesn't do any length checking (like the h5 and a53 i believe)
<bauen1>
i guess i should try to actually overwrite the stack
<smaeul>
how did you propose to sign the entry address? only the actual firmware item contents are hashed in the certificate
<bauen1>
but it's quite likely that the DMA descriptor is on the stack before the return address so some math and careful creation of an attack image might be required
<bauen1>
smaeul: that isn't really right, the image specifies the data offset from the header and the length of the data to be hashed, verified and executed
<bauen1>
so the idea is to make an image like [toc0 header][toc0 items][real bootcode][certificate]
<bauen1>
then you specify the offset/length to include the (header maybe) items, specifically the run_address and the bootcode
<bauen1>
now the run address and various other fields are part of the signature
<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>
and the first word of the signed data blob needs to be a branch instruction to the actual bootcode
<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
<smaeul>
you'd want to add a dummy item header (i.e. not 0x10?0?) before the firmware item header, and start the signed chunk there
<bauen1>
right that would also be a way, i think
<bauen1>
but you can also (ab)use the bootcode entry
<bauen1>
adding another entry is easier, right
<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
Kwiboo has joined #linux-sunxi
Ixnus has joined #linux-sunxi
<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
<smaeul>
the toc0 items are parsed to a different structure by func_94e4. I haven't examined how that works yet, but I don't think all fields are used
<bauen1>
which would be most relevant to pre-H6 SBROMs that can't specify the boot order
asdf28 has quit [Ping timeout: 256 seconds]
<Ixnus>
gediz0x539: can you get the A100 and H313 datasheets/user manuals also ?
asdf28 has joined #linux-sunxi
daregap has quit [Quit: daregap]
<Ixnus>
bauen1, smaeul, apritzel super reverse engineering, good luck.
Ixnus has quit [Remote host closed the connection]
<bauen1>
thanks
<gediz0x539>
Ixnus: any link to their documents from baidu or CSDN?
<gediz0x539>
i'm looking for designware ddr documents. found some old ones and i'm not sure if they were already publicly available.
<gediz0x539>
i'll upload them to somewhere asap and share the link here.
lkcl has quit [Ping timeout: 246 seconds]
reinforce has quit [Quit: Leaving.]
ldevulder_ has joined #linux-sunxi
chewitt has quit [Read error: Connection reset by peer]
chewitt has joined #linux-sunxi
ldevulder has quit [Ping timeout: 256 seconds]
lkcl has joined #linux-sunxi
psydread has joined #linux-sunxi
psydread has left #linux-sunxi [#linux-sunxi]
niceplace has quit [Ping timeout: 264 seconds]
psydread has joined #linux-sunxi
<bauen1>
i do have to give it to allwinner, they are checking buffer sizes in (almost) all places in the brom
eduardas has quit [Quit: Konversation terminated!]
JohnDoe_71Rus has joined #linux-sunxi
florian has quit [Quit: Leaving]
vagrantc has joined #linux-sunxi
hexdump0815 has joined #linux-sunxi
<hexdump0815>
Ixnus: for h313 i guess you can simply take the h616 manual - i'm currently running a h313 tv box here with an adjusted kernel based on the orange pi zero 2 bsp sources and it runs perfectly fine
<hexdump0815>
Ixnus: i've meanwhile even removed the h313 opp cap and it runs fine and stable even at 1.5ghz as a h616 for me - doing a -j4 kernel compile again right now ...
lurchi_ is now known as lurchi__
Kwiboo has quit [Quit: .]
Kwiboo has joined #linux-sunxi
gnarface has quit [Remote host closed the connection]
gnarface has joined #linux-sunxi
asdf28 has quit [Ping timeout: 260 seconds]
asdf28 has joined #linux-sunxi
abelvesa has quit [Remote host closed the connection]
mauz555 has joined #linux-sunxi
lurchi__ is now known as lurchi_
abelvesa has joined #linux-sunxi
gnarface has quit [Ping timeout: 260 seconds]
gnarface has joined #linux-sunxi
tnovotny has quit [Quit: Leaving]
abelvesa has quit [Remote host closed the connection]
hexdump0815 has quit [Remote host closed the connection]
arete74 has quit [Ping timeout: 272 seconds]
jstein has joined #linux-sunxi
lukedashjr has joined #linux-sunxi
luke-jr has quit [Ping timeout: 260 seconds]
lukedashjr is now known as luke-jr
lurchi_ is now known as lurchi__
netlynx has quit [Quit: Ex-Chat]
<bauen1>
currently taking a dig at what ever verifies the "key ladder"
<bauen1>
it could be that the h6 sbrom also supports 3072 bit rsa keys, at least judging by buffer size
abelvesa has joined #linux-sunxi
abelvesa has quit [Client Quit]
<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>
looks kind of like a "copy in reverse and fill remaining with 0" or something like that
abelvesa has quit [Remote host closed the connection]
matthias_bgg has quit [Ping timeout: 272 seconds]
The_Loko has joined #linux-sunxi
<bauen1>
so 0x10303 probably supports 3072 bits, but 0x10101 only supports (up to) 2048 bits
<bauen1>
which is a bit stupid since the buffers are 0xc00 (3072 / 8) bytes big ...
abelvesa has joined #linux-sunxi
asdf28 has quit [Ping timeout: 260 seconds]
asdf28 has joined #linux-sunxi
<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>
doesn't look like anything weird, except that it's a custom format ?
<bauen1>
there are also some checks like: length(modulus) + length(public exponent) < 0x201
<bauen1>
not really sure what to make of that
lurchi_ is now known as lurchi__
<bauen1>
hm, that length check can probably be made to overflow e.g. with length_modulus = 0xFFFF, length_public_exponent = 0x1
<bauen1>
*0xFFFFFFFF, 0x00001
<bauen1>
but i don't think that does anything problematic
lurchi__ is now known as lurchi_
<bauen1>
and the first 4 bytes of the keyladder must match sid[0x5c] unless sid[0x5c] is 0
<bauen1>
which i think could be used as a sort of rollback prevention
<bauen1>
and that appears to be all that it's being used for ...
<bauen1>
smaeul: i assume the "keyladder" term in toc0.log is from allwinner ?
yoq has joined #linux-sunxi
asdf28 has quit [Ping timeout: 240 seconds]
cmeerw has quit [Ping timeout: 240 seconds]
<yoq>
In the android kernel source dump for the OPi Zero2 (H616), there are some binaries, including a TOC0.GLH that looks very different from what's documented on the wiki. Might be useful
<apritzel>
yoq: did you find anything about libdram in there? typically just an ELF file (without an extension, possibly)
<apritzel>
yoq: thanks for those links, btw!
shailangsa has quit [Ping timeout: 256 seconds]
<yoq>
you're welcome! libdram is typically linked into SPL / BOOT0, right? longan.tar.gz has u-boot-2018 sources but i haven't seen any libdram
mauz555 has joined #linux-sunxi
<apritzel>
yoq: thanks, was worth a shot. Some of the code dumps in the past contained this ELF file, which had debug symbols, so this simplified reverse engineering
<apritzel>
and yes, to be linked into SPL/boot0
<apritzel>
we even had a hack to link into it mainline SPL, to get started with mainline Linux development
mauz555 has quit [Ping timeout: 244 seconds]
<bauen1>
the 1. bit in the BROM_CONFIG mode also seems to switch between two different boot functions
<bauen1>
that's probably BOOT_MODE[0]
qschulz has quit [Remote host closed the connection]
mauz555 has joined #linux-sunxi
qschulz has joined #linux-sunxi
<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
<yoq>
pwd
mauz555 has quit [Ping timeout: 272 seconds]
<smaeul>
/
<smaeul>
0x10303 format is [vendor ID][rotpk_n_len][rotpk_e_len][certkey_n_len][certkey_e_len][signature_len][rotpk_buffer(512)][certkey_buffer(512)][empty(32)][signature]
<bauen1>
wow you've been busy
<bauen1>
takena a look at 0x341c yet ?
shailangsa has joined #linux-sunxi
<bauen1>
looks just like the "normal" boot sequence but calls some functions that do "magic" checking against 'BT0.RRTB', '"BT0.DMTB', 'BT0.NTAB'
<smaeul>
only the end, where it decides which boot sequence to use
<smaeul>
(2-item vs 3-item)
<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>
e.g. 0x3448
<smaeul>
0x341c vs 0x31ec is a bit in BROM_CONFIG (read in 0x78c)
<smaeul>
yes, this is documented in the manual, the efuse-based boot always starts with MMC0
<bauen1>
oh right
lkcl has quit [Ping timeout: 264 seconds]
<smaeul>
speaking of boot process: neither the hotplug nor standby boot processes do any signature checking, and the entry flag/addr registers are NS in the RTC block. that's how I first got secure code execution to dump the SBROM
<smaeul>
so FEL access continues to be game over
<bauen1>
smaeul: didn't the smc trick work ?
<smaeul>
SMC breaks FEL if you don't switch back, so it doesn't work the way it's programmed in sunxi-fel
<smaeul>
I only learned that after comparing the H5 and H6 SBROMs and seeing that the monitor mode code was identical [except for SRAM A2 moving]
<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
<smaeul>
so it does work from a "allows you to enter secure mode" perspective
<bauen1>
i'm so annoyed that there isn't an easy way of disabling fel
yoq has quit [Remote host closed the connection]
<smaeul>
wrt SPC, the "unlock everything" function is 0x2d50, and that proves there is indeed a SPC at 0x3008000
<smaeul>
apritzel: I don't think the eGON can be any bigger, it's the TOC0 file that contains it which can use all of SRAM A1 + SRAM C