Need to root Quaderno Gen2 A4

[Pajace]

Hi

I have a Quaderno 13.3, and it's version is 1.1.01.04100FP, when try to use dpt-tools.py for upgrading it, it always shows Error, Unable to update. Error code: 900001.

Does anyone know how to solve it? Or I cannot root my Quaderno 13.3 ?

--

Updated:
I found a project A4_fw_unpacker that can unpack FwUpdater_gen2_1.1.01.04100FP.pkg

But, after remove all of exit 1 from unpacked script, I cannot find a way to repack it back to pkg file.

unofficial_pkg_unpacker.sh is not for those files that unpacked by A4_fw_unpacker

Thanks

[ygjsz]

Repack the package needs the private key of the original PKG which we don't have. So it's impossible to make a flashable without replacing the public key in the rawdata partition. So currently, we can't rooting the Gen 2. [Unless someone find a bug in the updater script which can bypass the signature check mechanism]
Btw, Sony DPT's PKG firmware layout is different from the Gen 2’s.

[Pajace]

Got it. Thanks

[csdvrx]

I'm coming back to this now that I've got a Bigme ebook: it helped me learn many things about Android!

[Unless someone find a bug in the updater script which can bypass the signature check mechanism]

I'm getting good at that, so I've started looking at the scripts: yours and the one in the image

The verification is conditional on buildvariant, so the simplest way to bypass the signature check would be to change the buildvariant to avoid the condition: [ "$buildvariant" = user ] && openssl dgst -sha256 -verify $contents_sign_key -signature $preparation_sign < $preparation_archive

Changing it to say buildvariant=root should not trip the script set -eu or the error detection, as you can try with that:

#!/bin/sh
# replicate the script settings
exec 2>&1
set -eu
buildvariant=root
# test what happens
[ "$buildvariant" = root ] && echo "doing this"
[ "$buildvariant" = user ] && echo "but not that"
echo "and the script keeps going happily"

This buildvariant is defined in the boot.img at the end of the cmdline parameters: console=tty0 init=/init rdinit=/linuxrc androidboot.selinux=permissive androidboot.hardware=freescale androidboot.primary_display=imx-drm firmware_class.path=/vendor/firmware transparent_hugepage=never loop.max_part=7 cma=800M@0x400M-0xb80M androidboot.wifivendor=mrvl androidboot.selinux=permissive buildvariant=user

Changing that last buildvariant=user to buildvariant=root or anything else that's 4 characters should be enough

The boot.img partition can be obtained from your script by unzipping the tmp file left: I got a boot.img with md5 a654bf0b3251ed40d687d606d0757a43 from 26010FP

Changing the buildvariant as suggested would require:

• editing the cmdline flags inside boot.img while keeping the rest of boot.img intact (and maybe adding a few things too like magisk does during its patching) I don't know if boot.img has a checksum for the cmdline flags but I'd try with hexedit first
• flashing the patched boot.img: if it's the same size or less, it could be flashed with uuu from mfgtools: since the Gen2 is a imx8mm, check https://github.com/nxp-imx/mfgtools/blob/master/uuu/uuu.cpp and https://www.nxp.com/docs/en/user-guide/IMX_LINUX_USERS_GUIDE.pdf

If I understand the documentation correctly, there is a hardware recovery mode, and it should always be available when the bootloader switches from primary to secondary - it's different from the "recovery" partition also called "diagnostic" mode, as it sits at a much lower level.

To check what the bootloader supports, we can extract not just boot.img but also u-boot-imx8mm.imx to study it: its md5 is e0d81c0689c635bf547dd3b950ceb2f5

Inside, I see it supports Serial Downloader Protocol, usb_dnload, USB EHCI, Android Fastboot, load binary file over serial line, mmcinfo, mmc part, tftpboot ... so I think it has absolutely everything we might need to do things directly to test a boot.img without even flashing it!

And if it didn't, since the imx8mm is a standard platform for the evk, we can download the evk, compile the bootloader, and flash one with the extra things we need - or just grab a premade one.

Google for the bootloader file name and you'll find many others, and documentation on how to flash it: uuu_imx_android_flash -f imx8mm -a

It's not clear which DTBO should be used (there are many in the image) so instead of flashing it, I'd first try load the bootloader to ram with -i and test load the patched boot.img to see it can can boot, maybe by changing the console to console=ttymxc1,115200 earlycon=ec_imx6q,0x30890000,115200 to grab the boot messages or changing the init to busybox to bypass the login and just see what happens :-)

As it would all be done it ram, it would facilitate tests.

Btw, Sony DPT's PKG firmware layout is different from the Gen 2’s.

Then could you please detail the difference or explain me how to pack a .pkg that will match Fujitsu layout?

In case this fails, I saw another potential bug in the updater that might be even simpler to exploit, but all the information I could find for the Sony was in https://github.com/HappyZ/dpt-tools/raw/master/fw_updater_packer_by_shankerzhiwu/pkg_example/hack_basics/fw.pkg :

• byte 1--4: DPUP - file recognizer
• byte 5--8: data offset location A
• byte 9--12: total data content size D
• byte 13--16: nothing
• byte 17--20: sigfile size B
• byte 21--(20+B): sigfile data
• byte (21+(-B%16)%16)--(25+(-B%16)%16): encrypted data aes key size (BE) C
• byte (+1)--(+C): encrypted data aes key bytes
• byte (+1)--(+32): initial vector --- up till now bytes shall equal to A
• byte (A+1)--(A+D): encrypted data
• byte (+1)--(+4): animation header size E
• byte (+1)--(+4): animation data size F
• byte (+1)--(+4): animation sigfile size G
• byte (+1)--(+(-G%16)%16): animation sigfile --- here bytes shall be A+D+E
• byte (A+D+E+1)--(A+D+E+F): animation data

In your script, I see you're skipping 20 bytes for B, then 12 (so 3x4) which could be for the animation but the differences don't really stand out to me.

@ygjsz, if you have some time, could you have a look at the small FwUpdater.pkg from inside system.img, try to remove unpack/root/etc/init.d/S99updater, and explain me repack this FwUpdater.pkg in the Fujitsu Gen2 format?

This is just to see what happens when it's fed to the Quaderno while I try my other method: where it will fail, what will be shown on the screen etc.

replacing the public key in the rawdata partition

If it's really needed, that should be possible from a normal update if any daemon is listening for connections during the firmware update process: I see root has a shell in etc/passwd: root:x:0:0:root:/root:/bin/sh

Also, the unpacked etc/shadow contains a password: root:$6$J06953XoTz8pr$hOi5FrCEtWrvIUIs8rYL0PKWQnn2TpIi60KkRWtKKGCBLKT8AgzsqMEFbQB.RtqHjkd.nZ50gFZ7dRC.fj2dn/:10933:0:99999:7:::

The previous Sony hack just changed the existing root password by tweaking the shadow file, but we may not be able to do that yet.

So what about running hashcat on this sha512, to get the root password?

If there's something listening and allowing a root login during the update (and I think there's login running on a USB serial tty), we can:

• login as root during the update,
• immediately chmod -x the reboot and poweroff binaries, in a race to stop the updater script from rebooting
• then there would be time to do more interesting things, like changing the keys in the rawdata partition.