eliboa

Jette un œil à ça : How to skip the "Connect Joycons" system init screen | GBAtemp.net - The Independent Video Game Community

Moi je pense qu'il y a rien  au soleil nous avons que Nintendo of america qui s"attaque à une  la personne publique un peu trop exposé  ...

Comme a l'époque de Nintendo France avec le doctor 64 et les teams dumping  pour ceux qui on connu . (quand il y avait pas l'internet "publique"  il me semble même qu'il y a eu un reportage par une chaîne publique en France  faudrait que je fouille sur l'INA) ou de revendeurs trop exposé.

 

Nintendo a toujours utilisé la peur du gendarme contre un des maillons (les revendeurs plus facile à attaquer juridiquement ).

Après pour le futur il y aura toujours des dev et le désir de hacker  qu'il soit par passions ou par business.

 

Même si ça porte un coup a SX OS pour le support FW , nous avons toujours le site SXOS actif et le serveur de licence qui fonctionne .

Bref en dehors des déboires judiciaire d'une  partie de la team exécuter . attendons de voir la suite  ...

Ta référence à l'époque d'avant "les internets" ça me rappelle quand mon daron fabriquait des décodeurs pirates canal+. A l'époque, y'a plus ou moins 30 ans, tu commençais à en trouver pour quelques centaines de francs si tu connaissais un mec qui connaissait un mec qui connaissait.... Tout ça était pas hyper connu du public lambda, mais internet n'avait pas encore relié tous les êtres humains sur terre. J'ai parfois la nostalgie (surement fantasmée) de cette époque ^^ Internet à rendu les choses tellement faciles maintenant, c'est une autre dimension.

En tout cas, Canal+ avait répliqué avec un nouveau décodeur plus sophistiqué. Puis ce fût le jeu du chat et de la souris (ou le jeu de la taupe pour reprendre les avocats de big N).

Pour moi, dès lors que quelqu'un cherche à faire du profit via le hack, l'entreprise visée est non seulement légalement mais surtout moralement légitime à répliquer de manière très dure.

Le passionné qui fait de la retro ingénierie, le hackeur ou le gars qui partage ses connaissances avec la communauté ne sera jamais à mettre sur le même plan.

89% des switch hackées à la ventes chez les revendeurs ont SX OS installé, quand même. Je pensais pas que c'était autant. 

Nintendo justifie sa plainte en parlant avant tout du préjudice concernant les jeux vidéos (c'est bien le piratage qui est visé, plus que le hack).

Intéressant aussi de voir comment quelques pauvres posts de blog qui montrent des images de SX OS en action constituent une preuve de violation des DMCA. Pareil pour SX Dumper ou SX Installer.

Ca m'a fait sourire, à un moment donné Nintendo évoque les Switch erista patchées (à partir de juin 2018) : "Bien que ni SX Pro ni SX Tools n'étaient capables de contourner les protections des consoles après juin 2018, il y a alors environ 20 millions de consoles qui pouvaient toujours être hackées avec ces produits. Pourtant ça n'a pas arrêter l'accusé". Lol, genre Gary OPA se serait contenter du SX Pro Nintendo n'aurait rien dit

Sur le Stealth mode : "Cette fonctionnalité permet à l'utilisateur de se connecter en ligne sans se connecter aux serveurs Nintendo, permettant d'éviter la détection de SX OS, ce qui pourrait déclencher le bannissement de la console. Apparemment conscient que sa fonctionnalité ne permettait pas de complétement cacher un utilisateur SX OS de Nintendo, la TX a publié un post sur son blog pour avertir qu'elle ne ne pouvait pas garantir la non détection par Nintendo". Haha ce troll.

J'aime aussi cette référence au jeu de la taupe ^^ :

He has empowered resellers to re-emerge and launch new websites — including after the same websites had been shut down by courts and other vehicles of enforcement — and facilitated additional avenues of distribution, all for distribution, all forcing Nintendo into a game of whack-a-mole

Après peut-être aussi que la console ne déclenche pas son mode RCM de manière automatique, la corruption du BOOT0 est peut-être à un endroit permettant un pseudo démarrage de la console et que ça bug ensuite (genre problème d'Efuses par exemple même si ici normalement c'est pas le problème puisque mise à jour de manière officielle mais bon c'est pour illustrer se qu'il pourrait se passer). Là le mieux pour tester serait, une fois la console branchée au PC, de maintenir le bouton "Power" pendant une bonne vingtaine de secondes puis de faire la manipulation pour passer en RCM (un jig serait top ici mais bon sinon avec la méthode trombone et démarrage en maintenant "VOL+" et en appuyant une fois sur "Power" ça peut fonctionner) puis voir si le mode RCM est détecté. Sinon méthode infaillible pour savoir si c'est un souci hardware qui empêche totalement la console de démarrer (sauf si batterie HS bien sûr), maintenir le bouton "Power" pour éteindre totalement la console, déclipser la nand de la console puis démarrer la console branchée au PC, là au moins on sera certain de passer directement en RCM et si console détectée en RCM, reclipser la nand puis tenter la manipulation pour activer l'auto-RCM.

En effet si le brick n'est pas au niveau des BCT et qu'au moins le bootloader est chargé alors la console passera pas en RCM automatiquement, bien vu.

Le solution de démonter la NAND est radicale mais effectivement imparable.

SX OS n'est pas compatible avec le firmware 11.0.1

Cette erreur est remontée par Hekate il me semble, pas par Atmosphère. Tu utilises bien la dernière version d'hekate ?

https://github.com/C.../hos/pkg1.c#L44

Corriger moi si j'ai mal réinterprété le texte

Non c'est bien ça.

sm gère la communication entre les process concurrents (IPC). Par exemple deux process qui veulent accéder à la même mémoire, ou deux process qui veulent partager des données. Ca peut passer par des signaux, des files d'attentes, de la mise ne mémoire partagée, etc. C'est un module central du coup.

Bonsoir,
On a plein de voyants ici, digne de 3615 Madame Soleil.
Nous verrons bien c'est le futur qui le dira.
Pour ma part 4 possibilités.
1-La TX revient, sous une forme libre et anonyme quand ça se sera bien calmé, histoire que la justice ne les cherche plus trop (il n'y a pas que les États-Unis dans le monde).
2-Si la TX est généreuse, il lâche leurs codes pour que d'autres reprennent librement le truc (on peut rêver).
3-D'autres reprennent le truc, via reverse engineering, pas simple mais des fois que cela intéresse un mordu de la chose.
4-Ils reprennent le business, là où Nintendo ne peut les attaquer (Chine/Russie ect...).
Bref le temps le dira. D'ici peut-être que je passerai sous Atmosphère pour ma console en 11.0.1.

J'aime ta remarque sur Madame soleil (RIP)... suivi de tes propres pronostics sur l'avenir de SX OS

Allez pour te répondre sérieusement :

1 - La TX revenir sous un autre forme ou autre nom ? why not ? Ils l'ont déjà fait après Gateway. Bon là faut pas oublier que c'est le big boss qui a été serré quand même.

2 - La TX généreuse ? Oui tu rêves je pense ^^

3 - RE il y a déjà eu. Des devs capables de reprendre ça existe. Mais ils auront autant Nintendo au derche que la TX.

4 - La TX vendait déjà ses produits depuis la chine.

Enfin bon, je suis pas madame soleil ^^

Si j'ai bien compris, sthetix a utilisé "Emmchaccgen" de suchmememanyskill pour mettre à jour le package2

 

edit: si le but de c'est de repasser le pkg2 en 11.0.0 mais laisser le binaire de SystemVersion (0100000000000809) en 11.0.1 alors ça sert à rien. Repasser le kernel en 11.0.0 c'est comme repasser toute la console en 11.0.0 puisque la diff apportée par le 11.0.1 est essentiellement dans le kernel, donc le pkg2.

C'est exactement ça que les gens ne comprennent pas.

Ca me taraudait donc j'ai fini par regarder.

Alors en fait, les fichiers proviennent d'un site chinois : Switch 硬破设备 11.0.1 魔改 NAND 支持SX 3.1.0引导图文教程 | 时鹏亮的blog (shipengliang.com)

Et après vérification, le package2 a bien été downgradé (passé de la version 17 à 16) :

Inutile donc. Autant downgrade son fw directement.

Xcuter devrai réagir pour cette maj, et pour le "hack" de leur sxos, certains vont être surpris ! "Comme un aigle" "comme un aigle"....

Le spoofer de Reacher17, il fonctionnera toujours sur SX OS 3.1, la TX ne peut rien y faire.

S'ils sortent une nouvelle version de SX OS, bah le spoofer sera logiquement bloqué mais ceux qui ont acheté une licence seront contents, les autres auront quand même un SX OS gratuit avec tous les jeux qui fonctionnent avec un SDK <= 11.0. 

Mais bon je mettrai pas trop d'espoir sur une nouvelle version.

Grosse maj, quasi tous les titles modifiés. Ne pas mettre à jour.

Liste des NCA : https://www.eliboa.c...itle=&fw=12.0.0 (Merci Zoria pour le fw)

NxNandManager mis à jour pour support 12.0.0 ici

Avec nxnandmanager on peut flasher sur l'emunand?

Oui, tu peux faire un backup/restore d'une partition sur n'importe quel type de NAND, sys ou emu.

D'après se que j'en comprend il faudrait flasher ces fichiers BCPKG* sur la nand que l'on souhaite traiter (emunand ou sysnand selon utilisation du CFW), faisable avec NXNandManager par exemple. Après d'où viennent ces fichiers et qu'est-ce qui a été fait dessus c'est se qu'il faudrait savoir.

Hello

Si j'ai bien compris, sthetix a utilisé "Emmchaccgen" de suchmememanyskill pour mettre à jour le package2

edit: si le but de c'est de repasser le pkg2 en 11.0.0 mais laisser le binaire de SystemVersion (0100000000000809) en 11.0.1 alors ça sert à rien. Repasser le kernel en 11.0.0 c'est comme repasser toute la console en 11.0.0 puisque la diff apportée par le 11.0.1 est essentiellement dans le kernel, donc le pkg2.

quand tu utilise le mode rcm c est que tu as pas d emunand donc si tu upgrade et que tu a pas le rcm tu brule tes efuse donc pas de retours en arrière sur ton ancien firmware.
mais si tu laisse le rcm actif la console ne démarre pas sur l horizon nintendo donc tu peut upgade et downgrade sans risque de brûlé tes efuse.
si tu as une emunand donc tt le taf ce faut qur ta sd tu peut laisser sans rcm car si elle démarre sur ta sysnand ta nintendo sera vide avec rien d installer dessus normal car tt est sur ta sd.

Tu confonds auto RCM et mode RCM.

Le mode RCM permet de démarrer en CFW (entre autres), ce n'est pas lié à l'emuNAND, en tout cas pas directement

Donc, si je résume, ça me donne :

 

Démarrage avec une emunand installée

  |

  |

  --- Si pas de mode RCM ---> Démarrage en sysnand ---> Mode de fonctionnel habituel de la switch avec juste un emplacement des données différent (Pas de données sur la switch / Données sur la première partition SD) ---> De fait si MAJ "classique" (sans choixdujour), eFuses tout de même grillés & online possible avec risque de ban bien moindre

  |

  |

  --- Si mode RCM  ---> Démarrage en emunand ---> Fonctionnalités emunand disponibles avec données sur la seconde partition SD ---> Upgrades / downgrades possibles sans incidence sur les eFuses & Utilisation des homebrews possible mais online fortement déconseillé

 

AutoRCM démarre systématiquement en mode RCM, mais "provoque" le problème d'alimentation

Si je veux me passer de AutoRCM en attendant une alternative meilleure, je peux démarrer manuellement en RCM à chaque fois pour à ce moment-là basculer sur l'emunand, c'est bien ça ?

Si la console n'est pas démarrée en RCM => Lancement de l'OFW (donc forcément en sysNAND)

Si la console est démarrée en mode RCM => On peut lancer le CFW (en sysNAND ou en emuNAND) ou bien lancer l'OFW en bypassant le contrôle des fuses (via Hekate ou SX)

Ne pas confondre OFW/CFW et sysNAND/emuNAND (2 concepts différents).

PS : Le problème d'alimentation avec l'autoRCM est pas forcément un problème selon moi. J'ai une Switch en autoRCM depuis plus de 2 ans. Elle est souvent tombée à plat de batterie, tu la charges une heure et ça suffit à injecter un payload (ex Hekate). Ensuite tu la laisses se recharger via Hekate jusqu'à ce qu'il y ait assez de jus pour lancer l'OS.

En effet PRODINFOF ne contient que les logs de la phase de calibration en usine donc complètement inutile en théorie.

J'ai regardé un peu comment exosphère récupère le device id. J'avais pas capté depuis tout ce temps que le device id est programmé dans les registres fuses du tegra. Ce qui expliquait qu'on ait jamais pu retransplanter une NAND depuis une autre console, les fuses ne pouvant être programmés qu'une seule fois à l'usinage.

L'idée ici est donc "simplement" de spoofer la fonction GetDeviceId du driver de fuses afin que le device id de cal0 et celui des fuses soient identiques in fine. Nice.

Faut juste recompiler Exosphere avec le device ID forcé dans le fichier adéquat, faut bien-sûr  rechiffrer correctement les PRODINFO et PRODINFOF sources puis les injecter, faut aussi configurer Atmosphere ou Hekate (selon méthode de lancement) pour qu'il lance cet Exosphere modifié. L'inconvénient de cette technique est qu'à chaque fois qu'on mettra à jour Atmosphere il faudra recompiler Exosphere (s'il a évidemment été modifié entre les deux versions se qui risque d'être le cas, soit lui-même ou soit la bibliothèque dont il se sert comme base) mais bon entre çà ou une console ne fonctionnant plus du tout le choix est vite fait surtout qu'au final une fois qu'on a compris c'est pas trop difficile en vrai. Heureusement que tu as indiqué qu'il y avait une méthode de ce genre car sinon j'aurais pas cherché et en plus durant mes recherches je suis aussi tomber là-dessus et j'ai découvert EmmcHaccGen qui est très sympa comme outil (deux découvertes pour le prix d'une c'est la fête), d'ailleurs une mise en place de ce dernier dans mon script est actuellement en cours et bientôt totalement implémenté car mon test avec le firmware 10.2.0 et cet outil a été un succès lors de mes tests.

Ok donc il faut bien les PRODINFO+PRODINFOF complets de la console donneuse. 

Effectivement le fait de devoir rebuilder exosphère est un petit inconvénient mais le jeu en vaut la chandelle au final

J'avais repéré le projet EmmcHaccGen mais pas encore testé. Si je comprends bien tu as réussi à refaire une NAND basée sur un firmware 10.2 avec cet outil ? La ou CDJ ne supporte que les fw < 6.2. Si c'est le cas c'est effectivement très utile.

Merci pour le feedback.