yashsingh1/xdaforums huggingface dataset:
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] mtrantalainen:
If I just want to backup TA partitions with latest official firmware, is following possible:

Downgrade to supported old version with newflasher

Run exploit to get temporary root

backup TA via temporary root

install latest official firmware with newflasher

If I've understood correctly, that should result in fully standard install with locked bootloader but I have a good copy of TA partition. Is this correct?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] mtrantalainen:
I'm trying to avoid possible future where Sony decides to prevent downgrading and I'm no longer able to extract the TA partition. My plan is to try to stay with the latest official firmware as long as Sony does not do anything too stupid but I want to have plan B with working camera.

As far as I know, unlocking of bootloader cannot be undo even if I later install full official firmware and restore TA partition. As such, I prefer to avoid unlocking the bootloader until I really have to do it. Another reason is that my banking app that my bank requires me to use has explicitly banned LineageOS (I don't understand why and they haven't bothered to answer when I've asked) so I'd rather avoid having to do extra work to hide both root and LineageOS if I switch to fully custom ROM. If I change the firmware, I'd prefer to go with full Open Source implementation as much as possible. I'm not interested in setup where I root (in practice with Magisk) the official firmware only.

(TL;DR: I just want to make sure that I never lose the TA partition even if I currently continue using stock firmware and switch to custom ROM in the future.)
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=9827937]mtrantalainen[/MENTION], to answer your original question - yes, you can just backup the TA after downgrade, not unlock and upgrade. You can unlock later, when needed. It has even been tested to unlock on pie and restore previously backed up TA (obtained on exploitable oreo) without downgrade to oreo (you may use twrp or magisk to get a root shell after bootloader unlock for TA restore).

You are right that sony might forbid bootloader downgrades, but it does not seem very probable.

In fact it's a question how many new updates are yet to come.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=9827937]mtrantalainen[/MENTION], as you wanted to downgrade from the latest stock fw, having still bootloader locked, could you please confirm, that it is possible to downgrade even the bootloader?

The 47.2.A.10.107 fw version contains LA2_0_P_114 bootloader version.

You will need to downgrade to exploitable oreo fw version for the TA backup you have been planning to do.

Please try to downgrade also the bootloader (i.e. downgrading the fw including flashing of complete boot/ subfolder, with all .sin, .xml, .ta files that are there).

Let me know please if it went ok - I would assume so. Very little probability may be there, that flashing of the bootloader is just refused with some error - you may check the log and service menu to see what version is running after the fw downgrade.

I am still wondering about the changes introduced with the fw in VerifiedBoot uefi component of xbl as mentioned in post#1073.

Anybody, please comment, if you noticed something with this regard.

Thanks.

Checking the commit, it seems you are probably right.

The question is: could that change even be running under some conditions?

What that change is really about? What would be blowing some fuses on tamper detection for?

If tampered and locked, a device would not boot anyway, would it?

xzp/xz1/xzc phones are not running AVB 2.0, while the commit explicitly mentions it - may be they picked the commit with a general security merge even if not used with yoshino platform?

Or is sony preparing the bootloader to switch to AVB 2.0 for next major upgrade eventually? That does not seem very likely to me.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=7543898]Blu-eyes[/MENTION], just to confirm, the serial console can be safely enabled (and disabled) even with a _locked_ phone - I just tested that with my still locked xz1c. Verified the effect described in post#1126 via temproot.

So the post#1125 can be safely used with locked phones too (as expected).
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
I tried but nothing useful appeared on USB connector, also various connection, pulsing vbus, haven't done nothing of interesting, appeared in the log extracted from ta.

I found a UART reference( UART enabled @3M baudrste or similar) in USBdevice.pe in the xbl, so probably here is enabled, and probably here we could find useful information how to enable it.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=7543898]Blu-eyes[/MENTION], I am not sure, if we should look for the "[SONY - UART]" in bootloader log TA unit - it seems to me that possibly appears only when entering sony service mode (i.e. sony flash mode, green led) and most likely needs something special on usb.

If you check the xz2 thread you have linked, there is nothing about "[SONY - UART]" either.

It is question, what would be there, if they try to boot to flash mode.

I've checked sony xz2 kernel sources, the problem of not appearing kernel log in the liked sony forum thread is caused by not enabling the debug console in the 0x09a9 TA unit indeed.

Checking CONFIG_SERIAL_MSM_GENI_CONSOLE mentioned there - it needs SERIAL_MSM_GENI enabled, resulting with drivers/tty/serial/msm_geni_serial.c driver compiled in.

Comparing drivers/soc/qcom/console_setup.c between yoshino and tama sources, tama uses "/soc/qcom,qup_uart@0xa84000" device tree node, that leads to the msm_geni_serial driver.

The logic for oemandroidboot.babe09a9 is the same.

So the guy on sony forum could get the kernel log if he enabled it in 0x09a9 TA unit.

It may be worth to ask there, what he used to get that serial connection, if it was a usb cable or a serial cable connected to some test pins on motherboard?

I guess our serial could be similar.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
I'm believing some comercial products like usb to uart might work? Just need to be bidirectional? Here is some threads on xda https://xdaforums.com/showthread.php?t=1901376 maybe might help. Just to share, I'm done my project completelly. I'm suprised how precise it is, 16bit measurement with 24bit floats, regulation steps is in 12bit (4096 steps for volt and ampere adjustement), wow \0/
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] pbarrette:
[MENTION=7543898]Blu-eyes[/MENTION]

I'm sure you've seen this already, but:

http://www.loper-os.org/?p=2415

I know that's a Rockchip device and not a Qualcomm, but you did mention seeing unidentifiable signals on some other pins.

Are we sure it's not just acting as its own USB serial adapter over non-standard data pins when the CC pins are pulled down?

Essentially acting like a PL2303 that spits USB data over SBU1/2 (or some other pin set) instead of D+/-.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
Another implementation is

http://www.loper-os.org/?p=2403

For the suzy-Q cable I haven't tried , but seems that no valid USB signal appeared on digital analizer (as far I know a USB device to be enumerated must pull low d+ and d- for 10ms after that the USB is plugged (vbus>vbus_min))

Can anyone tell me what the CONFIG_USB_SERIAL_QCAUX kernel config do?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=7543898]Blu-eyes[/MENTION], in my opinion the USB_SERIAL_QCAUX enables driver for Qualcomm modems using some proprietary protocol instead of AT commands. Not sure if that can be useful for us.

But see this post of me - I have a patch for USB_SERIAL_QUALCOMM driver - when applied (to your desktop linux kernel), it provides serial devices in your PC for phone connected over USB-C after switching the phone's composite usb device setup to a diag mode.

It might be useful in general, if you can setup the wiring in a way, that an unknown usb device would appear - you could add it's usb ids and endpoints setup in order to make a ttyUSBx available in linux for it in a way I did it for diag mode.

For sure there are other possibilities for the usb composite device setup.

I've managed to get a serial console this way by use of USB_CONFIGFS_SERIAL in phone's kernel - but that needs configfs magic setup after kernel is booted, to properly setup usb otg and conflicts with sony fw default setup.

So it cannot be used for kernel boot up logging as usb otg configfs is only available after kernel is already booted.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
With regard to the possibility to flash subcomponents of bootloader via dd command as described in post#1059 with details about certificates embedded in the .mbn files described in post#1065 - I just tested flashing xfl.mbn from LA1_1_O_77 while running LA1_1_O_79 bootloader version. Sony service mode (the flash mode) could still be booted.

A 'fastboot getvar all' command in flash mode provided following difference while comparing o77 with o79 xfl:

-(bootloader) Loader-version:XFL-MSM8998-N-41-A
+(bootloader) Loader-version:XFL-MSM8998-N-45

So it looks like version matching is not implemented, not at least for xfl boot.

But I am still hesitating to test downgrade of abl.mbn, because if that did not boot, it would be a hard brick in my opinion.

Knowing that may be particularly useful though as it implements all kernels loading&verification, including fastboot.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Flashing via flash mode allowed? Might be problem flashing with dd since trim area contain bootloader version string.

---------- Post added at 09:10 AM ---------- Previous post was at 08:47 AM ----------

On z1c this script enable eng mode (give two protocols on pc via usb, at least I have tested that some years ago, one is gobi which reguire special qcom usb drivers, and seccond didn't remember)

#!/system/bin/sh

echo 0 > /sys/class/android_usb/android0/enable
echo "0FCE" > /sys/class/android_usb/android0/idVendor
echo "diag" > /sys/class/android_usb/android0/f_diag/clients
echo "smd,tty" > /sys/class/android_usb/android0/f_serial/transports
echo "smd,bam" > /sys/class/android_usb/android0/f_rmnet/transports
echo 5416 > /sys/class/android_usb/android0/idProduct
echo "mtp,adb,serial,diag,rmnet" > /sys/class/android_usb/android0/functions
echo 1 > /sys/class/android_usb/android0/enable

exit 0

Edit:

I'm believing you can't get uart without opening backside of the phone and connecting rx and tx, those two pins is out of usb-c like it was on xa2
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4120742]munjeni[/MENTION], did not test it, but assuming that abl cannot be flashed via fastboot nor via flash mode (xfl) - only as a complete bootloader package in flash mode imho.

Bootloader version string is updated on each boot if not matching reality. No problem there.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Ok yes, problem might be guesed types e.g. like we found in xfl, e.g. referenced by abl at specific memory address, it might be a problem if you not use whole "boot" and your diferent abl (not from that boot bundle) reference it to diferent address xbl will fail than, just example, I think thats risky mixing diferent mbn files.

Also having two rx and tx, one on usb and seccond on dedicated pins on mainboard I think have no sense, it not going to work on usb probably, only after kernel boot but not for low level debug, for that dedicated pins will need.

Edit:

"We found" in abl not in xfl.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
VBUS pulse might be related to shorting testpoint pin to gnd? Related to X Boot PAL protocol whatever that mean.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
bootloader versioning and backup partitions

Just noticed, there must be some versioning implemented in bootloader (not sure what component is controlling that) - there are following partitions and corresponding .mbn files in bootloader fw flashable .sin file:

abl
cmnlib64
cmnlib
devcfg
hyp
keymaster
pmic
rpm
tz
tzxflattest
tzxfl
xbl
xfl

Each of them has a sibling, with 'bak' suffix, like 'ablbak' or 'xflbak' partitions.

Just compared my recent backup of all partitions with .mbn files from extracted bootloader .sin packages to find out, that the 'bak' partitions contain the newest bootloader version ever used on the phone - I had LA2_0_P_110 version there.

That I've flash long time ago (it appeared with 47.2.A.10.28 fw version), for sure the last two bootloader versions I've flashed have been LA1_1_O_77 followed by LA1_1_O_79.

Could that be that some part of fw (primary boot loader or possibly the xfl/loader during flashing) checks the booloader versions and updates the 'bak' only if just flashed bootloader version is newer and could be booted successfully?

There even might be some mechanism, that would boot or revert the primary partitions from the 'bak' variants if current bootloader partitions could not be booted?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
Today my phone dropped, again, and it "decided:D" that was a good idea to show me some hidden pin:confused::

You can see by the picture(sorry for the low quality) at the top left and at the bottom right, a probably also at the other corner, two pins shorted together by a removable metal plate, anyone has an idea of what these pins do? Probable they are some external test point. Would be useful if anyone with a "open" (probably no one ) phone based on the yoshino platform check if these are connected to some internal testpoint or the are there for some useless (from the perspective of modding and debugging)function.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=7543898]Blu-eyes[/MENTION], could that be a thermal conductor to extend cooling to the aluminium plates on top and bottom?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
The are too small for any useful heat transfer, maybe these are some antenna extension. The only think that I noticed is that with this metal plate in place at the kernel is passed lcdid_adc=114 while without it change to lcdid_adc=343, but maybe this variation is there for other reason
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] mirhl:
ADC should be the (voltage?) Analog-to-Digital Converter which somehow is used as a random number generator in querying display panels (don't ask why). Or something.

I don't know how the bootloader gets involved in asking for it, but I really doubt it matters here.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Lcdid_adc setup is inside kernel mdss_dsi_panel_driver, value 114 and 343 might be unrelated to opening case.

---------- Post added at 09:28 AM ---------- Previous post was at 09:21 AM ----------

If I remember corectly bak partitions is never used, I have replaced something some years ago and ended without it, so it was not restored from bak
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
permanent root with still locked xz1c preview

Here a preview video of my current work: still locked xperia xz1c with permanent root on latest fw

Phone since power up, no unlocked bootloader warning screen, i.e. still locked, with root / magisk right after boot, even auditor app passes the hardware attestation confirming locked state.

fw version 47.2.A.10.107 (July 1, 2019 security patch level)
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] SGH-i200:
Should I wait? I was about to unlock the bootloader of a XZ1 dual.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] shoey63:
Can this fix be adapted for those who have restored their original TA after unlocking the bootloader, or must it only ever be for those who are yet to unlock?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] rizky_zulfikar:
i've download 3 times the 47.1.A.2.324_CE1 fw, and it's corrupt. could u fix that?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] ecksdeeay:
I was under the impression this is what's been done!
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] shoey63:
I hope so, just the term "still locked“ led me to think bootloader had not been unlocked.

You are probably right though, it's doubtful [MENTION=4418980]j4nn[/MENTION] has a spare device which he hasn't unlocked yet.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] 4rz0:
Interesting. I was thinking about finally rooting my device. It still sits on some 2018 firmware.

How was the still locked root achieved?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] niaboc79:
Is that root on locked bootloader or you found a way to relock the bootloader after restored TA?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] ecksdeeay:
This is hiding the splash on bootup with unlocked bootloader AFAIK
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
guys, it is what it says it is - my new root exploit.
[MENTION=1995555]SGH-i200[/MENTION], it does not matter what exploit would be used to backup locked TA before unlocking.
[MENTION=5060283]rizky_zulfikar[/MENTION], the fw archive is all right, just use proper sw to extract it.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] kojak1989:
What about root without unlocking bl? Twrp works too?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Klaus N.:
I guess, it's not possible with a locked device, at least if you won't unlock it.

[MENTION=4418980]j4nn[/MENTION]

As most of the people who follow your thread and have already operated your "native" root exploit, I'd like to pick up [MENTION=4675598]shoey63[/MENTION]'s question in post #1157 ;)

But when I read your post (# 1164), I'm a little confused now :confused: Just to be clear: If I've understood your post correctly ("guys, it is what it says it is - my new root exploit."), it's only related to untouched devices with a locked bootloader to proceed it, isn't it?

Thanks in advance!
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] kojak1989:
No one really knows what's going on here, it's for unlocked bl with drm keys backed up or for locked bl ?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4898998]Klaus N.[/MENTION], yes, it is mainly useful for still locked bootloader.

I am not aware of any way to relock bootloader nor how to hide unlocked warning screen.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] ra1n25:
Oh that sounds nice ? Can't wait to try this
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] kojak1989:
so twrp will works too ?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Klaus N.:
Yes, because you will have to unlock the bootloader right after backing up your ta partition using the new exploit (as soon as j4nn has released it), I guess.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] kojak1989:
No need to unlock it's for locked phone and j4nn quoted you with this.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=5520227]kojak1989[/MENTION], I can only confirm what [MENTION=4898998]Klaus N.[/MENTION] says - twrp needs to be used with unlocked bootloader.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] serajr:
So you're able to create a new root exploit - these days - with all the "security patches" already released, etc... really?

You are insane!! Epic!!! :highfive:
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
Unfortunately I am not sure that I am winning - my score:

two root exploits for xz1c vs two xz1c not-recoverable-hard-bricks
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
exploiting xperia XZ2 - good and bad news

I bought recently a second hand single sim XZ2 - just for testing my new xz1c root exploit.

Good news is that I've managed to adapt the first stage and eventually have been able to backup TA partition still in locked state.

But then it went south, phone complained about corruption or something, refusing to boot and just powered off with no way of recovery - except bootloader unlock, that allowed me to eventually fix it.

That's not what I've hoped for - been forced to unlock it that soon.

But it gets worse - even though I've both TA backups (locked and unlocked), restoring locked TA does not restore drm functions probably as the service security screen still complains about suntory errors, even when running kernel patched with my bootloader unlock hide patch (which is working at least from what security screen tells).

Even though the unlock has been done on 52.0.A.8.131 fw - I get camera black preview, when running bootloader unlock hiding kernel.

It works with stock kernel though (where unlocked state is visible in security screen). The behaviour is the same with both "locked" and "unlocked" TA.

I've verified that the device master key is present in the 0x1046b (66667) TA unit in the TA-locked.img backup.

So I am not sure where the score moves now...

The bad news - it seems that simple restore of "locked" TA backup would not help with XZ2 phones anymore, even with BLU hiding kernel.

I've always wondered why the unlock state would not be checked already when the device key is used in trust zone - may be it now is and a present device key is not used in TZ if unlocked...
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] shoey63:
[MENTION=4418980]j4nn[/MENTION]

So the act of running the exploit caused a corruption message which could not be resolved by a full firmware flash with newflasher, and the only way out was to unlock the bootloader?

Do you think backing some up other partitions while still locked and restoring them after unlocking would have resulted in a better outcome?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
I wish it could be solved in such an easy way.

I am not sure what has caused it. I've been working on it, powered it off in a good state before going to sleep, when tried to power it on the next day, I got the corruption message. Big unfortunate surprise:(

I am not sure what do you mean.

I am not aware of any corruption, still got the message.

If you mean that drm stuff seems not to work even with restored locked TA, I am afraid, there is nothing else to backup.

Restoring persist partition (to try to restore the android attest key) has never worked on yoshino, so I doubt that for tama too.

I've tried to downgrade to 52.0.A.3.126 pie firmware, assuming that is the first fw version with sony fix for unlock with regard to camera. Running kernel patched to hide bootloader unlock still results in

Rooting status NOT_DONE
...
Suntory blobs [ERROR]
Android Attest Key NOT PROVISIONED
Credential Manager
Secondary [ERROR]

Downgraded to the first fw version ever available - oreo 51.1.A.2.183 - exactly the same results with BLU hiding kernel and TA-locked restored.

So in my opinion, TAMA has been released since beginning with additional checks and probably does not use the device key even if it was present in TA unless it knows in TrustZone that bootloader is still locked.

-- edit --

Just checked drminfo on that oreo 51.1.A.2.183 (with BLU hiding and locked TA): it reports widevine L3 security level, HDCP unprotected. So that L1 drm feature is gone too even with device key present and kernel hiding unlock. I guess we are very lucky with yoshino platfrom.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Mr Zhao:
I want to ask specifically how to operate? Can you send specific tutorial? I would like to relock or hidden power unlock tips.Thank you so much !
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] ecksdeeay:
My assumption was wrong.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
So the 22022 offset looks good after all. It is quite hard to get kind of deterministic behaviour out of unknown/random preconditions - the base for the offset is determined heuristically.

I will need some time to extend my code for a next step.

Thanks a lot for now.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
I've reworked threads setup and synchronization - could you please verify that it gets similar hit results for the

./mvuaf3 -s 16 -o 22022

as before?

Thanks.