21 Feb
2024
21 Feb
'24
12:24 a.m.
On Sun, Feb 11, 2024 at 10:07 Undescribed Horrific Abuse, One Victim &
Survivor of Many <gmkarl@gmail.com> wrote:
> i plan to resume my day now but at
> https://tinyhack.com/2021/01/31/dissecting-a-mediatek-bootrom-exploit/ it
> says the bootrom exploit is very simple and “This guide will try to guide
> beginners so they can add support for their own phones.”
>
2024-02-20 1732-0500
tinyhack.com “a hacker does for love what others would not do for money”
- author unbricked a xiaomi phone using an undocumented exploit they found
- links to discoverer (Xyz), implementor (Choasmaster) and initial
preexisting one
Xyz: https://blog.xyz.is/
Chaosmaster: https://github.com/chaosmaster
preexisting: https://github.com/amonet-kamakiri/kamakiri/
- allows unsigned code execution in the bootrom, which provides to
read/write all regions and storage
- only snippets of decompilation of the bootrom are shown to respect
mediatek rights
. Bricking my Phone and understanding SP Flash Tool
- xiaomi phones are cheaper, common in Thailand author’s country, and easy
to unlock
- they come with different chipsets. mediatek bricks easier.
- mediatek has added boot security functions
https://www.xda-developers.com/xiaomi-edl-unbrick-authorized-mi-accounts/
https://medium.com/swlh/modding-the-redmi-note-8-pro-an-adventure-e473e84d4d14
- SLA Serial Link Authorization, DAA Download Agent Authorization, or both
- SLA is in the bootrom, DAA is in the user’s provided signed DA
- Loading a custom DA that bypasses authorization requires bypassing SLA
. MTK Bypass
- luckily https://github.com/MTK-bypass published after above
- edit device.c to add chipset
- find addresses to add to file, mostly in the chip’s bootrom
- BROM proto docs, partial
http://www.lieberbiber.de/2015/07/02/mediatek-details-soc-startup/ (1 link
deep)
https://blog.oxygen-forensic.com/support-for-mediatek-devices-in-oxygen-forensic-detective/
(karl has reversed this too via software usb sniffing iirc)
- Chaosmaster published general brom dumping payload
- addresses needed are:
comms
:: send_usb_response
:: usbd1_put_dword
:: usbd1_put_data
:: usbd1_get_data
:: uart_reg0 (in public linux kernel)
:: uart_reg1 (in public linux kernel)
auth bypass
:: sla_passed
:: skip_auth_1
:: skip_auth_2
- use generic dumper and disassemble firmware
- compare its code to find more addresses
https://github.com/chaosmaster/bypass_payloads
- author used cli tool called “binary ninja” unaware of github repo to
reverse the dumper, loaded at 0x0
- i think it says the tool uses binary string searching for prolog bytes to
find the address of a function in the brom
- looking at the decompilation, i think that’s a rough simplification that
is good enough
- author used ghidra to verify address was correct function in the bootrom
by comprehending its behavior
-> note: both binary ninja and ghidra are nowadays producing full
decompilations into obscured C
- the send_dword function collected sendbyte and wait from a
function_pointers structure, iterated 4 bytes and passed them to sendbyte,
then called wait
- further disassembly analysis shows which other functions needed are in
different offsets in function_pointers
- usbd1_put_dword can be substituted with usbd1_put_data in the exploit to
reduce needed addresses
- send_usb_response was hard to find. it takes 3 non-pointer parameters,
and must be called prior to a usb data send.
- sla_passed, skip_auth_1, and skip_auth_2 are global vars, not functions
- author searched brom for handshake bytes A00A5005 to find where command
selection is performed after (one for usb one for uart)
it might be helpful to try to do this alongside the example disassembly
pictures, to stay with it
- for author, the function to process commands was 2 after the one to
handshake. contains big classic switch case operation, which sounds normal
in firmware for author.
- the exploit code uses get_target_config 0xd8 to read the global auth
values over usb, so the branch 0xd8 is inspected and its output generation
compared with the bitmasks used in the exploit code to find the gvar
addresses.
- secure boot is first bit, then sla, then da
- sla involves two variables, so the called function is cross-refd in
ghidra. access proceeds either if sla is disabled or passed, so an or
condition identifies the other variable:
> is_sla = bit_is_sla();
> if ((is_sla == 0) || (*sla_passed != ‘\0’)) {
- daa involves three variables. the daa bit retrieval function is inspected
and comprehended. it calls a subfunction that uses the two variables:
> if (*(int *)(skip_auth_1 + 0xc) != 0) {
> return *(int *)(skip_auth_1 + 0x14);
. How the BootROM Exploit Works
- the protocol allows a data upload
- the usb control transfer handler blindly indexes a function pointer table
https://www.beyondlogic.org/usbnutshell/usb4.shtml
- it indexes a value*13
- the array value is unknown, but most devices have a 0x100a00 entry
- the value can be bruteforced to invoke the payload
- experimentation may be needed as the 0x100a00 does not always work
- a simple restarting payload is provided to ease finding address and
control values
. Addendum
- the generic dumping utility is at
https://github.com/chaosmaster/bypass_payloads/blob/master/generic_dump.c
It looks to me like if you want more information, to review the chaosmaster
and xyz sites.