- links to discoverer (Xyz), implementor (Choasmaster) and initial preexisting one
- 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.
. MTK Bypass
- compare its code to find more addresses
- 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
- 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
It looks to me like if you want more information, to review the chaosmaster and xyz sites.