yashsingh1/xdaforums huggingface dataset:
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Pixel Shader™:
You guys I don't think you know what does a hard brick means. All you said is useless as nothing work. Plus I am not using a second phone. I only have mine which is dead now. My phone is no longer recognized by computer at all, so I can't do anything unless t is a hardmod which I am not gonna even consider it. Also, [MENTION=4418980]j4nn[/MENTION] I tried to restore the misc-locked, because, when I restored my TA-locked in Oreo I upgraded to Android Pie to continue rooting my phone and all, but then I noticed that X-reality and PS4 Remote Play no longer work. I checked the devices security and found out that all the key are lost including the Android attest keys. The camera was fine (I think it is because of Android Pie the camera is no longer take green pictures even without restoring TA?). So I assumed it is because of the other backups. I tried misc-locked and bump phone is hardbricked aka DEAD.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Almar033:
Ok sorry I have read too fast...

Really and sincerly sorry for you, hope you will find a solution.

Regards
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] kentaurest:
Maybe try Qualcomm QPST to fix the TA partition or use warranty and get a new phone.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] SGH-i200:
I had to delay the rooting to tomorrow.

I can't wait to hear the news! :svetius:
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Pixel Shader™:
[MENTION=4418980]j4nn[/MENTION] I did asked here why the restoration of my TA didn't make X-reality and Remote Play work before testing anything. Also I had that exact Pie version 47.2.A.0.306. When I saw things didn't work I returned back to the exploitable Oreo to check if things work and yeah everything seemed working camera, X-reality, Remote Play, etc. I was wondering why they don't work, so I restored the unlocked TA and upgraded back to Pie 47.2.A.0.306 to check and found out the camera still fine but the rest are not. I decided to restore the locked TA in Pie using the twrp it was restored but still nothing worked (except camera), so I returned back to the exploitable Oreo were everything worked just fine and then I said what would happen if I restored the misc and then upgrade to Pie? Will the X-reality and Remote Play work in Android Pie. I posted here, however, before getting a reply i have already tried the misc backup and bricked my phone before knowing that flashing the secd ignore will make X-reality work again as stated in the reply I've read. Anyway u said that ur bricked XZ1C was able to enter flashmod, so I was wondering if u were able to boot in fastboot and then executed the twrp booting code and tried to restore ur original TA back?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
I'm mentioned in post above your that console is disabled on production devices, see build prop value!

About exploit, did you found a working exploit publicly available for 32-bit kernels? I'm searching with no way to get it
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
If I understand corectly we need to spray object till after strcpy(event->name,file_name); right? How you use function add_key, how its working? In short we need to add some machine code into new file name which will modify inotify_handle event_function right? And what is a maximum bytes we can add to the new file name?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4120742]munjeni[/MENTION], it is unfortunately not that straightforward. What I've described, is just the first phase - a PoC to get overwrite of next slub unit.

The publicly available PoC (CVE-2017-7533 from offensive_poc git repo) does not do any overwrite, because it works only with filenames up to 32 characters, that are for performace reasons stored directly in dentry struct without using heap allocator.

So first we need to extend the PoC to work with longer filenames, we need more than 128 bytes as that is the minimal slub unit size in arm64 linux kernel.

This can be achieved with exploiting use after free.

The overwrite of next slub unit can be done with strcpy in the inotify event handler. The file_name points to the slub unit, to which old_name in the rename pointed, but was freed (in ideal case soon enough) by kfree_rcu in the copy_name function (in dcache.c). Since the allocation unit is freed, it may be allocated for something else.

If we are fast enough we may allocate that slub unit with the add_key syscall, which can place our arbitrary string there (it does not matter that the syscall fails - it allocates kernel memory just to check the parameters, see it in keyctl.c).

If all this is done before the strcpy, then the strcpy will copy whatever we provide with add_key instead of the original file name. If the string there is longer than can fit in the allocated memory for the inotify event, it would overflow the 256 bytes sized slub unit into a next one.

If we can craft this nearly reliably, the next phase could be started - force some useful struct into the next slub unit to be overwritten with our string from add_key.

But lets stay with the phase one.

The problem is, there is only very little time between strlen and strcpy in the kernel's inotify event handler.

Unfortunately the kfree_rcu (if I am not mistaken) does not free the old_name immediately.

Instead it seems to move the external_name struct to be freed into a list, which is used in background to reclaim the memory, possibly using kind of destructor callbacks of RCU subsystem. In case of kfree_rcu, the callback is simplified to just kfree.

So I am currently facing the problem, that kfree (probably from the rcu_reclaim background thread) is reliably called only if I add a sleep of about 15ms, but such time is too long for few function calls that are done between strlen and strcpy in the inotify event handler (which runs independently on another cpu core).

Considering the timing, it seems quite impossible to achieve - but it was demonstrated on that conference, that it is somehow possible.

So my questions still remain:

Is there any way I can force kfree_rcu called from vfs_rename (copy_name) to call kfree immediately?

Or is it possible to somehow stop Thread-1 in order to wait until the old name is freed with kfree and updated with add_key?

Is here anybody who could help debugging this on an unlocked device, so we could use modified kernel to provide feedback when trying to win the use after free race and tune the timing accordingly?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
I can't help I don't have 64 bit device :(

Don't understand how it works, but maybe use pthread mutex or maybe instead of usleep some loops for null checks for old_name, don't know realy, hard for my head realy.

---------- Post added at 09:34 PM ---------- Previous post was at 09:21 PM ----------

Anybody here with unlocked device? Is possible that nobody here have no free one hour time per day to help [MENTION=4418980]j4nn[/MENTION] and test his program on device? You want root guys? Help j4nn, you have a chance right now!
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4120742]munjeni[/MENTION], actually the vulnerability is quite general - I believe it would work the same on 32bit as well as 64bit architectures.

It may be possible that on other archs than arm64 it would work for smaller slub units than 128 or 256 bytes sized.

But even with those other archs you may select you want to target slub 256 and in that case the same procedure with use after free exploit would need to be used.

I guess the requirement to have any reasonable testing is arch with 4 and more cpu cores.

Concerning synchronization options - not really possible - you need to start inotify event at the same time as the rename, each on different cpu core, in order to start the strlen with the old name - this can be synchronized. But the event handler in kernel would finish very fast, while the kfree (from kfree_rcu) seems to be done in background much later.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] munjeni:
Sorry can't help, even I not understand how you used and where you placed add_key function.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
The rename in the poc causes kfree_rcu to free the old name used in kernel's filesystem subsystem.

If there was simply kfree in the copy_name instead of the kfree_rcu, I believe it would work great when add_key would be called from the application right after the rename from the same thread.

Unfortunately it seems not to work this way with kfree_rcu as kfree seems to be postponed.

If I add some checks in the kernel (when testing with qemu), I can trigger it with something like this:

rename()
<precise sleep for 20ms>
add_key()

If mdelay(22) is added before the strcpy in inotify_handle_event in the kernel, I can trigger the use after free exploit - but that requires waiting for 22ms in the kernel, which was not there.

The call to add_key is described in the slides as add_key("spray", payload, 0, 0, 0);

The first string does not matter, the second string is key description (see man add_key), for that parameter checking in add_key syscall, kmalloc (or some kind of strdup from userspace which uses kmalloc) is used.

It may be extended with third string instead of 0 providing it's length instead of the other 0 followed, then you would get two kmalloc calls from single add_key in a row, spraying the first and second free slub unit. The add_key call fails and calls kfree for previously allocated strings, but the memory is overwritten and we hope that it was the previously freed old_name place.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] moofesr:
[MENTION=4418980]j4nn[/MENTION] & [MENTION=4120742]munjeni[/MENTION] I've got a bootloader unlocked XZ1C right now (RIP DRM keys!) so if you need any help off me, let me know and I'll try to help out!

For your testing purposes, will it be an issue if I were to flash a DRM fix onto the phone or do you want the phone to remain "unfixed" without any DRM fix for your testing purposes? (it doesn't matter for now as I have another phone which I'm using as a daily driver)

One other thing in case it becomes relevant later: I'm on the March 2018 security patch in case you wish to compare against different firmwares.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Inerent:
I can help with XZ premium revert ed to nougat, but locked bootloader. Just pm what to do... Should i start with rampage apk? ?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=5697586]moofesr[/MENTION], thanks, that is great, I will try to prepare something, but it may take some time (quite busy right now). I assume a custom kernel will be needed. Ideal case would be if it could be just booted via fastboot without flashing. Followed by a test from adb shell.

I am not sure about drm fix or other patches required for root.

If there are such changes, would a different kernel boot normally?

Would stock kernel boot normally if flashed after drmfix/root?

It might be easier if stock unmodified fw is flashed, probably the 47.1.A.2.281 would be best, as that's the one I am testing with. Assuming the unlocked phone can boot unmodified stock fw normally (not considering the crippled green pics camera and other drm dependant components).

[MENTION=8615083]Inerent[/MENTION], rampage apk tested already, but with xz1c, see the post#41. Unless xz premium has different ram chips/design, I would not expect any success. In any case, there is no exploit publicly available, drammer/rh-test source is incomplete/old if compared to the apk, developing get root exploit based on this RAM bug would be in my opinion lot more difficult than inotify/rename one.

But surely try with your xz premium - it's always good if tried by multiple parties and since you have an older device, there is a chance, that it is vulnerable.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Inerent:
No bugs found in Oreo .179 but XZP can be reverted to android Nougat, which XZ1 can't. It's just hardware ram bug, not software also?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=5697586]moofesr[/MENTION], could you please test this kernel?

https://mega.nz/#!nTgj3ACI!FLN78E3CkgfWyOFyI2UZq4BfjNpRPoJjGkIEcyt7j7o

I guess it may be booted with

fastboot boot boot.img

but obviously I cannot check that. Or to flash it, use possibly

fastboot flash boot boot.img

(not checked either).

And here is a test tool:

https://mega.nz/#!SaonnQba!JIdqy-CKVrZwNE3LwaumDRFrXqoVXNB-Xqb8rgaK3dQ

After booting with the provided kernel, use adb to get the tool to the phone and start it like this please:

adb push mytest-linux /data/local/tmp
adb shell
cd /data/local/tmp
chmod 755 mytest-linux
./mytest-linux

The kernel changes with the test tool have been tested in qemu, so I hope we see something with the real device.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] 4rz0:
This may be of interest: https://github.com/JiounDai/Bluedroid
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] moofesr:
This doesn't appear to have gone as well as I'd have hoped it would. Here's how my flashing went:

C:\Flashtool\x10flasher_lib
λ fastboot flash boot xda_boot.img
target reported max download size of 536870912 bytes
sending 'boot' (20468 KB)...
OKAY [ 0.469s]
writing 'boot'...
OKAY [ 0.007s]
finished. total time: 0.486s

C:\Flashtool\x10flasher_lib
λ fastboot reboot
rebooting...

finished. total time: 0.007s

After rebooting, the phone is just stuck at the white screen with the Sony logo and stays like that with no movement and the only thing I can do is a forced reboot by pressing POWER + VOL UP at the same time.

I'm not sure why this has happened but could it because the kernel is incompatible with my firmware version? I suspect this might be because I hadn't downgraded to 47.1.A.2.281 (which is what you're currently using) and the kernel I flashed is designed specifically for 47.1.A.2.281?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] moofesr:
Update: So I was able to successfully restore my phone to working order and I even managed to downgrade my FW to the same version as j4nn (G8441_Commercial and Journalists_1309-6967_47.1.A.2.281_R1B).

Again, I flashed the image but it still results in a bootloop.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
Guys, I am sure you know what is needed to change to make a custom built kernel to boot with stock firmware.

Please advice, so I do not need to re-invent the wheel (particularly when the only way to test it is via a third party).

Some DM_VERITY options need to be switched off? Or that may not be needed if system partition is unmodified?

Or it still may be needed (off) because kernel contains new private key generated with custom build?

Anything else, like SELINUX stuff in ramdisk?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
There seems to be something missing when I build a kernel from sony sources - all builds tested on an unlocked xz1c by [MENTION=5697586]moofesr[/MENTION] (special thanks to him for his testing) resulted in a bootloop:

adb logcat via usb could not connect (suggestion to enable adb access with stock kernel booted before flashing test kernel did not help).

So we switched to G8441_DE_47.1.A.12.75 stock firmware and tested if it boots with [MENTION=490110]janjan[/MENTION]'s kernel from [KERNEL]/[BOOT]+[DRMFIX][MAGISK]Sony XZ1 Compact [G8441]-6-JULY-2018] thread - the [SONY-XZ1 Compact/[G8441][47.1.A.12.75][21/Feb/2018] one. Flashed only the full stock G8441_DE_47.1.A.12.75 firmware followed by the 1-boot.img from janjan's package via fastboot, nothing else (twrp not flashed). And it boots ok.

Tried to rebuild sony's xz1c kernel from source (commit with "47.1.A.12.75" comment of 47.1.A.12.xxx branch of https://github.com/sonyxperiadev/kernel-copyleft git repository), using build instructions from README_Xperia in the source tree.

Tested combined with ramdisk extracted from stock kernel boot image or ramdisk extracted from janjan's kernel.

Also tried with kernel config from janjan - none of the built kernels could boot - all resulted in a bootloop. Tried even to disable verity option in /system and /vendor mounts in device tree (by removal of "verify=..." option) - did not help.

Tried to use the same commandline from stock kernel or from janjan's, tried with and without buildvariant=userdebug, which is mentioned in the README_Xperia: no luck.

Here one of the last trials:

boot-12.75-jj.img - built from 47.1.A.12.75 unmodified sony kernel source with kenel config extracted from JanJan's kernel combined with ramdisk extracted from JanJan's kernel

I am using toolchain from https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9 git repository.

And mkbootimg script from https://android.googlesource.com/platform/system/core git repository 'android-8.0.0_r4' branch, 'mkbootimg' subdirectory - it seems to be a python script which does not need to be compiled.

Any idea what is wrong/missing so that built kernel results in a bootloop?

I would appreciate an opinion or help particularly from [MENTION=490110]janjan[/MENTION] who managed to somehow compile his kernel which boots stock fw successfully.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
git clone https://github.com/sonyxperiadev/kernel-copyleft kernel-copyleft-test
cd kernel-copyleft-test

git checkout -b 47.1.A.12.75 5679b97cecdb359ba8ae7e8870c938142d2593e6

export PATH=/path/to/aarch64-linux-android-4.9/bin:$PATH
export ARCH=arm64
export CROSS_COMPILE=aarch64-linux-android-
export KBUILD_DIFFCONFIG=lilac_diffconfig
export KBUILD_BUILD_USER=user
export KBUILD_BUILD_HOST=host

# for sony's default config:
make msmcortex-perf_defconfig O=../kernel-copyleft-test.out

# or just replaced ../kernel-copyleft-test.out/.config with one from janjan's kernel
# (extracted with extract-ikconfig script from splitted android image)
cp ../kernel-janjan/kernel.config ../kernel-copyleft-test.out/.config

# build the kernel
make O=../kernel-copyleft-test.out -j7

# create android boot image
../mkbootimg/mkbootimg \
--kernel ../kernel-copyleft-test.out/arch/arm64/boot/Image.gz-dtb \
--ramdisk "../kernel-janjan/ramdisk" \
--cmdline "androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x37 ehci-hcd.park=3 lpm_levels.sleep_disabled=1 sched_enable_hmp=1 sched_enable_power_aware=1 service_locator.enable=1 swiotlb=2048 androidboot.configfs=true androidboot.usbcontroller=a800000.dwc3 zram.backend=z3fold" \
--base 0x00000000 \
--kernel_offset 0x00008000 \
--ramdisk_offset 0x01000000 \
--tags_offset 0x00000100 \
--pagesize 4096 \
-o ../kernel-copyleft-test.out/boot-12.75-jj.img

Here is the 'ramdisk' used with mkbootimg above (it was extracted from janjan's 12.75 kernel):

ramdisk

it seems to be all right as it is possible to decompressed it with gzip and cpio.

Thanks.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] tonsofquestions:
I don't know what gives you the impression that we don't know what hard brick means. I certainly can relate; I've had it happen to me on phones, too.

The fact that j4nn could boot his into flash mode doesn't mean it wasn't hard-bricked - he still couldn't do anything with it, because of the TA corruption, so it was effectively the same.

No, he wasn't. Flashmode happens before fastboot; he couldn't get into fastboot. On top of that, you can't flash TA from fastboot, so it wouldn't even help if you could.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
No, I could not get into fast boot mode (blue light).

I did not need any key combo, the phone always went to flash mode (green light) immediately when connected to PC with usb cable.

In the flash mode, it was possible to flash sony fw images, but nothing else.

Flashing entire fw including everything did not help at all. And you can not flash anything else than signed sony fw .sin files even though the bootloader had been already unlocked.

So it was a hard brick at least for me.

Maybe sony would have possibility to flash something to recover it (they have the keys for that), but not me.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
That was also my understanding, seeing other posts. I did not test it yet myself.

But seeing following post here:

https://xdaforums.com/showpost.php?p=78682507&postcount=11

makes me wonder, if camera works only in 47.2.A.0.306 and stops working in following 47.2.A.2.33, 47.2.A.4.41 and 47.2.A.4.45 firmware versions if drm keys had been lost with unlock (TA not restored)?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] russel5:
On 45 version camera works without drm fix
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Pixel Shader™:
[MENTION=4403504]tonsofquestions[/MENTION] lol bro I don't think u understand anything. I am not mad or anything as this is nothing. I didn't like my XZ1 to begin with as it had the annoying known issues which are the loudspeakers sizzling/distortion and the WiFi problem. They were annoying like hell except WiFi drops and deconnection which was happening rarely. So I was planning to change it. I am leaving now the XZ1/XZ1C forums/threads and return back to my previous Xperia XZ. At least in my Xperia XZ there are no such issues and in top of that I can git ride of the warning bootloader unlock whenever I want to. The only thing I liked about the XZ1 was its 10nm SD835 CPU, and the 64GB storage anything else like camera the XZ is more than enough as I use selfie (which is the same as XZ1) more than the rear camera. I might return if I heard that there is a new way or possibility to restore the TA and remove the warning screen as we used to do in Xperia X-XZ on all newer Xperia smartphones but it will definitely not the XZ1 lol.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] SGH-i200:
Donation

Since I'm grateful for all your hard work, I sent you a donation! :highfive:
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] tonsofquestions:
I'm glad about that, then. Comments like this one:

Sure made it sound like you were pretty frustrated. But if you've got the means to have more phones and not mind if some get bricked, then more power to you.

I agree the bootloader display is annoying, but since I want a compact phone, the XZ1c is really the only viable option for me at the moment. :(
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=1995555]SGH-i200[/MENTION], thank you for the donation, really appreciated.

Thanking again (now in public) to [MENTION=4898998]Klaus N.[/MENTION] for his generous donation too.

Thanks again to all who donated last year and to all who may follow.

As already hinted a bit, I am still working on something, just be patient and stay tuned - I believe you will like it!
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Pixel Shader™:
[MENTION=4403504]tonsofquestions[/MENTION] I wasn't frustrated in that. It is just made me sad as those who were suggesting things to solve my problem didn't know or didn't read what I wrote. They keep telling me to use other softwares despite the fact I said my phone is bricked and there is no way to get connected so anything useless except a hardmod which as I said I am not gonna do as i don't like a disassembled phone even if a way exist.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
I am wondering about that possibility to get rid of the bootloader warning screen - was it possible with xperia XZ to remove the warning while still keep the bootloader unlocked or was it removed only because there was a possibility to relock the bootloader forcing you to flash virgin stock fw without any modification/rooting possibility?

Did restore of TA relock the bootloader? If so, I wonder how drm keys were restored while keeping the bootloader unlocked?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Klaus N.:
No, unfortunately it wasn't possibly to get rid of that annoying message on boot, also with the XZ.