shadow256

Je suis plutôt dégouté car j'avais fait plusieurs fois des vidéos mais supprime par magie ... Et malheureusement les 3/4 des vidéos sur youtube tu as des gogoles qui font une vidéo en 4 minutes ils n'explique rien a par de faire un bout sous sysnand avec risque de ban et elle ne sont pas supprime. Donc effectivement quand tu suit une vidéo de golbute qui t'explique rien a part 99% de chance de te faire ban en suivant une vidéo de merde .... Beaucoup vienne demander quand il est trop tard car ils font des manipulation sans comprendre ce qui doit être fait ... Même pas un backup complet Nand etc ...

Suivre une vidéo pour un hack logiciel c'est la pire idée car les éléments changent souvent et elles deviennent vite obsolète contrairement à un tuto textuel qui lui est plus facile à mettre à jour. Mais bon les gens sont des gros flemmards... Maintenant on a des supers packs tout fait qui intègrent les protections qu'il faut, franchement aujourd'hui ceux qui mettent à jour le font exprès, ça ne peut plus se faire par erreur. Perso comme d'habitude mon pack attendra que tout soit stabilisé pour recevoir sa mise à jour officielle, ceci dit la version de développement intègre les derniers éléments.

C'est à cause du script de débrickage qui a changé des éléments sur ta SD, faut maintenir "R" en lançant l'album ou remettre un pack comme le switch_AIO_LS_pack.

Encore merci pour ton super pack
 
Tu ne mettra jamais Mission-Control dans le pack ?

Je vais répondre pour lui, il n'y aura pas ce module dans le pack car les modules sont trop souvent cause de problèmes et retardent les mises à jour du coup, je fais la même chose dans mon pack à l'exception que moi j'utilise aussi le module Tesla pour les overlays alors que dans ce pack il me semble qu'il n'y est pas.

Très bien la modif qui reboot en OFW avec la config stock si une erreur se produit, au moins les utilisateurs standards sans connaissances n'auront plus de souci avec les majs officielles sur la sysnand.

Ne plus utiliser les sig_patches conventionnels et n'utiliser que Sys-patch, le module fonctionne parfaitement bien et a été plus que largement testé maintenant et au moins plus de fichiers à mettre à jour à chaque fois qu'Atmosphere est mis à jour (loader_patches) et même parfois pas de mises à jour du module à faire à un changement de firmware vu que les patches sont appliqués dynamiquement avec une recherche de paterns, si un est trouvé alors ça applique le patch directement.

Même procédé que sur ce sujet.

Toujours lancer les homebrews hors mode applet (donc pas via l'album), c'est la base pour éviter d'avoir des soucis.

Primo il te faudrait un PC sous Windows, sous Mac ça va vraiment être compliquer de régler ton souci.

Une fois que tu es sous Windows tu mets en place notre pack switch_AIO_LS_pack sur la SD de ta console histoire d'avoir tous les outils à jour, par principe lors du script de nettoyage je te dirais de répondre oui à tout histoire de ne pas avoir de soucis de compatibilité avec le pack. Note qu'une fois le pack en place le démarrage sur l'emunand est automatisé, pour l'annuler il suffit d'appuyer sur la touche "vol-" à l'affichage du tout premier logo, cela aura pour effet de lancer l'interface de Hekate.

Maintenant pour ton souci d'installation du mauvais driver ça se complique un poil, déjà mets en place mon Ultimate-Switch-Hack-Script sur le PC (pas sur la SD de la Switch). Notes que tu aura besoin de dumper les clés de ta console avec le payload Lockpick-RCM (inclus dans mon pack, juste à le lancer grâce à Hekate et à choisir "dump from sysnand" en validant avec "Power" (les touches de volume servent à se déplacer dans ce payload)), le fichier "prod.keys" contenant les clés nécessaires se trouvera dans le dossier "switch" de la SD.

Petite note pour l'utilisation du script car souvent les gens ne comprennent pas ça, quand j'indique un choix "Tout autre choix: ..." ou "N'importe quel autre choix: ..." cela signifie que rentrer un choix ne se trouvant pas dans la liste ou entrer un choix vide permet de faire l'action décrite.

Une fois arrivé sur le menu principal du script tu vas dans "Fonctions de base" (choix "1") puis dans "Installer les drivers" (choix "3" il me semble) et tu choisis l'installation automatique. Un assistant va s'ouvrir, juste à cliquer sur "Suivant" et les drivers s'installeront, tu pourras cliquer sur "Terminer". Normalement cette étape n'est pas nécessaire mais j'aime autant prévoir.

De retour sur le menu principal du script tu vas dans la "Nand Toolbox" (choix "3") puis dans "Installer le driver EXFAT" (choix "6") et tu n'as plus qu'à suivre les instructions. Au moment de choisir sur quoi installer le driver le choix à faire va dépendre du type de ton emunand, si via partition alors le script te proposera un choix qui la ciblera directement et si c'est une emunand via fichiers il faudra que tu fasses le choix "0" puis, dans la fenêtre qui s'ouvrira il faudra que tu ailles chercher le fichier "00" de ton emunand (souvent il se trouve dans "emummc\sd00\EMMC", si tu ne sais vraiment pas où il se trouve tu peux consulter le fichier "emummc/emummc.ini" à la ligne commençant par "path", le chemin est indiqué après le signe "=" donc tu n'auras plus qu'à t'y rendre et à entrer dans le dossier "EMMC" s'y trouvant pour trouver le fichier). Autre note, quand le script te demandera les clés il te suffira de lui indiquer le fichier "prod.keys" dumpé précédemment dans le dossier "switch" sur ta SD.

Voilà, normalement ça devrait être bon, le script flashera se qu'il faut et tu n'auras plus qu'à relancer ton emunand.

PS: Ne te laisses pas impressionner par la longueur et l'apparente complexité des explications, en vrai ça se fait très vite et très simplement si tu fais les choses dans l'ordre, c'est finalement plus long à écrire et à lire qu'à faire.

La question est est-ce que les sigpatchs fonctionneront pour la prochaine maj d’atmosphère ?

Les sig_patches non, le module Sys-patch oui. Comme je l'avais expliqué dans une new précédente le support des fs_patches ne sera plus présent avec la prochaine version d'Atmosphere donc les sig_patches comme on les connaissait largement jusque là ne fonctionneront plus, les fs_patches servant à lancer le contenu (loader patches) mais aussi à l'identifier correctement (fs_patches). En gros les patches se trouvant dans le dossier "kip_patches" d'Atmosphere ne serviront plus, les es_patches eux fonctionneront mais Sys-patch prend en charge la majorité d'entre eux, souvent on utilise les es_patches ailleurs pour créer un logo personnalisé à la place du logo Nintendo Switch.

Donc se sera comme d'habitude, faudra attendre la mise à jour du module Sys-patch si le patern des différents éléments a été mis à jour par Nintendo avec ce firmware, Nintendo peut bien faire se qu'ils veulent les sig_patches existeront toujours et seront mis à jour d'une façon ou d'une autre, il ne me semble pas possible pour eux de réellement mettre fin à cela.

Ba nous avons une puce , donc un dual boot.
On joue en live sur le firemeware officielle , donc si on mets pas a jour on est bloquer pour jouer.
C'est lourd de répéter a chaque mise a jour la même chose sérieux toujours les mêmes question , forcement si on demande c'est qu'on a besoin.

Bah non c'est pas du tout obligatoire d'avoir une partie officielle et une autre non, ça dépend de l'utilisation de chacun, que se soit avec une puce ou non donc bah non la question n'est pas évidente puisqu'on ne sait pas sur quel élément elle porte précisément même si on s'en doute bien évidemment.

Et les réponses sont toujours les mêmes à savoir que oui la partie n'utilisant pas Atmosphere peut être mise à jour, le seul truc qui peut être perdu temporairement est le support des cartouches sur la partie hack à cause des Efuses Lotus si la mise à jour en grille plus que le firmware sur lequel est l'emunand. Pour la partie hack il faudra attendre le support des outils, encore une fois comme d'habitude en fait mais de ce côté rien ne presse.

Voilà, cinq centième fois qu'on l'explique, ça par contre c'est pas chiant du tout, c'est un vrai bonheur de répéter encore et encore et encore et encore et encore et encore et... les mêmes choses, non franchement on adore ça!

Pour les sig_patches plus la peine de s'emmerder, le module sys-patch le fait très bien et Atmosphere ne supportera de toutes façons plus les fs_patches dans sa prochaine version. Après sys-patch a été retiré de Github, va falloir chercher.

J'ai jamais utilisé AIO-Switch-Updater pour ça, j'utilise le pack switch_AIO_LS_pack qui contient le homebrew AIO_LS_pack_Updater qui fait très bien le travail en mettant à jour le pack avec tout se qu'il faut (si les logos ne te plaisent pas le homebrew te permettra de les supprimer durant la mise à jour) et en appliquant certaines sécurités (suppression du thème s'il y en a un avant de mettre à jour le firmware). Par contre si tu souhaites utiliser ce genre de homebrews il faut une SD en FAT32, les SD en EXFAT sont trop sujettes à corruption de données.

Shadow c’est quoi exactement des données télémétriques?

Se sont des données recueillies en général pour faire des statistiques, ici par exemple ça pourrait être le nom du jeu, sa version, le temps qu'il a été lancé, etc... Après ça peut aussi servir à identifier des problèmes, par exemple si je vois qu'un jeu n'est jamais lancé plus de dix ou vingt secondes je peux en déduire qu'il ne fonctionne pas comme il faut. Il est aussi possible d'intégrer d'autres données comme la version de l'OS, la quantité de ram, la configuration de l'émulateur, etc... en fait c'est au final un ensemble de donnée, généralement anonymes, envoyées sur un serveur pour effectuer ensuite diverses analyses. Enfin ça peut aussi servir pour afficher de la publicité ciblée, c'est d'ailleurs de cette façon que la télémétrie est utilisée par beaucoup de grosses entreprises comme Microsoft ou Google et bien d'autres, dans ce cas on a un identifiant unique pour chaque enregistrement télémétrique qui permet de regrouper les résultats pour l'utilisateur ciblé et lui renvoyer des choses pertinentes (ou pas...).

Dans le cadre de Yusu je ne sais pas se qui était recueilli mais de toute évidence il y en avait bien assez pour faire tomber toute l'équipe, en lisant la plainte on apprenait que Nintendo voulait utiliser les données télémétriques de Yusu, ça aurait fait de jolies statistiques pour démontrer le piratage important causé par l'émulateur. Pour moi dans cette affaire il y a eu trois points importants qui ont fait reculer directement l'équipe de Yusu:

• La télémétrie comme je l'ai expliqué.
• Le fait que Nintendo accusait clairement les membres de l'équipe de s'être servi de jeux piratés pour développer l'émulateur et l'adapter à certains jeux (clairement ils auraient pu le prouver facilement et faire payer chacune des personnes individuellement et pour moi c'est surtout ça qui a fait que l'équipe de Yusu s'est couchée directement).
• Le déchiffrage à la volé, là ça aurait été plus délicat pour Nintendo de gagner sur ce point mais ça restait probable mais ça à la rigueur Yusu aurait pu le supprimer et obliger les utilisateurs à extraire les contenus eux-même grâce à Hactool par exemple, moins pratique à l'usage mais bon loin d'être infaisable et surtout facile à automatiser.

Oui, sur les Switch de première génération (avant la lite) le module se déclipse.

Ce one shot de @nightwolf pour deviner qui était le technicien c'est impressionnant, c'est là qu'on voit indiscutablement la différence entre réalité et rumeur au sujet de tel ou tel technicien.

En relisant ton post que veux tu dire par : si la console a déjà été hackée ? Je pars du principe que si on peut injecter le payload et démarrer sur Hekate c’est qu’elle a déjà été hackee non ?

Non, quand je dis est-ce qu'elle a déjà été hackée j'entends plutôt est-ce qu'elle a subit des modifications via un hack (remplacement de PRODINFO, installation de contenus via Atmosphere sur la sysnand, activation de l'auto-RCM même si dans ce cas il suffit de le désactiver via Hekate... bref des modifications visibles par Nintendo). On peut noter que juste lancer Atmosphere sur la sysnand n'est normalement pas visible par Nintendo.