M
Membre supprimé 438334
- #1
Bonjour ,
Je vais vous présentez Suhide . Suhide est un mod expérimental (et officiellement non pris en charge) pour SuperSU qui peut cacher de façon sélective la racine ( le su binaire et le nom du paquet ) d'autres applications .
Cette opération comporte des risques. Ni moi ni Phonandroid ne peuvent être tenu responsables des éventuels problèmes rencontrés. Pensez à effectuer une sauvegarde de votre système et EFS avant toutes modifications ou flash !
Merci à
S'il vous plaît,
Connexion
ou
S'inscrire
pour voir le contenu ou les urls !
SafetyNet a vérifié le passage au 2017.08.10 .
C'est finalement un jeu perdant (voir la prochaine publication). Suhide peut cesser de fonctionner à tout moment.
Exigences
- SuperSU v2.82 SR2 ou plus récent ( lien
S'il vous plaît,
Connexion
ou
S'inscrire
pour voir le contenu ou les urls !
)- SuperSU installés en SBIN le mode ( par défaut sur O +)
- Android 6.0 ou plus récent
- TWRP ( 3.0.2 ou plus récent avec accès à / données), FlashFire est pas (encore) pris en charge .
Xposed
Pas actuellement testé ou pris en charge.
CyanogenMod / LineageOS
Pas actuellement testé ou pris en charge. Peut-être que ça marche, peut-être pas.
Changelog :
2017.10.01 - v1.09
- Remove ODM and OEM mounts
- Setpropex: set multiple properties
- Cleanup: remove /boot
2017.08.15 - v1.08
- Fix a process freeze issue
- Fix framework restart survival (stop && start)
- Fix double free crash
2017.08.11 - v1.07
- Startup: Fix parallelism
2017.08.10 - v1.06
- Startup: Disable parallelism (temporary?), causes things to break sometimes
2017.08.10 - v1.05
- GUI: Synchronize changing items with the same UID
- GUI: Hide system apps (UID < 10000)
- GUI: Fix UID / package display line to ellipsize instead of wrap
- Properties: Adjust various build, adb, debug and security properties
- Startup: Improve performance by running operations in parallel
- ZIP: Allow flashing directly after SuperSU switch from image to SBIN mode, without reboot in between
2017.08.09 - v1.00
- Initial release of new code
- For old code, see
2016.10.10 - v0.55 - RELEASE NOTES
- Some code cleanup
- Support for blocking based on process name
- Should fix some crashes (requires uninstall/reinstall to activate)
2016.10.07 - v0.54 - RELEASE NOTES
- Fix for latest SafetyNet update
2016.09.19 - v0.53 - RELEASE NOTES
- Haploid container (monoploid)
2016.09.18 - v0.52 - see v0.51 release notes below
- Fix root loss on some firmwares
2016.09.18 - v0.51 - RELEASE NOTES
- Complete redesign
- Zygote proxying (haploid)
- Binder hijacking (diploid)
- su.d instead of ramdisk modification
- Xposed supported (-ish)
2016.09.04 - v0.16 - RELEASE NOTES
- Fix some SELinux access errors
- Should now work on devices that ask for a password/pattern/pin immediately at boot - for real this time!
- Binderjacking improvements for Nougat
2016.08.31 - v0.12 - RELEASE NOTES
- Fix some issues with suhide-add/rm scripts
- Fix not working at all on 32-bit devices
- Should now work on devices that ask for a password/pattern/pin immediately at boot
- Rudimentary GUI hiding
- No longer limited to arm/arm64 devices: support for x86/x86_64/mips/mips64 devices added
2016.08.29 - v0.01
- Initial release
- Remove ODM and OEM mounts
- Setpropex: set multiple properties
- Cleanup: remove /boot
2017.08.15 - v1.08
- Fix a process freeze issue
- Fix framework restart survival (stop && start)
- Fix double free crash
2017.08.11 - v1.07
- Startup: Fix parallelism
2017.08.10 - v1.06
- Startup: Disable parallelism (temporary?), causes things to break sometimes
2017.08.10 - v1.05
- GUI: Synchronize changing items with the same UID
- GUI: Hide system apps (UID < 10000)
- GUI: Fix UID / package display line to ellipsize instead of wrap
- Properties: Adjust various build, adb, debug and security properties
- Startup: Improve performance by running operations in parallel
- ZIP: Allow flashing directly after SuperSU switch from image to SBIN mode, without reboot in between
2017.08.09 - v1.00
- Initial release of new code
- For old code, see
2016.10.10 - v0.55 - RELEASE NOTES
- Some code cleanup
- Support for blocking based on process name
- Should fix some crashes (requires uninstall/reinstall to activate)
2016.10.07 - v0.54 - RELEASE NOTES
- Fix for latest SafetyNet update
2016.09.19 - v0.53 - RELEASE NOTES
- Haploid container (monoploid)
2016.09.18 - v0.52 - see v0.51 release notes below
- Fix root loss on some firmwares
2016.09.18 - v0.51 - RELEASE NOTES
- Complete redesign
- Zygote proxying (haploid)
- Binder hijacking (diploid)
- su.d instead of ramdisk modification
- Xposed supported (-ish)
2016.09.04 - v0.16 - RELEASE NOTES
- Fix some SELinux access errors
- Should now work on devices that ask for a password/pattern/pin immediately at boot - for real this time!
- Binderjacking improvements for Nougat
2016.08.31 - v0.12 - RELEASE NOTES
- Fix some issues with suhide-add/rm scripts
- Fix not working at all on 32-bit devices
- Should now work on devices that ask for a password/pattern/pin immediately at boot
- Rudimentary GUI hiding
- No longer limited to arm/arm64 devices: support for x86/x86_64/mips/mips64 devices added
2016.08.29 - v0.01
- Initial release
Usage
Installation / mise à niveau
Tout d'abord, assurez-vous d'utiliser SuperSU en mode SBIN sur Android 6.x et 7.x
- Démarrez dans TWRP
- adb shell
- echo "BINDSBIN=true">/data/.supersu
--- OR: flasher SuperSU Config et selectionner Systemless SBIN mode
- Reflash SuperSU v2.82 SR2 or newer
- Redémarrez dans Android au moins une fois
Avec SuperSU en mode SBIN
- Flash le suhide ZIP dans TWRP
- Redémarrez dans Android
Si votre TWRP ne déchiffre pas complètement / les données, reflashez SuperSU ZIP et flashez immédiatement le suhide ZIP , sans redémarrer entre les deux peut parfois permettre le suhide À installer aussi bien où il y aurait une erreur autrement .
Si vous venez de flasher une ROM , il est conseillé de la laisser complètement démarrer au moins une fois avant d'installer suhide .
* Utilisation avancée
Vous pouvez ajouter / supprimer / supprimer manuellement les entrées dans la liste noire de suhide en utilisant ces commandes:
/sbin/supersu/suhide/add UID-or-processname
/sbin/supersu/suhide/rm UID-or-processname
/sbin/supersu/suhide/list
noms de paquets d'application sont habituellement les mêmes que le nom du processus, mais pas toujours. L'utilisation de l'UID est plus sûre. Vous pouvez trouver l'UID en exécutant 'ps -n' (6.x/7.x) or 'ps -An' (8.x). L'UID est la première colonne, et un numéro à 5 chiffres commence par 10: 10xxx.
S'il vous plaît,
Connexion
ou
S'inscrire
pour voir le contenu ou les urls !
S'il vous plaît,
Connexion
ou
S'inscrire
pour voir le contenu ou les urls !
(
S'il vous plaît,
Connexion
ou
S'inscrire
pour voir le contenu ou les urls !
A lire
Racine cachée: un jeu perdant - rant du jour
La plupart des applications qui détectent la racine tombent dans la catégorie de paiement, de banque / investissement, de sécurité d'entreprise ou de (anit tricherie).
Alors que beaucoup d'applications ont leurs routines de détection de racine personnalisées, avec l'introduction de SafetyNet la situation pour les utilisateurs a été pire, comme les développeurs de ces applications peuvent maintenant utiliser une API unique pour vérifier si le périphérique n'est pas évidemment compromis.
SafetyNet est évidemment développé par Google, ce qui signifie qu'ils peuvent faire quelques astuces que d'autres ne peuvent pas facilement faire, car ils ont un meilleur accès à la plate-forme et de contrôle. Dans son incarnation actuelle, les routines de détection fonctionnent toujours comme un utilisateur non privilégié et n'utilisent pas encore les informations des composants attendus à être sécurisés tels que le chargeur de démarrage ou TPM. En d'autres termes, même s'ils ont un peu plus d'accès qu'une application tiers, ils ont encore moins d'accès qu'une application root.
Il en résulte que tant que quelqu'un est prêt à consacrer du temps et de l'effort - ce qui peut devenir très complexe et prendre beaucoup de temps très rapidement - et SafetyNet conserve ses routines de détection dans la même classe, il y aura en théorie toujours Être un moyen de battre ces détections.
Alors que la lecture qui peut d'abord faire certains d'entre vous se réjouissent, c'est en fait une mauvaise chose. Comme l'a déclaré un ingénieur de sécurité Android à Google, ils doivent "s'assurer que Android Pay fonctionne sur un appareil doté d'un ensemble bien documenté d'API et d'un modèle de sécurité bien compris".
Le problème est qu'avec un dispositif enraciné, il n'est finalement pas possible de garantir ledit modèle de sécurité avec la classe actuelle des routines de détection de sabotage de SafetyNet. Le jeu de chat et de souris actuellement en cours de lecture - SafetyNet détecte la racine, quelqu'un le contourne, SafetyNet le détecte à nouveau, répète - ne fait que souligner ce point. Plus nous poussons cela, plus cela devient évident pour tous les acteurs impliqués, et le SafetyNet (et les solutions similaires) plus rapides vont se développer au-delà de leurs limites actuelles.
En fin de compte, les informations seront fournies et vérifiées par les chargeurs de démarrage / TrustZone / SecureBoot / TIMA / TEE / TPM etc. (Samsung le fait déjà avec ses solutions KNOX / TIMA). Les parties de l'appareil que nous ne pouvons pas facilement atteindre ou de patch, et donc viendra un moment où ces contournements de détection mai ne plus viable. Cela se produira indépendamment de nos efforts, car vous pouvez être sûr que les auteurs de logiciels malveillants travaillent sur cela aussi. Toutefois, ce que nous faisons les utilisateurs influents peut influencer le calendrier. Si une dérivation atteint la masse critique, elle sera corrigée rapidement.
Plus de sécurité nécessite plus de verrouillage. En fin de compte, ces caractéristiques de sécurité sont sur l'argent - incroyablement de grandes quantités d'argent. Ceci tandis que nos précieux débloqués bootloaders et les solutions racines sont plus d'un développeur et enthousiaste chose. Alors que nous sommes tous généralement amateurs de secouer nos poings à des goûts de Google, Samsung, HTC, etc, il convient de noter qu'il ya des gens dans toutes ces entreprises de lobbying activement pour garder débloqué / déverrouillable dispositifs disponibles pour nous de jouer avec, Avec la seule limitation étant que certaines affaires financières / d'entreprise peuvent ne pas fonctionner si nous jouons trop dur.
Il serait beaucoup plus facile (et plus sûr de leur point de vue) pour toutes ces parties de simplement brancher ce trou et verrouiller complètement la plate-forme (au-delà des applications tierce partie en utilisant uniquement les API normales). Bypassing root checks en masse n'est rien de moins que piquant l'ours.
Néanmoins, les utilisateurs veulent cacher leurs racines (donc les auteurs de malware ...) et au moins cette implémentation de suhide est simple. Je pense toujours que c'est une mauvaise idée de le faire. Puis encore une fois, je pense que c'est une mauvaise idée de faire quelque chose de financier lié au smartphone Android qui n'est pas complètement propre, mais c'est juste moi.
Notez que j'ai délibérément laissé de côté tout débat sur la question de savoir si SafetyNet / AndroidPay / etc doit être parfaitement sécurisé (la plupart des gens font leurs opérations bancaires sur des installations Windows infectées par le virus après tout), qui devrait décider quel risque vaut la peine d'être pris ou même Si Google et les cohortes seraient en mesure de concevoir les systèmes de manière plus robuste afin que le processeur de l'application principale n'aurait pas besoin d'être de confiance du tout. (Ce dernier pourrait être fait pour Android Pay, mais ne serait pas nécessairement résoudre quoi que ce soit pour Random Banking App). Alors que ce sont des points de discussion très intéressants, c'est finalement Google qui décide comment ils veulent que ce système fonctionne, indépendamment de nos opinions sur la question - et ils veulent le sécuriser.
La plupart des applications qui détectent la racine tombent dans la catégorie de paiement, de banque / investissement, de sécurité d'entreprise ou de (anit tricherie).
Alors que beaucoup d'applications ont leurs routines de détection de racine personnalisées, avec l'introduction de SafetyNet la situation pour les utilisateurs a été pire, comme les développeurs de ces applications peuvent maintenant utiliser une API unique pour vérifier si le périphérique n'est pas évidemment compromis.
SafetyNet est évidemment développé par Google, ce qui signifie qu'ils peuvent faire quelques astuces que d'autres ne peuvent pas facilement faire, car ils ont un meilleur accès à la plate-forme et de contrôle. Dans son incarnation actuelle, les routines de détection fonctionnent toujours comme un utilisateur non privilégié et n'utilisent pas encore les informations des composants attendus à être sécurisés tels que le chargeur de démarrage ou TPM. En d'autres termes, même s'ils ont un peu plus d'accès qu'une application tiers, ils ont encore moins d'accès qu'une application root.
Il en résulte que tant que quelqu'un est prêt à consacrer du temps et de l'effort - ce qui peut devenir très complexe et prendre beaucoup de temps très rapidement - et SafetyNet conserve ses routines de détection dans la même classe, il y aura en théorie toujours Être un moyen de battre ces détections.
Alors que la lecture qui peut d'abord faire certains d'entre vous se réjouissent, c'est en fait une mauvaise chose. Comme l'a déclaré un ingénieur de sécurité Android à Google, ils doivent "s'assurer que Android Pay fonctionne sur un appareil doté d'un ensemble bien documenté d'API et d'un modèle de sécurité bien compris".
Le problème est qu'avec un dispositif enraciné, il n'est finalement pas possible de garantir ledit modèle de sécurité avec la classe actuelle des routines de détection de sabotage de SafetyNet. Le jeu de chat et de souris actuellement en cours de lecture - SafetyNet détecte la racine, quelqu'un le contourne, SafetyNet le détecte à nouveau, répète - ne fait que souligner ce point. Plus nous poussons cela, plus cela devient évident pour tous les acteurs impliqués, et le SafetyNet (et les solutions similaires) plus rapides vont se développer au-delà de leurs limites actuelles.
En fin de compte, les informations seront fournies et vérifiées par les chargeurs de démarrage / TrustZone / SecureBoot / TIMA / TEE / TPM etc. (Samsung le fait déjà avec ses solutions KNOX / TIMA). Les parties de l'appareil que nous ne pouvons pas facilement atteindre ou de patch, et donc viendra un moment où ces contournements de détection mai ne plus viable. Cela se produira indépendamment de nos efforts, car vous pouvez être sûr que les auteurs de logiciels malveillants travaillent sur cela aussi. Toutefois, ce que nous faisons les utilisateurs influents peut influencer le calendrier. Si une dérivation atteint la masse critique, elle sera corrigée rapidement.
Plus de sécurité nécessite plus de verrouillage. En fin de compte, ces caractéristiques de sécurité sont sur l'argent - incroyablement de grandes quantités d'argent. Ceci tandis que nos précieux débloqués bootloaders et les solutions racines sont plus d'un développeur et enthousiaste chose. Alors que nous sommes tous généralement amateurs de secouer nos poings à des goûts de Google, Samsung, HTC, etc, il convient de noter qu'il ya des gens dans toutes ces entreprises de lobbying activement pour garder débloqué / déverrouillable dispositifs disponibles pour nous de jouer avec, Avec la seule limitation étant que certaines affaires financières / d'entreprise peuvent ne pas fonctionner si nous jouons trop dur.
Il serait beaucoup plus facile (et plus sûr de leur point de vue) pour toutes ces parties de simplement brancher ce trou et verrouiller complètement la plate-forme (au-delà des applications tierce partie en utilisant uniquement les API normales). Bypassing root checks en masse n'est rien de moins que piquant l'ours.
Néanmoins, les utilisateurs veulent cacher leurs racines (donc les auteurs de malware ...) et au moins cette implémentation de suhide est simple. Je pense toujours que c'est une mauvaise idée de le faire. Puis encore une fois, je pense que c'est une mauvaise idée de faire quelque chose de financier lié au smartphone Android qui n'est pas complètement propre, mais c'est juste moi.
Notez que j'ai délibérément laissé de côté tout débat sur la question de savoir si SafetyNet / AndroidPay / etc doit être parfaitement sécurisé (la plupart des gens font leurs opérations bancaires sur des installations Windows infectées par le virus après tout), qui devrait décider quel risque vaut la peine d'être pris ou même Si Google et les cohortes seraient en mesure de concevoir les systèmes de manière plus robuste afin que le processeur de l'application principale n'aurait pas besoin d'être de confiance du tout. (Ce dernier pourrait être fait pour Android Pay, mais ne serait pas nécessairement résoudre quoi que ce soit pour Random Banking App). Alors que ce sont des points de discussion très intéressants, c'est finalement Google qui décide comment ils veulent que ce système fonctionne, indépendamment de nos opinions sur la question - et ils veulent le sécuriser.
Vos retours sont les bienvenus !
Dernière édition par un modérateur:
