# MTKClient talks to a MediaTek bootrom and expects different rules per chip > MTKClient is a reverse engineering and flashing utility for MediaTek devices. Newer chipsets use a patched V6 bootrom and require a different setup path, while Windows, Linux and macOS have separate installation guidance. **bkerler/mtkclient** — Mediatek Flash and Repair Utility - Repository: https://github.com/bkerler/mtkclient - Stars: 1,361 · Forks: 273 - Language: Python - License: GPL-3.0 - Published: 2026-10-17 · Updated: 2026-10-17 · Language: en - Canonical page: https://hysenlabs.com/projects/bkerler-mtkclient ## What the tool does and what it assumes The description in pyproject.toml is Mediatek reverse engineering and flashing tools, and the README's own summary is blunter: an mtk tool for exploitation, reading/writing flash and doing crazy stuff. The mechanism starts with the device. Once the mtk script is running, you boot the phone into brom mode by powering it off, holding either volume up plus power or volume down plus power, and connecting the phone. Once the tool detects the device, you release the buttons. For devices that use brom mode, that handshake is the entry point. Two platform facts follow immediately. On Windows you need the stock mtk port and the usbdk driver installed. On Linux a patched kernel is only needed when using old kamakiri, and the README explicitly excepts read/write flash from that requirement. The package is a Python project with a console entry point and a separate GUI. The project metadata defines four scripts: `mtk` mapped to `mtkclient.mtk:main`, `stage2`, `da_parser` and `brom_to_offs`, plus a `mtk_gui` in the gui-scripts group, which is the convention for a graphical entry point that should not shadow the console one. The GUI exists because the work involves a lot of state, and the credits name a specific person for the GUI, design and fixes. ## Newer chipsets need a different path entirely The most useful section of the README is the chipset list, because it tells you the tool is not one program with one procedure. For MT6781, MT6789, MT6855, MT6886, MT6895, MT6983 and MT8985, the chips use a new protocol called V6 and the bootrom is patched. For those, you need the `--loader` option with a proper loader from the Loaders/V6 directory. The bootrom will not work, so you use preloader mode with no hardware buttons pressed at all, just connecting the phone. There is a further wrinkle: on some devices preloader is deactivated, and it can be reactivated by running `adb reboot edl`. So there are two distinct entry modes in one tool. Older devices go through the volume-button-and-power brom handshake; the newer ones go through preloader with a loader binary, no buttons. A guide that only describes the first will simply not work on a current phone. The configuration surface is also explicit. Chip details and configs live in `config/brom_config.py`, and unknown USB vendor and product IDs for autodetection go in `config/usb_ids.py`. Those two files are where you add a device the tool does not recognise, which is the actual extension point for someone bringing up a new model. ## Installation is four documents, and one of them is a Live DVD The README does not carry installation steps itself. It links to Linux and macOS installation hints in `README-INSTALL.md`, Windows hints in `README-WINDOWS.md`, and an automated Windows installer maintained in a separate repository, codefl0w/mtkclient-windows-installer. Usage instructions live in their own `README-USAGE.md`. So the documentation set is split by concern rather than by one document with sections, and each of these has a Chinese translation alongside it at the repository root. For people who would rather not configure anything, there is a Live DVD based on Ubuntu with the credentials documented in the README: user `user`, password `user`, based on Ubuntu 22.04 LTS, with separate downloads for the general image and a V6-specific one. Publishing default credentials in the README is at least honest about it, and the Live DVD is a convenience for people running it locally on their own machine. It is still worth saying plainly: an image that boots with user and user should not be put on a shared host or a network where anyone else can start it. The runtime dependencies are small and tell you what the tool talks to. `pyusb` is the USB layer, `pyserial` is serial, `pycryptodome` and `pycryptodomex` handle the crypto involved in the flash protocol, `mfusepy` is for eMMC, `colorama` for terminal output, and `shiboken6` with `pyside6` for the Qt-based GUI. The requirements.txt file adds the disassembly and emulation libraries that are useful for the analysis side rather than the flashing side: keystone-engine, capstone and unicorn, alongside keystone. ## When something goes wrong, the log is the deliverable There is a short section on reporting issues that is worth internalising as a workflow rule: if you have issues, send logs and full console details, and run the tool with `--debugmode`, which writes to `log.txt`. For a tool that depends on USB enumeration, driver state, button timing and a bootrom protocol, logs and full console details are useful additions to a bug report. The failure surface is genuinely wide. Drivers on Windows, a patched kernel on Linux for some operations, which chipset generation the device is, whether preloader is still enabled, whether the loader binary matches the chip, and whether autodetection knows the device's USB identifiers. Every one of those produces a different symptom, and the debug log is what distinguishes them. The repository also ships `examples/run.example` as a starting configuration, `shell.nix` for a reproducible shell, and a `mtkclient/` package with `Setup/` and `Tools/` directories alongside the top-level `mtk.py`, `stage2.py`, `mtk_gui.py`, `mtk_api.py`, `mtk_iot_api.py` and a TCP/IP client and server pair. Those last two are notable: `mtk_tcpip_client.py` and `mtk_tcpip_server.py` suggest the tool can be driven over the network rather than only over a local USB connection, which is the sort of capability worth understanding before enabling it on a network you care about. ## Versions, packaging and the licence The recent releases are v2.1.4.1 tagged as version 2.1.4 on 2026-03-18, v2.1.3 in February 2026 and v2.1.2 in January 2026. The last push was on 2026-10-12 and the repository is not archived, so work is landing between releases. The declared development status is `Development Status:: 4 - Beta`, which is the honest label for a tool that depends on undocumented bootrom protocols that vendors change. Packaging is Hatchling, with an sdist include list that says a lot about the shape of the project. Loader binaries are included from `mtkclient/Loader/*.bin`, preloader binaries from `mtkclient/Loader/Preloader/*.bin`, payloads from `mtkclient/payloads/*.bin`, Windows DLLs from `mtkclient/Windows/*.dll`, GUI images, and `Tools/*.py`. So the prebuilt loaders and payload binaries ship inside the distribution rather than being fetched at run time. The artefacts are opaque binaries you cannot inspect from the Python source alone. A wheel file for a device-flashing tool containing undocumented binaries deserves the scrutiny any binary deserves. The wheel also force-includes the top-level scripts `mtk.py`, `mtk_gui.py`, `stage2.py`, `Tools/brom_to_offs.py` and `Tools/da_parser.py` into the package namespace, which is how a repository with files at the root ends up importable as `mtkclient`. The licence is GPL-3.0, with a LICENSE file at the root and a classifier for GPLv3. The keywords in pyproject.toml are mediatek, mtk, flashing, reverse engineering and firmware. The credits list kamakiri for the original work, the linecode and heapbait exploits from chimera, Chaosmaster, and Geert-Jan Kreileman for the GUI. ## Conclusion Adopt MTKClient if you own MediaTek devices and need to read or write their flash for repair, custom firmware or research, and you are prepared to follow per-chipset instructions rather than a single setup path. Do not adopt it expecting a single procedure across chipsets, since the newer ones require the V6 protocol path with a loader and preloader mode instead of the hardware button combination. Verify first which chipset your device has, install the stock mtk port and the usbdk driver on Windows, and note that the Live DVD image shipped for convenience ships with the default credentials user and user, which you should change before putting it anywhere shared. ## FAQ ### How do I boot a MediaTek device into brom mode for MTKClient? With the mtk script already running, power the device off, hold either volume up plus power or volume down plus power, connect the phone, and release the buttons once the tool detects it. Note that newer chipsets do not use this path; they need the V6 protocol with the --loader option in preloader mode. ### Which chipsets require the V6 protocol in MTKClient? MT6781, MT6789, MT6855, MT6886, MT6895, MT6983 and MT8985. For those the bootrom is patched, so you need the --loader option with a loader from the Loaders/V6 directory, and preloader mode with no hardware buttons pressed. If preloader is deactivated you can reactivate it with `adb reboot edl`. ### What does MTKClient need on Windows and Linux? On Windows you need the stock mtk port and the usbdk driver, and there is a separate automated Windows installer repository. On Linux a patched kernel is only needed when using old kamakiri, and not for read/write flash. Installation details are in README-INSTALL.md and README-WINDOWS.md. ### How do I add a device MTKClient does not recognise? Chip details and configs go in config/brom_config.py, and unknown USB vendor and product IDs for autodetection go in config/usb_ids.py. When reporting problems, run the tool with --debugmode so the log is written to log.txt and include it with full console details. ## Sources - [bkerler/mtkclient on GitHub](https://github.com/bkerler/mtkclient) - [Issues](https://github.com/bkerler/mtkclient/issues) - [License: GPL-3.0](https://github.com/bkerler/mtkclient/blob/main/LICENSE) - [README](https://github.com/bkerler/mtkclient/blob/main/README.md) - [Releases](https://github.com/bkerler/mtkclient/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bkerler-mtkclient