shadow256

@eliboa : J'utilise la même version de Memloader que tu as modifié pour Tegrarcm GUI et j'utilise cette commande pour Tegrarcm Smash:

tools\TegraRcmSmash\TegraRcmSmash.exe -w tools\memloader\memloader_usb.bin --dataini="%ini_path%"

Ou la variable "ini_path" prend la valeur défini selon le choix de la partition de l'utilisateur stocké dans la variable "disc_mounted":

IF "%disc_mounted%"=="1" (
set ini_path=tools\memloader\mount_discs\ums_emmc.ini
) else IF "%disc_mounted%"=="2" (
set ini_path=tools\memloader\mount_discs\ums_sd.ini
) else IF "%disc_mounted%"=="3" (
set ini_path=tools\memloader\mount_discs\ums_boot0.ini
) else IF "%disc_mounted%"=="4" (
set ini_path=tools\memloader\mount_discs\ums_boot1.ini
) else (
    goto:end_script
)

@PanpanDanton2 :

Pour le souci avec Memloader là je ne vois pas d'où cela pourrait venir, perso je n'ai jamais eu ce genre de problème. Faudrait faire un test avec mon script pour voir si la même erreur ce produit (Choix 3 dans le menu principal) mais là soit tu as un problème avec l'USB côté Switch, soit un souci au niveau de la nand, soit un souci sur le PC avec des drivers qui seraient en conflit, après se qui est vraiment étrange c'est que ça ne se produise que sur BOOT1 et la RAWNAND. Par contre rien à voir avec NXNandManager mais peut-être un bug avec Tegrarcm GUI même si j'en doute, en fait mon script et le soft d'@eliboa utilise exactement la même version de Memloader ainsi que la même méthode pour le lancer donc pas vraiment de raison que ça fonctionne sur l'un et pas sur l'autre.

Pour l'info sur le bannissement je ne l'ai jamais ajoutée à la FAQ car je ne suis pas certain de sa véracité. Oui ça semble important mais en même temps ne pouvant être sûr de rien je préfère éviter les infos que je ne peux pas vérifier.

Enfin non, tu ne peux restaurer les partitions différente du firmware que tu utilises (SYSTEM c'est certain car les NCA du firmware s'y trouve, peut-être que USER c'est faisable par contre mais perso je ne le ferais pas).

Les choses se précisent, là on a le début de l'environnement qui est mis en place. Du bon travail.

@PanpanDanton2 :

Comme je te l'ai dit j'aime pas trop définir des valeurs arbitraires, moi soit je fais quelque chose qui marche pour 99% des gens, soit je ne fais pas mais pas question de transiger avec une solution qui ne serait pas valable pour tous en théorie. De fait la seule solution serait donc de faire plus ou moins comme je l'ai dit avant, en prenant en plus en compte que la fenêtre peut être redimensionnée durant le script se qui oblige à vérifier tout le temps la taille de la fenêtre (encore du temps de perdu). Cependant je le ferais peut-être un jour, se sera une fonctionnalité que je noterai dans la section des choses à faire dans la documentation et si un jour j'ai envi de me lancer dans le développement de cette fonctionnalité je le ferai, comme j'ai fini par le faire pour le multi-langues et l'auto-updater que j'ai mis certes du temps à sortir mais un jour j'ai fini par m'y mettre et maintenant c'est intégré pleinement à mon script.

Pour le HS en fin de ton message je dirais plutôt que ma richesse est celle de l'espris, le reste tant que je peux avoir un toit au-dessus de la tête et à manger j'ai finalement pas besoin de bien plus.

tu as checkpoint pour les save de jeux aussi note bien l' arborescence de ta save puis tu replace au même emplacement puis checkpoint et tu restore tes saves

Oui enfin pour son cas là ça n'a aucune importance, les sauvegardes seront gardées avec la manipulation que je propose. Ceci dit Checkpoint reste un homebrew très utile et ça peut faire une sécurité en plus au cas où il y ait un souci durant le processus et qu'il faille au final recréer une emunand mais bon si les choses sont bien faites normalement aucun souci de ce type ne devrait se produire.

@marto : Parfois il vaut mieux prendre du recule un temps, ça évite de saturer et de complètement rejeter en bloque les choses. Pour les raisons personnelles qui me font m'éloigner de la scène elles sont très positives, se sont juste d'autres projets qui n'ont aucun lien avec le développement ni même avec l'informatique (un nouveau chiot vient de rejoindre ma petite meute donc je dois me concentrer sur son éducation et je veux aussi mettre en place un potager (germination, herbes aromatiques et médicinales, légumes, etc...) en permaculture et là aussi ça prend et prendra du temps) et ces projets sont des choses que je met en place tranquillement depuis très très longtemps (il faut des connaissances, de l'argent, du terrain et de la logistique et préparer tout çà ne se fait pas simplement en claquant des doigts) et là j'arrive aux phases de concrétisation des choses donc je dois m'y consacrer de manière nettement plus intensive si je veux que ça fonctionne.

@gurdhyl : Oui, cette technique est et restera d'actualité.

@PanpanDanton2 :

 

Déjà merci beaucoup pour tes retours enthousiastes, ça fait toujours plaisir de voir que le travail convient aux utilisateurs dans l'ensemble.

Merci pour l'erreur pointée dans les crédits, elle sera corrigée dans la prochaine version.

Pour GagOrder non, il ne fonctionne plus depuis très longtemps (d'ailleurs je ne suis même pas certain qu'il ait un jour fonctionné réellement correctement), raison pour laquelle j'ai fini par le retirer.

Pour couper les mots ou les phrases oui se serait faisable mais pour le faire vraiment proprement il faudrait avoir une variable contenant la largeur de l'écran et avant chaque "echo" compter le nombre de caractère de la sortie voulu, couper la phrase au mot précédent si la longueur dépasse la largeur de l'écran et refaire cela si la longueur dépasse encore la largeur de l'écran jusqu'à se que se soit bon. Si on ne le fait pas ainsi on peut le faire aussi en décidant arbitrairement d'un endroit à laquelle couper la phrase mais voilà, selon la largeur de l'écran de l'utilisateur cela pourrait donner un résultat plutôt aléatoire se que je ne veux absolument pas, soit on le fait bien ou soit on ne le fait pas. Perso je trouve que faire cela serait une bonne chose mais déjà se serait un gros travail de réécrire chaque "echo" de cette façon et puis bon c'est du temps de traitement relativement inutile au final, si le script était un programme C par exemple çà vaudrait le coup mais avec du batch je ne suis pas certain que l'idée soit très bonne; cependant si tu veux le faire soit il faudrait écrire un programme en C prenant en paramètre la phrase souhaitée ainsi que la largeur de l'écran et qui s'occupe de faire le traitement et d'afficher la sortie ou soit on pourrait utiliser "grep" pour compter le nombre de caractère du "echo" (via un pipe) puis gérer le traitement via une fonction globale écrite en batch. Et puis bon il faudrait aussi gérer les "set /p" de cette façon pour vraiment bien faire se qui augmente encore le temps à passer pour faire cela. Voilà, c'est pas infaisable dans l'idée mais perso je ne pense pas que je le ferai ou du moins pas d'ici un bon bout de temps au vu du travail important à fournir pour implémenter cela.

Pour compter réellement le temps passé sur ce script il faut en premier lieu remonter à ce script qui a posé les bases au fur et à mesure, mon script pour la Switch est la continuité de celui de la Wii U même si maintenant mon script Wii U me parrait bien mal ddéveloppé et pauvre à côté de mon script pour la Switch dont l'auto-updater et le multi-langues sont pour moi une sacré satisfaction.

 

Pour finir j'aurais meilleur compte à réécrire le script en C ou en Python car se serait bien plus puissant mais bon c'est amusant de développer en batch (certaines fonctionnalités ont été un vrai défit) et surtout pas besoin de librairies à installer ou pas besoin de compiler avec tel ou tel environnement de développement, normalement on lance et ça fonctionne (bon après certains programmes tiers peuvent avoir besoin de .net Framework ou des librairies de VisualC++ mais je ne crois pas qu'il y en ait tant que çà).

@marto : Mon éternel souci est que je suis un peu perfectionniste et que donc j'ai du mal à laisser mon travail se perdre dans l'obsolescence (il n'y a que mon script PS3 que j'ai pour l'instant laissé de côté car trop de choses à réécrire) donc je ferais probablement toujours des mises à jour, seulement elles seront bien moins fréquentes qu'avant. Là par exemple j'ai vu la sortie de Atmosphere 0.10.2 mais les fichiers de configs ont encore été changés et donc il faut que je mette aussi à jour la fonction de configuration manuelle de ces fichiers dans mon script, fonction qui n'est à mon avis utilisée que par peu d'utilisateurs mais je me refuse à publier une mise à jour tant que ceci n'est pas fait car sinon j'ai une partie de mon script que je juge vraiment importante qui ne fonctionnera plus bien (j'essaie vraiment d'avoir un script sans bugs et sans manquements pour la préparation d'une SD) mais voilà, ceci prend encore pas mal de temps à faire à chaque fois et là la logique du fichier "overide.ini" a été complètement revue et réadapter le script nécessite que je révise la logique pour ce fichier se qui est long et je n'ai plus le temps de faire tout cela pour l'instant pour pas mal de raisons personnelles qui s'ajoutent à mon agacement effectif contre pas mal d'utilisateurs dont je trouve le comportement irrespectueux des travaux qui ont été faits sur ce forum pour rendre la plupart des choses accessibles et simples pour peu qu'on prenne le temps de les regarder ou d'utiliser la fonction de recherche du forum.

@oob :

 

Déjà le support des XCI n'a rien d’anecdotique et peut s'avérer parfois plus pratique que les NSP (perso je n'ai jamais eu de comportement bizarre avec mes supers XCI là où des NSP ne fonctionnent plus entre certaines mises à jour du firmware, ne se lance plus on ne sait pourquoi... bref moi les XCI on toujours fonctionnés sans aucun souci et si j'ai besoin de reset ma console il n'y a qu'à sauvegarder/restaurer les sauvegardes des jeux mais pas besoin de réinstaller quoi que se soit). De plus SX OS dispose aussi du support des disques USB pour lancer les XCI, les homebrews et aussi pour installer des NSP (attention, on installe pas de NSP sur le disque USB mais depuis le disque USB). SX OS reste aussi très simple d'utilisation (on ne se prend pas la tête avec les sig_patches ou autres, juste deux fichiers à copier pour que ça fonctionne). Pour le reste par contre Atmosphere fonctionne au moins aussi bien que SX OS (sauf l'emunand via fichiers en FAT32 qui est catastrophique sous Atmosphere) et supporte en général mieux les nouveaux modules et certains homebrews. Enfin, Atmosphere est plus configurable que SX OS, pratique mais pas franchement utile pour beaucoup d'utilisateurs qui se contenteront des paramètres par défaut.

Voilà, utiliser Atmosphere peut suffire mais SX OS apporte certaines choses en plus qui peuvent être intéressantes. Perso j'utilise les deux, Atmosphere pour toute la partie homebrews/modules et SX OS pour la partie lancement de jeux, les deux CFWs partageant la même emunand il est aisé de passer de l'un à l'autre très facilement.

Autant mettre à jour en 9.1.0 et SX OS 2.9.3 beta, c'est ni plus ni moins stable que la 9.0.1 avec SX OS 2.9.2 donc bon autant mettre à jour sur la dernière version.

Je rappel également que quand on ne suit plus le hack depuis un moment, il y a toujours la FAQ qui centralise les infos essentielles et que j'essaie de maintenir le plus à jour possible.

@RomAnOCrY : Très probablement, je ne vois pas se que ça pourrait être d'autre.

La team Xecuter va sortir une solution hardware pour les consoles patchées en début d'année prochaine, par contre on ne connait pas le détail du fonctionnement ni même s'il y a des limites au niveau du firmware ou si l'exploit qui sera utilisé sera patchable ou pas par Nintendo avec une mise à jour. En tous cas si tes gamins veulent jouer en ligne il faut mettre à jour la console sur la dernière version du firmware (aujourd'hui la 9.1.0) et ne pas utiliser de DNS spécifique car ça bloquera le jeu en ligne (les DNS servent à bloquer l'accès aux serveurs de Nintendo). Sinon si tu ne veux prendre aucun risque pour le hack alors il faudra attendre pour le jeu et les actions en ligne.

Selon Switchbrew, c'est un firmware spécial qui est installé en usine. C'est une version minimale qui contient un nombre très limité de titles par rapport au firmware "retail". Une version modifiée du boot2 (premier sysmodule non intégré qui est lancé) est installée et permet de lancer un module "manu" (manufacturing) qui n'existe pas sur les firmware retails ainsi qu'un titre appelé "Test Application Launcher" à la place du qlaunch. 
D'après la description du module Manu sur Switchbrew, c'est une simple interface USB qui permet de créer des pipes pour lire/écrire via USB. Je suspecte que c'est via l'USB que sont ensuite transférées les données qui permettront la calibration et le firmware retail. Ca doit être comme ça qu'il injectes les certifs je pense donc le fait d'avoir un dump de ce firmware ne risque pas de permettre de "débannir" une console mais bon j'avais pas trop de doutes la dessus ^^.
Donc pour répondre à ta question (qui ne s'adressait pas à moi héhé), je dirai que ce firmware factory se trouve sur la NAND (logique), surement dans les partitions BCPKG2 (package2 : kernel et sysmodules) et peut-être aussi sur d'autres partitions (qui peut-être sont différentes de celles de la version retail), je ne saurait trop dire.

Je ne savais pas que c'était décrit sur Switchbrew (bon après j'ai pas trop cherché non plus j'avoue), j'y vois un peu plus clair maintenant sur comment ça fonctionne. Merci.

@Boukaki76 :

Je pense que ce menu n'apportera rien de plus au niveau du hack à proprement parlé, c'est-à-dire qu'on y découvrira pas de nouvelles failles exploitables car ce menu n'est pas sur les consoles en temps normal. Après ça risque de nous en apprendre sur la dernière chaine du process de fabrication de la console et on pourra peut-être en faire quelque chose pour les consoles non-patchées, faudrait savoir exactement se que ce menu est et permet pour se prononcer.

Autre possibilité, ce menu est un payload signé qu'on pourrait exploiter via le RCM et là comme il est signé on pourrait l'exploiter sur toutes les consoles mais bon je doute très très fortement que se soit ce genre de choses, déjà parce que le payload serait sur la console et exécuté directement et çà j'en doute vraiment. Par contre si c'est çà là ça pourrait devenir très intéressant car on pourrait découvrir des éléments sur le processus de signature d'un payload par Nintendo mais bon ne rêvons pas trop.

On pourrait aussi imaginer un élément exécuté via des partitions non chiffrées et en ce cas il serait possible, en utilisant un élément externe, d'écrire le programme sur la nand pour ensuite forcer la console à l'exécuter mais si le truc est sur une partition chiffrées bah là ça n'apportera encore rien du côté des consoles patchées.

En résumé pour les consoles non patchées on a ici un menu qui peut être intéressant selon se qu'il permet de faire et pour les consoles patchées par contre ça ne changera probablement rien, ceci dit se que je dis n'est qu'hypothèses, avec si peu d'informations on ne peut rien prédire et je comprends que les développeurs s'y intéressent de près.

PS: Quand je dis console patchés j'entends celles qui sont sur un firmware supérieur au 4.1.0, je considère que pouvoir exécuter Cafeine donne les mêmes possibilités que pour les consoles non-patchées mais avec le risque que si on fait une mauvaise manipulation et qu'on brick c'est bien plus compliquer de réparer, sans les clés de la console ou un dump de la nand c'est même impossible.
 

Zoria s’y connais bien aussi

@eliboa également et bien mieux que moi d'ailleurs.

Homebrew très pratique mais je trouve qu'une réécriture en SDL n'a pas d'intérêt ici, le homebrew faisait une taille réduite de quelques KO avant et maintenant il dépasse les 8 MO. Selon moi ce genre de programme n'a pas besoin d'être beau, juste il doit être pratique et une faible taille fait partie de cet aspect pratique. Bon après c'est que 8 MO me dira-t-on avec raison d'ailleurs, qu'est-ce que 8 MO même sur une carte de 64 GO mais bon pour un homebrew de ce type pour moi ça fait déjà bien trop.