Bonjour à tous,
Mise à jour du lien du tuto pour la version 2.77 de SuperSU, la seule fonctionnelle !
Voici un commentaire de ChainFire sur la nouvelle protection du Note 7, et qui explique aussi pourquoi il n'y a pas encore de CFroot sur le Note 7.
Unfortunately SuperSU did not work on the Note7 (Exynos) out-of-the-box. As its release has been delayed in my country, we've had to resort to remote debugging, which is slow and frustrating. But, thanks to the ever helpful Dr.Ketan and SeraphSephiroth we finally got it working.
New exploit protections
As isn't uncommon with Samsung, they've built-in some new (and arguably ineffective to actual exploits) protections directly to the kernel code, that cannot be turned off by just modifying the boot image ramdisk.
This time, they've decided to kernel panic in case a 'priviliged' process (uid or gid below or equal to 1000, so this includes root and system processes) creates another process that isn't stored in /system or rootfs. SuperSU itself does this, but so do a great many root apps. Any time this happens: immediate reboot.
I'm not going to elaborate why in my opinion this is a fairly useless protection exploit-wise, but needless to say it is fairly bothersome for the normal root user, which is probably a lot more relevant for the average reader here.
Unfortunately - unlike many of the security features developed by Google - this feature is not easily disabled by modifying initramfs (boot image ramdisk), and requires further trickery to bypass.
Maybe a better bypass is yet to by found, but for the time being, I have resorted to patching the check inside the kernel itself when the systemless SuperSU boot image is created. This prevents the user from needing a custom source-built kernel, but it's questionable how long this hex patch will work. The code that performs this patch is fairly trivial - it may keep working the rest of the Note7's lifetime, or stop working the next update.
In other words, this could end up being resource intensive to support, or not. We don't know yet. We have to wait and see what Samsung is going to do.
Bearer of bad news
We know S and Note development are generally strongly related, so we should assume to see the same 'protections' appear in the S7 sooner or later as well. This is probably the (ugly) way forward.
Workarounds
Aside from the binary/hex patch SuperSU employs (see common/hexpatch inside the ZIP), there are some more ways to get around this protection.
If you're compiling kernels from source, it seems that setting CONFIG_RKP_NS_PROT=n gets rid of these protections. You may want to disable other RKP and TIMA settings as well, but that is the one directly relating to this issue.
This protection also disables itself in recovery mode, so simply copying a boot image with these protections to the recovery partition and rebooting into recovery (which will then just launch Android) will work beautifully as well.
CF-Auto-Root
The test CFARs I have made so far for the Note7 have not worked, so since both TWRP and SuperSU ZIPs are already available for this device, I'm dropping CFAR development until I have a device in-hand.
Traduction approximative :
Malheureusement SuperSU ne fonctionne pas sur le Note7 (Exynos) out-of-the-box. Comme sa sortie a été retardée dans mon pays, nous avons dû recourir à un débogage à distance, ce qui est lent et frustrant. Mais, grâce à la Dr.Ketan jamais utile et SeraphSephiroth nous avons finalement obtenu ce travail.
Nouvelles protections
Comme il est pas rare avec Samsung, ils ont construit dans des nouveaux (et sans doute inefficaces pour les exploits réels) protections directement au code du noyau, qui ne peut pas être désactivé en modifiant simplement l'image de démarrage ramdisk.
Cette fois-ci, ils ont décidé de kernel panic dans le cas où un processus «privilégié» (uid ou gid inférieur ou égal à 1000, de sorte que cela comprend les processus de racine et système) crée un autre processus qui ne sont pas stockées dans / système ou rootfs. SuperSU se fait, mais il ne faut un grand nombre d'applications de racine. Chaque fois que cela se produit: redémarrage immédiat.
Je ne vais pas expliquer pourquoi, à mon avis cela est une protection assez inutile exploit sage, mais il va sans dire qu'il est assez gênant pour l'utilisateur root normal, ce qui est probablement beaucoup plus pertinent pour le lecteur moyen ici.
Malheureusement - contrairement à beaucoup de fonctionnalités de sécurité développées par Google - cette fonction est facilement désactivé en modifiant initramfs (boot images ramdisk), et exige en outre la ruse à contourner.
Peut-être une meilleure dérivation est encore en trouver, mais pour le moment, je l'ai eu recours à la correction du chèque à l'intérieur du noyau lui-même lorsque l'image de démarrage systemless SuperSU est créé. Cela empêche l'utilisateur d'avoir besoin d'un noyau de source construit sur mesure, mais on peut se demander combien de temps ce patch hex fonctionnera. Le code qui effectue ce patch est assez trivial - il peut continuer à travailler le reste de la durée de vie du Note7, ou cesser de travailler la prochaine mise à jour.
En d'autres termes, cela pourrait finir par être beaucoup de ressources pour appuyer, ou non. Nous ne savons pas encore. Nous devons attendre et voir ce que Samsung va faire.
Porteur de mauvaises nouvelles
Nous savons S et notez le développement sont généralement fortement liés, de sorte que nous devrions assumer pour voir les mêmes «protections» apparaissent dans le S7, tôt ou tard aussi. Ceci est probablement le (laid) aller de l'avant.
Solutions de contournement
Mis à part le patch binaire / hex SuperSU emploie (voir common / hexpatch dans la ZIP), il y a quelques autres façons de contourner cette protection.
Si vous compilez les noyaux de la source, il semble que la mise en CONFIG_RKP_NS_PROT = n se débarrasse de ces protections. Vous pouvez désactiver les autres RKP et paramètres TIMA aussi bien, mais qui est celui se rapportant directement à cette question.
Cette protection se désactive également en mode de récupération, afin de simplement copier une image de démarrage avec ces protections à la partition de récupération et redémarrer dans la récupération (qui sera ensuite il suffit de lancer Android) fonctionnera admirablement aussi bien.
CF-Auto-Root
Les CFARs de test que j'ai fait jusqu'à présent pour le Note7 n'a pas fonctionné, donc depuis deux TWRP et SuperSU ZIP sont déjà disponibles pour cet appareil, je tombais le développement CFAR jusqu'à ce que j'ai un dispositif dans la main.
