[Switch] Ultimate-Switch-Hack-Script 4.3.163 disponible
[Vita] VitaDock Plus v2.6 disponible[XB/XB360] Disponibilité de FATXplorer v3.0 Beta 33Depuis cette news, mon ensemble de scripts batch permettant de faire de multiples choses liées au hack de la Switch a pas mal évolué et de nombreux bugs ont été corrigés.
Pour rappel, mon script permet par exemple de préparer une SD avec le contenu nécessaire au lancement d'un CFW, des homebrews, des modules et des overlays; de plus, il est possible de créer des profiles pour chaque élément se qui permet une configuration à la fois assez précise et qui peut être reproduite rapidement. Le script contient aussi de multiples fonctions permettant d'agir sur la nand (infos, dump, restauration, activation/désactivation de l'auto-rcm, montage d'une partie de la nand sur le PC grâce à Memloader...), il contient un lanceur de payload, on y trouve aussi NSC_Builder traduit en français et encore bien d'autres choses, voir cette page pour voir une liste de fonctionnalités plus détaillée.
Beaucoup de choses ont évolué depuis la dernière new, par exemple dans la préparation d'une SD la gestion des sig_patches est réapparue grâce à un projet externe, les consoles équipées de puces SX Core/Lite sont maintenant supportées dans pas mal de fonctionnalités, le script de débrickage a pas mal évolué, les derniers firmwares sont supportés, les différents outils/CFWs/homebrews ont été mis à jour... et de nouvelles fonctions sont apparues comme la création de forwarders compatibles avec les dernières versions d'Atmosphere, la création des sig_patches pour Atmosphere, le flash des puces SX Core/Lite... Bref comme d'habitude il y a bien trop de choses qui ont évolué et beaucoup de bugs corrigés, pour savoir se qui a changé je vous suggère de consulter les changelogs qui seront indiqués un peu plus loin.
Je me permet de rappeler que mon script n'est qu'une aide pour le hack et même si les choses sont généralement expliquées durant l'exécution des fonctionnalités cela ne dispense pas de comprendre se que l'on fait, par exemple il y a la FAQ qui est un bon point de départ et qui contient pas mal d'informations et de liens vers différents tutoriels. Il y a aussi la documentation du script qui pourra parfois vous aiguiller sur les choses à faire ou sur les éléments contenus dans la préparation d'une SD, n'hésitez pas à la consulter et même à regarder les crédits qui peuvent contenir des informations intéressantes.
Pour voir les évolutions de mon script, vous pouvez vous rendre sur cette page pour le changelog du script et sur cette page pour le changelogs des packs de CFW/homebrews/modules/overlays/cheats.
La version base peut être téléchargée ici; pour la version complète vous pouvez cliquer ici mais je recommande plutôt de passer par la version base et d'utiliser le gestionnaire de mises à jour intégré au script pour ajouter ou mettre à jour les différentes fonctionnalités.
Histoire de clarifier le comportement du gestionnaire de mises à jour du script je vais réexpliquer son fonctionnement, la demande intervenant en premier lieu juste après le premier message du script met seulement à jour les éléments de base du script comme les menus ou les programmes indispensables au bon fonctionnement de l'ensemble, ensuite chaque fonctionnalité est gérée indépendamment et si la mise à jour est acceptée sur une fonctionnalité, les éléments de base seront aussi mis à jour. Bon maintenant pour expliquer en pratique on va imaginer que vous utilisiez le script pour lancer des payloads et préparer une SD se qui représente deux fonctionnalités différentes, pour avoir la dernière mise à jour des deux fonctionnalités il faudra lancer chacune d'entre elle et accepter à chaque fois la mise à jour. Après il y a aussi une fonction qui permet via le menu "A propos", de mettre à jour l'ensemble des fonctionnalités du script en même temps mais ceci peut donc prendre beaucoup de temps car il y aura beaucoup de choses que le script devra vérifier/télécharger.
J'ai choisi cette façon de fonctionner car mon script est devenu assez volumineux avec le temps et tout mettre à jour en même temps n'est, selon moi, pas la bonne stratégie car même vérifier que tel ou tel élément est à jour est déjà très long alors qu'avec ma méthode déjà on ne récupère que se dont on a besoin et quand on en a besoin (bon plus parfois car par exemple dans la préparation d'une SD tous les packs sont récupérés alors que tout ne servira probablement pas mais bon encore une fois à un moment il faut faire des choix) et surtout les vérifications et mises à jour sont bien plus courtes et donc celles-ci peuvent être faites plus souvent tout en étant moyennement gênantes dans l'utilisation.
En cas de bugs, de propositions de fonctionnalités ou d’améliorations veuillez s'il vous plaît passer par le Github du projet ou bien par le sujet dédié à mon script sur le forum, de cette façon je peux traiter bien plus rapidement les informations/demandes.
Enfin, vous avez cette page pour voir les nombreux crédits pour les outils utilisés dans mon script à un moment ou à un autre, comme d'habitude remercions tout ce beau monde pour leurs travaux, leurs participation au projet d'une manière ou d'une autre et également un grand merci aux quelques donateurs.
Merci pour le travail fourni meme si je préfère tout faire manuellement que via un script.
En effet, quand je dis "manuellement", je parle des opérations basiques.Si tu parles de la préparation de la SD je peux comprendre mais faire les choses manuellement requière d'aller chercher chaque élément séparément (et avec le nombre d'outils et de forks sur Switch c'est pas toujours évident de trouver, encore moins si on ne maîtrise pas trop l'anglais) et surtout cela requière aussi de bien savoir se que l'on fait, par exemple entre Atmosphere 0.20.0 et 0.20.1 il faut supprimer le fichier "fusee_mtc.bin" et modifier le fichier "atmosphere\config\bct.ini" pour s'épargner un bug gênant, chose que gère automatiquement mon script sans obliger à chaque fois à une reconfiguration. Et des exemples du genre il y en a pas mal (un autre exemple est la configuration automatique du fichier de configurations pour l'overlay FastCFWSwitch selon les paramètres choisis pendant la préparation de la SD qui est tout de même plutôt pénible à faire manuellement même si normalement on ne le fait qu'une fois), comme mon script suit les évolutions du hack quasiment depuis le début il sait aussi gérer les choses dans un grand nombre de situations. Après l'inconvénient est qu'il peut y avoir des bugs durant le script (même si en général j'essaie de les corriger dès que je les remarque ou dès qu'on m'en fait part) et il y aura forcément des choses inutiles sur la SD (choses qui prennent très peu de place je précise) puisqu'un maximum de configurations sont prisent en compte avec les réglages même les plus basiques (d'ailleurs au passage je pense qu'un allègement du pack Atmosphere sera fait très bientôt). Du coup effectivement on a des avantages et inconvénients dans les deux cas, se que je peux dire c'est que mon script est de loin le plus complet dans la mise en place/mise à jour d'une SD pour le hack Switch avec une personnalisation extrêmement poussée si on se donne la peine de la faire mais je conçois complètement qu'on ne souhaite pas automatiser cela.Par contre pour des fonctions comme le débrickage, la préparation d'un firmware sur la SD pour une mise à jour via Daybreak, la réécriture des key_blobs d'un fichier BOOT0 (aujourd'hui plus vraiment nécessaire car Atmosphere 0.20.0 ne s'en sert plus et le démarrage officiel n'utilise plus ces clés depuis le firmware 6.2.0) et quelques autres fonctions c'est limite du masochisme de s'imposer çà manuellement, par exemple http://www.logic-sun...ant-choidujour/ plutôt pénible ne se résume qu'à une procédure guidée par une série de questions et d'instructions plutôt basiques et le script TegraExplorer qui y est lié permet de résoudre la majorité des problèmes en à peine 10 minutes. Et tout cela se sont des choses qui ne sont pas développées ailleurs, tout comme les informations d'analyse d'un fichier de clés qui peut s'avérer très utile pour savoir quelles clés son uniques à la console, lesquelles sont communes ou lesquelles de ces clés communes seraient manquantes (notons que toutes les clés communes ne sont pas indispensables mais ça peut orienter vers une piste pour résoudre certains soucis). Et il y a même des outils existants qui sont améliorés par rapport à se qui existe, par exemple la création de fforwarders ou de jeux GameMaker pour ne citer que les plus récents travaux.Bref comme tu l'as fait remarqué avec ton utilisation du Serial Checker il y a forcément au moins une fonction utile pour chacun, son côté "ultimate" je pense qu'on peut dire qu'il ne l'a pas volé et d'ailleurs il l'est tellement qu'il devient impossible de tout tester correctement par moi-même se qui est la raison pour laquelle j'insiste toujours pour que les utilisateurs me rapportent les bugs rencontrés.Merci pour le travail fourni meme si je préfère tout faire manuellement que via un script.
En effet, quand je dis "manuellement", je parle des opérations basiques.
En résumé: utiliser Tegra, Lockpick, Hekate, Atmo, DBI et les derniers sigpatch pour exploiter une Erista.
Oui je me doutais bien et en plus faire les choses manuellement permet de mieux les comprendre.
La version 4.3.160 prend en charge Atmosphere 1.0.0 avec un nettoyage des fichiers inutiles des anciennes versions dans la préparation d'une SD.
La version 4.3.160 prend en charge Atmosphere 1.0.0 avec un nettoyage des fichiers inutiles des anciennes versions dans la préparation d'une SD.
Parfait. Cela va faciliter les migrations et éviter les erreurs de suppressions des users pas très à l'aise...
Merci à toi.
J'espère que ça servira...
La version 4.3.162 est disponible, j'ai réécrit le script permettant de générer un SXOS hacké car il y a eu des mises à jour que je n'avais pas suivi à ce sujet qui ont amélioré pas mal de choses. De plus, le script sur Gbatemp comporte certains bugs pénibles à l'heure actuelle, ceux-ci je les ai corrigés, voir ici pour voir le script corrigé en question.
Edit: Version 4.3.163 qui ajoute quelques possibilités au spoof de SXOS, ici à savoir l'activation ou non de l'autoboot. La gestion des paramètres a également été revue pour être plus précise et quelques autres changements ont été apportés.
