New ADB challenge examples

[1alessandro1]

Hello, I will share here some hashes and some solutions, hoping maybe somebody with very powerful hardware / GPUs can take a look and try to reverse this function too.

Validity for each password has 5 minutes duration

AT+QSECCFG="adb_auth"
+QSECCFG: "adb_auth","geKH1jzO7dSHjd0pHIbIA9qX6TljyGWoSTkB1w3MPQgjugy5orLz7EC9mliUCl5qkGO/fbqSdq4HZoaBAUO/XHyGvWDITrf2R4PFQF0D7xHA8vXO745NXC4hA1tTsgQOIA2+Dj0dfE0v6Dy98Tysfp/ALhyLbnS6uL/lsRj5gU6lBm6ySSxPuH2FgKvgWs043kFTEhkbNGX7RBmPDg+RORcDmiLppwLiyZv2pZomNQLb9gnnaKf1VHfppfy+tCjZ4rnfOluS5aAAPVvehd7UFkbsdscqaADbkKwiNQ8+ncFjOSeskWRmpxNvYl54aF/Pr4A5HFqhZlcfDWpGMXytnA=="

OK
AT+QSECCFG="adb_auth","a684d27dba12ff99"
OK

AT+QSECCFG="adb_auth"
+QSECCFG: “adb_auth”,“CbESVXyE5GAgdWhVat/WF1kp8H7wlciDRj8WXl1wnw1JWv7l3J5pGQSs4t0qkDPi5h14ZcG9H/7P99Edw1aATc6J7LuWIAJ2GsbuAHeGVJUMDnndpzqLQk0Zgb3kGM6rkYpVtfNuc8j274g1WA3miYWgLyDYKEibndLv0o4GFQgjK3wFNoQ5C7fIlIfy2Q6NfApuCQSPq8DlX475niQFUqJrsWpBs9U1WUN1M6JyWaI8qiw5Lq0+loW1h/so04vgEqEe3ocmN2k810Vn0TgI9tkiauFHY67lBsrSFq25dH1jhinwcaTMkdYe5U+qlS+EJhJncOvCKdhmsPfHttXA8g==”

AT+QSECCFG="adb_auth","f029b5f3f6ae86b5"
OK

[CirnoT]

with very powerful hardware / GPUs can take a look and try to reverse this function too

Factorization of 2048-bit RSA would take more than "powerful GPU" :>

[1alessandro1]

I added the s at the end indeed

[clndwhr]

@1alessandro1 do you have the request times available?

[1alessandro1]

@clndwhr I might have found a way to bypass the entire adb 2048 bit challenge entirely... I need someone to test this on a RM551E-GL, @iamromulan do you have one to test?

[1alessandro1]

With the help of @stich86, looking at the library logic, to execute AT+QCFG="usbcfg" with the second to last bit set to 1, you need to have a file called .adb_enable set inside /data: this is what the function does when a successful unlock is made with Quectel's command (calculated by them)

In order for us to have ADB enabled by default you can unpack sysfs.ubi with ubidump, include a .adb_enable file inside /data and then reubinize the filesystem, replace it inside the RM551ER01A03/update folder, and adjust the md5.txt file accordingly

[1alessandro1]

If you want to test, please report if this works, after installing just run AT+QCFG="usbcfg",0x2C7C,0x0122,1,1,1,1,1,1,0

https://mega.nz/file/OXxSmZhK#GugJb-plo7PWchJYC3TCJUSORGFYCuChrrQ4gOiWRlo

EDIT: new link https://mega.nz/file/iahEnQqS#xHKi7YPI90WIjlhbdlGTkGa4tNeL-BVUxPCp3fnSlXI

[clndwhr]

Awesome! I was planning on this week breaking down the modem files in thing flash to see what Hayes command logic they have put in for this and some others things.

[CirnoT]

With the help of @stich86, looking at the library logic, to execute AT+QCFG="usbcfg" with the second to last bit set to 1, you need to have a file called .adb_enable set inside /data: this is what the function does when a successful unlock is made with Quectel's command (calculated by them)

In order for us to have ADB enabled by default you can unpack sysfs.ubi with ubidump, include a .adb_enable file inside /data and then reubinize the filesystem, replace it inside the RM551ER01A03/update folder, and adjust the md5.txt file accordingly

You can go level deeper and modify rawdata partition directly, to set appropriate USB modes and skip entire userland logic. The partition itself is binary representation of packed C struct alongside simple CRC. This partition is never updated during flash and contains some of the data such as VID, PID, PCIe config state as well as current security state and hashed security password (for secure debugging). The fact that it is not touched during upgrade is the reason why once enabled ADB debugging stays enabled even after flashing firmware. As added bonus, it is impossible to disable it via AT commands without .adb_enable file present (which gets removed when flashing new firmware), so that's a fun state to be in :>

You can also go another route. Since you are already modifying filesystem, why not replace libql_atcop.so.1.0.0 responsible for actual check with older version (or build fresh one from QuecOpen SDK which doesn't have these checks) to do the bidding for you? As a bonus, you can also replace the PAM plugin that is responsible for doing same RSA check when logging in over UART console. Or better yet, why not inject public key for a pair of keys you control?

[grapexy]

You can go level deeper and modify rawdata partition directly, to set appropriate USB modes and skip entire userland logic. The partition itself is binary representation of packed C struct alongside simple CRC. This partition is never updated during flash and contains some of the data such as VID, PID, PCIe config state as well as current security state and hashed security password (for secure debugging). The fact that it is not touched during upgrade is the reason why once enabled ADB debugging stays enabled even after flashing firmware.

I have verified this works.

1. Flashed firmware where old AT+QADBKEY method is still accessible (RM551EGL00AAR01A02M8G)
2. Went through adb unlocking procedure
3. Deleted file /data/.adb_enable just in case.
4. Flashed new firmware where AT+QADBKEY is gone (RM551EGL00AAR01A03M8G_A0.001.A0.001)
5. adb still works and usbcfg is preserved:

AT+QCFG="usbcfg"
+QCFG: "usbcfg",0x2C7C,0x0122,1,1,1,1,1,1,0

So until Quectel releases devices with FW version that can't be downgraded to A02 where QADBKEY exists, this is the easiest route for now.

Note: RM551EGL00AAR01A03M8G to RM551EGL00AAR01A02M8G downgrade works just fine.

[stich86]

So looks like we need to use touch instead of copy the .adb_enable file from /data in the rootfs when the module starts, otherwise it will not boot and you need to restore in edl mode. @1alessandro1 will upload new revision with the fix :)

Please note that EDL boot point on FM190 isn’t working like RM551. I had to solder a small wire on PIN 68 of PCIe connector, and put it on a 1.8v point to boot the module in edl, so be aware 😅

[1alessandro1]

Yes, here's the fixed version: https://mega.nz/file/iahEnQqS#xHKi7YPI90WIjlhbdlGTkGa4tNeL-BVUxPCp3fnSlXI

[1alessandro1]

I think we can close this, I hope it will last as much as possible

[iamromulan]

Well done!
Although, when I made my firmware /data was on the usrdata ubi with an empty mount point on the rootfs ubi.
Maybe only the usrdata ubi needs the modification? This is just an empty file that is placed there? Apologies I haven't been able to test yet. Just now landing in Paris.

I have made some automation scripts that help me quickly unpack and repack the ubi/ubifs images. My method is: use nandsim to simulate the nand geometry of the module then flash the ubi images to the appropriate parts and mount them. Make edits then use mkfs.ubifs and ubinize from those mount points. This makes it easier for capturing the state of an existing module as well as you can use dd on the rootfs mtd, save the dump to usrdata then transfer that to your development machine and flash the nandsim. (You cannot flash a dd directly as it makes a dirty flash environment that fails on first write.)

[stich86]

usrdata ubi is empty when you flash, then there is the script /etc/scripts/createsymlinks.sh that will create all other mount points, copy content of rootfs /data to new folder and the mount bind these partitions using usrdata volume. So if you factory restore the module, lost the access to ADB (without using the challenged). I've made a simple trick, added a touch of .adb_enable into the symlink script, so each time you do a factory reset, it will be created on new volume :)

[1alessandro1]

May I have a look at those scripts? #alessandro1537 on discord

[balika011]

The implementation in RM551EGL00AAR01A04M8G is broken.
AT+CFUN=1,1
wait till it reboots
AT+QSECCFG="adb_auth",""
it will pass authentication with flying colors.
now you can use AT+QCFG="usbcfg" to enable adb as usual

note: if you send any other adb_auth command before or after it will respond you with ERROR. but due to how they fucked up the implementation, this will give OK back. 🤣🤣

[balika011]

@iamromulan i think you should update your wiki

[iamromulan]

@iamromulan i think you should update your wiki

Thanks for that info! Let's try and keep this from Quectel as long as possible. We'll keep what you said here only for now 👍😁