yashsingh1/xdaforums huggingface dataset:
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] mirhl:
Veeeery cool (lol, this seems almost like hacking a game console)

Don't forget that all cpus should be affected by Spectre then (and 845 also meltdown afaiu)

In fact, the original paper specifically attacked an 835.

Some protection was already merged in december though.

EDIT: funny first arm exploit guide
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
Not sure if spectre could help us or if there is any useful exploit actually available for arm64/android.

As it is about getting not accessible data, it might be possible to use it to find out the kernel slide to bypass KASLR?

Maybe you/someone can research & test it?

You know guys, I have never implemented any exploit, this is my first time!

Likely a very big challenge to begin with something like android 8.0 with all those security mitigations in place.

But I see it as any other programming/development and an opportunity to learn new things.

You know, the source code for the test described in post#104 has about 3200 lines currently and we are still at the start.

It would be great if some devs step in to help with the development. Particularly the kaslr bypass is a pretty independent task.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] miniletsgo:
Hi j4nn,

Really good work so far! Doing some research, I found a PDF from BlackHat that may help you:

blackhat.com/docs/asia-18/asia-18-WANG-KSMA-Breaking-Android-kernel-isolation-and-Rooting-with-ARM-MMU-features.pdf

I'm working on getting a build env setup for qemu and android to try to help out on your work. Is your latest 'mytest' code available? Also trying to read relevant portions of the ARM v8 A Reference Manual.. Most of this stuff is a bit over my head, but you inspired me stating it's your first exploit to work on. Keep up the good work and thank you for your help!

:good:
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=5180591]miniletsgo[/MENTION], not to be picky, but reading the first page of this thread, you would see me mentioning that pdf in post#5 already. I got lot of the ideas from that pdf, it was helpful, but it is also very simplified, the biggest problem with delayed kfree from kfree_rcu (which I have described in post#33, post#44 and post#48 posts) is not mentioned at all.

My code is not publicly available. I might consider releasing it, if there is proven interest (by experienced linux developers) to help with the development - this was not the case so far unfortunately.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] notaz:
For KASLR (and kernel memory dumping in general) CVE-2017-18344 would help if CONFIG_CHECKPOINT_RESTORE was enabled. Unfortunately it isn't for the kernel on my phone at least, but that has all the updates. To check it on older firmwares it's enough to see if /proc/self/timers exists.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=9191353]notaz[/MENTION], thanks for the idea, unfortunately it seems to be disabled by default - it is not enabled in 47.1.A.2.281 fw (checked inkernel config extracted from the fw) and not enabled in 47.1.A.8.49 fw either.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] tommy17:
I know it might seem completely out of topic, but I've been following the thread since the beginning and I just wanted to let you know that I'm sure there are a lot of people like me that are really grateful for what you are trying to achieve!

Keep you the great work ;)
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
I am afraid this would not help us, at least not with regard to KASLR - we would need meltdown instead, i.e. the Variant 3 and according to info from arm, only Cortex-A75 is vulnerable. Snapdragon 835 has Kryo 280 cores and those are based most probably according to annandtech on Cortex-A53 (for low power cores) and either Cortex-A72 or Cortex-A73 (for high performance cores).

I am not sure what Variant 3a (CVE-2018-3640) and Variant 4 (CVE-2018-3639) actually mean - is 3a a variant of meltdown?

What is Variant 4? That could work on 835 as it is stated as yes for both A72 and A73, Variant 3a only for A72.

It looks more probable that 835 has A73, so Variant 3a is probably also out of question.

Can we use somehow Variant 4? Is any poc available?

Please note, we need to pin any poc to high performance cores when testing as the low power A53 is not vulnerable according to arm.

-- edit --

The Variant 4 is a new spectre variant, so probably no use for us either.

I guess only chance would be if Kryo 280 was based on A72 (not very probable) then the Variant 3a of meltdown could work - if poc for V3a is available, we might test that.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Raz0Rfail:
Hi, today I got news about the "at commands" to access the android modem. I don't know if it's possible to get information about system data or push something into system partition:

https://atcommands.org

German news article:

https://www.golem.de/news/at-comman...rch-modem-befehle-verwundbar-1808-136205.html
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] WheelchairArtist:
Hi, another vulnerability we might can use could be this CVE-2018-9445

I was able to mount my sdcard at /mnt/## as mentioned in the writeup but couldn't further test because of missing the right hardware (computer won't switch usb into client-mode).

Also another writeup of the kernel space mirroring attack used by ReVent Rooting Solution in conjunction with CVE-2017-7533. It might be useful.

And this brings me to following thoughts (please correct me if i am wrong):

1. we have a working exploit and can write to kernel space.

2. we need to bypass kaslr, pan and pxn. This is done in the slide via the mirroring attack. For this we need to get the kernel slide and then attach the payload to kernel address “0xFFFFFFC230002000”

3. the kernel slide is calculated by leaking the address of a inode and then reading ‘i_op’ of this inode. On Google i found this article about bypassing kaslr. This should be patched in the kernel and according to the patch there shouldn't be any memory address in "/proc/*id*/stat", but on the first run i got the exact same result as in the article and after reboot i got a other value (kernel address + slide?). So please forgive me if this is complete nonsense, but it seems this patch is not present on our device and we still can use this to get the kernel slide once we get the kernel address of a system with kaslr disabled?? I am running build 47.1.A.5.51 with kernel 4.4.78 btw.

4. once we have all this done we need to disable selinux, which is done by writing ‘0’ to the mirroring addresses of ‘selinux_enable’ and ‘selinux_enforcing’ according to the slide.

5. finally we need to patch a syscall to run our payload which is waiting in the mentioned mirroring address “0xFFFFFFC230002000”

@Raz0Rfail

I just tried this on my phone. atinteract.py wasn't able to find any interface and from the output of lsusb -v it doesn't look like there is another usb configuration to expose a interface to the modem.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=5505196]Raz0Rfail[/MENTION], interesting what can be achieved with at commands, but I am not sure if there is something we can use (have not studied it) - is there any way to enable unrestricted flashing with at commands with a sony phone?

[MENTION=7556135]WheelchairArtist[/MENTION], thanks, interesting finds.

About the kaslr and wchan - I am afraid, this is patched. Sony's source does contain the commit you've linked. And testing with 47.1.A.2.324 fw shows the kernel address is not present - I get just 1 value in the 35th field (the wchan). The field 30 also mentioned there is current instruction pointer and most likely contains only userspace address before switching to kernel with a system call (if blocked in kernel).

The CVE-2018-9445 looks very interesting. I do not have time to test that though and considering how far I got with the inotify/rename vulnerability, I am sticking with that one.

Current state is that I can trigger an overflow of a 256 bytes sized slub allocation unit. This is not yet an arbitrary kernel write, but that is what I am working on right now - need to shape the heap to make the overflow useful and have that rather reliable to avoid kernel crashes. I have some progress with qemu, but it seems not to be effective with the phone.

The mirroring attack looked wonderful since the beginning to me, but correct me if I am wrong, do we really need it?

I mean if we achieve (nearly) arbitrary kernel write with kaslr bypassed (which is a prerequisite to the mirroring attack), there should be also other ways to achieve the needed kernel space changes to get root with selinux disabled, should not be?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Raz0Rfail:
I just got the news about it today. I don't found an example how to trigger these at commands and what is possible with these commands. In the at database https://atcommands.org/atdb/ I found only old Sony devices with max Android 5.0.2 :(.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] DripleX:
There you can get the source code of the at-commands: https://github.com/FICS/atcmd

You can find the original code from 2016 here: https://github.com/ud2/advisories/tree/master/android/samsung/nocve-2016-0004

You can check the XZ1 with Linux :

Plugin the XZ1 to the USB Port

execute "lsusb" in terminal

Get the Sony XZ1 Device ID. It looks like: ID xxxx:xxxx

Execute "lsusb -d xxxx:xxxx -v | grep bNumConfigurations" in terminal

If you get "bNumConfigurations 1" the hack does not work, because you only have one USB mode.

This code and manual is not from myself.

I got this from golem.de (https://forum.golem.de/kommentare/s.../120162,5168850,5168850,read.html#msg-5168850) and translated it.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] nailyk:
Am ready to do some testings. Device unlocked, actually running [MENTION=3355564]derfy[/MENTION]t lineage. Switched to a nexus5 for the testing time. xz1c sitting on the desk waiting for some omnirom love and your instruction about helping you on this DRM crap.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
You can use a phone that is rooted and with a kernel that support fuse, next you need to compile fusermount code with Android ndk and run on the phone, finally you need to supply the file created by fusermount to the Android usb_gadget in the lun file

echo 0 > /sys/devices/virtual/android_usb/android0/enable
echo "mass_storage,adb" > /sys/class/android_usb/android0/functions
echo "path to the image to mount over usb" > /sys/devices/virtual/android_usb/android0/f_mass_storage/lun/file
echo 1 > /sys/devices/virtual/android_usb/android0/enable

I tried this on a galaxy S5 running LOS 15, it works when attached to a PC(I can see fusermount switching),

I haven't tried it on my phone because I'm running 47.1.A.12.270 that integrate August Patches, and I don't have a type c otg cable :crying:

If you need I can send you the Android ndk project and the compiled binary file
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
What about the devinfo partition on the XZ2 (about the yoshino,in post 154, you said that on these phone(yoshino) it doent's got touched)

#ifndef _DEVINFO_H_
#define _DEVINFO_H_

typedef struct device_info device_info;

#define DEVICE_MAGIC "ANDROID-BOOT!"
#define DEVICE_MAGIC_SIZE 13

struct device_info
{
unsigned char magic[DEVICE_MAGIC_SIZE];
bool is_unlocked;
bool is_tampered;
};

#endif

probably the unlock status is Fused in qfprom or written to RPMB, but I think a check on that partition is worth
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] shoey63:
Yeah, that's what I meant.

I was thinking about getting an xz3 for my next phone (also Tama), pending a TA backup exploit which you have now achieved, but I'll have to re-asess my options now.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=7543898]Blu-eyes[/MENTION], unfortunately I made a backup only of the TA partition with the XZ2.

I just assumed that it would be the same as with XZ1c - there I've compared devinfo partition before and after unlock and they have been exactly the same - they are probably not used.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] kaleyaki:
I wanted to root my xz1 to get viper4android however the process is very difficult and risky for me (I am very novice) should I resign myself to live without viper4android? greetings and thanks for your work
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Thats most possible. And if that is one time programmable that's the the end with ta backups mechanism we used earlier.

Might be some unused emmc space keeps some secrets? :)
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
I think that this is the most realistic scenario,

Here somebody thought a QSEE exploit written "manually" the (OTP) fuses and unlocked the bootloader(It's a quite old blogpost, before the XBL and UEFI):

http://bits-please.blogspot.com/2016/02/unlocking-motorola-bootloader.html

Probably the RPMB(Replay Protected Memory Block) can hold these "secrets", is the perfect candidate but this area of the UFS is secured by a sha-256 key (as stated here https://jaehyek.github.io/2014/05/22/eMMC-UFS-About-eMMC-1/ )
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
One thing which is not clear to me about rpmb is what about if I replace emmc, does I need to send new emmc to sony production line in order to write new rpmb secret key? Or it is writen by (trusted firmware environment in the field after eMMC/UFS/NVMe is replaced with a new one)? And another thing, does some hardware tools is able to wipe whole emmc including rpmb, does in that case rpmb access also need hmac?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] mirhl:
See this and here, everything should be covered.

(too bad JEDEC requires heaps of money for the emmc/UFS specs)

Also, the stuff I posted on page 108 I guess if you want to try to tinker with TZ.

Btw, couldn't WV and camera just require some tinkering with secd extensions?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
some idea about XZ2 device key to make it work

Checking the ABL (LinuxLoader.pe) of H8216-52.0.A.8.131 fw (LA2_0_P_118 bootloader version), there is a function at 0x03BE74 address, let's call it init_security_DK_decrypt.

This function seems to read the DeviceKey from 66667 (0x1046B) TA unit. It reads other phone unique identifiers, like IMEI, die id, "embedded roots" whatever that is and something from hwconfig - present in TA 2003 (0x07d3) unit - which is a sony signed blob.

It seems that the hwconfig contains half of the Device Key - there is also 16 bytes retrieved from hwconfig unit similarly as 16 bytes are expected to be read from 66667 TA unit.

The DK from hwconfig and DK from 66667 TA unit are XORed at 0x03CA10 address.

There is a function at 0x14CD0 address - let's call it xboot_publish_attestation.

This function clearly uses the DK (possibly the decrypted combination of DK from hwconfig and DK read from 66667 TA unit).

It also checks unlock status, uses IMEI, something from hwconf and "keystore xcs rot" whatever that might be.

It seems to me like maybe a hash of all the info might be computed in this function, but I am not sure.

Probably calling some attestation related function in TZ with all that info or it's hash.

The question is, if it was hashed including the unlock status?

Is so, it would be clear, that the restored DK would not work - and that it would behave the same like when it is lost, in which case ZERO DK is used by default.

On the other hand, it might be possible to revert the unlock influence by providing a different 66667 unit value to compensate for the calculation change after unlock?

That is obviously only if the calculation was fully analysed and if we were able to modify the 66667 unit safely.

There are TA partition images attached in the previous post, one may try to recompute the calculations using the data from relevant units.

There are functions in the fw writing into high area units, so it may be possible to write even the modified DK unit if we bypassed particular unit number checks.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
You can't bruteforce (modify and write another dk) that is imposible without root key (master signing key used in production). I have thinked for a years to try to understand and simulate dk <-> unlock_key using openssl but ended without idea how to simulate it. There is definitelly something related to HUK key, IMEI and some things from TA. Getting idea about simulating all that might be possible but getting to the HUK might be imposible. Without HUK I think its complete wasting of time at the start of thinking to simulate something.

This one is interesting:

Seems before unlocking bootloader "hash of data" (hash of dk??) is stored inside an (curently unknown place), so after unlocking bootloader (dk is deleted) new hash (of what??) replaced previous hash which is reason why restoring ta no more work, thats what I thinking. We need to identify location of that new hash. Is it in dtbo_a or boot_a? Is that partitions flashed trought entire ftf flash with newflasher? Seems these two partitions must be dumped in the same time while backing up ta? One thing need to be try before unlocking bootloader is dumping whole emmc with dd before unlocking and after that after unlocking trying to restore whole emmc dump, in that case we will be sure if "thing" lives inside an secure place or not.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4120742]munjeni[/MENTION], in my opinion, functions that are in the fw may be actually used to modify even the device key. There is following log in the my-xz2-locked-8.131-logcat.log file:

I tad : MiscTA Unit 66671:
I tad : WRITTEN (Size 4)
I tad : Actual erase/write to flash done (count 1, time 1569798068).
I tad : MiscTA: Write of unit 66671 completed - OK
I tad : MiscTA Unit 66671:
I tad : WRITTEN (Size 0)
I tad : Actual erase/write to flash done (count 2, time 1569798068).
I tad : MiscTA: Write of unit 66671 completed - OK

If unit 66671 can be written, most likely also the 66667 can be too, having root on the device.

The 'Hash of data does not match digest' - that is because I am using the bluhiding kernel.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
It can be writen yes but it will nover be corect hash (whatever it is). Did you see sub_1ED28 ? seems used with keystore for decryption? *a2; is 8 bytes len, seems function for getting hash?

Problem

guessed type __int64 __fastcall sub_207EC(_QWORD);
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4120742]munjeni[/MENTION], that is tad writing the unit. If you call the api, it will compute all checksums for you.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Blu-eyes:
So Apperar that RPMB is used olny for Verified Boot, if it used only by verified boot, it is useless IMO.

I aggre with the idea, but I think that is not applicable, afaik we could gain temp root, so we gain the ability to run code at EL1, so every code running at EL2(Hypervisor), or EL3 (Secure monitor) con intercept our call and deny/return all zero; so dumping with dd can lead an incomplete dump, and while restoring could lead to a hard bricked devices. To do in the " "safest" :confused:" way, we need to read the ufs directly, but this even less applicable(we need at least two devices to destroy, one for the pinout and the other for the dump/restore)

Edit:

Here https://www.nccgroup.trust/us/our-research/extracting-ecdsa-keys-from-qualcomms-trustzone/:
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] mtunc52:
Can xz1 be relocked again?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
https://github.com/nccgroup/cachegrab

---------- Post added at 05:00 PM ---------- Previous post was at 04:58 PM ----------

I don't know if we have the same sub_1ED28 but on mine this is what I mean:

signed __int64 __fastcall sub_1ED28(signed __int64 result, __int64 *a2, signed __int64 a3)
{
_QWORD *v3; // x6
signed __int64 v4; // x3
__int64 v5; // x4
__int64 v6; // x5
unsigned __int8 v7; // vf
signed __int64 i; // x2
__int64 v9; // x4
__int64 v10; // x5
__int64 v11; // x8
__int64 v12; // x9
__int64 v13; // x10
__int64 v14; // x11
__int64 v15; // x12
__int64 v16; // x13
signed __int64 j; // x2
__int64 v18; // x4
__int64 v19; // x5
__int64 v20; // t1
int v21; // t1
__int16 v22; // t1

v3 = (_QWORD *)result;
if ( a3 >= 64 )
{
v4 = -result & 0xF;
if ( v4 )
{
a3 -= v4;
v5 = *a2;
v6 = a2[1];
a2 = (__int64 *)((char *)a2 + v4);
*(_QWORD *)result = v5;
*(_QWORD *)(result + 8) = v6;
v3 = (_QWORD *)(result + v4);
}
v7 = __OFSUB__(a3, 64i64);
for ( i = a3 - 64; !((i < 0) ^ v7); v3 += 8 )
{
v7 = __OFSUB__(i, 64i64);
i -= 64i64;
v9 = *a2;
v10 = a2[1];
v11 = a2[2];
v12 = a2[3];
v13 = a2[4];
v14 = a2[5];
v15 = a2[6];
v16 = a2[7];
a2 += 8;
*v3 = v9;
v3[1] = v10;
v3[2] = v11;
v3[3] = v12;
v3[4] = v13;
v3[5] = v14;
v3[6] = v15;
v3[7] = v16;
}
a3 = i + 64;
}
v7 = __OFSUB__(a3, 16i64);
for ( j = a3 - 16; !((j < 0) ^ v7); v3 += 2 )
{
v18 = *a2;
v19 = a2[1];
a2 += 2;
v7 = __OFSUB__(j, 16i64);
j -= 16i64;
*v3 = v18;
v3[1] = v19;
}
if ( j & 8 )
{
v20 = *a2;
++a2;
*v3 = v20;
++v3;
}
if ( j & 4 )
{
v21 = *(_DWORD *)a2;
a2 = (__int64 *)((char *)a2 + 4);
*(_DWORD *)v3 = v21;
v3 = (_QWORD *)((char *)v3 + 4);
}
if ( j & 2 )
{
v22 = *(_WORD *)a2;
a2 = (__int64 *)((char *)a2 + 2);
*(_WORD *)v3 = v22;
v3 = (_QWORD *)((char *)v3 + 2);
}
if ( j & 1 )
*(_BYTE *)v3 = *(_BYTE *)a2;
return result;
}
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4120742]munjeni[/MENTION], everything I've written recently have concerned xz2 abl.te binary attached here.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4120742]munjeni[/MENTION], what I've meant by using fw api to write to TA units is that the fw uses that api to change for example 66671 ta unit as documented in the log. So it may be possible to use the same API (libmiscta.so) to write DK unit. It may be refused by 'tad' even when run under root user. But in case there is only a check for specific unit numbers in tad to be refused, that could be easily bypassed. In that case using the api would take care about proper consistency of TA partition calculating all checksums the same way as the fw changed the 66671 ta unit - if I am not mistaken, that has been the 'allow oem unlocking' toggled to on.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4120742]munjeni[/MENTION], in case some decryption key is calculated by use of DK from 66667 unit combined with the other part from hwconf and combined with other device specific ids, like imei and so on, it possibly may be salted also by "unlock state" or something depending on it.

But we have all input values, having the locked ta backup.

We could calculate the working output value from those inputs if the algorithm is properly reverse engineered.

If the influence of "unlock state" could be put into formula with a possibility to revert it's change by a change in DK part in 66667 ta unit, we could write a DK working in unlocked state.

There may be needed some level of brute force in the calculation but it also may not be needed, depending on what algorithm sony used.

All this is just a hypothesis assuming that the reason for not working restored DK is is the unlocked state itself.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Thing which I know on all older devices until z3, unlocking bootloader just replaces unit 66667 with unit 0x8b2, 0x8b2 is storage for unlock key, the rest of trim area modification is just logs, I compared it, deleted almost half of trim area which was changed...etc, device was locked after writing back 66667 unit and deleting unit 0x8b2. Didn't tried to keep booth units, my wrong.

You can use this tool to regenerate trim area dump if you hex modify something on it, it will recalculate adler hashes and reconstruct it propertly.