Life is definitely full of surprises sometimes. I’m going to talk about a method that allows to safely jailbreak (not root though) any KaiOS device - and by jailbreaking, I mean enabling the way to install third-party apps, to use the Developer menu under Settings - Device section, and to enjoy unrestricted WebIDE access to the system processes and allowing to install application packages in an autonomous fashion with utilities like OmniSD.
Any KaiOS device? Sounds too good to be true. Well, this method by itself really works for any phone - no strings attached, but the caveats start appearing when you try to apply it to a particular device. This is what most of the article will be about.
But before we start, let me make one thing perfectly clear: this post, as well as this whole blog, is not about ready-made solutions. It’s about fundamental research and occasional personal rants. So, if you’re looking for a way to jailbreak or root a particular device, you’ve come to the wrong place. But if you’re willing to find out more about the inner workings and the tech behind them, then read on.
Without futher ado, here is the method itself: in the root of the cache partition, put the __post_reset_cmd__ file (notice the double underscores around the name) with the root string as its contents. After the reboot, the Developer menu will appear in Settings - Device.
Is that it? Yes, that’s all about this method (which I called “B2G cache injection jailbreak”). The code snippet that makes this possible is in the B2G codebase itself and is behind the famous navigator.mozPower.factoryReset('root') call, so it works on really any KaiOS device regardless of its vendor or hardware platform. I didn’t lie about that. Moreover, it had been there for all these years. But you might already have guessed where the tricky part is. The tricky part is being able to write to the cache partition from the state of fully locked-down phone. This can range from easy to almost impossible.
The easiest scenario is when you somehow already have the ADB root access but don’t have the Developer menu. In this case, just run:
1 | echo 'root' > /cache/__post_reset_cmd__ |
And you’re all set.
But this is a rare situation. Usually, you don’t have that kind of access. However, this is still possible if you have the access to the official flashing tool for your hardware, EDL firehose (for Qualcomms) or Fastboot mode for your device (fastboot flash cache command must be unrestricted there). In this case, prepare a 10MB ext4 image with this file in the root and just flash it onto the cache partition. If you can’t prepare it yourselves, you can use cache-jb.img file from this archive. Then you must boot normally and ensure that both “ADB only” and “ADB and DevTools” mode give you necessary connection, then reboot into the recovery and use “wipe cache partition” in it to restore the normal size of your cache. After that, the mission is complete.
But what if you don’t have the access to the official tools and your device doesn’t have any key combination to enter Fastboot? Here’s where the platform differences come into play. For Spreadtrum/Unisoc, I honestly don’t know what to do (as of now) since I don’t have any Unisoc-based KaiOS device yet. For Qualcomm, your only chance is to find the correct firehose binary for EDL mode - there’s not much else you can do. For MediaTek, however, there seems to be quite a universal way to put any MTK device into Fastboot mode, regardless of the key combos it has. And most probably, the fastboot flash cache command will be unrestricted there.
So, what do we need to enter the Fastboot mode in, say, MT6572 KaiOS phone? The ready recipe (alongside the script) is in the same archive but I’m going to focus on the theory here. Upon powering up, the first thing that MediaTek chipset runs is the BootROM (BROM) which is baked into the chipset itself (similar to PBL in Qualcomms). Then, the first thing NOT baked into the chipset is run: a preloader (similar to SBL in Qualcomms but not quite). The preloader opens a serial port (I’m calling it a bootport for convenience) over USB for the brief moment before further passing the control to the actual bootloader (U-Boot etc). Remember: Fastboot is implemented in U-Boot but the bootport is opened by the preloader. This is a very important bit.
While the bootport is open, the preloader can accept either the binary sequence to enter the Download mode (hex: a0 0a 50 05), which is “normal” flashing mode, or some ASCII string sequences to enter some other modes. If you have the preloader binary file for your device, you can easily see these string sequences. I’m using Sigma S3500 sKai as a reference, and I had seen the following command sequences that make any sense:
METAMETA: enter the META mode (the commands still not reversed);FACTFACT: enter the Factory mode (the test menu flashed on factory);FACTORYM: enter the ATE Signaling Test mode (some scary stuff);FASTBOOT: enter the Fastboot mode (the thing we need);ADVEMETA: perform a normal boot but with some advanced META debugging.
And we just start spamming one of these strings on the port until we get the correct preloader response. This response happens to be READY + last three letters of the commands reversed. So, if we send FASTBOOT, the bootport will respond with READYTOO, if we send METAMETA, the port will respond with READYATE, and so on.
So, spamming the string FASTBOOT on the bootport until we get READYTOO response is really all we need to put any MediaTek KaiOS device into Fastboot mode. And then we can act according to the above information and flash the patched cache image.
Now, I’d like to reply to this comment:
Just be careful here - hijacking recovery service is pretty common way to root a device.
First, he was writing this as if rooting is something bad - in the Bugzilla of a supposedly open OS! Second, just no: in general, jailbreaking the device to get the privileged developer access doesn’t move you even a bit closer to the root access. These two mechanisms are totally unrelated. Moreover, old and tested temporary rooting tricks like using engmodeExtension.startUniversalCommand call don’t work anymore on some new MediaTek-based devices, so they require patching the boot partition in the proper way and reflashing it via Fastboot (which is not a safe procedure anymore) and only then you can get any ADB root access. So, proprietards have little to worry about this jailbreaking method anyway.
I think this discovery will open much more possibilities for large amount of newcoming KaiOS devices, most of which are based on MediaTek chipsets. I believe this can be a new page in the history of KaiOS jailbreaking and can have much more impact on the user-vendor relationship in the future. This was worth waiting almost two years, and this was worth returning to.
The show must go on!