[SuperSU] Chainfire:
I have been at CES the past week, which is why I have not responded to posts earlier.

Developer discussion thread

I have created a new thread specifically for development issues, as several people have requested it. This is for developers (and the very tech-savvy / well-versed) only: http://xdaforums.com/apps/supersu/devs-supersu-developer-discussion-t3291434.

[MENTION=336863]garyd9[/MENTION] [MENTION=4163343]NZgeek[/MENTION] [MENTION=2605798]nkk71[/MENTION] I have moved or copied posts of yours there

Root lost after reboot

I've had various reports from users losing root after reboot. If you are suffering from this, please post again, including device and firmware details, and specifically whether root comes back after (one or more) reboots by itself, or if you need to re-flash it. If you have not tried multiple reboots, do so before posting.

Lost signal / IMEI

I've had several reports from users losing IMEI on 2.66, only to see it return after removing root / installing a different version. I need more details. Specifically, I need everyone who has seen this issue to post their device and firmware details, and hopefully I'll be able to replicate it once someone posts with a device that I actually have.

(1) No. There is no way to reliably catch this. Some basic mount shell commands can be rerouted, but without very invasive changes to the system, the mount() call inside any binary program cannot be caught.

(2) SuperSU -> Settings -> Full Unroot

Check the installer script inside the ZIP, all the patches necessary for systemless root are in there. They are broken up into a handful of commands specifically so developers can more easily replicate the behavior with possible adjustments to their own setup. Really, it all comes down to the following, I'm not sure how much easier you want it:

# patch sepolicy
/su/bin/sukernel --cpio-extract /sutmp/ramdisk sepolicy /sutmp/sepolicy
/su/bin/supolicy --file /sutmp/sepolicy /sutmp/sepolicy_patched
/su/bin/sukernel --cpio-add /sutmp/ramdisk /sutmp/ramdisk 644 sepolicy /sutmp/sepolicy_patched

# add launch_daemonsu.sh script
/su/bin/sukernel --cpio-add /sutmp/ramdisk /sutmp/ramdisk 700 sbin/launch_daemonsu.sh source-to/launch_daemonsu.sh

# apply patches
/su/bin/sukernel --patch /sutmp/ramdisk /sutmp/ramdisk stockbootimage.img

As for supporting different compression formats, obviously that is high up on the to-do list. GZIP is the most common easy to implement, and thus the first to be supported. Supporting various formats is not as simple as some scripts make it out to be. SuperSU supports 8 different architectures, and the (de)compression code needs to compile and work properly on all of those. Some of these formats have some very annoying licensing restrictions to deal with as well.

Falling back to system-based root may be an option, but if your boot image is stock 6.0, that simply won't work.

That's weird. Can you or anybody else elaborate on why flashing back to stock still leaves you with the deep sleep issue? It's the first I've heard of it.

In system mode, installing SuperSU does not create the deep sleep issue, and as such, it is not responsible for fixing it.

The ZIP files are signed with a cryptographic signature. Recoveries check this signature against an embedded certificate. Custom recoveries (virtually) all use the same certificate, from AOSP sources. Stock recoveries (virtually) all use a vendor-specific certificate we do not have access to.

When done properly, only the vendor can sign a flashable ZIP file that will pass signature verification on a stock recovery.

Interestingly, some (older) devices and firmwares are known to use the wrong signature or simply do not verify the ZIP file. This can indeed be exploited to gain root. I have not heard of popular recent devices that have this large gaping security hole, though.