yashsingh1/xdaforums huggingface dataset:
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4133204]lilbrat[/MENTION], well I am not sure which method he has chosen after all, but described few for him.

For example you can use adb to get directly a root shell when twrp is booted (and adb had been enabled and acked PC's fingerprint on main fw in advance).

Or do it from twrp integrated shell app (not recommended, not comfortable, possibility for type errors).

Another (probably not tested) option might be to restore it on runtime when booted after flashing magisk.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
deploy magisk from temproot on locked phone

Anybody interested to use renoroot exploit to start up magisk for use by apps while still having phone's bootloader locked?

Not persistent obviously (renoroot needs to be run after each boot followed by a script to start up magisk).

Might be useful mainly for testing or for somebody who needs magisk for specific app (like afwall+ for example) while not wanting to do bootloader unlock.

I just got that working, might post a guide, if there is anybody interested (magisk features are limited though as it gets started after phone is fully booted)...
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] lilbrat:
So in theory, it could be be done twrp..

Oh, and I have another question for you, how different are the kernels for the XZP and the XZ1?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
ThomasKing's new rooting method (WrongZone root) slides

Thanks for letting me know - I guess that shall be a very interesting reading.

Building universal Android rooting with a type confusion vulnerability.pdf

his twitter post with a link to rooting demo video

This has been fixed with android 2018-12-01 patch level:

https://source.android.com/security/bulletin/2018-12-01#kernel-components

So in case of xz1c the last vulnerable fw version would be 47.2.A.2.33 (a second pie release?).

Most likely it could be a chance for xz2/xz3 phones too...
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Sungfive:
I made a backup of DRM keys (TA locked and unlocked are both on my PC). I restored them following the tutorial, booted Stock 9.0 and now I have not DRM features enabled.

What did I probably do wrong?

Inviato dal mio G8341 utilizzando Tapatalk
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] ecksdeeay:
Now flash the hide-unlock NOT FOR THE LATEST RELEASE THOUGH

https://xdaforums.com/xperia-xz1/development/rooted-kernel-hiding-bootloader-unlock-t3898833
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Sungfive:
I'm on 47.2.A.10.45 stock. If I flash the hide unlock it will fully restore (and make them be recognized) my DRM?

Thanks for your help

Inviato dal mio G8341 utilizzando Tapatalk
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] ecksdeeay:
Correct
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Sungfive:
Really thanks

Inviato dal mio G8341 utilizzando Tapatalk
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=6031898]MartinX3[/MENTION], I do not doubt that a drmfix may achieve many things, but there certainly can be things that simply cannot be fixed (at least not if sony did not screw up and implemented drm related stuff properly) - see here, please:

https://storage.googleapis.com/wvdocs/Widevine_DRM_Getting_Started_Devices.pdf

In other words, if device key is lost, widevine L1 would not work as it must be encrypted by device-unique secret key and therefore no drmfix can restore that.

What I meant with "concentrate the development effort into proper TA backup via exploit" was that if all experienced developers since beginning started co-working on a kernel exploit instead of a drmfix, we could have had proper TA backup lot earlier and possibly did not need any drmfixes at all.

But surely I understand that currently there are many who could not have done their locked TA backup, so drmfix may be better than nothing.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] MartinX3:
I never said that the drmfix is the universal final solution of the drm question. :silly:

But it is a very nice addition.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
playstore certification of XZ2, unlock hiding kernel

[MENTION=4898998]Klaus N.[/MENTION], please find the kernels for your XZ2 here for testing (I cannot test them):

boot-H8216-52.0.A.8.50-hideunlock.img

boot-H8216-52.0.A.8.50-hideunlock-magisk-19.2.img

The test procedure:

flash hideunlock.img kernel (it does not contain magisk)

either

do a factory reset (sure way) or

uninstall Magisk Manager and Erase All Data of 'google play store' and 'google play services' (find them in App Info menu) - not that sure way, I guess it could work too but not 100% sure about it

connect to play store, download whatever updates, check the play store certification - may need some time to get the certification status updated, be sure to check it more times and spend some time for it

when you are certain that your xz2 phone is 'certified' and everything works similarly as with xz1, flash hideunlock-magisk-19.2.img variant and install magisk manager

work with the playstore online for some time to see if the certification status stays or not

This procedure (first without any trace of magisk) should confirm that your fw running with kernel patched to hide bootloader unlock can be certified (I am not sure if you are using any other fw customizations, that might also be intrusive with regard to play store certification).

The second trial with magisk included would possibly reveal if magisk is detected and that causes the certification fail.

As an independent test you may try to 'fastboot boot' both kernels to see if my build allows them to be booted from usb when running unmodified stock fw (possibly useful for system fota upgrade).

Please note, both kernels have dm-verity enabled. And it is wise to keep it that way - it might be one of the things google may also check with regard to certifications.

Customizations may be done by system less magisk modules.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Klaus N.:
[MENTION=4418980]j4nn[/MENTION]

Thank you very much for your efforts :highfive:

I will do that tomorrow right after work and will give you a feedback, ofc :svetius:

[MENTION=4418980]j4nn[/MENTION]

Here are my findings:

First I did a fresh install of the latest firmware (8.50), then

1. flashed your boot-H8216-52.0.A.8.50-hideunlock.img and simply rebooted. Result: bootloop

2. installed the appropriate twrp for the 8.50 fw, followed by flashing Magisk v18.1. Result: bootloop

3. again in twrp, set dm-verity to off via terminal, then flashed Magisk 18.1 again. Result: boots into system and after logging into my Google account, my device is certified!

...but 3a. the preview in the camera app stays black, therefore

4. flashed the original boot.img, then twrp and Magisk v18.1. Result: boots up into system, device is still shown as certified, and the camera preview works!

Btw, I tried to flash and boot your boot-H8216-52.0.A.8.50-hideunlock-magisk-19.2.img in a various ways:

1. simply flashed it and rebooted. Result: bootloop

2. flashed it, the again the 8.50 twrp, followed by Magisk v19.2. Result: bootloop

3. again the same way as in 2., but now - before flashing Magisk, I set dm-verity to off, but the result: bootloop

So I went back to the 8.50 stock kernel with Magisk v18.1 - and (at least until now) my XZ2 is shown as a certified device ;)
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4898998]Klaus N.[/MENTION], that is not what I hoped for. So I tried to build the kernel the same way as previously did for [MENTION=3989065]serajr[/MENTION]:

boot-H8216-52.0.A.8.50-hideunlock-magisk-18.1.img

boot-H8216-52.0.A.8.50-hideunlock-magisk-19.2.img

boot-H8216-52.0.A.8.50-hideunlock.img

Please try to follow the post#663 using the hideunlock-magisk-19.2 kernel.

Please be sure to follow all details in that post, i.e. have not modified at all stock fw, including kernel, stock recovery, dtbo and other partitions.

And boot the hideunlock-magisk-19.2 kernel from usb via 'fastboot boot' as described.

That should confirm we are at the same state as that time.

If you can get it boot that way, just follow the above steps to reset certification status and wait to get it.

If that works, we need to find a way how to flash the kernel and be able to boot it.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Klaus N.:
[MENTION=4418980]j4nn[/MENTION]

I'll try that tomorrow and report back. It was a long day today...

Thanks again for your efforts :good:

[MENTION=4418980]j4nn[/MENTION]

Edit:

I''ve installed the 8.50 fw from the scratch (flashed everything - even userdata)

Results:

fastboot boot boot-H8216-52.0.A.8.50-hideunlock-magisk-19.2.img

=> bootloop (4 tries; in 2 cases at the SONY logo, 1 time a little after [while the screen was black], and one time at the "PROVIDED BY ANDROID" lettering)

fastboot boot boot-H8216-52.0.A.8.50-hideunlock-magisk-18.1.img

=> boots into system

and after entering my Google account, my device is shown as certified!
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] leiersai:
can i use G8142_45.0.A.1.244 to make your process done on my xzp?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Klaus N.:
I would not recommend to try that! Have you already read the whole op?

In the op (at the bottom of the "SUPPORTED TARTETS" section) you will read:

...means for you, you have to update your device to:
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=8154665]leiersai[/MENTION], as written by [MENTION=4898998]Klaus N.[/MENTION] (thanks), you need to upgrade - but that's good - you might even be able to backup all your data - and even do it before unlocking!

Just wait please with the unlock itself, I can post a howto for starting magisk from temproot - that would allow you to use apps that need gui root on still locked phone (easy backup possibility or apps like afwall+).
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4898998]Klaus N.[/MENTION], so it looks like the magisk-19.2 is causing some issues if 18.1 works.

You can try to flash the boot-H8216-52.0.A.8.50-hideunlock.img kernel and magisk-18.1 over it.

I am not sure if that's done automatically by magisk, but you may need also to disable verity in vbmeta (that's something specific to tama platform, I have no experience with it) - so most likely you need to do:

fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img

then boot twrp, flash boot-H8216-52.0.A.8.50-hideunlock.img (select image flashing to flash the kernel) and flash magisk-18.1.

You can get the vbmeta.img in xz2 twrp thread package.

Let me know please if it works - the kernel is built for booting from usb. If it does not work when flashed, I can try to build it according to sony howto to see if it helps.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] leiersai:
thanks a lot, but actually i have reset my phone already… so let me just follow your instructions above. i have downloaded that special version system, and i will follow your guide.:)thank you again.

---------- Post added at 02:03 AM ---------- Previous post was at 02:01 AM ----------

afterwards i saw that… so i will do as the guide says. thank you:)
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Klaus N.:
Well, the boot-H8216-52.0.A.8.50-hideunlock.img you've provided in post #971 boots up without any problem, and my device is shown as "certified".

But: The camera stays black. I guess, neither serajr's nor Martin's camera fix works with it.

Moving back to stock kernel, and the camera preview is back...

Btw, my device is still shown as certified.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
[MENTION=4898998]Klaus N.[/MENTION], I guess you are a victim of that Green Pictures / Black preview - Stock Firmware 52.0.A.3.126 #261 sony tama platform buggy bootloader not announced change, where if unlocked with older fw, you get not working camera on newer fw versions, while others who unlocked with fw 52.0.A.3.126 or newer have camera working - is that right?

In that case I believe you should do as I've described (disable verity in vbmeta, flash the hideunlock kernel which does not contain magisk, flash magisk 18.1 over it) and use that [Pie][Magisk]Camera_fix_by_Serajr.zip magisk systemless module to fix the problem with camera.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] shoey63:
[MENTION=4898998]Klaus N.[/MENTION]

So if you fastboot boot boot-h8216-52.0.a.8.50-hideunlock.img it loops, but if you fastboot flash boot it, the phone boots, but without camera preview and play store shows certified?

I will test this too, as I am interested in hiding bootloader unlock for play store certification as well. I know Magisk will take care of it, but I do my modifications in TWRP prefer not to use Magisk for various reasons, not the least of which is that nothing above 18.1 works on Tama devices.

[MENTION=4418980]j4nn[/MENTION]

I did a successful OTA from 8-25 to 8-50 by building an 8-25 kernel with your commits and fastboot booting it on pure unmodified stock.

So it seems disabling verification in vbmeta prevents fastboot booting, but boots up when flashing directly to /boot.

I will test myself and report findings.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] moofesr:
No worries, here you go

Edit: Added new output files with non-zero ts_ranges
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
Could you please try following two variants in addition?

./mvuaf2 -s 1
./mvuaf2 -s 2

Again, only nonzero ts_range, please.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] moofesr:
Output from -s 1 is as follows:

rate 19200000
rename 0,0
spray#1,0
trials 100
offset 0
ts_range 191643 (count=5)

And output from -s 2 is as follows:

rate 19200000
rename 0,0
spray#2,0
trials 100
offset 0
ts_range 183519 (count=5)

RENAME SPRAY HIT#0 on cpu#0 (count=12):
last_ts1 = 79317655367
ts_offset + 22022
rename_start = 22028
copy_name + 29759
kfrcu_start + 29816
rename_end + 32044
kfrcu_kfree + 378864
kfrcu_kfcpu = 0
addkey_start + 379167
add_key + 379171
status = 0x07

RENAME SPRAY HIT#1 on cpu#0 (count=13):
last_ts1 = 79317655367
ts_offset + 23857
rename_start = 384188
copy_name + 385272
kfrcu_start + 385274
rename_end + 385346
kfrcu_kfree + 1146485
kfrcu_kfcpu = 0
addkey_start + 1146673
add_key + 1146677
status = 0x07

RENAME SPRAY HIT#2 on cpu#0 (count=24):
last_ts1 = 79369085916
ts_offset + 44044
rename_start = 44050
copy_name + 47408
kfrcu_start + 47409
rename_end + 49139
kfrcu_kfree + 403683
kfrcu_kfcpu = 0
addkey_start + 403535
add_key + 404001
status = 0x07
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
Good, and what about this:

./mvuaf2 -s 2 -o 22940

Thanks.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
If you don't mind for few more tests, could you please do following (keep an eye on non-zero ts_range as usual):

./mvuaf2 -s 2 -o 22022 -R -5 -S -5
./mvuaf2 -s 2 -o 22022 -R 17 -S 17
./mvuaf2 -s 2 -o 22022 -R -19 -S -19

--- edit ---

And it seems running double spray threads than number of cpu cores is pretty effective on qemu - I get 76 hits out of 100 trials.

Could you please try following for such case:

./mvuaf2 -s 16

Thanks.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
It might seem I am too picky, but there is a reason for all these testing variants - it's called probability.

Let me explain: there is a very small chance to trigger inotify/rename race condition - the vulnerable code path takes only 24 timer cycles: that means very very small probability. When that is triggered, we need to hit the kfree'd memory with add_key "spray" (that is what we currently test here). We skipped the inotify/rename race precondition, just to make testing of the kfree/add_key easier. As we need both probability events to get true, the probabilities multiply - if one is small and the other is also small, the overall probability goes to zero. If we can craft it in a way that both events are very probable, we may have a good chance.

Unfortunately it gets worse.

There will be a second phase - if we can make both inotify/rename and kfree/add_key very probable one after the other - in that case heap slub unit overflow may be achieved.

But we will need to do yet another heap shaping to actually have there some useful object (that shall get overwritten from slub overflow) that would allow us to get the slub overflow useful in some way to achieve kernel write or finally kernel code execution.

That is why we need any particular probability event to be as much probable as possible.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
Thanks again to you both guys for the testing.

Could you please test this as well?

./mvuaf2 -s 16 -o 28020
./mvuaf2 -s 16 -o 27878
./mvuaf2 -s 16 -o 22022

Thanks.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
This looks quite good - 65 hits out 100 trials.

If you have time and feel for it, you might try to experiment with the offset on command line (the -o option) - in the range between 1 and 191800.

Maybe recheck if 22022 gets around 65 hits reliably. Or if it is rather random not depending on various offsets.

Please note, when -o with positive number is specified, you do not need to watch for non-zero ts_range as that is not used in case of cmdline specified offset.

Rather interesting is the final number of hits - if you can get that (repeatedly) for some other offset even higher the hits number, it would be great.

Thanks.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
I am impressed, thank you for the commitment. Though I cannot say much about the script, windows and power shell is not for me.

If I run adb shell "with some command" from linux, it returns if the command terminates in android. In windows it does not?

Also it should be possible to write some similar linux shell script and execute it in the adb shell instead.

Anyway, there is no need to test each value of the 1 and 191800 range.

This is already done by the mvuaf2 if no '-o offset' is specified, even though the range is split to 100 points for 100 test trials (and each such offset is tested just once).

And it is possible to specify number of trials and therefore split the range to more points with "-n num_of_trials" option if needed.

If both -o and -n are specified, the requested offset would be tested specified number of times (instead of 100). So it might be possible to script the test run for specific offsets and each test for example only 10 times like this:

mvuaf2 -s 16 -o $i -n 10

to make needed time to run smaller (and step the $i by bigger step instead of just i++).

From the results from you and [MENTION=5697586]moofesr[/MENTION], the value 22022 looked interesting to me.

Could you confirm that with this offset you get repeatedly the number of hits of about 65 plus/minus?

I had few random trials in mind, like using some thousand less or more or few tests for some picked offsets in the mentioned range to confirm that 22022 provides best (and reproducable) number of hits.

Or if it behaves random with the number of hits for any offset value including the 22022.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Raz0Rfail:
I didn't use linux but for windows it works if i use adb.exe Shell + commands. Try it at yourself with adb shell "command 1 && command 2".

I did 20 tests on 22022:

RENAME SPRAY HIT#23 on cpu#0 (count=98):

RENAME SPRAY HIT#70 on cpu#0 (count=97):

RENAME SPRAY HIT#29 on cpu#0 (count=98):

RENAME SPRAY HIT#54 on cpu#0 (count=88):

RENAME SPRAY HIT#55 on cpu#0 (count=99):

RENAME SPRAY HIT#24 on cpu#1 (count=99):

RENAME SPRAY HIT#14 on cpu#0 (count=91):

RENAME SPRAY HIT#21 on cpu#0 (count=99):

RENAME SPRAY HIT#71 on cpu#0 (count=99):

RENAME SPRAY HIT#40 on cpu#0 (count=99):

RENAME SPRAY HIT#20 on cpu#0 (count=99):

RENAME SPRAY HIT#35 on cpu#0 (count=87):

RENAME SPRAY HIT#42 on cpu#0 (count=98):

RENAME SPRAY HIT#21 on cpu#0 (count=90):

RENAME SPRAY HIT#8 on cpu#0 (count=99):

RENAME SPRAY HIT#10 on cpu#0 (count=90):

RENAME SPRAY HIT#45 on cpu#0 (count=99):

RENAME SPRAY HIT#18 on cpu#0 (count=92):

RENAME SPRAY HIT#29 on cpu#0 (count=91):

RENAME SPRAY HIT#50 on cpu#0 (count=96):

very different hits :/
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
This is what I was a bit afraid of.

Could you re-run your 20 times script with offset set to 1, i.e. having

./mvuaf2 -s 16 -o 1

in it for comparison?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Raz0Rfail:
./mvuaf2 -s 16 -o 1

RENAME SPRAY HIT#19 on cpu#0 (count=97):

RENAME SPRAY HIT#11 on cpu#0 (count=90):

RENAME SPRAY HIT#4 on cpu#0 (count=83):

RENAME SPRAY HIT#14 on cpu#0 (count=97):

RENAME SPRAY HIT#10 on cpu#0 (count=99):

RENAME SPRAY HIT#16 on cpu#0 (count=94):

RENAME SPRAY HIT#16 on cpu#0 (count=94):

RENAME SPRAY HIT#5 on cpu#0 (count=74):

RENAME SPRAY HIT#12 on cpu#0 (count=61):

RENAME SPRAY HIT#8 on cpu#0 (count=67):

RENAME SPRAY HIT#6 on cpu#0 (count=97):

RENAME SPRAY HIT#2 on cpu#0 (count=93):

RENAME SPRAY HIT#7 on cpu#0 (count=82):

RENAME SPRAY HIT#20 on cpu#0 (count=97):

RENAME SPRAY HIT#27 on cpu#0 (count=94):

RENAME SPRAY HIT#14 on cpu#0 (count=97):

RENAME SPRAY HIT#14 on cpu#0 (count=98):

RENAME SPRAY HIT#14 on cpu#0 (count=74):

RENAME SPRAY HIT#10 on cpu#0 (count=93):

RENAME SPRAY HIT#7 on cpu#0 (count=83):
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] j4nn:
So it seems there is some influence after all.

Could you please re-run with

./mvuaf2 -s 16 -o 77070

to see if it changes anything?
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Raz0Rfail:
RENAME SPRAY HIT#19 on cpu#0 (count=88):

RENAME SPRAY HIT#11 on cpu#0 (count=98):

RENAME SPRAY HIT#16 on cpu#0 (count=99):

RENAME SPRAY HIT#14 on cpu#0 (count=93):

RENAME SPRAY HIT#15 on cpu#0 (count=98):

RENAME SPRAY HIT#6 on cpu#0 (count=96):

RENAME SPRAY HIT#8 on cpu#0 (count=98):

RENAME SPRAY HIT#18 on cpu#0 (count=94):

RENAME SPRAY HIT#10 on cpu#0 (count=84):

RENAME SPRAY HIT#23 on cpu#0 (count=98):

RENAME SPRAY HIT#13 on cpu#0 (count=99):

RENAME SPRAY HIT#12 on cpu#0 (count=89):

RENAME SPRAY HIT#8 on cpu#0 (count=99):

RENAME SPRAY HIT#5 on cpu#0 (count=97):

RENAME SPRAY HIT#17 on cpu#0 (count=92):

RENAME SPRAY HIT#5 on cpu#0 (count=88):

RENAME SPRAY HIT#27 on cpu#0 (count=96):

RENAME SPRAY HIT#12 on cpu#0 (count=98):

RENAME SPRAY HIT#13 on cpu#0 (count=94):

RENAME SPRAY HIT#9 on cpu#0 (count=81):
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] Klaus N.:
Yes I have unlocked my device still Oreo running, that's why I need the camera fix. But didn't get it to work with your kernel hiding bootloader for some reason... On the other hand, your kernel (without Magisk included as well as with 18.1 included) boots up flawlessly on an untouched device. If I modify system or/and vendor, I have to flash Magisk right after to let it boot up!

But again: The camera fix only works with pure stock kernel.
[Sony Xperia XZ1 Compact ROMs, Kernels, Recoveries,] mad0701:
I'll believe you haven't understood the issue to 100%

You said, your Device is on Orego and you you need a camera fix. This means, you've unlooked your BL without saving before unlook your TA partition. The kernel doesn't help to retrieve your DRM Keys.

In your case, you have only the chance to upgrade your device to Pie, so that you can used your camera again.