13:26 <f_> phh: yep, it was completely encrypted

13:26 <f_> I've been hard at work reversing and inspecting the bootROM for clues lately

13:27 <f_> There is a function "auth_image()" which takes care of running other functions that check the @AML header.

13:27 <f_> There is an fip_check() function, which is being ran, which checks if the header is valid. I concluded that function runs on decrypted data as it straight looks for e.g. the "@AML" magic.

13:28 <f_> In the end, this is what I found (simplified):

13:28 <f_> if (readl(0xc8100228) & 0x10000000) { decrypt(...) }

13:29 <f_> a dump of 0xc8100228 is printed over UART on bootup, it's that "FEAT:..." thing. And indeed, on the TV stick, it is not == 0.

13:40 <f_> Now. I can run unsigned code in Secure World thanks to amlogic-usbdl, so I could've just tried reading that BL2 and decrypting, all by running the bootROM's functions.. But TBH I'm a bit skeptical about running random functions I have not completely figured out.

13:43 <f_> anyway, tl;dr BL2 is encrypted with AES-256-CBC to no one's surprise, and also to no one's surprise the key and IV are stored in OTP memory

14:28 <f_> (there is a copy of the OTP memory also, stored at 0xd9013c00)

15:40 <f_> Btw while I was reversing the bootROM I also started writing some notes, could be useful for troubleshooting boot or something

15:41 <f_> https://git.vitali64.duckdns.org/misc/reversing-gxbb-bl2.git/tree/docs/gx-bootrom.md

16:26 <chewitt> f_ nice findings :)

16:27 <f_> chewitt: heh, I'm probably not the first one :p

16:27 <chewitt> no, but you're more likely to do something useful with them

16:27 <f_> ;)

16:32 <f_> and there we go, managed to dump acs

16:32 <f_> Once the BL2 image is decrypted things become easy :p

16:42 <f_> > .ddr_set_version = 2,

16:42 <f_> o.O

16:47 <f_> > NOTICE: BL3-1: Built : 17:28:39, Apr 1 2021 < happy april 1st all

16:48 <f_> 🤣

17:11 <f_> Now in my dump I see some stuff I've never seen before, @KEY?? @KMX?? second @AML before BL2??

17:13 <f_> still I call that progress :p

17:13 <f_> Oh also it looks like BL3* are encrypted too

17:14 <f_> and apparently not with the same kay

17:14 <f_> Will require more digging ^^

17:14 <f_> But at least I now have a decrypted BL2.. the rest I don't really care all that much about

17:15 <f_> (and when I say "BL3* are encrypted" I mean also the AMLC header is encrypted - not even gxlimg can recognise them)

17:46 <exkc> f_:

17:47 <exkc> what is AML_RES

17:47 <f_> "resources"?

17:47 <exkc> it is from rsv.img

17:48 <f_> where?

17:48 <exkc> rsv.img

17:48 <f_> Yes, where did you fetch it?

17:48 <exkc> newer 9 ota zip

17:49 <exkc> or older a9

17:49 <exkc> idk which a9

17:49 <exkc> i did that a while ago

17:51 <exkc> yeah it is lastest a9

17:51 <exkc> i sisnt change file name of the zip

17:51 <exkc> *didnt

17:51 <exkc> acc to that and https://xdaforums.com/t/official-stock-firmware-thread-mi-box-mdz-16-ab-and-mdz-22-ab.4241475/

17:51 <exkc> it is the latest one

19:26 <f_> CyReVolt: gentle ping: are you aware of amlogic-usbdl? https://fredericb.info/2021/02/amlogic-usbdl-unsigned-code-loader-for-amlogic-bootrom.html

19:28 <f_> The blogpost says it affects S905D3[G], but it actually also affects most older 64-bit Amlogic SoCs, so GXBB, GXL, are affected and G12A/B and SM1 should also be affected (although I did not test). No idea about AXG though.

19:28 <f_> Well. S905D3 *is* SM1..

19:36 <f_> Maybe I should probably work on the DTS instead of trying to run funny stuff in secure world on a secureboot-enabled device

19:37 <f_> "dc:~$ cat /proc/cmdline" => "console=tty0 console=ttyAML0,115200n8 reboot_mode=cold_boot <...> androidboot.veritymode=enforcing androidboot.verifiedbootstate=green" :D

20:31 <CyReVolt> <f_> "Daniel aka CyReVolt 🐢: gentle..." <- I think I'd seen it, yea. :)

20:33 <f_> CyReVolt: nice

20:41 <CyReVolt> I'm currently on other platforms again... SG200x (DRAM hates me...), BL808 (we have PSRAM up and working), and K230 (works well now :))

20:57 <f_> CyReVolt: gotta boot them all

21:28 <CyReVolt> haha x)

21:28 <CyReVolt> btw I moved all my *_loader tools over to

21:28 <CyReVolt> https://github.com/platform-system-interface/

21:52 <f_> Awesome

21:52 <f_> https://github.com/platform-system-interface/aml_boot/issues/1#issue-1994498834

21:53 <f_> CyReVolt: I know on GXL (and I think GXBB too) a copy of the OTP data is available at 0xd9013c00

21:54 <f_> I know it's the efuse because that's where the bootROM fetches stuff related to it and also where I found xiaomi's AES key x)

21:54 <f_> Some GPL sources also mention 0xd9013c00 as "efuse mirror" or something

21:54 <f_> CyReVolt: Actually, I think I remember seeing the exact same thing on the newer S905D2's bootROM. One second.

21:55 <f_> yep. It's 0xfffe7c00 on S905D2+

21:55 <f_> Though if I were you I wouldn't try writing to them

21:55 <f_> doing so is pretty risky Imo

21:56 <f_> CyReVolt: Finally, I remember seeing stuff related to efuses in the amlogic u-boot source code. Registers and such.

22:02 <f_> specifically in this repo https://github.com/libre-computer-project/libretech-amlogic-boot but there's no reason why it wouldn't be in the other amlogic-u-boot repos

22:04 <f_> https://github.com/libre-computer-project/libretech-amlogic-boot/blob/master/fip/stool/signing-tool-gxl-dev/efuse-gen.sh also looked slightly interesting to me though I didn't scan it entirely

22:08 <f_> But from what I saw the bootROM usually seems to work with that copy of the OTP instead of the OTP directly. But there might be places I overlooked in the bootROM.

22:08 <f_> (the one at 0xd9013c00 or 0xfffe7c00)