yashsingh1/xdaforums huggingface dataset:
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] mirhl:
Also https://www.zdnet.com/article/qualp...chips-let-hackers-compromise-android-devices/

I'm not really sure what's the deal with this mashup ideas.

Downgrade isn't officially forbidden, so it's not going to help with root.

And afaiu trustlets still don't implement rollback protection thanks god, so nothing to see there even for attestation and/or an eventual interdependence between these and bootloader.

If the only deal is trying to figure out the camera, I don't know why going as far as xbl. Put aside that anyway if you can glue stock blobs to aosp, then you can even probably do the other way around, why simply not investing the time into decompiling them? It seems even more farsighted.

And why not, perhaps you may understand whatever magic they set on unlock on oreo (probably in the TA?) that makes the camera misbehave afterwards.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] ashkan.t:
I did backup on oreo (with recommended firmware) after that

I flashed latest pie to unlock bootloader. now I want to restore ta

I left renotrap working for 10 hours and events count goes 700000 (higher and higher )

I think it is not normal.

what should I do now ?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=5847405]ashkan.t[/MENTION], trying to run renoroot on different fw then one of those listed is useless, just read it in the guide.

Having your bootloader unlocked, just boot twrp to get a root shell with adb and restore the TA from there.

Or you could dowgrade back to the supported fw if wanted to use renoroot again for restore.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
Thanks, that is another very interesting vulnerability. But another way to get root obviously would not help us as we already have that - could be useful for newer phones, like xz2 or even the latest range though.

What I would like to get is a code execution in Trust Zone, but that is currently out of reach for me.

The idea to use components from older bootloader would be useful to know that it works in general.

I came to that because of the changes in the latest Sony fw - the 47.2.A.10.107 updates the bootloader to LA2_0_P_114 which brings very strange changes in verified boot uefi xbl bootloader component - following text messages have been added in the VerifiedBootDxe module (compared to LA2_0_P_110 bootloader version that appeared with 47.2.A.10.28 fw version):

QCOM_VB_Send_Milestone: set_fuse (TZ_HLOS_BL_MILESTONE_FUSE) fails!
QCOM_VB_Send_Milestone: TZ didn't support this feature! Version: major = %d, minor = %d, patch = %d
QCOM_VB_SendROT: QCOM_VB_SendBootState fails!
QCOM_VB_SendROT: set_fuse (TZ_HLOS_IMG_TAMPER_FUSE) fails!
QCOM_VB_SendROT: set_fuse (TZ_HLOS_TAMPER_NOTIFY_FUSE) fails!
QCOM_VB_SendROT: TZ didn't support this feature! Version: major = %d, minor = %d, patch = %d
LocateProtocol failed for set_fuse!
ScmSipSysCall failed for set_fuse!
LocateProtocol failed for get_fuse!
ScmSipSysCall failed for get_fuse!
LocateProtocol failed for ScmGetFeatureVersion!
ScmSipSysCall failed for ScmGetFeatureVersion!
TZ_INFO_GET_FEATURE_VERSION_ID failed, Status = (0x%x)

It's also interesting the 4kB size increase in the VB module, while it did not change in any previous bootloader version:

53248 VerifiedBootDxe-o77.pe
53248 VerifiedBootDxe-o79.pe
53248 VerifiedBootDxe-o82.pe
53248 VerifiedBootDxe-p104.pe
53248 VerifiedBootDxe-p105.pe
53248 VerifiedBootDxe-p106.pe
53248 VerifiedBootDxe-p107.pe
53248 VerifiedBootDxe-p110.pe
57344 VerifiedBootDxe-p114.pe

This makes me wonder what is sony doing in the latest bootloader version controlling something with qualcom fuses in the verified boot component, that has not been there before?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] ashkan.t:
SOLVED

I downgraded to oreo and renotrap works. thank you
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] ra1n25:
probably this: https://www.xda-developers.com/qualpwn-vulnerability-snapdragon-835-snapdragon-845/
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] mirhl:
That's what I linked in the previous page, and it has nothing to do with bootloader, fuses or even the trustzone.

Speaking of which

https://github.com/enovella/TEE-reversing

https://github.com/bkerler/twrp_tz_fixes

So, they just pulled in this commit?

And yes, root for XZ2 would be appreciated. I'm still sticking to the first November pie rom just for safety of that :)
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] novebis:
[MENTION=4418980]j4nn[/MENTION] Thank you! I have tested the usbnet modules and it works with 47.2.A.10.107 firmware, the modules are copied to the phone and then loaded with adb shell with root.

I have ethernet connection with usb adapter and everything works correctly, but it stops working after the restart. It would be great to be able to install the modules permanently!

Although Just for that you deserve a donation from me, I hope more people consider donating, I think it is the best way to thank their contributions and time dedicated to the community.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=800675]novebis[/MENTION], thank you for the donation. Only few actually donate for the drm keys backup possibility. So it is really appreciated.

I tried to create a magisk module to load the usbnet modules on boot up - the first magisk module I've created... Hopefully it works.

Just put it to your sdcard or somewhere accessible in the phone, enter magisk manager, modules, + to add it and select the xz1-usbnet-modules.zip file.

After reboot the modules should be loaded automatically. I've tested it with my xz1c, but as I am currently running the oreo kernel (and it's xz1c not xz1), it did not load, but I can see errors in kernel log, that the modules have been tried to be loaded, so it should work in your case with xz1 pie 10.107 firmware.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] novebis:
[MENTION=4418980]j4nn[/MENTION], my mistake when typing the name (edited) .. but the right thanks and donation! .... many people have benefited from your contributions and I hope that more users value it and donate rewarding your effort and your time.

I will test the usbnet module for magisk and report the results.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] novebis:
Installed and running!, [MENTION=4418980]j4nn[/MENTION] magisk usbnet module loads correctly after reboot, detects the usb ethernet adapter and works ok. Thanks!!
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] vofferz:
I also think people should give something back to j4nn for all his hard work on this great little phone.

I donated a small amount in July, hopefully the money found it's way to [MENTION=4418980]j4nn[/MENTION] 's account.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=7803472]vofferz[/MENTION], thank you for your donation, I could find it quickly as you've been the only one in July. Sorry if I did not thank you sooner (not sure anymore)....

You know, it's not nice that even many that promised something in the bounty thread would not keep their word. I guess it would be much better to forbid all these bounty threads on xda as cooperation among developers is significantly reduced because of the imaginary bounty that would not be paid anyway... Not that I would do it for the bounty (I did it for me), but still it feels sad, that just 16 persons kept they promise while 23 did not so far (most of them still active on xda).

Not to mention the 4030 downloads of renoroot but only 111 thanks in the first post...
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] mirhl:
That's sounds perfectly normal (especially if you consider that you can put only one thank, but download multiple times)

https://en.wikipedia.org/wiki/1%_rule_(Internet_culture)
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
A possibly useful info about unwanted flashing of fw for different sony xperia model into Xperia 1 dual device - please see here.

Based on that added following advice into the TA backup guide:

An advice: before flashing anything, enable 'OEM Unlocking' in android developer menu and if flashing a fw for different phone model, skip flashing bootloader (i.e. remove boot/ subdirectory completely before using newflasher). /added on 2019-08-27/

Thanks to [MENTION=4120742]munjeni[/MENTION] for pointing me to that thread.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
I have found something https://xdaforums.com/crossdevice-dev/sony/simlocks1-t3963806/post80171690#post80171690
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
I think I have interesting finds to discuss as coincidently I have been analysing boot override possibilities myself for few days alredy...

With firmwares for yoshino platform, the bootloader .sin file is flashed together with Lilac_XBootConfig_MiscTA.ta.

The comment in that .ta file says "YoshinoXbootConfig-11-15935-5-FCP1191485-PA5.xlsm".

In my opinion, the 0x0084F and 0x008FD units can be used to setup boot options and their priorities or next boot override.

Particularly the second one seems to me that it allows to override 'startup' and 'warmboot' variables of the bootloader for the next boot. In the bootloader's .ta file it is set just to one zero byte.

But the abl tries to parse it for bigger size structure - if the first two bytes are set to 0xAC and 0xBD, it checks for 0x83 and 0x81 tags and most likely a value after each tag would override startup or warmboot.

But there is some quite complicated function that makes it not easy to see, how it should be set up.

If you look at the attached abl-o77.pe (abl PE/efi executable extracted from abl.mbn of xz1c's LA1_1_O_77 bootloader, you can see MOV W0, #0x8FD just before a function call that reads that TA unit and the next following function call parses it (see 0x25FDC text address) with following debug log error message saying "Override parsing failed, checking wb".

Even more interesting but also lot more difficult to understand (and parse) is the 0x0084f ta unit - but that one I do not understand at all yet, but possibly it defines the boot options and/or triggers, possibly also boot order. See the 0x25DA4 text address, with the call loading and parsing the unit. It is followed by debug error message saying "Will invoke Sony service to obtain a bootconfig" in case it fails. Sony service is the flashmode (the xfl kernel with lilo/loader).
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
from xboot_glue
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
right, the decompiler - have seen that...

following into the calls of

sub_27AD8(0x81u,

and

sub_27AD8(0x83u,

will bring you to needed setup for startup and warmboot override that maybe defined in 0x008fd unit as I've described above.

All this even in decompiled C code is quite difficult to understand, but at least for the 0x008FD unit possible.

Lot more difficult (but possibly even more useful) is the 0x0084F unit - the bootconfig unit - which loader and parser I've also pointed to...
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
I will look tommorow, its interesting
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
In my opinion it may be useful to understand these two ta units as they seem to be freely modifiable (being low numbered units) without any sony signatures.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Yes, I will need to implement into newflasher reboot option (see isues on newflasher git), and whole my idea was to write startup reason bfore reboot.

This ocouped me right now:

v40 = sub_287B8(2u, 0x1046Bu, v61, (unsigned int)v226);

...

...

for ( i = 0i64; i < *(unsigned int *)(v39 + 24); ++i )

*(_BYTE *)(*(_QWORD *)(v39 + 16) + i) = *(_BYTE *)(v61 + i) ^ *(_BYTE *)(v46 + i);

---------- Post added at 11:17 PM ---------- Previous post was at 11:04 PM ----------

Problem is I dont have trim area dump for looking in the same time
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
hmm, that's interesting - where did you see that? It's not in the abl.pe I've posted, is it?

There I can find only reading the DK unit (or it's size) in order to _delete_ it...
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Its from abl you posted

---------- Post added at 05:15 PM ---------- Previous post was at 04:46 PM ----------

Seems unit 10471 is keystore. Reading that unit depending on existence of unit 874:

v4 = sub_2873C(2u, 0x874u, &v225);
if ( !v4 )
{
v4 = sub_2873C(2u, 0x10471u, &v221);

About DK 1046b its something to do with IMEI but curently didn't figured out what is hored. A lot of functions is involved. Imei is shifted and swapped with sub_1ED28, hard now for my head. Received some private hobby things and to be honest I must finish it first, see you later. This is what I have designed and going to start selling, first one with oled display and fully digitally controled volts and amps trought two DAC, via i2c trought pic12f1840, real volts, amps and power displayed on oled screen, with menu ...etc, just small adwertise hope ok :D
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
Let me explain what I have in mind: with bootconfig (0x0084f ta unit) it may be possible to persistently switch what partition is booted by default. Asking what for? We might be able to get rid of the unlocked bootloader warning screen.

There is a possibility for example with 'ramdump' partition - that is empty by default. But it looks like ABL checks it if it contains a magic, it tries to load a special kernel for dumping ram in case the phone crashes.

The most importantly: sony service mode (i.e. the flash mode used with newflasher, green LED) is implemented with a linux (android) kernel with a ramdisk, both stored in 'xfl' partition. This kernel is booted _without_ bootloader unlocked warning screen.

If it was possible to switch content of 'xfl' and 'boot' partition with corresponding change in 'bootconfig' ta unit, it might be possible to boot normal android through 'xfl' without the unlocked warning screen and boot flash mode from 'boot' partition with warning screen instead - all this just a theoretical thinking.

We do not know yet if we even can replace 'xfl' content with something else, like even a different xfl version the least as it has not been tested yet.

Anybody interested to help with reverse engineering the previously attached abl.pe to get understanding of the bootconfig (0x0084f) ta unit?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
This is possible only on unlocked bootloader, but also if I remember coreclty when bootloader is unlocked only android related partitions is "unlocked", the rest I think is the same like when bootloader is locked, its also noticeable when you use fastboot flash xfl_partition, getting not allowed. It stil be done trought rooted android to flash to xfl partition, but in case you mess something and it not boot you will get lost bootloader, thats risky.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4120742]munjeni[/MENTION], knowing how bootconfig TA unit works may reveal additional possibilities.

There is a use case even with the mentioned restrictions: some guys mentioned they would need to relock bootloader. If stock boot kernel (sony signed unmodified kernel image) had been flashed instead of xfl (via dd), it may pass verification and boot stock sony fw without bootloader unlock warning screen - that would get you very close to a re-locked bootloader state. With changed bootconfig to force xfl partition boot on power up, one may not notice bootloader had been unlocked.

-- edit --

If xfl does not boot, most likely fastboot still can be used for recovery - fastboot is implemented in ABL.

That is unless bootloader verifies all the components, including xfl, even in case when xfl would not be tried to boot.

Fastboot (on unlocked phone) should allow to boot a custom kernel that would allow to fix up xfl.

Corrupted bootconfig TA unit would require working xfl for recovery - in case of bootconfig TA unit parse error, abl boots xfl to get valid bootconfig (most likely expecting it to be flashed via the 0x84f ta unit).

Or just booting a kernel from fastboot and flashing full TA partition backup, the question is, if fastboot can be entered when bootconfig contains an error.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] pbarrette:
[MENTION=4418980]j4nn[/MENTION] regarding the TA read of 0x84F at assembly address 0x26874 in sub_26860.

The contents of 0x84F appear to get passed as a byte pointer to a function I've named "sonyboot_ConfigParser" found at sub_26DD0.

I've named it that because the debug strings reference the "sony_boot_config_parser.c" file.

If you look at the function, one of the first things it does is check:

- Is the first byte <> 0x1A.

- Is the second byte <> 0xCE.

When I look at my 0x84F TA unit (from a locked dump taken long ago), the first two bytes are, in fact "0x1A 0xCE".

So I'm certain that this function is what is being used to "decode" that TA unit.

There's some interesting [ERROR] strings in that function:

- MiscTA unit %d could not be read!

- No room for additional TA units

- No TA units to add to commandline

- Failed to allocate VBUS pulse array!

- None or incorrect vbus_pulse configuration!

Among other things, it looks like the config bytes:

- Set up some triggers (I'm assuming for boot type: ie - holding VolDown+Power, etc).

- Backlight / VBUS power configurations.

- Other MiscTA units to be called as cmdline parameters.

Someone with a bit more time might be able to work through the ~100 or so bytes manually to see if they correspond to any valid TA units of interest.

Also, the TA read function at sub_28494 isn't the only TA read function.

That one is actually calling a separate sub_287B8 which is part of "ta_interface.c" and has a number of cross-refs.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
if ( *a2 != 26 || (unsigned __int8)a2[1] != 206 )

You are right. Also you are right about some other trim area read-write functions, I have labeled one for read and one for write but later found other ones. Can I get trim area dump from somebody by pm?

Edit:

there is a lot of guessed types e.g. guessed type void *off_C4D48, its hard decoding. Solution is to shim xfl and print some things of interests to the log, but j4nn say xfl is not working corectly when runing from custom kernel, right?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4782500]pbarrette[/MENTION], thank you for the initial check of the bootconfig (ta 0x84F unit) parsing - I have not noticed the two magic bytes check. I think you are right with the rest general overview, I got the same impression with my disassembly based on debug/error messages - that's not difficult.

The parsing itself of the bootconfig, that's another thing.

I've also noticed, that bootconfig allows to specify which ta units are read and added to kernel command line - it seems to me that it is this:

oemandroidboot.babe09a9=00
oemandroidboot.babe08b3=50
oemandroidboot.babe137e=22

- that is ta units 0x09a9, 0x08b3 and 0x137e. It's question what is their purpose on android runtime.

[MENTION=4120742]munjeni[/MENTION], running lilo/loader that is part of xfl kernel is one thing, reverse engineering abl is another thing.

You may get general TA partition parsing functions out of xfl/loader, but I am not sure, if there is bootconfig parsing there too - is it?

I've managed to get the xfl's loader running with custom kernel and custom ramdisk, that's right, but it does not behave the same as if xfl is booted normally (the sony flash mode). I did not try to flash a fw in my custom environment with loader, but you can use 'fastboot getvar all' command both in normal flash mode and in my custom loader boot.

Unfortnatelly I had to patch kernel to return some values that loader expected from TrustZone/qseecom calls in order to make it return something with 'fastboot getvar all' command.

Similarly, 'fastboot reboot' command does not work with my custom boot of the 'loader', while in normal xfl boot (sony flash mode green led), you can use 'fastboot reboot' to reboot the phone (but it reboots back to sony flash mode).

So it seems to me, that when the xfl's loader is running in normally booted kernel (from 'boot' partition or via 'fastboot boot kernel.img'), there are some qseecom functions not available in that mode and they are needed for the 'loader' - it seems that api is available only if booted from xfl partition (sony service mode aka flash mode/green led).

That is probably also the reason, why xfl kernel if copied to boot partition does not run - it boots probably, but usb device is not initialized, so sony flash mode is not available.

Concerning TA partition backup - I could send you mine. But considering you mentioned not having the time - would it help?

If we consider just the 0x84F and 0x8FD ta units parsing/reversing - they are both present in the Lilac_XBootConfig_MiscTA.ta, getting overwritten with each bootloader flashing, so their content is pretty much fixed.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] pbarrette:
[MENTION=4418980]j4nn[/MENTION]

If you look at the init found in the ramdisk of the kernel image, you'll see that it's referencing "oemandroidboot.babe09a9" in a function that's related to SELinux policy loading. Based on the value of that boot string, it jumps to a function that writes a value to "/sys/fs/selinux/checkreqprot".

There's no reference in init for 0x08b3 or 0x137e

There's a reference in the kernel for both "oemandroidboot.babe09a9" and "oemandroidboot.babe137e", but decompiling the kernel without kallsyms leaves me without a x-ref to those strings. It'd be a lot easier if it weren't for "kptr_restrict=2"

What I find odd about 0x84F is this:

02 00 A9 09 BE BA A9 09

00 00 7E 13 BE BA 7E 13

00 00 B3 08 BE BA B3 08

Each unit definition (the BABEXXYY) bit has the TA unit on either side of the BA-BE construct (in little endian, obviously).

Based on the data structure, it looks like left hand side is actually being read. So why is it duplicated on the right?