[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4120742]munjeni[/MENTION], you can just extract partition.zip in fw package, those .sin files there contain just the GPT of all the 3 LUNs.

The problem is the UFS flash has 4096 bytes sized sectors, so that is the unit GPT uses too - on PC having it in a file using fdisk that understands GPT is not good - I could not make it use 4096 byte sectors.

But if I transfer the unpacked gpt image to the phone, where I have fdisk supporting gpt, I can list the same GPT from /dev/sda as well as from the extracted gpt from the .sin file.

Here is the partition layout directly from the xz1c phone:

Note: sector size is 4096 (not 512)
Found valid GPT with protective MBR; using GPT

Disk /dev/block/sda: 62480384 sectors, 59.5M
Logical sector size: 4096
Disk identifier (GUID): 98101b32-bbe2-4bf2-a06e-2bb33d000c20
Partition table holds up to 66 entries
First usable sector is 6, last usable sector is 7810042

Number Start (sector) End (sector) Size Code Name
1 6 517 512 0700 TA
2 518 4613 4096 0700 LTALabel
3 4614 4741 128 0700 rpm
4 4742 4869 128 0700 rpmbak
5 4870 5381 512 0700 tz
6 5382 5893 512 0700 tzbak
7 5894 6021 128 0700 hyp
8 6022 6149 128 0700 hypbak
9 6150 6277 128 0700 pmic
10 6278 6405 128 0700 pmicbak
11 6406 6789 384 0700 abl
12 6790 7173 384 0700 ablbak
13 7174 7174 1 0700 devinfo
14 7175 7302 128 0700 keymaster
15 7303 7430 128 0700 keymasterbak
16 7431 7558 128 0700 cmnlib
17 7559 7686 128 0700 cmnlibbak
18 7687 7814 128 0700 cmnlib64
19 7815 7942 128 0700 cmnlib64bak
20 7943 8454 512 0700 sti
21 8455 8486 32 0700 devcfg
22 8487 8518 32 0700 devcfgbak
23 8519 8550 32 0700 storsec
24 8551 8582 32 0700 storsecbak
25 8583 16262 7680 0700 xfl
26 16263 23942 7680 0700 xflbak
27 23943 24070 128 0700 tzxflattest
28 24071 24198 128 0700 tzxflattestbak
29 24199 24326 128 0700 tzxfl
30 24327 24454 128 0700 tzxflbak
31 24455 24486 32 0700 xflkeystore
32 24487 24518 32 0700 xflkeystorebak
33 24519 32710 8192 0700 persist
34 32711 33094 384 0700 fsg
35 33095 33098 4 0700 sec
36 33099 61258 28160 0700 modem
37 61259 65354 4096 0700 dsp
38 65355 81738 16384 0700 boot
39 81739 81994 256 0700 bluetooth
40 81995 82058 64 0700 apdp
41 82059 82122 64 0700 msadp
42 82123 82123 1 0700 dpo
43 82124 90479 8356 0700 splash
44 90480 90480 1 0700 limits
45 90481 90736 256 0700 toolsfv
46 90737 92784 2048 0700 logfs
47 92785 109168 16384 0700 FOTAKernel
48 109169 109424 256 0700 ddr
49 109425 109936 512 0700 modemst1
50 109937 110448 512 0700 modemst2
51 110449 110449 1 0700 fsc
52 110450 110451 2 0700 ssd
53 110452 207731 97280 0700 cache
54 207732 207987 256 0700 misc
55 207988 208115 128 0700 keystore
56 208116 208243 128 0700 frp
57 208244 208259 16 0700 vbmeta
58 208260 212355 4096 0700 appslog
59 212356 220547 8192 0700 diag
60 220548 226691 6144 0700 Qnovo
61 226692 226948 257 0700 fsmetadata
62 226949 235140 8192 0700 rdimage
63 235141 337540 100K 0700 oem
64 337541 730756 384K 0700 vendor
65 730757 2010756 1250K 0700 system
66 2010757 7810042 5663K 0700 userdata

Note: sector size is 4096 (not 512)
Found valid GPT with protective MBR; using GPT

Disk /dev/block/sdb: 8192 sectors, 8192
Logical sector size: 4096
Disk identifier (GUID): 98101b32-bbe2-4bf2-a06e-2bb33d000c20
Partition table holds up to 1 entries
First usable sector is 6, last usable sector is 1018

Number Start (sector) End (sector) Size Code Name
1 6 1018 1013 0700 xbl

Note: sector size is 4096 (not 512)
Found valid GPT with protective MBR; using GPT

Disk /dev/block/sdc: 8192 sectors, 8192
Logical sector size: 4096
Disk identifier (GUID): 98101b32-bbe2-4bf2-a06e-2bb33d000c20
Partition table holds up to 1 entries
First usable sector is 6, last usable sector is 1018

Number Start (sector) End (sector) Size Code Name
1 6 1018 1013 0700 xblbak

I've tried once again to intercept the fota update, with following results:

when you click to install it, there is a progress for few seconds, not sure what it is doing, but when it rebooted, the main kernel has been booted again, but not to runtime android - there was the 'verify update' progress. This means this phase, whatever has been done there, is not handled by fota-ua in the FOTAKernel, but by something in the 'boot' kernel (there is fota-ua binary too, exactly the same as in fotakernel) - possibly the difference may be access to userdata decryption in main kernel?

The 'misc' partition contains 'bootonce-bootloader' string - not sure if it's important.

Kernel command line contained startup=0x00008004 warmboot=0x77665502 settings.

There has been following content in cache partition, under 'recovery':

$ cat block.map
/dev/block/bootdevice/by-name/userdata
420897111 4096
2
5279744 5310464
5312512 5384551

$ cat command
--update_package=@/cache/recovery/block.map
--locale=en_GB
$ cat uncrypt_file
/data/media/0/recovery/update_package_renamed

$ cat uncrypt_status
uncrypt_time: 4

$ hexdump -C last_log.gz
00000000 1f 8b 08 00 f1 8c ae 5d 00 03 |.......]..|
0000000a

I've tried to read the update package file using the mapfile info with dd command, like this:

dd if=/dev/block/bootdevice/by-name/userdata of=${DIR}/blockfile-5279744.img bs=4096 skip=5279744 count=$((5310464 - 5279744))
dd if=/dev/block/bootdevice/by-name/userdata of=${DIR}/blockfile-5312512.img bs=4096 skip=5312512 count=$((5384551 - 5312512))

The two files if concatenated would result with a slightly bigger file rounding to 4096 block size.

But for some reason the content has been different than the original update package file present in internal storage.

I am not sure what I am doing wrong - I've expected to read the same file from the block map.

Instead it looks like the userdata filesystem encryption has still been involved - maybe it did not yet go through the uncrypt process?

I've assumed that should have been done right after clicking 'install' button still on the main android runtime before rebooting to fota update.

Maybe the dd command/offsets should be done differently?

Unfortunately the update did not go through this time (possibly verification failed for some reason), so that is basically all.

But it at least outlines the very start of the fota process - the posted stuff is not in-the-middle snapshot, but a snapshot before starting fota-ua, including surrounding info like startup/warmboot flags and misc partition content.