yashsingh1/xdaforums huggingface dataset:
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Dmesg log and repeated mesages about tzflattest match repeated mesagge in your previous post inside log.log. It would be great if you add some more patches inside kernel to print app id and also to print local time. See my previous post, repeating error is probably caused by already loaded tzflattest.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4120742]munjeni[/MENTION], in my opinion it repeats simply because the loader is calling it multiple times.

There is no error when loading tz app blob - in fact it looks like the extracted tzxfl/tzloader is loaded just fine.

Concerning the time - it is wrong, probably simply because there is no code to restore system time from rtc (like it is not within xfl kernel/initramfs).

My ramdisk is bare bone, based on xfl ramdisk - instead of starting only the loader, it starts only adbd.

I then need to start logd manually and swith usb config to combination of adbd and xfl/loader.

So there is nothing that would previously load any tz applet.

Except the bootloader itself, which clearly loads some to populate TZ and verify boot images.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
The above qseecom change is against kernel source version for 47.1.A.8.49 (just happend to have source of that one used last).

As you can see, the __qseecom_send_cmd() with the change _always_ logs the appid (even in case it would end with error just in the beginning).

So unless some other kernel function is used, these are the only calls made via qseecom api from the loader - calling "tzxflattest" applet.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
But please look carefully, it fail at 09:20:37 bacause of app id 131074 is allready loaded! It would be great if you add one more patch to kernel to print app id too.

log.log

$ adb shell
~ # cat /log.log
INIT: Sat Feb 13 09:20:37 1971
[ERROR @ keystore.c:319]:

logcat

02-13 09:20:37.152 699 699 D QSEECOMAPI: QSEECom_get_handle sb_length = 0x1000
02-13 09:20:37.152 699 699 D QSEECOMAPI: App is already loaded QSEE and app id = 131074

Can this work for time?

struct timeval now;
struct tm tm_val;

do_gettimeofday(&now);
time_to_tm(now.tv_sec, 0, &tm_val);
printk("%02d:%02d:%02d\n", tm_val.tm_hour, tm_val.tm_min, tm_val.tm_sec);

---------- Post added at 10:31 PM ---------- Previous post was at 10:23 PM ----------

I do not see app id in your dmesg
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
It is logged a bit before:

[ 701.335405] QSEECOM: qseecom_load_app: App (tzloader) does'nt exist, loading apps for first time
[ 701.369222] QSEECOM: qseecom_load_app: App with id 196611 (tzloader) now loaded

right after loader unpacks it.

The "already loaded" messages is in my opinion not an error, but just a notice/warning.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
I agree in case kernel side, but in case loader side its seems loader want to load it but it was allready loaded and it is probably our case for error.

---------- Post added at 10:45 PM ---------- Previous post was at 10:41 PM ----------

No its not, see:

02-13 01:51:51.315 788 788 D QSEECOMAPI: app_arch = 1, total_files = 9
02-13 01:51:51.350 788 788 D QSEECOMAPI: Loaded image: APP id = 196611

Error is excatly at 09:20:37 at the same time after this:

02-13 09:20:37.152 699 699 D QSEECOMAPI: QSEECom_get_handle sb_length = 0x1000
02-13 09:20:37.152 699 699 D QSEECOMAPI: App is already loaded QSEE and app id = 131074
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
If you check the loader-o79, the sub_CBAAC is referencing the "App is already loaded QSEE" string.

For that case it returns -4 as the result code. That result code is ignored (being checked from 0xCB694 .text address) in the sub_CC6DC - the function continues with ION memory allocation.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Ok. What is a name of the app with id 131074 ?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
I will check it, but my guess is that it is the "tzxflattest" as logged in the patched kernel log.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
Check the last commit, I forgot to enable the USE_DECOPILER_OPTION, so add that line if you need it
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
[MENTION=4418980]j4nn[/MENTION] , no. Scm is bridge between normall world and secure world and it may work. I'm unsure why tzXflAttest is in use allready. Tz XFL Attest app is I'm believing part related to XFL? Can it be possible that XFL is allready in background? One thing might be good for try, to do qseecom_unload_app (e.g. implement it till after this /* SCM_CALL to check if app_id for the mentioned app exists */), when you call qseecom_unload_app it will return success or error (Can't unload app with id %d (it is inuse)). In that case we can know if we have problem with app_allready_in_use or problem with permission in comunication between normal world and secure world. I'm believing problem is only that app_in_use. Can you try?

app in use might have two meaning (this is what I thinked)

if (qseecom_unload_app(app with id = 131074) == ERROR)
{
// error 1 - can't unlod (might mean error 2 too)
// error 2 - nobody can reuse app since its in use and busy
goto skip;
}

// load app for the first time
goto skip2;

skip:
// don't load for the first time

skip2:
// continue
}
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4120742]munjeni[/MENTION], I am sorry but I am not sure I follow what you mean. In my opinion, the applet being loaded already is perfectly ok.

Have you checked my post#1288 - as far as I can see in the loader disassembly, the "already loaded" message is just a notice/warning, the code does not go into an error branch in that case.

In my opinion the 'tzxflattest' applet is used for all the attestations, to check signatures validity, rooting status, etc.

And it is loaded already, because ABL used it before starting the main android kernel (in case of normal boot) or it is loaded even in case of xfl kernel boot, because that needs to be verified too.

Check the abl.pe binary, the 'tzxflattest' string is there and it is used with QseecomStartApp function.

There is nothing like "xfl" in background, if we do not consider TZ/hyp/mon. There are just many kernel threads and the few processes I've listed with "ps -ef | grep -v ' \['" command.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Ok. If I decide to buy xz1c (it will probably not happen since this is what I want to buy) I will try some things by myself, just no want to waste your time and my time too (wasted allready a lot of years), good luck!
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4120742]munjeni[/MENTION], I do appreciate your help so far, it is definitely not about wasting my time.

I just did not understand what you wanted me to test with your last post.

I am just trying to get all the facts to hopefully find some hole.

So it is a shame you leaving, but I can understand that - wish I had more time myself.

Thank you for your support.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
Checking 'tzxflattest-o82' applet, there is a sub_70 with a 'switch' construct (in the beginning checking size of response buffer) - there is a 'case 7' which may correspond to command id#7, possibly the first byte of our req buffer showed in the posted dmesg log.

This 'case 7' calls sub_6C0 which is most likely get_raw_sec_data() api call as can be derived from the present log.

In the beginning this function checks qword_8048 for zero and in that case it returns 0xFFFFFFFD - that could match our RSP data (00000000: fd ff ff ff) returned from qseecom driver.

This branch of the function logs "get_raw_sec_data: xflsecdata is empty" message before returning that result code.

If the above is really corresponding to what is called from lilo/loader (and it could be, as it tries to obtain security and rooting status) - the reason would be that qword_8048 pointer has not been initialized.

It should get a memory allocated to hold raw sec data. It may be this is initialized only in case of XFL boot (by call of qseecom cmd#6?).

There are other interesting functions as may be derived from presents logs, like set_sec_data, qsee_blow_sw_fuse, get_rpmb_sector, ...
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
Probably, when you boot to xfl this pointer is filled up, and xbl set the MMU to map a physical memory to virtual one.

Or probably set different memory mapping for different boot mode.

Searching for TTBR0_EL3 in xbl and looking for different register settings, could confirm or deny this hypothesis.

P.S. to get friendly arm name like ttrb0_el3 vbar... Etc you need to use ida FRIEND plugin
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Excatly what I think. Guessed types - pointers which I have mentioned in earlier posts. it might be possible that it is populated by tzxflattest. But since it is populaed in some memory regions which is not accessible trought "normal world" you will probaably can try to unload app tzxflattest and load it before you start lilo. I have mentioned it in my previous post. I'm unable to explain it very good since my english is limited, and probably you not getting what I mean.

Can you post your qseecom.c ? I will add thing from my previous post for test with lilo.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
Here is the qseecom.c with the described changes attached.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=7543898]Blu-eyes[/MENTION], that friend plugin is really nice. Thanks for the tip.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Here is for test
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] bartys:
Is temp root available for xz2 or are you working on it and we can expect it in near future?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4120742]munjeni[/MENTION], unfortunately it seems not to boot, I am not sure why, there is no pstore log.
[MENTION=6248091]bartys[/MENTION], temp root for xz2 is not available. I've managed to get first stage to backup locked TA, but that does not help after unlock - see older posts here...
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
My wrong. I thinked function which contain string "allready loaded" seen in dmesg log was inside function qseecom_load_app but I see now , string "allready loaded" in dmesg log is from function qseecom_query_app_loaded . I have moved modification now to the qseecom_query_app_loaded function
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] kojak1989:
[MENTION=4418980]j4nn[/MENTION]

Hi, i have problem with reno root on android 9 to start, i make a backup of my TA partion on android 8 but now i unlock my bl on android 9 and i trying to make reno root for restore my ta.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] shoey63:
[MENTION=5520227]kojak1989[/MENTION]

Renoroot does not work on Pie. You can flash twrp and do restore command in twrp terminal or shell on pc. Even terminal emulator on the rooted device.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Shady_BlackSn0w:
[MENTION=4418980]j4nn[/MENTION]

Quick question is your new exploit compatible with this new update ?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] 4rz0:
Speaking of exploit, may this be relevant for our devices?

https://github.com/grant-h/qu1ckr00t
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Can you please post that update file, I want to reverse enginer it and make decompiler for it.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Shady_BlackSn0w:
[MENTION=4120742]munjeni[/MENTION] You want the FTF or the unpacked one?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
No. Is not that file an OTA encrypted file?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
Most likely.

I guess it could be used on (or ported for) any fw up to oreo. But not with any pie fw version.

Your link leads to poc.c which links to the bug which shows the fix. The changed code is present in sony kernel source code since the first pie fw release (47.2.A.0.306).

The new fw (47.2.A.11.228) contains the same bootloader version (p114) as the 47.2.A.10.107 fw.

What might have changed with regard to TZ - the tz applets present inside android part of the fw.

I can check and post that, if this is what you mean.

-- edit --

Here are the tz applets extracted from the fw. In my opinion they are exactly the same, only re-signed.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
@4jnn thanks. One strange thing there is no line in dmesg from qseecom_load_app about tzxflattest, there is only from function qseecom_query_app_loaded which indicate that tzxflattest is seems not loaded again, it might be that I have missing something. Do you have idea how can we force 1. unload tzxflattest and 2. force load? Thing which I want to achieve and thing which I'm believing is that tzxflattest if loaded from the same "world" in our case if we load lilo and reload tzxflattest in the same time tzxflattest will populate memory region to the same world (memory region) as lilo, in that case I'm believing lilo will be abble to access that tzxflattest populated memory region.

About ota I meant small ota over the air update, one which is an small update which is installed trought stock android, not an ftf. I want to reverse enginer that over the air ota update, make an decompiler.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4120742]munjeni[/MENTION], In my opinion, the tzxflattest applet is never unloaded even though the call to unload it returns OK result code.

That is why the next query still returns that it is still loaded.

Most likely that applet is not meant to be ever unloaded/reloaded, as it is also suggested in the kernel source, where it is checked to skip in case of unload attempt.

Even if it was really unloaded, it would not be easy to load it again - there is probably no support for that in XFL.

Certainly the blob is not present in the XFL initramfs.

I guess it would need userspace support to load it from somewhere (like directly from partition), similarly like the tzloader is loaded from the lilo/loader app, but most likely this is not implemented in that app.

Do you like to see how ota update package looks like when the phone is doing the ota update?

I also wondered about that. It should be possible to check that while we can have root during ota update with BLU hiding kernel.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
I think its unloaded corectly! See:

Another idication which tells that "munjeni" patch have miss to load 131072 truslet:

Failed to start tzxflattest tz app. (-1)

Unload is seems achieved corecly because error -1 mean "truslet doesn't exist" ? We now only need to force load tzxflattest from kernel side.

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

Yes, excatly what I need.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
In my opinion, it does not get unloaded - you see with subsequent queries TZ replies it is still present.

The lilo/loader reports error because your changes do not fill the query response data - so the lilo/loader thinks that the applet is not loaded, but it still is, since next query call returns the success query data again as can be seen from the kernel log.

What you like the ota package from the phone for if I may ask?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
I see :(

3430.314830] QSEECOM: qseecom_query_app_loaded: App id 131074 (tzxflattest) already exists
[ 3430.314842] QSEECOM: qseecom_query_app_loaded: munjeni: Try removing app_id 131074, hope it get reloaded
[ 3430.314846] QSEECOM: qseecom_query_app_loaded: munjeni: success unloading app_id 131074
[ 3430.316319] QSEECOM: qseecom_query_app_loaded: App id 131074 (tzxflattest) already exists
[ 3430.316324] QSEECOM: qseecom_query_app_loaded: munjeni: Try removing app_id 131074, hope it get reloaded
[ 3430.316329] QSEECOM: qseecom_query_app_loaded: munjeni: success unloading app_id 131074
[ 3430.325918] QSEECOM: qseecom_query_app_loaded: App id 131074 (tzxflattest) already exists
[ 3430.325925] QSEECOM: qseecom_query_app_loaded: munjeni: Try removing app_id 131074, hope it get reloaded
[ 3430.325929] QSEECOM: qseecom_query_app_loaded: munjeni: success unloading app_id 131074
[ 3430.332565] QSEECOM: qseecom_query_app_loaded: App id 131074 (tzxflattest) already exists
[ 3430.332570] QSEECOM: qseecom_query_app_loaded: munjeni: Try removing app_id 131074, hope it get reloaded
[ 3430.332572] QSEECOM: qseecom_query_app_loaded: munjeni: success unloading app_id 131074
[ 3430.339722] QSEECOM: qseecom_query_app_loaded: App id 131074 (tzxflattest) already exists
[ 3430.339726] QSEECOM: qseecom_query_app_loaded: munjeni: Try removing app_id 131074, hope it get reloaded
[ 3430.339729] QSEECOM: qseecom_query_app_loaded: munjeni: success unloading app_id 131074

It indicate that something outside kernel repeatedly reload it after we unload it from kernel side, might be xbl repeatedly reload it? It might mean too that we didn't realy unloaded it. Nevermind, it seems not working.

I wanted to do it many years ago but never done it, simple didn't had time to at least make an good look on that file. I'm believing its easy to reverse enginer by lookng into fotarecovery recovery binary
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4120742]munjeni[/MENTION], it is called repeatedly because the lilo/loader calls it repeatedly, the same as it queries the root status and other things with repeated calls.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Two things I need to finish finaly:

1. to make fota unpack tool

2. to finish this (done)

---------- Post added at 10:58 AM ---------- Previous post was at 10:56 AM ----------

I am confused now. Didn't you said that lilo loads only one trustlet (not that tzxflattest)?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4120742]munjeni[/MENTION], yes, it _loads_ just the tzloader. But it _queries_ if tzxflattest applet is loaded before each call to it. Those calls are probably in a 'cmd' function, so with each command call, query is called too.

At least this is how it looks to me.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Ok. Than this have two meaning:

1. kernel patch didn't realy unloaded tzxflattest

2. kernel unloaded tzxflattest but tzxflattest is momentaly reloaded outside of kernel probably by xbl and prevent us to load it trought kernel
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4120742]munjeni[/MENTION], or tz simply ignores the unload request for certain applets and returns ok status for the unload regardless not unloading it. Similarly like the kernel avoids unload of the two applets.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
It might be true. It would be usefull adding small update to patch e.g. after we call munjeni_unload_app in function repeatedly do another call munjeni_load_app just for getting what dmesg will say. It probably will give "ok" but it would be usefull if we try that to be sure. Thats what I wanted to achieve from the start.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4120742]munjeni[/MENTION], you could try that, but it would not be simple. In my opinion, that call would need to be accompanied by loading of the tz applet blob.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
Here it is - has been stored in internal storage:

https://www.androidfilehost.com/?fid=1899786940962612305

-- edit --

I am afraid this would be encrypted somehow - it could be downloaded from internal storage directly using MTP usb transfer, no root required at all.

Added also a screenshot to see matching size (401.4MB). With the next screenshot note the 'recovery' folder in the internal storage.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4120742]munjeni[/MENTION], I've managed to get root during installation of the above fota update, there is /sbin/fota-ua process running and it works with '/cache/recovery' directory.

It most likely decrypts the 'recovery' directory from internal storage into a temp file in '/cache/recovery', but it looks like stream lined - there is a changing /cache/recovery/fota/tmp/fw_backup file of about 112MB size.

I've copied few snapshots during the installation - it is uploaded here:

https://www.androidfilehost.com/?fid=1899786940962612567
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
I'm unable to test thing without having device, whole thing is done with android uncrypt tool or some sony variant

// This program takes a file on an ext4 filesystem and produces a list
// of the blocks that file occupies, which enables the file contents
// to be read directly from the block device without mounting the
// filesystem.
//
// If the filesystem is using an encrypted block device, it will also
// read the file and rewrite it to the same blocks of the underlying
// (unencrypted) block device, so the file contents can be read
// without the need for the decryption key.
//
// The output of this program is a "block map" which looks like this:
//
// /dev/block/platform/msm_sdcc.1/by-name/userdata # block device
// 49652 4096 # file size in bytes, block size
// 3 # count of block ranges
// 1000 1008 # block range 0
// 2100 2102 # ... block range 1
// 30 33 # ... block range 2
//
// Each block range represents a half-open interval; the line "30 33"
// reprents the blocks [30, 31, 32].
//
// Recovery can take this block map file and retrieve the underlying
// file data to use as an update package.

This is what I'm getting on ubuntu

./uncrypt ./update_package_renamed ./block.map

/dev/block/bootdevice/by-name/userdata
420897111 4096
8
2054144 2056192
2068480 2070528
2064384 2068480
2600960 2613248
2877440 2881536
23273472 23281664
23312384 23318528
23330816 23394663

Since have no device to try I have hardcoded uncrypt on ubuntu to use encryptable=yes and encrypted=no , I'm believing you can test allready existing tool in /system/bin/uncrypt , if update_package is encrypted do in mind it will write to your block device and make your android unbootable!
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4120742]munjeni[/MENTION], in my opinion, you are focusing on something not that important.

Most likely the purpose of the 'uncrypt' tool is only to allow recovery boot to access the downloaded update package from encrypted data parttion without needing user to provide decryption keys (in form of pin, fingerprint, whatever he has setup as unlock way).

In other words, the fota package as uploaded, is stored directly into the mapped blocks and recovery running 'fota-ua' would read the same file from the mapped blocks, without need to mount the userdata encrypted partition.

So I believe you could skip this step - the same file content (still fota encrypted) is accessed by 'fota-ua' in recovery boot.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
It would be hard. update_package_renamed is I think an scattered sin file, at the end of the update_package_renamed is start of the sin file (sin header only), when I extract sin header with hex editor and try to decompile it with sin extractor getting some good information, see picture

Without sin header, data size is excatly like in sin header (blue)

Some logs I found on google

http://webcache.googleusercontent.c.../report-txt.221775/+&cd=1&hl=en&ct=clnk&gl=rs

https://pastebin.com/DqfuN8Vp

In most case we need to look into p_ctx part

Edit:

I'm sorry this is hard for my head, looking almost for two hours into ua binary and hex of the ota package, have realy no idea what to do next. How p_ctx->package.inc array calculate address? Most likely this is not a sin file as I thinked, sin header here is just to verify size of the data, verify signature and certificate, nothing more.