yashsingh1/xdaforums huggingface dataset:
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4120742]munjeni[/MENTION], I can only confirm, what [MENTION=7543898]Blu-eyes[/MENTION] has written - even though all stock kernel images have signature at the end (even after extraction from .sin), android boot.img flashed into xfl partition results with a hard brick. One could think that only xfl would not boot as it is loaded from ABL, but even abl does not boot, so you cannot recover even via fastboot. I know, because I got that hard brick testing this idea before getting the above info from [MENTION=7543898]Blu-eyes[/MENTION].

Exploiting the xfl/loader might be doable - I already have managed to start the loader from custom normal boot kernel, so can use newflasher with it (tested only flashing a .ta that worked), so tracing and debugging on the device side is possible.

But I am not sure if all functions work in this normal boot - it seems to me that getting rooting status and other properties obtained via qsee api (or something) does not work. That is also one of the reasons it seems to me that xfl (sony service mode) boot can have different possibilities with tz api calls vs normal android boot.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
I'm just checked that. Kernel image extracted from sin do not have certificate at the enf of file. Xfl after extraction from sin do have digital certificate at the end of file, I can confirm that. So replacing xfl partition context with something will definitelly cause hard brick. One good thing trought that now we know that xfl certificate is not in secure place but inside xfl itself, and that certificate is checked while bootloader check validity of xfl.

One thing which migh be diferent in that case, kernel. Probably you will need to use kernel from xfl which might be diferent that one from android. Probably kernel from xfl have something special which normal kernel no not have, e.g. some more things inside qsee api which normal kernel missing?

Edit:

See picture, its very noticeable diferencie in size of the zImages between normal kernel and one from xfl
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
For what tzxfl partition is used for? I have found it contains single file tzloader.mdt which is an ELF for ARM (Shared object), reguire library libcmnlib.so , after unpackig xfl ramdisk (I thinked xfl interact with that partition) but I didn't see libcmnlib.so inside ramdisk. But what part of the thing use tzxfl partition at all? Android? Tzxfl seems can't be part of the boot chain since all things in bootchain is static objects? Inside tzloader.mdt some interesting strings about QSEE SW FUSES e.g. "QSEE_SONYTZAPPXFL_LOADED_FUSE is blown. Refuse to invoke tzapploader". We would be able to load tzloader with android kernel scm to read-write sw fuses? The some strings is inside xz1c lilo about sw fuses too, interesting.

Imported functions from cmnlib:

00005848	GPAppLib_appInit
0000584C	GPAppLib_appShutdown
00005850	CApp_openSession
00005854	GPAppLib_handleRequest
00005858	cmnlib_release
0000585C	qsee_err_fatal
00005860	cmnlib_init
00005864	qsee_fuse_read
00005868	qsee_fuse_write
0000586C	GPAppLib_init
00005870	qsee_is_sw_fuse_blown
00005874	qsee_log
00005878	TZAPPENTRY
0000587C	app_heap_base
00005880	app_stack_limit
00005884	app_stack_base
00005888	app_heap_limit
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
$ hexdump -C boot-G8441-47.2.A.10.107.img | tail -n 64 | head -n 10
01422000 30 82 03 e5 02 01 01 30 82 02 be 30 82 01 a6 a0 |0......0...0....|
01422010 03 02 01 02 02 01 00 30 0d 06 09 2a 86 48 86 f7 |.......0...*.H..|
01422020 0d 01 01 0b 05 00 30 18 31 16 30 14 06 03 55 04 |......0.1.0...U.|
01422030 03 14 0d 78 5f 6b 65 72 6e 65 6c 5f 37 62 37 61 |...x_kernel_7b7a|
01422040 30 1e 17 0d 31 37 30 32 32 34 31 32 35 38 32 37 |0...170224125827|
01422050 5a 17 0d 34 37 30 32 32 34 31 32 35 38 32 37 5a |Z..470224125827Z|
01422060 30 18 31 16 30 14 06 03 55 04 03 14 0d 78 5f 6b |0.1.0...U....x_k|
01422070 65 72 6e 65 6c 5f 37 62 37 61 30 82 01 22 30 0d |ernel_7b7a0.."0.|
01422080 06 09 2a 86 48 86 f7 0d 01 01 01 05 00 03 82 01 |..*.H...........|
01422090 0f 00 30 82 01 0a 02 82 01 01 00 c4 78 f5 f3 b2 |..0.........x...|

$ hexdump -C xfl_X_BOOT_MSM8998_LA2_0_P_114.mbn | tail -n 64 | head -n 10
00d7c000 30 82 03 de 02 01 01 30 82 02 b8 30 82 01 a0 a0 |0......0...0....|
00d7c010 03 02 01 02 02 01 00 30 0d 06 09 2a 86 48 86 f7 |.......0...*.H..|
00d7c020 0d 01 01 0b 05 00 30 15 31 13 30 11 06 03 55 04 |......0.1.0...U.|
00d7c030 03 14 0a 78 5f 78 66 6c 5f 32 38 62 65 30 1e 17 |...x_xfl_28be0..|
00d7c040 0d 31 37 30 34 31 31 30 35 32 38 30 39 5a 17 0d |.170411052809Z..|
00d7c050 34 37 30 34 31 31 30 35 32 38 30 39 5a 30 15 31 |470411052809Z0.1|
00d7c060 13 30 11 06 03 55 04 03 14 0a 78 5f 78 66 6c 5f |.0...U....x_xfl_|
00d7c070 32 38 62 65 30 82 01 22 30 0d 06 09 2a 86 48 86 |28be0.."0...*.H.|
00d7c080 f7 0d 01 01 01 05 00 03 82 01 0f 00 30 82 01 0a |............0...|
00d7c090 02 82 01 01 00 b2 c8 4e 01 d7 1c bf 09 d0 88 dd |.......N........|

If you compile a custom kernel, the above stuff at the end of the image is not present.

In my opinion, it is a sony signature/certificate - present in kernel (boot) / recovery (fotakernel) img files extracted from .sin files.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
Probably is the cmnlib64.mbn file or in the cmnlib.mbn

$ file cmnlib64.mbn
cmnlib64.mbn: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, no section header

$ file cmnlib.mbn
cmnlib.mbn: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, no section header
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
On one side j4nn post g8441 and on other side post lilo from xz2, or on another side I post from H8314, can you tell me which device we analysing and on which firmware excatly we need to be focused? Its noticeable that our 3 types of firmware is totaly diferent. Can we define which firmware we going to use further?

Edit:

Where you found abl-xz2-p118.pe ? One from abl_X_BOOT_SDM845_LA1_0_O_60.mbn is ELF but yours MZ

---------- Post added at 03:11 PM ---------- Previous post was at 02:43 PM ----------

Where you found cmnlib.mbn?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
In the bootloader.sin file toghether with
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
Please see here:

https://worthdoingbadly.com/qcomxbl/

It is all described there - the way to extract them to UEFI components.

The inner part is compressed (see the extraction with 7z), that is why texts and other things are not easily visible in a .mbn file. The uefi-firmware-parser is a great tool - it needs to be used twice as described...

abl.mbn does not contain an inner blob that would need to be extracted with 7z followed by another use of uefi-firmware-parser - there is LinuxLoader PE32 uefi executable extracted as section1.pe after the first use of uefi-firmware-parser already (i.e. the abl.pe file I've posted).

The xbl.mbn needs the described two phases for full extract of it into many files/components of the uefi xbl.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Thanks! Can we define which firmware we going to use further for our analises?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4120742]munjeni[/MENTION], I wanted to concentrate only on xz1c, but since getting new root exploit working on the latest xz1c fw I wondered if it could work on tama platform too, so I got a second hand xz2 and made a first stage of the exploit working there too.

But as restoring device key on xz2 did not restore drm functionality, in the xz2 case I am mainly interested to see what is the reason, why it does not work.

In case of xfl/loader experiments, with main goal to get TZ code execution or ability to relock BL, my test target is xz1c.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
In case of xz1c, I am using lilo/loader from LA1_1_O_79 bootloader posted as lilo-xz1c-o79 binary (it appeared first with 47.1.A.5.51 xz1c fw, last present in 47.1.A.12.205 version). It is the second earliest bootloader of xz1c fw releases.

I am not using LA1_1_O_77 bootloader becasue it uses too old kernel, of which source code is not clearly released/tagged. But only for abl analysis, I've used ABL from the oldest bootloader, the o77 to hopefully have all potential bugs present.

In case of xz2, I've used the H8216-52.0.A.8.131 fw which has LA2_0_P_118 bootloader version (it was the latest when I got the xz2 and I used it just to avoid downgrades, hoping ta backup/restore would work similarly as with xz1c).
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
Can someone post the trustzone.mbn from two different firmware version, I would like to check if diaphora can find something useful by binary diffing.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
I'm deleted it two hours ago including whole firmware :( You have xz1c device?

---------- Post added at 09:16 PM ---------- Previous post was at 09:13 PM ----------

@j4nn this one https://xdaforums.com/showpost.php?p=80511711&postcount=1243 is from CE1 47.2.A.10.107 /R1C ? Can I start looking to CE1 47.2.A.10.107 /R1C ? I want to be synchronysed with you and Blu-eyes. Can you tell me restore drm functionalitty is working on zx1c? Relock is working too?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=7543898]Blu-eyes[/MENTION], if you mean tz.mbn, here it is from all bootloader versions for xz1c.

-- edit --

Added few other components.

[MENTION=4120742]munjeni[/MENTION], restore of drm functionality works nice in case of xz1c. I am not aware of any method to relock xz1c bootloader.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4120742]munjeni[/MENTION], that post has been only for the signatures in kernels.

It would probably be better to analyse older fw, for possible bugs.

My best disassembly is of abl-o77.pe and lilo-o79 - see my previous post about fw versions. I am not sure if it is possible to somehow transform disassembly of older version to a newer one.

[MENTION=7543898]Blu-eyes[/MENTION], I've also tried diaphora for few components, including abl and few others. But it has been my first time use and it seems the tool does not make super miracles, but maybe I am not using it right.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4120742]munjeni[/MENTION], you have it right. But as written in my post, you need to unpack that "obfuscated" file with 7z and run the uefi extraction tool again on it.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
It not work with 7z, not a valid archive, but I done it manualy with hex editor. Need to be removed some parts of the section0.guid to get valid gz archive :)
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Wow! Didn't know anything about great tool. And didn't know that xbl contain all this ton of pe files, bmps...etc

Edit:

interesting stufs if uefi pe files, TzDxe.pe contin scm things related to cmnlib and tzxfl, generaly all things related to trustlets, i2c.pe spi.pe ... a lot more
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
Maybe a bit off topic, but still interesting: in case of xz2, there is a difference with camera functionality if you unlock on fw 52.0.A.3.84 or any older or if you unlock on 52.0.A.3.126 or any newer fw version.

In the first case you would always get black camera preview with any newer fw.

In the second case, it would be ok.

See the never fixed bug on sony github here:

https://github.com/sonyxperiadev/bug_tracker/issues/261

It is interesting that the change is only about one byte change in tzsuntory blob - see the post#990.

The tzsuntory blob is part of the fw, not part of the bootloader, but it is possibly very important with regard to drm keys even in case of xz1c.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
Quick Update:

I ran Diaphora against all version of TrustZone, diffing every version with the previous one, and as result I got that the 104/105/106/107 are the same binary(100% match), the 110 and the 114 differ from the 104-107 series for some fixes regarding the "BMIC" and "/dev/BIMCError" anyone know what are they?

In the attachment, there is a report of the matched/unmatched function in the diffing process
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Jerpelea is working in sony on stock roms as maintainer?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
Here are trust zone applets present in most of the xz1c firmware versions available, including tzsuntory.

My guess: if there should be a bug in some trust zone component, it is more likely to be in sony specific stuff than in qualcomm provided components.

I've also included my diffing results (zero size means no change in the main part of the applet). The scripts to make the diff are included too.

For analysis/disassembly, the unify_trustlet tool with 64bit support is needed (already mentioned by [MENTION=4120742]munjeni[/MENTION]), there is a pull request with that available here.

Following versions included:

G8441-47.1.A.2.281
G8441-47.1.A.2.297-GLOBAL-GDIALER
G8441-47.1.A.2.300
G8441-47.1.A.2.324
G8441-47.1.A.2.374
G8441-47.1.A.5.51
G8441-47.1.A.7.1
G8441-47.1.A.8.49
G8441-47.1.A.12.34
G8441-47.1.A.12.75
G8441-47.1.A.12.119
G8441-47.1.A.12.145
G8441-47.1.A.12.179
G8441-47.1.A.12.205
G8441-47.1.A.12.235
G8441-47.1.A.12.270
G8441-47.1.A.16.20
G8441-47.2.A.0.306
G8441-47.2.A.2.33
G8441-47.2.A.4.41
G8441-47.2.A.4.45
G8441-47.2.A.6.30
G8441-47.2.A.8.24
G8441-47.2.A.8.24-GLOBAL-GDIALER
G8441-47.2.A.10.28
G8441-47.2.A.10.45
G8441-47.2.A.10.62
G8441-47.2.A.10.80
G8441-47.2.A.10.107

At least following .mdt (tz applets) are included:

a530_zap
a540_zap
cmnlib64
cmnlib
fidocfg
fidocrypto
ipa_fws
tzattest
tzfingerprint
tzhdcp
tzsuntory
tztpm
tzwidevine
tzwvcpybuf

(the archive is highly compressed with 'xz', decompressed size is about 90MB)
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
Maybe also important: XFL component (responsible for sony flash mode, green led light) has changed from o77 to o79 and to o82 bootloader versions.

Any newer bootloader version still contains binary identical XFL kernel (including ramdisk and the loader/lilo in it) - the first fw version released with LA1_1_O_82 bootloader version has been the 47.1.A.12.235 oreo fw.

In addition to edits that added attachments in post#1253 with bootloader components, here are few more attached.

The pmic may be interesting due to that it changed only one time, from o77 to o79 bootloader version.

-- edit --

Added xz1c-xfl-lilo.tar.xz.zip attachment - the lilo/loader binary extracted from xfl sony flash mode kernel from bootloader versions o77, o79 and o82.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
And here the XBL - the main uefi bootloader - unpacked into internal components from all bootloader versions sorted each component to it's specific directory with proper filename extended with version tag.

Where possible for a file (like bitmaps) ungzipped.

It's a nice base to make differential analysis of XBL components (not to be confused with XFL).

ASN1X509Dxe/
AdcDxe/
ArmCpuDxe/
ArmGicDxe/
ArmTimerDxe/
BATTERY/
BDS_Menu/
BootCounterDxe/
ButtonsDxe/
CapsuleRuntimeDxe/
ChargerExDxe/
ChipInfo/
ClockDxe/
ConPlatformDxe/
ConSplitterDxe/
DALSys/
DALTLMM/
DevicePathDxe/
DiskIoDxe/
DisplayDxe/
DxeCore/
EmbeddedMonotonicCounter/
EmuVariableRuntimeDxe/
EnglishDxe/
EnvDxe/
Fat/
FontDxe/
FvSimpleFileSystem/
GlinkDxe/
GraphicsConsoleDxe/
HWIODxeDriver/
HashDxe/
HiiDatabase/
I2C/
LimitsDxe/
MazeDetDxe/
MdtpDxe/
MetronomeDxe/
MpPowerDxe/
NpaDxe/
PartitionDxe/
PlatformInfoDxeDriver/
PmicDxe/
PrintDxe/
QcomBds/
QcomChargerApp/
QcomChargerCfg/
QcomChargerDxeLA/
QdssDxe/
RealTimeClock/
ReportStatusCodeRouterRuntimeDxe/
ResetCfgDxe/
ResetRuntimeDxe/
RngDxe/
RuntimeDxe/
SPI/
SPMI/
SdccDxe/
SecParti/
SecRSADxe/
SecurityDxe/
SimpleTextInOutSerial/
SmemDxe/
SobaDxe/
StartFlagDxe/
StatusCodeHandlerRuntimeDxe/
TaDxe/
TsensDxe/
TzDxe/
UFSDxe/
ULogDxe/
UsbConfigDxe/
UsbDeviceDxe/
UsbMsdDxe/
UsbfnDwc3Dxe/
VerifiedBootDxe/
WatchdogTimer/
XBootPALDxe/
XDeviceTreeDxe/
XDisplayDxe/
XHwresetDxe/
XOemCertDxe/
XResetReasonDxe/
battery_symbol_LowBattery/
battery_symbol_LowBatteryCharging/
battery_symbol_NoBattery/
battery_symbol_Nocharger/
battery_symbol_Soc10/
logo_charging_600_1024/
logo_no_charging_600_1024/
logo_sony_1080_1920/
logo_sony_720_1280/
logo_xcs_1080_1920/
logo_xcs_720_1280/
tracer_event/
tsens_thermal_err_symbol/
tsens_thermal_symbol/
uefiplat/
verifiedboot_state_orange/
verifiedboot_state_orange_720/
verifiedboot_state_red/
verifiedboot_state_red_720/
xbl-uefi-main/
xbl-o77.mbn
xbl-o79.mbn
xbl-o82.mbn
xbl-p104.mbn
xbl-p105.mbn
xbl-p106.mbn
xbl-p107.mbn
xbl-p110.mbn
xbl-p114.mbn

[MENTION=7543898]Blu-eyes[/MENTION], just wondering, are you able to script ida analysis including diaphora execution, to automate it for multiple versions?

I am not:(

One interesting change in XBL of recent fw has been already pointed out in post#1073 concerning VerifiedBootDxe.pe change with added logs about tz fuses (since 47.2.A.10.107 fw version).
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] mirhl:
I'm not sure that has ever been claimed... He certainly is in direct contact with the guys responsible for that though.

At least officially, his job should be maintaining SODP tree and community.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Can we do some mapping and dumps via drivers/soc/qcom on kernel level regarding information from this post

Can I get all "cat /proc/ioxxxx" log from xz1c?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
#MemBase, MemSize, MemLabel(32 Char.), BuildHob, ResourceType, ResourceAttribute, MemoryType, CacheAttributes
#--------------------- DDR -----
0x80000000, 0x05800000, "Kernel", AddMem, SYS_MEM, SYS_MEM_CAP, Reserv, WRITE_BACK_XN
0x86000000, 0x00200000, "SMEM", AddMem, MEM_RES, UNCACHEABLE, Reserv, UNCACHED_UNBUFFERED_XN
0x94000000, 0x09400000, "DXE Heap", AddMem, SYS_MEM, SYS_MEM_CAP, Conv, WRITE_BACK_XN
0x9D400000, 0x02400000, "Display Reserved", AddMem, MEM_RES, SYS_MEM_CAP, LdData, WRITE_BACK_XN
0x9F800000, 0x00200000, "FV Region", AddMem, SYS_MEM, SYS_MEM_CAP, BsData, WRITE_BACK_XN
0x9FA00000, 0x00200000, "ABOOT FV", AddMem, SYS_MEM, SYS_MEM_CAP, Reserv, WRITE_BACK_XN
0x9FC00000, 0x00300000, "UEFI FD", AddMem, SYS_MEM, SYS_MEM_CAP, BsData, WRITE_BACK
0x9FF00000, 0x0008C000, "SEC Heap", AddMem, SYS_MEM, SYS_MEM_CAP, BsData, WRITE_BACK_XN
0x9FF8C000, 0x00001000, "CPU Vectors", AddMem, SYS_MEM, SYS_MEM_CAP, BsData, WRITE_BACK
0x9FF8D000, 0x00003000, "MMU PageTables", AddMem, SYS_MEM, SYS_MEM_CAP, BsData, WRITE_BACK_XN
0x9FF90000, 0x00040000, "UEFI Stack", AddMem, SYS_MEM, SYS_MEM_CAP, BsData, WRITE_BACK_XN
0x9FFD0000, 0x00027000, "DBI Dump", AddMem, SYS_MEM, SYS_MEM_CAP, RtData, WRITE_BACK_XN
0x9FFF7000, 0x00008000, "Log Buffer", AddMem, SYS_MEM, SYS_MEM_CAP, RtData, WRITE_BACK_XN
0x9FFFF000, 0x00001000, "Info Blk", AddMem, SYS_MEM, SYS_MEM_CAP, RtData, WRITE_BACK_XN

folowing one match e.g.

80000000-857fffff : System RAM
80080000-81dfffff : Kernel code
82800000-82e3bfff : Kernel data

Seems all MemoryType = Reserv is accessible trought kernel?

Edit:

80000000-857fffff : System RAM
88f00000-8aafffff : System RAM
95300000-ffafffff : System RAM

Seems the most is accessible?

Edit:

Or for example:

0x05026000, 0x00002000, "GPMU_DRAM", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x0502A000, 0x00002000, "GPMU_BLOCK0", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE
0x05030000, 0x00002000, "GPU_ISENSE", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE

05000000-0503ffff : kgsl-3d0
05040000-0504ffff : /soc/arm,smmu-kgsl@5040000

Seems many of the registers memory regions is accessible too :)

This one is interesting

0x00780000, 0x00007000, "SECURITY CONTROL", AddDev, MMAP_IO, UNCACHEABLE, MmIO, NS_DEVICE

Or this one

0x9FFFF000, 0x00001000, "Info Blk", AddMem, SYS_MEM, SYS_MEM_CAP, RtData, WRITE_BACK_XN
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
The lilo/loader is using physical memory access via /dev/mem to interface with tz or bootloader in order to read some information (at least what I can see, there may be more if not writes too).

It also loads content from tzxfl partition, extracts it with tar and loads that tzloader applet via qseecom api probably to access some tz functions (qfuses?).
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
yes see https://xdaforums.com/showpost.php?p=80511607&postcount=1242 , tzxfl I'm believing doing something with SW FUSES whatever that mean. SW fuses I think is not one time programmable, I'm believing its just software fuses (e.g. some programmable software flags eg.g like one found year-two in devinfo partition related to bootloader lock-unlock flag at offsets 0x10 and 0x18 of the devinfo partition which is for (security reason?) moved from devinfo to tz probably)
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
Here's to you _Url_remover_due_diaphora changes, to load into IDA the diffed Database use the diaphora_load script, or open the ".dhiapora" file, that is basically a sqlite3 database with result

The diffing process needs to be "opimized" now I diff every possible combination of all file database created

Edit:

If somehow know how use sql under python, we could make the script to output a report of all match/unmatched function

Edit2: Added diff_Report_Tool
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Out of topic, just to share :)

1. jbc t245 general purpose handle (done)

2. heat gun (in plan)

3. digital led controler (inplemented only analog, plan to make it digitaly controled)

4. digital microscope (done)

5. everything touch screen controled e.g.(in plan)

6. move from pi zero w to pi 3A+ or pi 4 to use with 7" display (in plan)

7. After all done right make good enclosure (in plan)

This is what I have doing in spare time. Everything is based on raspberry pi.

Prototype = 3 in 1 (revork station, soldering station, microscope) :)

Some pictures of the prototype
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Lilo kernel and android kernel is diferent about 5mb in size and in most case have qsee things diferent than kernel from android. Did you tried to boot lilo kernel?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
The difference in size is obvious, the reason is different kernel config, xfl kernel is stripped down of network/wifi support and other big stuff. But qseemcom driver is the same in both.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Do we know that for sure?

Ufs info: H28U62301AMR the sime like on LG-LS993 , ufs can be accessed trought kernel scsi , just to share if it can be usefull for something.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
From log seem that SElinux or similar are blocking the loading, probably checking sepolicy/ context file from xfl ramdisk can be usefull
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=7543898]Blu-eyes[/MENTION], it is running in permissive mode - see the permissive=1 in each log entry.

The means the action has been allowed but normally it would not be, if it did not run in permissive mode. But it is, so it is just logged, telling us, what happens there.

-- edit --

BTW, stock XFL is running in permissive mode too!
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
What might mean error -3 ? Can it be that some truslets is allready in use?

Error -22 mean "qseecom_ioctl: failed load_app request: -22"

Sat Feb 13 05:01:20 1971

xflattest fail because of:

02-13 05:01:20.379 629 629 D QSEECOMAPI: App is already loaded QSEE and app id = 131074

APP id = 196611 is OK. Where we can see the name of the app id 131074 ?

Edit:

Google search gaved me this result:

QSEECOM: qseecom_load_app: App with id 131074 (tzfingerprint) now loaded

It might be that we will need to make some aplications in ramdisk to unload tzfingerprint trustlet before loader start. Or maybe on kernel level do that first

Edit:

Can you change kernel log level via ramdisk to give more logs?