yashsingh1/xdaforums huggingface dataset:
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4120742]munjeni[/MENTION], in my opinion it is much safer to use in-fw-api to write some units where the ta stack (in form of 'tad') would take care of all consistency checksums calculations automatically vs using a tool based on reverse engineering of some old sony phone (respect to that in any case).

If in-fw-api is able to modify 66671 ta unit it may as well be able to modify 66667 ta unit in a safe way.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
You're right. But be carefull since we don't know what will happen if 66667 didn't pass verification! In case somebody try that than it is useful to try use unlock key and put inside 66667, who knows maybe it going to pass verification.

Edit:

I put tool public in case somebody need.

Hey hey, I forgot something but now I found it and it might be interesting. Opendeveloper program gaved some years ago option "enable recovery mode", its gone curently from their site (with reason?), it need to be flashed with the name "openbootloader" but I have snifed its usb protocol and found what was flashed there, it was just one ta file:

0000084f 0054 1A CE 28 00 01 00 06 05 00 02 02 51 00 10 03 00 02 04 02 05 00 01 03 02 00 10 05 00 03 03 05 00 10 05 00 05 83 02 00 10 02 00 05 85 0A 00 02 00 A9 09 BE BA A9 09 00 00 04 00 03 00 02 00 04 00 04 00 B0 04 0E 00 06 00 B8 0B 01 4B 00 00 00 03 96 00 2C 01

000008fd 0001 00

This thing enables recovery mode on z1c! We are looking for boot overide? :) Unit 84F seems machine code for overiding-patching some bootloader functions?

It replace non recovery mode:

0000084F 0049 1A CE 1D 00 01 00 04 05 00 02 02 51 00 10 03 00
02 04 02 05 00 01 03 02 00 10 05 00 03 03 05 00
10 0A 00 02 00 A9 09 BE BA A9 09 00 00 04 00 03
00 02 00 04 00 04 00 B0 04 0E 00 06 00 B8 0B 01
4B 00 00 00 03 96 00 2C 01

0x8fd unit not exist in that case.

Can you please give me 3 units from your trim area:

0x7D3 (s1 boot sin file)

0x84f

0x8fd (startup reason overide unit)
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Just made comparison on [MENTION=4418980]j4nn[/MENTION] trim area dumps, this is all diferences I have found:

1. trim area partition 1 (trim partition), no changes.

2. trim area partition 2 (misc partition), all changes is down in table

------------------------------------------------------------------------------------------------
UNLOCKED BOOTLOADER | LOCKED BOOTLOADER
------------------------------------------------------------------------------------------------
unit size data unit size data
------------------------------------------------------------------------------------------------
00000805 0004 4D010000 | 00000805 0004 34010000
DELETED | 0001046B 0010 xxxxxxxxxxxxxxxxxxxx //device key
000008B8 0001 07 | 000008B8 0001 0A
000009BB 1000 (huge data) | 000009BB 1000 (huge data)
0000271C 0008 000000005D37D66B | 0000271C 0008 000000005A85FEBF
0000080B (log) | 0000080B (log)
0000080D (log) | 0000080D (log)
000009AB (flash log) | 000009AB (flash log)
0000080E (log) | 0000080E (log)
00000804 (log) | 00000804 (log)
00000803 (log) | 00000803 (log)
00000802 (last boot log) | 00000802 (last boot log)
0000271B 0002 0003 | 0000271B 0002 0005
00002710 0000 | 00002710 0008 000001619BA23F9B
000008A4 0000 (ac version) | 000008A4 000E 0000000000000000000000000000 (ac version)
00000808 (log) | 00000808 (log)
00000809 (log) | 00000809 (log)
0000080A (log) | 0000080A (log)
0000080C (log) | 0000080C (log)
0001046F 0000 (google lock) | 0001046F 0004 01000000 (google lock)

One thing which I found is no unit 0x8b2 in unlocked bootloader trim area dump! Thats probably writen to some unknown location and thats reason why restoring trim area no more working. :)

But on other side there is 3 calls to read_ta(0x8b2) inside abl-o77.pe , interesting. Can it be bootloader allow lock by presence of unit 0x8b2 inside trim area? See sub_9640() , rpmb lock is involved in same functon

Edit:

If I understand corectly sub_9640, unlocking is done by writing unit 0x8b2, than unit 0x8b2 is deleted, than master reset is set to 2, than XFlattest Lock RPMB SW fuse.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
The abl-o77.pe is from xz1c, the TA images are from xz2, you need to use abl-xz2-p118.pe from post#1199 to match the TA images.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
OMG I have used wrong file :( , reason why some of my post about sub_ didn't match yours
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4120742]munjeni[/MENTION], if I compare very early TA backup images that are not influenced by a full android boot after unlock from fastboot (I did boot instead my custom kernel bootimage right after unlock via fastboot boot), there are only these two changes if we skip the TA units with bootloader logs (and obviously the erased DK unit):

--- TA-xz2-locked/0x00805.bin.hex
+++ TA-xz2-unlocked/0x00805.bin.hex
@@ -1,2 +1,2 @@
-00000000 21 01 00 00
+00000000 39 01 00 00
00000004
--- TA-xz2-locked/0x009f6.bin.hex
+++ TA-xz2-unlocked/0x009f6.bin.hex
@@ -1,2 +1,2 @@
-00000000 00
+00000000 01
00000001
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Ok it might be true. Post above was what I found in your ta images by pm

From right .pe its sub_163F4 , procedure is similar to one from previous .pe except I didn't see XFlattest Lock RPMB SW fuse at the end.

This is how unlocking is done:

read 8b2 -> delete 8b2 -> get unlock status -> delee dk -> reset rollback counters -> update unlock status -> delete user sensitive partitions -> update rpmb (curently missing in this .pe or I not see it)

Edit:

It seems data from unit 0x8b2 is writen to RPMB via sub_447C ?

Edit:

mean this:

v47 = sub_41934(2i64, 0x8B2u, (__int64)&v165, v163);
if ( (_DWORD)v47 )
{
sub_447C(v47);
__setReg(18, (void *)v48);
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4120742]munjeni[/MENTION], the BL unlocking internal procedure on recent devices has been nicely described by [MENTION=3665957]the_laser[/MENTION] in this post.

My experience with xz1c seems to match that.

I am afraid the unlock itself is made persistent by a qualcomm fuse get blown.

While checking for unlock code and setting related TA units is done in ABL, I am not sure if the unlock itself is there too - it's done on reboot.

The important question is however why present DK does not work - I've outlined some ideas about that in my previous posts, like here.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Based on the_laser post no.1 is known allready

no 1.) Unit 8b2 writen -> units 8b2 and 1046b deleted, master reset set to 2

I didn't know about (no.2) So its seems posible for locking bootloader by similar way but instead of 8b2 it use unit 0x8bd which need to be signed. But why unit 1046b need to be deleted when it is allready deleted? Thats something unclear there. It seems unit 1046b is generated and writen to trim area trough locking routine.

About your question about dk, it not working because something hold "lock status" unrelated to unit 1046b whatever it is present or not inside trim area, thats what I'm believing. Unit 0x8bd (unlock status) I'm believing is the same 256 bit hash (hash, key, whatever it is) like dk and 8b2
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] kojak1989:
[MENTION=4418980]j4nn[/MENTION]

Hi, you write that to use twrp must be bootloader unlocked but in hide unlock thread you write something about to use twrp with boot twrp without flashing it, so it will be available?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] ecksdeeay:
Without flashing twrp the Sony updates will be able to install by doing what's in the description.

I haven't done it that way, just my understanding
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] kojak1989:
I'm talking about installing custom roms with new root exploit that j4nn will release, he said that for twrp it must be bl unlocked but in other thread he mentioned about using twrp without flashing it that's why I'm asking.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] vofferz:
I would say that it's impossible to install custom firmware without unlocking bootloader as the locked bootloader checks that the firmware is signed by Sony for the device.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] kojak1989:
When device is booted but if it only boot to fastboot and don't boot to system maybe is possible
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=5520227]kojak1989[/MENTION], no it's not possible to use fastboot for anything with locked bootloader. Not even for switch between A/B in case of XZ2. The kernel-hiding threads - that's completely unrelated - the kernel hides the unlock status on runtime so that drm stuff can work after drm keys had been restored from locked TA backup. There is no way to hide the bootloader unlocked warning screen on boot nor relock the bootloader.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
These "keys" are also present on the tz of the XZ1(G8341).

And in the Asus novaGO(https://sorel.pixconfig.fr/NovaGo/dev-analysis/sde20.txt)
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
It might be the variant from the same source code and might be for no use.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
Here [MENTION=4418980]j4nn[/MENTION] say that it has compared the devinfo and they locked the same at least for XZ1C

https://xdaforums.com/showpost.php?p=80432253&postcount=1183

https://xdaforums.com/showpost.php?p=77820873&postcount=153
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Interesting. sub_27D3C tells that dev info is updated but didn't tell where excatly :( Can it be in devinfo_bak? On another slot e.g. slot_b, or hiden by kernel level somehow

If the_laser is right flashing this file https://xdaforums.com/showpost.php?p=73524154&postcount=375 after relocking bootloader by restoring trim area dump device locks again, anybody tried?

---------- Post added at 10:37 PM ---------- Previous post was at 09:57 PM ----------

Can you give me stock kernel source code git link? Does stock kernel have rpmb user space interface?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
https://developer.sony.com/develop/open-devices/downloads/open-source-archives

Here's the Git link https://github.com/sonyxperiadev/kernel but I don't know if is the stock or the open source one

As Far I know only Trust Zone can interact to RMPB, the kernel will interact with trustzone via qseecom.c (in this file you can see the authenticate/write/read function)
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] pbarrette:
Two things to point out with that:

1 - That "devinfo.sin" file was signed by "x_root_flash_5ada".

You'll note from the contents of "boot_delivery.xml" that 5ADA seems to be a test and development signing key.

2 - The "devinfo.sin" file is basically empty.

So all it really does is wipe your devinfo partition clean.

- Looks like I may be wrong about the above. It's 1 byte in size, so it looks like it might just clear the first byte of the partition.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
A donation was received on Wed 09 Oct 2019 06:45:07 AM UTC. Thank you.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] mirhl:
That's SODP one.

The stock ones from the archives above sit in kernel-copyleft (even though the github is not updated so often)
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
2. Its empty because need to save some more space, but all partitions before flash got firstly erased with command e.g. erase:devinfo than flashed

E.g.

1. problem might be "test and development signing key", its not going to work e.g on precomercial :( But I'm believing we can use ssd.sin file which is empty too and modify newflasher a bit to instead of using "ssd" as a name for command use "devinfo" for example (in case bootoader didn't check file name already it will flash devinfo).
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] pbarrette:
Yes, I get that it's small because it's compressed.

I was simply noting that it's really small because it actually contains no real data.

The data to be placed into the partition is "00" and that's it.

Also, the "devinfo" name is used as the filename for both the CMS signature file and for the TAR file that holds that 1 byte of data. So I don't think you're going to be able to trick the SIN flasher in the bootloader. Even if it ignores that, or if you repack the SIN file, you'll find that the CMS signature also references the partition name, so you'd then fail the signature check.

My point is that, if it's just a single byte, it might be easier to just use "dd" to overwrite the first byte instead of trying to flash a SIN file.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
Let's say we could gain code execution in the xfl/loader (the .sin flasher aka sony service/flash mode, green led light).

Could that allow us to re-lock bootloader?

In my opinion XFL mode may have higher permissions with regard to TrustZone calls vs general android kernel code execution.

Having code execution in the loader could allow us to simulate flashing of not signed .sin files in theory, if we bypassed the signature check in the loader.

In my opinion the signature of .sin files is used only for flashing authorization - the signature itself is not flashed.

There are 'oem lock' and 'oem unlock' commands implemented in the xfl lilo/loader binary too for what ever reason (normally you are supposed to use fastboot mode handled by ABL).

Concerning devinfo, I totally agree with [MENTION=4782500]pbarrette[/MENTION].

In my opinion it is either not used at all or if it was used, there would need to be a shadow content of it filtered by TrustZone/monitor/hypervisor as [MENTION=7543898]Blu-eyes[/MENTION] mentioned in the post#1196 (and I believe that is very possible if not for devinfo than for other part of the ufs flash).

Attached the loader binaries from xz1c and xz2 firmwares.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
Not necessarily.

Let summary the XZ1 Boot Process from Exception Level perspective:

When you press the power button the BootRom, will provide some basic initialization and passes the control to XBL

XBL then will load all side firmware like rmp and pmic and trustzone and hypervisor and then it will load the EFI LinuxLoader.

Let's check at what exception level these firmware are running:

XBL one of the "most priviliged" precess in the boot chain itself run on EL1:

https://imgur.com/J0XjczF

So also LinuxLoader will be loaded at EL1.

The TZ is loaded at EL3

https://imgur.com/Zc1TDee

and Hyp Is loaded at EL2

https://imgur.com/rkWDoeS

So the EL2 and EL3 Exception Level are held by Hypervisor and TrustZone, and are reached by the corresponding hvc(hypervisor call) and smc( secure monitor call), when this call is issued the processor will look at VBAR_ELx and here will find where the vector table is located, and execute the code that is located at predefined offset (http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka16352.html), and will handle the call.

http://shell-storm.org/armv8-a/ISA_v84A_A64_xml_00bet7/xhtml/hvc.html

http://shell-storm.org/armv8-a/ISA_v84A_A64_xml_00bet7/xhtml/smc.html

So we can say Android kernel and XFL one, run on the same exception level(EL1, you can check this by Disassembly the kernel, and checking on which VBAR_ELx the kernel will register itself for svc(supervisor call) ).

Probably the XFL issue some "exotic" SMC command to put trust zone to a special mode, but the command if properly crafted can be sended by hand by "manually" issuing an SMC call, from the EL1 context (kernel),

https://github.com/sonyxperiadev/ke...cc65ba9fd6f513a8669fb/arch/arm/mach-msm/scm.c

Here the implementation of the scm(Secure Channel Manage) to issue the smc(secure monitor Call), you can see here the asm call to smc.

I'm not 100% sure of what I written(I hope it's not terribly wrong), probably I forgot some Permission register, or other think.

Btw, to run for example an unsigned boot.img from xfl, We need something like Kexec, or there is another way to boot a kernel from a kernel(the XFL is a stipped android kernel running the lilo binary, I'm right???)
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=7543898]Blu-eyes[/MENTION], that is good info and I think you are most likely right about everything as it fits also my general understanding without knowing some details you've mentioned.

But what I had in mind: ABL knows it starts XFL, i.e. it starts some android kernel, but it knows, it is sony service mode kernel, with verified signature, so in theory, ABL (or the layer above it, as ABL is not standalone, it also uses some api) may enable some service SMC calls that are not normally enabled in normal android system - only to provide XFL the possibility for some system functions, that would be activated only with special flashing commands that are signature authenticated (and there are such commands, I guess [MENTION=4120742]munjeni[/MENTION] might confirm that).

It is only a theory, so you may be right, that there is nothing to see, but the possibility for special TZ api calls only available in "Sony Service Mode" could also be real.

In that case it would not work to simulate those calls within normal android kernel booted in "Sony Mission Mode" (the normal android boot).

There may be multiple ways to get code execution in XFL/loader, one of them may be exploiting usb flashing protocol for example (sony service mode flashing protocol seems to be based on fastboot protocol with some extensions).

So the question is - would it be worth to try to find an exploit to gain code execution within XFL/loader?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
For getting clear idea read this plase (5 beautifull blog posts)https://github.com/alephsecurity/firehorse

This one mght be interesting too https://github.com/laginimaineb/fuzz_zone

extract mbn tustlets and some openssl simulations on signatures -> http://bits-please.blogspot.com/2016/04/exploring-qualcomms-secure-execution.html

Not working https://github.com/laginimaineb/unify_trustlet

some ida tools for trustlets https://googleprojectzero.blogspot.com/2017/07/trust-issues-exploiting-trustzone-tees.html

have modified unify_trustlet.py for aarch64 mdt

import sys, os, struct

ELF_HEADER_SIZE = 0x40
E_PHNUM_OFFSET = 0x38
PHDR_SIZE = 0x38
P_FILESZ_OFFSET = 0x20
P_OFFSET_OFFSET = 0x8

def main():

#Reading the arguments
if len(sys.argv) != 4:
print "USAGE: <TRUSTLET_DIR> <TRUSTLET_NAME> <OUTPUT_FILE_PATH>"
return
trustlet_dir = sys.argv[1]
trustlet_name = sys.argv[2]
output_file_path = sys.argv[3]

#Reading the ELF header from the ".mdt" file
mdt = open(os.path.join(trustlet_dir, "%s.mdt" % trustlet_name), "rb")
elf_header = mdt.read(ELF_HEADER_SIZE)
phnum = struct.unpack("<H", elf_header[E_PHNUM_OFFSET:E_PHNUM_OFFSET+2])[0]
print "[+] Found %d program headers" % phnum

#Reading each of the program headers and copying the relevant chunk
output_file = open(output_file_path, 'wb')
for i in range(0, phnum):

#Reading the PHDR
print "[+] Reading PHDR %d" % i
phdr = mdt.read(PHDR_SIZE)
p_filesz = struct.unpack("<I", phdr[P_FILESZ_OFFSET:P_FILESZ_OFFSET+4])[0]
p_offset= struct.unpack("<I", phdr[P_OFFSET_OFFSET:P_OFFSET_OFFSET+4])[0]
print "[+] Size: 0x%08X, Offset: 0x%08X" % (p_filesz, p_offset)

if p_filesz == 0:
print "[+] Empty block, skipping"
continue #There's no backing block

#Copying out the data in the block
block = open(os.path.join(trustlet_dir, "%s.b%02d" % (trustlet_name, i)), 'rb').read()
output_file.seek(p_offset, 0)
output_file.write(block)

mdt.close()
output_file.close()

if __name__ == "__main__":
main()
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
But did you analysed sub_xxx function ? It clearly claims "update DevInfo" at end of that function. By quoting...

...DevInfo inside that sub have many meanings, one might be devinfo partition but also might mean something diferent e.g. rpmb, I have no idea right now. We can only gues that devinfo partition is not used, but what about if important part of that partition is protected and returns zero while dumping by DD? Anybody tried to write to devinfo partition? One thing is easy for test and confirm. If writing to devinfo partition while root and it return error than it confirms my gues, but in case it didn't return error and it realy write something to devinfo at specific location e.g. at offset 0x10 and 0x18 than definitelly that mean that devinfo partition is not used at all. Until somebody confirm we can gues only.

---------- Post added at 07:02 PM ---------- Previous post was at 06:55 PM ----------

Yes! Can't confirm if it was the same kernel but its definitelly packed into android boot image format and lilo is inside regular ramdik. Lilo is our loader which interacting with newflasher, flashtool, emma, spcc.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] xtess3ractx:
Will not allow me to flash this firmware on a g8343
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=5740317]xtess3ractx[/MENTION], I am sorry to hear that, the thing is that G8341 and G8343 share the same kernel config - poplar_diffconfig - that means they can run the same kernel binary. If flashing 8341 fw into G8343 phone is refused with some error, that would not be nice, but the only thing you could try would be to get the same version fw released for G8343 assuming that the kernel in it would binary match the one in G8341 fw (maybe except the .sin signature).

Does your G8343 allow you to do bootloader unlock?

Is it sim-locked to any particular gsm operator?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4120742]munjeni[/MENTION], I've seen those firehorse exploit blogs. Unfortunately I see two problems:

we do not know how to enter EDL mode with our sony phones

even if we could get into EDL mode, we do not have sony signed firehorse programmer boot image (or did you find one?)

I believe the "Write Device Info" function (which the error log refers to) is the sub_2112C (of xz2 abl) - that function calls dynamic functions, resolving "verified boot protocol". So I would assume it's not a simple partition write. It may hold the same devinfo structure, but most likely is stored somewhere else (or shadowed or filtered by TZ/hyp/mon) and that is why even ABL needs to call VB stack to make the changes.

Mentioning you in the post#1231 I meant you probably know about SAKE auth restricted (or other signature needing) commands in sony flash mode, considering you've implemented newflasher.

Imagine we could bypass those checks - could that help in some way?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Regarding post 1231, yes, its good idea! Since xfl is able to flash bootloaders it is for sure working in privileged mode. Does xfl store debug log in trim area? One more thing, xfl is an boot image which contain standard ramdisk with lilo. What about if we replace that boot image with an android boot image? E.g. run android in privileged mode?

SAKE uthentification, I don't know right now if we even is able to call sake trought newflasher, didn't tried.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
Simple, you get a Hard brick,

the image is not only checked for signature but also checked if the signature matches the expected image

From https://www.qualcomm.com/media/docu...e-authentication-technical-overview-v2-0.pdf:
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
I mean signed boot image signed with sony priv key e.g. boot image from stock rom, will it work? Kernel.sin when extracted is also an .img format like xfl from sin!

Edit:

It might be no partition space for storing boot image

Edit:

You're right, .img do not have signature, signature of the xfl is somewhere else and it will definitelly not work.

Edit:

Searching for bug in lilo might be a nightmare.

Edit:

Regarding android .img in our case stock kernel image which is when extracted from .sin is in .img format do not have digital certificate at the end of .img but xfl.img have exception and do have it at end of file.