[XZ1c/XZ1/XZp] temp root exploit to backup drm keys implemented

j4nn · Jul 20, 2018

Tested also build without parallel make (removed the -j7 option). It did not help (stock ramdisk, not modified sony source).
Patched final linking of kernel with dtb images in order to produce dtb variants in the same order as it was present in the stock kernel, to have the dtb blob binary identical - no luck:

moofesr said:
Having tried both the NoJ7 and DTB kernel images, neither has worked whatsoever. They both result in the same issue as before: frozen on the sony screen before rebooting automatically. Once again, I tried to connect via ADB but in both cases, it was simply too early to hook up via ADB

--- edit ---
Tried with ramdisk rebuilt (unpacked stock ramdisk and re-packed it again) - to avoid possible garbage that could have been there from stock boot image split process.
According to @moofesr, it still failed to boot the same as the trials before.

@janjan, could you please let me know which toolchain and which mkbootimg do you use for build of your kernel?
Do you use some different option with mkbootimg?
I am already out of ideas what can be wrong with this

nailyk · Jul 21, 2018

Hi all,

just got my xz1c. Still locked for now (am reading xda threads about it, but almost really don't care of keeping it locked)
How can I help you on this?
(right now am on .179)

BTW hi @munjeni ! Funny to see you here, with the same device this time :highfive:

mirhl · Jul 21, 2018

Munjeni still just has z1c.
He just has a big helpful heart.

golden-guy · Jul 22, 2018

I won't be able to get my hands on it before mid of next week, but has anybody tried to make an arm64 build for that POC: https://github.com/xairy/kernel-exploits/blob/master/CVE-2017-7308/poc.c

PS: Will have received my XZ1c by then as well and join the fun

j4nn · Jul 22, 2018

@golden-guy, please check the the opening post, the CVE-2017-7308 had been already checked. You need to find userspace exploit to get NET_RAW capability first in order to be able to exploit via that CVE. Only very few processes have the needed capability. The oreo selinux setup is not nice with that regard.

golden-guy · Jul 22, 2018

j4nn said:
@golden-guy, please check the the opening post, the CVE-2017-7308 had been already checked. You need to find userspace exploit to get NET_RAW capability first in order to be able to exploit via that CVE. Only very few processes have the needed capability. The oreo selinux setup is not nice with that regard.

I read it, but wasn't sure about the progress on this one. So something like a ping is not supported on the shell? Since these cmds are normally symlinked with the shell binary (toybox/busybox) I would have assumed this cap is given when the exploit is executed via shell.

Either way, please let me know how to best support this effort. I will continue to do some research for now.

j4nn · Jul 22, 2018

@golden-guy, I am afraid that even though ping might have that cap, it does not mean the shell has it nor commands started from it.
If inotify/rename vulnerability would not go well, I see blueborne followed by CVE-2017-1000112 (memory corruption in UDP fragmentation offload) exploit as the next target.
You may check post#54 from @4rz0 that seems very interesting with regard to blueborne.
There is a problem to compile a kernel that would boot stock firmware on an unlocked phone - that would be useful in general for any kernel exploit debugging/testing.
Still waiting if @janjan has some idea what is wrong as he knows the right way. Or anybody else?

nailyk · Jul 22, 2018

j4nn said:
There is a problem to compile a kernel that would boot stock firmware on an unlocked phone - that would be useful in general for any kernel exploit debugging/testing.

Just unlocked mine. Feels free to send me some kernels to test on stock (with the according version to flash please)

janjan · Jul 22, 2018

j4nn said:
Tested also build without parallel make (removed the -j7 option). It did not help (stock ramdisk, not modified sony source).
Patched final linking of kernel with dtb images in order to produce dtb variants in the same order as it was present in the stock kernel, to have the dtb blob binary identical - no luck:

--- edit ---
Tried with ramdisk rebuilt (unpacked stock ramdisk and re-packed it again) - to avoid possible garbage that could have been there from stock boot image split process.
According to @moofesr, it still failed to boot the same as the trials before.

@janjan, could you please let me know which toolchain and which mkbootimg do you use for build of your kernel?
Do you use some different option with mkbootimg?
I am already out of ideas what can be wrong with this

j4nn said:
@golden-guy, please check the the opening post, the CVE-2017-7308 had been already checked. You need to find userspace exploit to get NET_RAW capability first in order to be able to exploit via that CVE. Only very few processes have the needed capability. The oreo selinux setup is not nice with that regard.

Unfortunately I am away from home and my PC..( summer holidays) I can't remember which one I used. But i use to compile my own. I will post my script, steps etc when I get home.

j4nn · Jul 23, 2018

nailyk said:
just got my xz1c. Still locked for now (am reading xda threads about it, but almost really don't care of keeping it locked)
How can I help you on this?
(right now am on .179)

nailyk said:
Just unlocked mine. Feels free to send me some kernels to test on stock (with the according version to flash please)

@nailyk, could you please test following kernel?
boot-12.179-osvs.img
It is a build of not modified sony kernel source released for 47.1.A.12.179 fw with ramdisk extracted from that fw's kernel.sin.
It is another attempt to test kernel build procedure.
This time I've added os version info and signed it with a test key.
Thanks.

j4nn · Jul 25, 2018

Anybody here with unlocked xz1c can test a kernel to boot for me please?
It seems that everybody previously willing to test is on summer vacation.
I can build a kernel for your stock (or stock based) fw version (to avoid need of reflash/downgrade) if that makes it easier for you.
I believe the test could be done even without flashing of the kernel - using 'fastboot boot boot.img' command - to just boot the image from usb.
Let me know please. Thanks.

blue-spiderfire · Jul 25, 2018

j4nn said:
Anybody here with unlocked xz1c can test a kernel to boot for me please?
It seems that everybody previously willing to test is on summer vacation.
I can build a kernel for your stock (or stock based) fw version (to avoid need of reflash/downgrade) if that makes it easier for you.
I believe the test could be done even without flashing of the kernel - using 'fastboot boot boot.img' command - to just boot the image from usb.
Let me know please. Thanks.

I'm still on 47.1.A.2.2.324 and I would like to test, if your kernel wouldn't hurt my daily driver.

j4nn · Jul 27, 2018

Let me show you something:

Code:

    /data/local/tmp # ./mytest-linux -p 1000 -l
    detected overwrite (event#561, count=1):
        len=208 name="p+ppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp"
    detected overwrite (event#829, count=2):
        len=208 name="p+ppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp"
    detected overwrite (event#1015, count=3):
        len=208 name="p+ppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp"
    detected overwrite (event#1441, count=4):
        len=208 name="p+ppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp"
    detected overwrite (event#1481, count=5):
        len=208 name="p+ppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp"
    detected overwrite (event#1627, count=6):
        len=208 name="p+ppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp"
    detected overwrite (event#1697, count=7):
        len=208 name="p+ppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp"
    detected overwrite (event#1793, count=8):
        len=208 name="p+ppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp"
    detected overwrite (event#1889, count=9):
        len=208 name="p+ppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp"
    detected overwrite (event#1943, count=10):
        len=208 name="p+ppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp"

This is my implementation of inotify/rename exploit run in qemu - I have found a way how to overcome the problem with delayed kfree from kfree_rcu described in post#33, post#44 and post#48.

And I've even managed to tune half of it for real locked xz1c - it triggers short filenames overwrite, but using the same method as with long filenames (or the first half of it as the second part with kfree_rcu is not needed in short file name case):

Code:

130|G8441:/data/local/tmp $ ./mytest-android                                   
detected overwrite (event#728, count=1):
    len=16 name="g+ggggggggggggg"
detected overwrite (event#802, count=2):
    len=16 name="g+ggggggggggggg"
detected overwrite (event#1418, count=3):
    len=16 name="g+ggggggggggggg"
detected overwrite (event#1778, count=4):
    len=16 name="g+ggggggggggggg"
detected overwrite (event#1834, count=5):
    len=16 name="g+ggggggggggggg"
detected overwrite (event#1982, count=6):
    len=16 name="g+ggggggggggggg"
detected overwrite (event#2038, count=7):
    len=16 name="g+ggggggggggggg"
detected overwrite (event#2066, count=8):
    len=16 name="g+ggggggggggggg"
detected overwrite (event#2102, count=9):
    len=16 name="g+ggggggggggggg"
detected overwrite (event#2116, count=10):
    len=16 name="g+ggggggggggggg"
G8441:/data/local/tmp $

Guys, is here really nobody (with _unlocked_ xz1c) willing to at least test with me?

Raz0Rfail · Jul 27, 2018

I would help you. I have an unlocked bootloader and I'm on build .235 so my test will fail?

j4nn · Jul 27, 2018

j4nn said:
It is another attempt to test kernel build procedure.
This time I've added os version info and signed it with a test key.
Thanks.

Raz0Rfail said:
I would help you. I have an unlocked bootloader and I'm on build .235 so my test will fail?

So we have a working build procedure now (reinvented the wheel after all; -)
With Raz0Rfail we could finally boot a kernel built from 12.235 source.
The cause of bootloop with all previous build attempts (that were tested by @moofesr) was missing os version setting in kernel boot image (what a shame that sony did not include that option in their kernel's readme).
So big thanks go to both, @moofesr and @Raz0Rfail for help with the testing.

Working build procedure allowed to get first insight into inotify/rename vulnerability time relations - I've reverted the fix for the vulnerability and built a kernel patched with important points timing recording:
boot-12.235-timing.img
It can boot the 47.1.A.12.235 stock firmware.
That allowed to finally proceed with post#53 to get some timing measurements (test result from Raz0Rfail):

Code:

...
status = 0x03 (#1) [0]
rename_start = 8614972865
inotify_start +      -4
fsnot_start   +     214
fsnot_strlen  +     249
copy_name     +    5349
kfrcu_start   +    5355
rename_end    +    5688
kfrcu_kfree   +  690549
addk_wake     +    5775
fsnot_strcpy  +     273
inotify_end   +    1332
...

This shows that there is only 273 - 249 = 24 timer cycles long the racy/vulnerable part of the inotify handler code, the part between the strlen and strcpy there.
While the actual kfree (marked as kfrcu_kfree) was invoked many orders later (690549 - 5355 = 685194) after the kfree_rcu call, confirming the problem with delayed kfree from kfree_rcu described in post#33, post#44 and post#48. The max delay of kfree in the results from one test attempt was even 1 316 601 timer cycles, while the min delay was 182 715, so that is quite a big range (done 10 trials).
The log from qemu showed in post#73 indicates that it may eventually work, still it will be very difficult (in case of qemu test I've put artificial delay of 20000 timer cycles in between the strlen and strcpy in order to increase probability to trigger the bug) - and try to "fix" the delay/timing problem of the kfree-add_key to fill the slub entry in time (i.e. to achieve the use after free exploit). That is we need to fit the delayed kfree followed by add_key spray into the 24 cycles long vulnerable part - seems impossible right?

j4nn · Aug 2, 2018

Could someone with unlocked and rooted XZ1c post a kernel boot log here please?
I assume you could do it with something like this:

Code:

adb shell
su
cd /data/local/tmp
dmesg > dmesg.txt
chmod 644 dmesg.txt
exit
exit
adb pull /data/local/tmp/dmesg.txt

Stock based fw/kernel would be preferred, but possibly any would do.
Thanks.

Tobi@s · Aug 3, 2018

Hope it helps.
Since I'm rooted the boot image isn't stock but magisk patched

j4nn · Aug 10, 2018

@moofesr or @Raz0Rfail or anybody else with _unlocked_ bootloader on XZ1c, could you please do a test with following kernel:
boot-12.270-mvuaf.img - sources patched for another timing test, ramdisk extracted from 47.1.A.12.270 (so it needs to be used with this stock fw)
You may either flash it with fastboot, or possibly just boot it with fastboot without flashing (in such case you may verify the kernel build date in "about phone -> kernel" that it was built today to be sure the kernel actually booted via fastboot from usb instead of the stock one in flash) - see post#53 for details.
After the kernel boots, copy the attached utility to the phone via adb and start the test as bellow:
View attachment mvuaf.zip

Code:

adb push mvuaf /data/local/tmp
adb shell
cd /data/local/tmp
chmod 755 mvuaf
./mvuaf

If this gets tested by multiple persons it would be great so we have timing from multiple devices.
Thanks.

moofesr · Aug 10, 2018

Here you go

j4nn · Aug 10, 2018

Thanks to both @moofesr and @Raz0Rfail for testing.
Guys, could you please do one more test with following updated mvuaf?
Unfortunately the offset did not advance as expected.

It would be great if you could get results where ts_range at the beginning is bigger than 100 000. Please skip those when "ts_range 0 (count=10)" is present.

[XZ1c/XZ1/XZp] temp root exploit to backup drm keys implemented

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Recognized Developer

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Attachments

Senior Member

Member

Attachments

Senior Member

Attachments

Similar threads

Top Liked Posts