CAT B35 jailbreak and rooting: a story of a single bit (+ bonus)

[Luxferre]

As we well know, CAT B35 has a working firehose loader, so, using the right tooling (see the guide in the README), we now have no issues with an open-source and cross-platform way of manipulating its partitions - reading, erasing and flashing. So, how to convert this power into a convenient jailbreak for this device? Let's find out.

First things first: boot partition needs to be patched. It's a normal Android boot partition so a tool like abootimg can be used, and standard cpio/gzip can be used to modify its internal structure. So, three changes were made in the boot.img:

- in the root /default.prop, ro.debuggable property was changed from 0 to 1;

- in the root /default.prop, ro.adb.secure property was changed from 1 to 0;

- the adbd binary itself was replaced with a rooted one (the same used in Gerda Recovery, for instance).

Here is the ready patched boot.img corresponding to the current CAT firmware version (LTE_010812O_B35_43): https://cloud.disroot.org/s/N9LiH3Lqnxciqin/download

(of course, don't forget to backup your original boot partition before patching)

So, the low-level things are sorted out, now we need to find a way to enable the developer menu itself. The simplest way to do this was to patch the runtime setting developer.menu.enabled in the userdata partition image. The only problem was that, unlike system partition, this setting in userdata resides in some kind of database. So, to avoid unpacking, searching, patching and repacking, we can resort to dirty direct patching of a dumped userdata partition:

1) open the userdata partition dump in a hex editor;

2) look for the developer.menu.enabled string in the dump;

3) find the closest faultValu string fragment next to it;

4) measure exactly 8 bytes from that last u letter (the target byte should be 00) and change the value of that byte from 00 to 01;

5) rewrite the userdata partition.

Yes, we change a single bit in the huge image that weighs over 1GB, and after the device reboot the developer menu appears where it should: in the Settings - Device - Developer. You get both rooted ADB and DevTools access.

Now, to ensure and get permanent privileged webtools access, just install Wallace Lite via either Pale Moon's WebIDE, recent KaiOSRT or kdeploy, press that damn # key and perform the privileged factory reset. The userdata partition will obviously be wiped, but Developer menu will be preserved, as well as the root ADB access. But you will still probably need to patch the boot partition back in case you want factory OTA updates - luckily, with the EDL access that's not a problem if you have the backups.

By the way, if you patch the userdata without patching boot, you'll get timed reboots every time you enable the debugging mode, because the adb access will be unauthorized.

And yes, you'll become able to run *#testbox# and even *#*#debug#*#* code, but you'll be only able to turn it on with *#*#debug#*#* - in case you want to turn it off, you'll need to do that from the menu.

And now...

Bonus!

Unfortunately, in terms of EFS, CAT B35 seems to be much more secure. You can't just go and modify any partition directly. The EFS seems to be evenly distributed across volatile modemst1/modemst2 and persistent fsg partition, which in this case is not a TAR archive but an encrypted container in Qualcomm's proprietary format (just like modemst1/modemst2 but with a bit different signature). However, guess what happened when I erased modemst1, modemst2, fsg, rebooted, realized that I had no radio connection available and then reflashed just fsg? The connection was restored but the IMEIs were lost. Not zeroed-out but deleted completely. Even AT commands couldn't read them.

And you know what happens when IMEIs are emptied in the Qualcomm architecture? Their write protection is lifted. So I tried to restore the IMEI at least for the first SIM by forging the following HDLC packet and sending it to the diagnostic port (enabled by default as part of CAT's composite device):

27 26 02 08 0a 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

(after this also a CRC and the trailing packet marker follows, I'm just showing the packet payload)

And... it works as expected. I think a POC IMEI changer in Python will follow, but we need to find a way to update the NV item 550 for the context of SIM2.

Hopefully all this info will be useful to B35 users. Have fun!

[Luxferre]

Here's the patched boot for the most recent CAT software update from June: https://cloud.disroot.org/s/8SMgrTtD8zBMQDk/download

[Luxferre]

So, after a bit of WriteDualIMEI utility disassembling and 5 hours of fiddling around with probably the most suffering radiomodule I have :), the format of dual-SIM IMEI manipulations through diagnostics port was finally found. Internet has no documentation whatsoever, so this will probably be world's first (as usual...)

So, first things first: the modemst1 and modemst2 partitions must be erased before any writing, otherwise the 07 error code (access denied) follows in the HDLC response.

The format itself is quite simple - for instance, these commands (not including HDLC footers with CRC) set the IMEI of SIM1 to 9999999999994 and of SIM2 to 111111111111119:

4b 30 02 00 26 02 00 00 08 9a 99 99 99 99 99 99 49

4b 30 02 00 26 02 01 00 08 1a 11 11 11 11 11 11 91

So, let's look at the format:

- 4b: start of extended subsystem command;

- 30: specifies that we're querying the NV subsystem;

- 02 00: NV item write subcommand;

- 26 02: NV item number (little-endian representation of the number 550, and this item is known as the storage for IMEI);

- 00 00 or 01 00: little-endian context ID - the value of 00 00 corresponds to SIM 1, 01 00 corresponds to SIM2;

- 08 xa xx xx xx xx xx xx xx - IMEI value in Qualcomm's format (to convert an IMEI to that format, prepend 80a to the IMEI string and then swap each pair of characters).

And these commands will read both IMEIs:

4b 30 01 00 26 02 00 00
4b 30 01 00 26 02 01 00

Explanation:

- 4b: start of extended subsystem command;

- 30: specifies that we're querying the NV subsystem;

- 01 00: NV item read subcommand;

- 26 02: NV item number (little-endian representation of the number 550, and this item is known as the storage for IMEI);

- 00 00 or 01 00: little-endian context ID - the value of 00 00 corresponds to SIM 1, 01 00 corresponds to SIM2.

When successful, the read HDLC buffer will be filled with the appropriate IMEI values.

P.S. If B35 reboots two times after the update, that's normal. Ideally the operation should be performed from the offline mode (one can swtich to it with 29 00 command and then reset the phone with 29 02 command), but this will also do. Probably I'm going to create a POC utility in Python to achieve this functionality (like the famous qcommand but more high-level).

[Roland Attila Kett]

Hi!

I have downloaded latest _B35_53 boot image from my phone. Can You patch it?

[Ivan Alex HC]

Should be enough to follow this guide (without patching the boot partition)

https://sites.google.com/view/bananahackers/install-omnisd/patching-data

[PuriShnit]

By patching userdata, you can get adb working, but without root. (maybe installing adb-root.zip would work on CAT...?)

Patching boot should be quite simple, as guided by Luxferre. (For Windows, use any Android Kitchen).

--
You received this message because you are subscribed to the Google Groups "comp.mobile.nokia.8110" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bananahacker...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bananahackers/7b1b0a9f-26c8-4d70-a60e-213d07246a8d%40googlegroups.com.

[Ivan Alex HC]

Yes, using a root app it works. Then just patching data with the missing adbkey should be enough.

[Luxferre]

Ok, so if you patch adbkey into userdata, you can definitely install the Wallace Lite app and then perform privileged reset or rooting or whatever.

But on Mac, for instance, this would require additional utilities like osxfuse+ext4fuse and make_ext4fs.

And if we have to use ext4 mounting anyway, we can also locate the DB file with developer.menu.enabled setting and perform its patching as well instead of pathing the raw image.

I'll get some more information soon about which file it is.