Root Boox Note Air 3C

[kyokugen]

Originally Posted by Renate

It's pretty similar to this thread.
Of course you start with the the correct update.upx

Where do I get the right update.upx?

[Renate]

Originally Posted by kyokugen

Where do I get the right update.upx?

In the link in Post #2

[SuiVu1fa]

How do you get the link to the `update.upx` for Note Air 3C? There is an update now. Last time, I got the link from packet sniffer, but there should be a better way.

Furthermore, is it possible to sideload `update.upx` from the one downloaded on the computer? Thanks.

[dcarvil]

Originally Posted by SuiVu1fa

How do you get the link to the `update.upx` for Note Air 3C? There is an update now. Last time, I got the link from packet sniffer, but there should be a better way.

Furthermore, is it possible to sideload `update.upx` from the one downloaded on the computer? Thanks.

Run this query, then look for the link in downloadUrlList.

http://data.onyx-international.cn/ap...t%22:%22%22%7D

Run these commands to install it.

adb push update.upx sdcard
adb shell am start -a onyx.settings.action.firmware

[jlark]

So, I'm trying to root this thing. It got recently upgraded to 3.5.4: NoteAir3C_2024-09-10_21-41_3.5.4_1a0fe4e9b.

I could not find any EDL loader that works. I'm on Linux. Tried everything that could make sense, it either errors straight away ("Mode detected: error"), or breaks somewhere soon enough:

$ ./edl/edl --loader $l --memory=UFS printgpt
Loading Loaders/lenovo_motorola/001b80e102e80000_8b2d1c830d9d8576_fhprg_moto_g52.bin
Capstone library is missing (optional).
Keystone library is missing (optional).
Qualcomm Sahara / Firehose Client V3.62 (c) B.Kerler 2018-2024.
main - Using loader Loaders/lenovo_motorola/001b80e102e80000_8b2d1c830d9d8576_fhprg_moto_g52.bin ...
main - Waiting for the device
main - Device detected :)
main - Mode detected: sahara
Traceback (most recent call last):
  File "/home/john/Work/android-tools/./edl/edl", line 393, in <module>
    base.run()
  File "/home/john/Work/android-tools/./edl/edl", line 293, in run
    version = conninfo.get("data").version
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: type object 'req' has no attribute 'version'

Tried with and without "--memory".

So I decided to go straight for root from the official update.upx:

$ fastboot flash boot magisk_patched-27000_bucD7.img 
Sending 'boot_b' (98304 KB)                        OKAY [  2.700s]
Writing 'boot_b'                                   FAILED (remote: 'unknown command')
fastboot: error: Command failed

Is this some "upgrade" brought along by the 3.5.4, or is there something special about my setup?

Know of a loader that works?

Something else I should try?

Note that I'm pretty technical.

Thanks

[Renate]

Originally Posted by jlark

Writing 'boot_b'                                   FAILED (remote: 'unknown command')

fastboot has been chopped down and now does not do anything useful.

Do not use a Motorola loader. That _g52.bin file is restricted. Even if you got it working it would not be able to access all of flash. (Yes, I suggested it previously, but I can learn stuff in a year.)

The thing is, you're not bound by the hash so the possibilities is larger. In such cases I run an automated trial and can try 1000 loaders in 20 minutes. But I don't have one of these NoteAir3C.

Try https://github.com/bkerler/Loaders/t...eneric/qcm2290

[jlark]

@Renate, thanks for the reply.

Originally Posted by Renate

Do not use a Motorola loader. That _g52.bin file is restricted. Even if you got it working it would not be able to access all of flash. (Yes, I suggested it previously, but I can learn stuff in a year.)

It would be nice if something would happen though.. anything other than an exception.

Originally Posted by Renate

Try https://github.com/bkerler/Loaders/t...eneric/qcm2290

Nope

Originally Posted by Renate

The thing is, you're not bound by the hash so the possibilities is larger. In such cases I run an automated trial and can try 1000 loaders in 20 minutes. But I don't have one of these NoteAir3C.

So, I did a brute force on everything qualcomm:

$ shopt -s globstar
$ for l in Loaders/qualcomm/**/*.{bin,elf,mbn}; do
> echo "== Loading $l"
> ./edl/edl printgpt --loader $l
> echo; echo
> sleep 1
> echo "== Loading $l / UFS"
> ./edl/edl printgpt --loader $l --memory ufs
> echo; echo;
> sleep 1
> done

Aaand... nothing. It consistently detects the device and breaks early in python code:

main - Device detected :)
main - Mode detected: sahara
Traceback (most recent call last):
  File "/home/john/Work/android-tools/./edl/edl", line 293, in run
    version = conninfo.get("data").version
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: type object 'req' has no attribute 'version'

I inspected that `conninfo.get("data")` but I didn't get very far...

I could do a script to run unattended on /everything/. But I somehow feel I won't get differing results.

@Renate such brute force works for you without any need to reset the connection between attempts with different loaders?

[jlark]

Originally Posted by Renate

fastboot has been chopped down and now does not do anything useful.

That is just so nice. One must not interfere with the chinese communist party's data mining operation.

I wonder if the know-how within decryptBooxUpdateUpx could be used for the reverse operation: to build a signed update.upx, or the encryption is asymmetric.

[Renate]

Originally Posted by jlark

Such brute force works for you without any need to reset the connection between attempts with different loaders?

Nope. The ROM bootloader (PBL) is fairly fragile and does not respond correctly after a failed loader attempt.

You need to do a full reset between trials.

But the good news is, most (all?) Firehose loaders don't care about batteries and certainly the PBL has no idea of what a battery is. That means you can run basic operations with PBL and loading a Firehose loader without the battery connected. Of course it has to get power over USB. But it doesn't need much, just 100 mA or so (vs. the 1000 mA or more for booting the full multicore OS).
So if you have a software controlled relay (or software power supply) you can use it to disconnect the USB power for a second to do a full reset.

Note that I am not claiming that flashing a whole device while running only on USB without a battery is the best idea.

AES is symmetric. You can turn a zip into a upx. But that won't get you much.

[jlark]

Originally Posted by Renate

You need to do a full reset between trials.

So if you have a software controlled relay (or software power supply) you can use it to disconnect the USB power for a second to do a full reset.

Whoah :)

This doesn't scare me, and I bet I could come up with something using a microcontroller... I'm just not all that fond of taking the thing apart. :)

(but I do have a heatgun :) )

I'll write a script then to monitor for its appearance, put it into edl, monitor again, and then try the loader. And do much manual shutting down.

Do you have any hints for making my life easier? Try only ufs? I'll focus on the “obvious“ loaders in the beginning.

Originally Posted by Renate

AES is symmetric. You can turn a zip into a upx. But that won't get you much.

Why say you that, what hurdles are you thinking of? I'd expect the reverse process for building an update package to be fairly straightforward (for one familiar with the code, anyway).

P S.: thanks so much for the input. very valuable.

[Renate]

Originally Posted by jlark

This doesn't scare me, and I bet I could come up with something using a microcontroller...

I'll bet that you could. If you have a 9 pin serial port you could use that too. By enabling and disabling "break" you have one bit control. You could also programmatically control the other two control signals for three bits total. You need a level shifter/relay driver, but that's only a transistor. You could do the same with a USB UART.

I bought an old TinkerKit DMX controller with 4 relays for $5 and rewrote the software to be a USB controlled relay set.

I also have a little homebrew CV/CC power supply that is USB controlled. I can use that to generate the 5V for USB Vbus.

Oh, I forgot to mention. You have to jumper the EDL test points so that it will come up in EDL mode all the time. Finding the EDL test points is a big theme. In olden days Onyx made it obvious. Now they are tricky. Compare the test points of the Poke3 (reed.jpg) vs. the Poke5 (reed3.jpg). Both of these have a reed magnetic switch on them so that I can always get to EDL without opening the cases (again).

You could also just use the power button. You could mechanically press it. You could electrically press it. It's easy enough to find with a DVM. Moreover, they always have an accessible test point for powering up the board by itself.

Worst case, 10 second press of power button, 30 second normal boot up to system, "adb reboot edl" to get to edl mode, loader attempt, repeat.

Originally Posted by jlark

Try only ufs?

Loaders have some combination of support for eMMC, UFS, NAND, NOR. But you don't have to specify that until after you get the loader loaded. Loaders also support some subset of processors AND some subset of power management ICs. So without the limitation of PK hash, the field is wide open.

Originally Posted by jlark

Why say you that, what hurdles are you thinking of?

For most folks, simply installing Magisk is the easy way out. If you're going to be difficult (I am) you can patch the kernel, resize internal partitioning of super, unshare system & vendor, rewrite sepolicy...