eliboa

@milerwan, tu es certain pour le stealth mode non actif sans licence ? Il me semblait pourtant le contraire mais ma mémoire me fait peut-être défaut.

En tout cas, si le stealth mode est pas activé à ce moment là, il vaut mieux alors privilégier l'activation offline. Je suis d'accord avec toi que si la NAND est clean les risques sont minimes mais en théorie c'est pas infaisable de détecter SX OS (en exécution, pas sur la NAND).

Sinon concernant le flash de BOOT0, je ne peux te parler que de ce que je sais en théorie (les infos viennent de hexkeys) car le code du SX est closed-source et j'ai pas de Switch Mariko personnellement. En gros le chip de la TX, pour éviter de se faire pirater, chiffre un "custom package1" (bootloader) et le stocke sur la partition BOOT0 (la partition qui contient déjà le pkg1 officiel) mais à un endroit non alloué (BOOT0 contient seulement 100Ko de données utiles pour une partition de 4Mo). Ce custom pkg1 est chiffré avec les clés du TSEC mariko + de la TX, que seule leur chip sait obtenir. Ensuite, le chip flashe un (ou deux je ne sais plus) des 4 BCT que contient BOOT0, simplement pour configurer le load de ce "custom package1". C'est tout de ce qui est modifié sur la NAND.

En toute logique, leur outil pour supprimer les traces effectue donc l'opération inverse, c'est à dire reconstruire les BCT précédemment flashées et réécrire des zéros dans la mémoire qui contenait le custom pkg1. J'ai pas trop d'inquiétude sur le fait que leur outil efface bien toutes les traces puisque tout ça est très circonscrit, mais bon ça reste à prouver.

Enfin, oui c'est nécessaire comme outil pour utiliser l'OFW en toute sécurité sur une switch mariko/ipatched car c'est facilement détectable par Nintendo ou NVIDIA, s'ils décident de le détecter. Tout ça reste théorique évidemment.

Il faut espérer que la puce TX soit vite crackée pour que la TX abandonne ce système, qui n'a pas d'autre but que protéger leur innovation. Pour l'utilisateur c'est tout de même assez lourd de reflasher boot0 entre chaque bascule OFW/CFW.

Le truc bizarre c'est que sur une console fonctionnelle cette erreur ne se d’éclanche pas alors que là si et sur toutes les consoles ayant affichées cette erreur (bon quand on a "got 246400 instead of 4294967295 bytes out" le premier nombre peut être différent selon la console) j'ai jamais réussi le moindre débrick, bon après on va chercher un peu car pouvoir écrire la nand avec le mode USB Tools de Hekate va pouvoir changer mon approche, je tiendrais au courant des résultats dès qu'on en saura plus.

Je me dis que cette erreur s'affiche peut-être tout le temps sur toutes les consoles mais que tu ne la vois pas car non persistante. Comme elle n'est pas bloquante, dans le cas d'une NAND non brickée, memloader va ensuite lancer uboot (c'est uboot qui monte ensuite la mmc). A ce moment ta console va rebooter et réinitialiser le hardware donc l'écran (et le framebuffer). Ca serait donc logique que tous les print de memloader disparaissent à ce moment là, même obligatoire.

En y repensant je me suis toujours dis que l'implémentation de minerva ne provoquait aucune augmentation de perf de memloader. Si effectivement le chargement des tables mtc plante systématiquement, c'est pas étonnant ^^.

In fine, j'ai vraiment l'impression que cette erreur est une fausse piste. Si vraiment on veut en avoir le cœur net il faudrait modifier le code source de memloader pour stopper l'exécution à ce moment précis du programme et prouver que cette erreur s'affiche tout le temps.

edit : memloader est vraiment à laisser tomber mainteant qu'hekate a implémenté l'UMS. Côté perf c'est le jour et la nuit.

Bha ton bytes dans le boot 0 a belle et bien ete inscrit donc possible detection nintendo pas pour rien que la Tx a fais le logiciel pour effacer ce dernier et pas sur qu’il soit present dans le cfw non complet

Et compare ce qu’il l’est console via rcm vs console sxcore/lite

Tu me dis fastidieuse.... humm que fera t-il pour mettre ses jeux si c’est fastidieux mettre ta sd dans son pc t’a un probleme la hahaha

Apres fait ce que tu veux et comme tu veux je m’en fou completement, je donnais une soluce offline c’est tout...

Oui enfin le flash de BCT dans BOOT0 pour le SX Core a vraiment rien à voir avec la validation de la licence. Et le risque intervient de toute façon en OFW, pas en CFW pour l'activation de la licence.

@milerwan n'a pas forcément tort sur l'activation via le CFW avec le stealth mode, c'est plutôt safe à mon avis (dès lors que tu utiliseras le stealth mode derrière dans ton utilisation quotidienne).

Après, on peut aussi ne pas avoir confiance dans le stealth mode et dans ce cas la méthode d'activation offline est effectivement à privilégier. Perso j'utilises pas le stealth mode, j'ai pas confiance car je sais pas comment c'est codé et ma switch en CFW est toujours offline.

En gros la solution à utiliser va dépendre de si tu utiliseras ou non le stealth mode par la suite.

@fatiguant enfaite si il lance un jeux nsp/xci puis il remet l'officiel (redémarrage)


Et ce connecte aux wifi pour faire une maj des jeux xci/nsp.

Nintendo va voir les log.

Ce que tu décris n'est un risque que si tu n'as pas d'emuNAND. Et si tu n'as pas d'emuNAND et que tu installes des NSP, ta sysNAND en OFW doit absolument être hors ligne sinon c'est comme si tu implorais Nintendo de bannir ta console

@eliboa : Si tu sais qu'est-ce qui peux provoquer cette erreur dans Memloader au niveau matériel ça m'intéresse fortement.

Côté memloader, il y a un truc qui me semblait être un piste dans l'erreur :

[MTC_Load] Error during lzma decompression, got 246400 instead of 4294967295 bytes out !

4294967295 c'est 0xFFFFFFFF, ce qui est la valeur max d'un entier non signé sur 32bits (u32). En général c'est que la variable u32 a été alimentée avec un entier plus grand que 0xFFFFFFFF (4Gb) ou que la variable n'est pas initialisée et allouée avec des 0xFF.

Je pense donc que cette variable est fausse et je suspecte que les 246400 bytes eux sont correct. 

Ensuite cette erreur est à un seul endroit dans le code de memloader, dans mtc.c (minerva training). Elle intervient lors de la décompression (lzma) des tables mtc qui sont contenues dans mtc_sdram.lzma, fichier ajouté au binaire de memloader lors de la compilation.

Bref, l'erreur est liée à minerva, ça pourrait venir du build de memloader utilisé dans ton script (peut-être), ou dans le mien si tu utilises toujours celui de tegrarcmgui, ou même celui de rajkosto.

Ce qui est bizarre c'est que la variable mtc_sdram_lzma_size qui contient la valeur 0xFFFFFFFF ne semble alimentée nul part dans le code de memloader, ce qui expliquerait logiquement cette erreur.

Bon cette erreur n'a pas l'air bloquante donc je pense que le programme plante plus tard, mais sans faire de print. Je pense que cette erreur n'est pas significative de toute façon. memloader fonctionne quand même sans faire de training de la sdram.

Sinon pour en revenir au pb de Linkynimes, le fait que locpick semble bien dumper toutes les clés exclu à mon avis un problème sur les partitions BOOT (pkg1) ou BCPKG2 (pkg2).

Ca semble être plus en aval dans le processus de boot. Peut-être côté HOS, si Linkynimes ne voit pas le bootlogo HOS.

Peut-être que c'est lié à SYSTEM ou USER ?

Tenez-moi au courant si vous trouvez la soluce en MP

Sous Hekate, dans USB Tools, il faut simplement décocher la case "read only" avant de monter la partition pour pouvoir flasher BOOT0/1.

Dans la future version de TegraRcmGUI je prévois de récupérer cet identifiant automatiquement. Par contre la release est pas pour tout de suite.

Sinon @Linkynimes ça devrait pas être très compliqué de compiler un petit payload qui te récupères cet ID en utilisant le bdk mis à dispo par CTCaer sur le repo d'hekate. Il suffit juste de lire CAL0 en utilisant le petit driver bis fait par shchmue, ici => https://github.com/C...e/nx_emmc_bis.c. Peut-être qu'il faudra lancer Sept pour les FW > 7.0 pour récup les bis keys par contre (à vérifier).

L'erreur 2002-0002 c'est le FS module qui retourne l'erreur "path already exists". On dirait que HOS essaye de créer un fichier/dossier alors qu'il existe déjà. Essaye peut-être de ne garder sur ta SD que ce qui est strictement nécessaire pour lancer le CFW, à savoir Atmosphère et Hekate mais retire tous le reste (dossier nintendo, switch, etc).

Le firmware 6.2 a changé complétement la façon de générer/dériver les clés de la console. A partir de ce firmware les keyblobs ne sont plus utilisés, ce qui explique sans doute pourquoi tes keyblobs apparaissent comme corrompus.

Il faut régénérer les bons keyblobs et les réinjecter dans chaque BCT de BOOT0. Tu peux le faire effectivement avec le script de shadow.

En tout cas, clairement, ta Switch n'est pas HS.

Hum Rajkosto n'a pas prévu de nouvelle version ?

Au pire la version actuelle fonctionnera avec les 1ère console.

Après rien n’empêche de faire bosser HOS pour faire le boulot de mise  a jour en déposant le firmware dans sa zone de MAJ (cf.Goldleaf ) .

Ou au pire via une Cartouche ou pourquoi pas une pseudo cartouche  avec le firmware qui nous intéresse (une sorte de MAJ offline) ...

rajkosto a quitté la scène il y a longtemps maintenant.

Même sans l'arrivée des Switch Mariko, j'attendais un programme open-source digne de ce nom depuis longtemps pour remplacer CDJNX.

Le problème avec CDJNX c'est qu'il est trop silencieux sur les erreurs d'installation et laisse parfois l'impression que tout s'est bien passé à tort.

CDNJX à aussi trois gros défaut majeurs selon moi : 

- Le fait d'activer l'autoRCM par défaut. L'autoRCM pour moi est trop mal compris dans son fonctionnement par les utilisateurs lambda, il ne devrait pas être activé par défaut.

- Le fait de ne pas forcer l'installation du driver exFat alors que le précédent firmware l'avait et que l'utilisateur à une partition SD en exFAT : il suffit de voir tous les sujets "écran noir après installation via CDJNX" sur le forum Switch pour se rendre compte des problèmes que ça pose.

- Le fait que ce programme soit closed-source, ce qui empêche quiconque de corriger ses défauts. C'est un peu ce que je reproche à rajkosto, à la fois sur CDJNX et sur HacDiskMount. D'ailleurs je n'aurai peut-être jamais fait NxNandManager si HacDiskMount avait été open-source. L'open-source c'est la vie !

Je n'ai pas encore testé l'API de SciresM mais j'espère que ces défauts seront corrigés (pour l'open-source c'est déjà fait ^^).

J'imagine que on pourra sélectionner la source du firmware : sur un serv privé, sur un serv public, sur divers clouds, sur la carte sd, ...

Pour le moment ce qui est prévu c'est une install de packages présents sur la SD ou dans SYSTEM :

https://github.com/A...s_utils.cpp#L58

Pourquoi vue tu que cela servent à la team Tx alors que leur outil de mise à jours est déjà pleinement fonctionnel.
ChoixdujourNx est aussi pleinement fonctionnel
Ici ScireM ne fait rien d'autre que réécrire la roue qui existe déjà depuis longtemps (rien de plus)

Lol, c'est vrai qu'avec cette façon de penser personne ne se serait emmerdé à créer Windows (car Mac existait), Android (car iOS existait).

Et puis c'est vrai quoi, pourquoi différencier un programme closed-source d'un programme open-source ?

Bien content pour toi Semaphore. Je suis pas mécontent non plus de ma première intuition sur le MBR (bon j'ai l'expérience de NxNM aussi) . Je pense que ton problème ne venait donc pas de CDJNX ni HOS, c'est finalement ça qui nous a fait partir vers une fausse piste à un moment. Il reste que je ne comprends pas exactement ce qui a pu provoquer le problème dans le MBR à la base.

En tout cas ça confirme ce que je pense depuis longtemps du payload SX loader (jamais mis à jour par la TX il me semble), il gère pas bien le MBR là ou Windows ou Hekate savent très bien le faire. Ayant étudier tout le design du MBR pour NxNM je vois pas en plus ce qu'il y a de compliqué la-dedans mais bon il faudrait avoir accès au code source du loader SX pour le savoir.

Et puis ce message d'erreur générique "boot.dat ?" est très joli mais il manque vraiment des informations pour comprendre le problème. A force de vouloir faire des trucs hyper user-friendly ils en oublient l'essentiel. De toutes façons, quand je regarde rétrospectivement tout le passif de la TX sur la scène Switch, je me dis qu'ils en ont rien a secouer que des utilisateurs soient incapable de résoudre les problèmes causés par leur software ou leur manque de communication. Je suis dur avec eux mais merde ils vendent quand même leur licence 30 boules.

Hello, ça pourrait être une sd défectueuse ou contrefaçon ou autre chose...

1) Tester ta SD avec le logiciel h2testw.

2) Si le test ne décèle pas d'erreur, nous dire quel est le bug et le message d'erreur exact parce que là tu nous donnes pas beaucoup d'éléments pour comprendre (quel logiciel tu utilises ? quel format de jeu nsp ou xci ? est-ce que tu as une emunand ?).

3) Faire un tour sur la FAQ de shadow, les problèmes de SD y sont abordés. Aussi n'hésites pas à faire une recherche sur le forum car ce genre de question/problème a déjà été abordé de nombreuses fois

Justement dans mon cas , j'ai juste recopier tout le contenu de la carte chinoise vers la carte officiel Samsung et ça marche , plus aucun soucis.

Souvent c'est un problème de capacité car les chinois trichent mais ça se détecte facilement  avec les logiciels de test .

Par contre des fois c'est d'autres soucis et là aucun logiciel ne peut rien faire ,obligé d'essayer la carte en condition réelle.

 

Les chinois pour vendent a très bas prix , ne respecte pas les standard internationaux que se soit en matière d’électroniquement , de mémoire , de câbles .....ect

 

Attention , on parle bien des produits a base prix car pour le reste y a pas de soucis , les grosse marque  Chinoise ont un niveau de qualité équivalent au marque occidentale .

C'est une coïncidence que dans ton cas que ça fonctionnait ou c'est peut-être parce que tu n'avais pas beaucoup de données sur ta carte car quand tu écris un fichier sur un/des secteur(s) qui n'existe(nt) pas physiquement (ce qui est le cas avec les SD fake), la donnée n'est pas vraiment écrite sur le disque (puisque le secteur physique n'existe pas). Pour autant ton fichier est bien alloué dans la FAT et bien décrit dans une entrée de la directory table. Mais la donnée réelle n'existe pas vraiment donc quand tu copies ce fichier vers une autre SD, c'est impossible que ça fonctionne, ton fichier peut paraître copié (sa structure) mais pas les clusters de données associés.

Par contre si ton fichier était stocké sur un ou plusieurs "vrais" cluster de ta carte SD fake, ça fonctionnera.

En fait, c'est hyper facile de faire une SD contrefaite. Tu prends une SD de 8 Go, tu changes le secteur de fin de ta partition dans le MBR et le nombre total de secteur de ta partition pour faire une partition de 128Go (par exemple) et voilà. 

Le truc c'est que tout ce que tu copieras au delà des 8 Go physique de ta SD ne sera soit pas copié du tout (le plus vraisemblable), soit copié sur un vrai cluster déjà alloué dans la FAT mais pour un autre fichier (corruption donnée existante). Dans les deux cas, tu as une perte de donnée, c'est inévitable.

Ton problème m'intrigue quand même, là on parle de boot.dat qui n'est pas trouvé, donc c'est quasi le premier truc que va faire le payload sx_loader. Le seul truc dont ce payload a besoin c'est boot.dat et ce serait bizarre que boot.dat soit corrompu (car pas touché par HOS). Un moyen rapide de t'en assurer est de comparer les hash md5 de ton boot.dat mais bon vu que ça marche sur ta SD n°2, peu d'intérêt !

Tu peux aussi tester de monter ta SD via Hekate, pour bien prouver que Hekate lui voit bien ta partition et tes fichiers.

Mais à mon avis le problème est ailleurs, je verrai bien un problème au niveau du MBR qui décrit les partitions de ta SD, ou plutôt la manière dont SX OS lit le MBR. Je serais toi je tenterais une reconstruction du MBR via un logiciel de partitionnement, ça vaut le coup d'essayer.

J'ai vraiment l'intuition que ton problème ne vient pas de tes partitions/données en elle-même, ce qui expliquerait pourquoi ça fonctionne quand tu copies/colles tes fichiers vers une autre SD.

Aussi je crois pas trop à une fake SD vu que tu as passé le test h2testw.

edit : ha oui, aussi avant de reconstruire le MBR, regarde bien l'adresse du premier secteur de ta partition sur la SD OK et compare le à celui de ta SD KO.

edit2 : le truc qui me fait douter sur l'origine de ton problème c'est que ça serait CDJNX qui aurait causé ça, ça colle pas.