Aller au contenu


shadow256

Inscrit(e) (le) 05 juin 2015
Déconnecté Dernière activité aujourd'hui, 04:25
*****

#1217424 [Switch] L'émulateur Citron a été pressé, c'est la fin de son dévelop...

Posté par shadow256 - aujourd'hui, 00:37

Pourquoi supprimer le code source du projet sans y être forcé ça je ne comprend pas, tout comme aller à s'embrouiller autant dans le milieu de l'open-sources auquel la concurrence ne réussi pas. Enfin bref encore un bon projet perdu.


#1217010 [Switch] LockSmith-RCM 0.10.0 disponible

Posté par shadow256 - 03 février 2026 - 07:53

Attention, ce payload n'a pas été testé sur un grand nombre de consoles, bien que j'ai pu le tester sur une console Erista et une OLED les retours seront grandement appréciés, pour l'instant n'effectuez pas d'actions avancées ou pouvant impacter dangereusement votre console si vous n'êtes pas capable de réparer manuellement, vous êtes donc comme d'habitude seul responsable de vos actes.

Trois semaines de travail (et encore de nands/emunands logiciellement flinguées par mes divers tests) après la première release de mon nouveau projet, LockSmith-RCM, qui est un payload multi-fonctions, je vous propose la version 0.10.0 de celui-ci.

Ce payload combine les fonctions des payloads Lockpick-RCM, ProdinfoGen, Incognito, DowngradeFixer et FusesCheck mais pas uniquement, il permet aussi de faire un dump/restauration de PRODINFO et une vérification/corrections des hashes de celui-ci, un dump du firmware de la nand, un reset de la nand, du contrôle parental, de débricker avec un package EmmcHacGen placé dans le dossier "cdj_package_files" (avec ou sans suppression de données et beaucoup, beaucoup, beaucoup plus rapidement que mon script équivalent via mon Ultimate-Switch-Hack-Script et TegraExplorer sur les consoles Mariko) et encore bien d'autres choses.




Et se n'est pas terminé, contrairement à tous les payloads sur lesquels il est basé celui-ci fonctionne sur une plus large quantité de configurations, notamment d'anciennes configurations basées sur des puces utilisant Spacecraft qui pouvaient poser des problèmes dès qu'on souhaitait travailler sur ou avec la nand (emunand ou sysnand qu'importe). Bien sûr le payload peut travailler sur la sysnand, sur l'emunand d'Atmosphere mais aussi sur les emunands basées sur la variable "emupath" dans les configs de Hekate (fonction qui n'a pas été testée), dans le cas de plusieurs emunands configurées correctement sur la SD un choix devrait pouvoir se faire pour sélectionner l'emunand sur laquelle travailler. Il peut aussi, comme TegraExplorer, utiliser un fichier de clés pour charger les clés à utiliser pour déchiffrer les nands, pratique si par exemple vous utilisez une nand d'une autre console que vous auriez besoin de débricker.

Et attendez ne partez pas, la plupart des fonctions du payload peuvent aussi être exécutées automatiquement juste en plaçant des fichiers sur la SD qui feront office de flags, dans ce cas le payload exécutera les fonctions selon les fichiers trouvés puis affichera un log récapitulant les actions effectuées et enregistrera ce log sur la SD.

Changelog 0.10.0:

  • Mise à jour du BDK de Hekate
  • Ajout des fonctions de vérification, correction, sauvegarde et restauration de PRODINFO. Les fonctions de vérification et de correction sont portées depuis ce script Python de mon Ultimate-Switch-Hack-Script
  • Ajout de la fonction incognito.
  • Ajout de la fonction de dump du firmware.
  • Toutes les fonctions sont maintenant accessibles via des fichiers de flags.
  • Correction de la fonction unbrick sans suppression de données, qui maintenant n’effectue réellement plus de suppression de données.
  • Correction des messages de FuseCheck, en particulier lorsque pas assez d'eFuses sont brûlés ; dans ce cas, la console démarre normalement mais brûle les eFuses manquants. D’autres messages ont également été réécrits. Cette fonction a aussi été largement optimisée en taille en empaquetant la table des NCA lors de la compilation et en modifiant la manière dont les noms des NCA sont vérifiés pour identifier un firmware.
  • La majorité des messages affichés sont maintenant centralisés et les fonctions pour les afficher/enregistrer ont été réécrites ; elles sont désormais basées sur un pool de messages généré à la compilation. Le gain en taille est faible, mais c’est toujours un gain.
  • Réécriture des fonctions ProdinfoGen (désormais basées sur les fonctions de vérification/correction de PRODINFO implémentées), gain de taille important.
  • Réécriture des fonctions cal0_read (désormais basées sur les fonctions de vérification/correction de PRODINFO implémentées), aucun gain de taille mais au moins les mêmes fonctions et structures sont maintenant utilisées partout.
  • Optimisation importante de la taille du payload grâce à de nombreuses réécritures de code, trop de changements pour être listés.
  • Correction de nombreux bugs.
  • Préparations pour de possibles améliorations futures.
  • Mise à jour du fichier readme.

Bref si vous voulez en savoir plus allez voir le readme sur le Github du projet, vous y trouverez tous les détails du fonctionnement de ce payload et pour télécharger le payload c'est par ici.

Pour ceux étant encore là après tant de lecture (bravo et merci à vous) j'ai aussi besoin de vos avis. En effet je souhaite implémenter le contrôle du payload avec les joycons (fonction dispensable) et surtout le dump des sauvegardes des jeux sur la nand (un peu comme JKSV même si sera bien moins précis à cause de l'environnement limité d'un payload). Mais voilà, ces fonctions prennent trop de place pour la taille restante dans le payload et je ne pense pas être capable de mettre en place un système de module comme NYX dans Hekate. Donc selon vous, surtout parmi ces fonctions lesquelles vous semblent inutiles:

  • Dump du firmware
  • Travail sur les emunands basées sur les configs de Hekate
  • Dump/restauration de PRODINFO
  • Synchronisation des joycons entre les nands
  • Fonction basée sur FuseCheck

Si vous appréciez mon travail vous pouvez me faire une donation via ce lien si vous avez un compte Paypal (n'engendre pas de frais de transaction) ou via ce lien si vous n'avez pas de compte Paypal et n'hésitez pas à faire vos retours car j'en manque sérieusement.




#1216930 [WiiU] Aroma Beta 25 disponible

Posté par shadow256 - 30 janvier 2026 - 09:31

Ca a résolu tous mes problèmes de modules incompatibles !


Du coup j'ai mis à jour mon Ultimate-Wii-U-Hack-Script pour qu'il utilise cette nouvelle version, merci du retour.


#1216926 [WiiU] Aroma Beta 25 disponible

Posté par shadow256 - 30 janvier 2026 - 08:10

@Jaffar : Ulaunch est pour la Switch, pas pour la Wii U. A ma connaissance il n'existe pas de launcher alternatif pour la Wii U.


#1216905 [WiiU] Aroma Beta 25 disponible

Posté par shadow256 - 29 janvier 2026 - 18:07

Je ne crois pas, sauf à passer par un menu alternatif je doute qu'il soit possible de bypass cette limite.


#1216834 switch + picofly ne se lance plus

Posté par shadow256 - 27 janvier 2026 - 14:55

Maintenant dans Hekate tu vas dans "launch" et tu retrouveras les configs comme avant, ici je pense que tu auras besoin de lancer une fois la config "Atmosphere sysnand" ou "stock" pour que ça génère se qu'il faut, une fois cela fait normalement le warmboot sera copié et ça refonctionnera. Au moins une chose est sûre, tu es à jour donc ne touches plus à la SD.


#1216822 [Switch] SciresM envisage de se retirer du monde du hack

Posté par shadow256 - 27 janvier 2026 - 11:07

Si seulement les gens qui profitent du boulot des gens comme lui étaient prêts ne serait ce qu'à donner 1€/mois, il y aura des talents qui pourraient faire de cette passion leur travail, ce qui poserait moins de questionnements.


Oui je suis bien d'accord mais la majorité des utilisateurs et pour moi encore pire des techniciens puisque eux gagnent vraiment de l'argent sur ce genre de travaux (les utilisateurs eux aussi y gagnent car ils piratent en majorité donc indirectement économisent mais pour moi c'est différent) ne donnent jamais rien, j'en ai déjà parlé un paquet de fois, la dernière étant sur ce sujet.

Bon après dans le cas de SciresM je pense que c'est pas l'argent le problème mais vraiment le temps, faire tout se qu'il fait et en plus gérer une vie familiale ça devient pour ainsi dire impossible, à un moment il doit faire des choix et arrêter ce genre de projets est le meilleur choix car même si les utilisateurs donnaient ça n'aurait rien de stable de toutes façons.


#1216812 [Switch] SciresM envisage de se retirer du monde du hack

Posté par shadow256 - 27 janvier 2026 - 09:26

Et oui à un moment faut que ça s'arrête les projets passions... Bonne continuation à lui pour la suite et merci pour tout son travail open-sources, je ne sais pas qui va être capable de reprendre ses travaux vu le niveau de malade qu'il a, ils ne sont pas nombreux les développeurs ayant autant de talents que lui et surtout ayant cette volonté de partage, on verra bien.


#1216761 switch + picofly ne se lance plus

Posté par shadow256 - 26 janvier 2026 - 10:27

Vu que tu sembles être sur le pack switch_AIO_LS_pack vu les libellés des icônes dans Hekate je te suggère de mettre à jour celui-ci plutôt que de vouloir mettre à jour les composants individuellement, voir ce tutoriel, dans ton cas passes par la procédure de mise à jour manuelle.

Là ton souci est que tu n'as pas mis à jour Hekate, "fusee.bin" est en fait "atmosphere_fusee.bin" dans mon pack donc comme tu ne l'as pas remplacé la config "atmosphere auto" continue à utiliser la vieille version de lancement pour une nouvelle version d'Atmosphere. Mais ça ne sera pas le seul problème, après comme tu étais sur une ancienne version d'Atmosphere tu auras probablement des problèmes avec les homebrews puisqu'il faudra les mettre aussi à jour, raison pour laquelle je te suggère fortement de mettre à jour le pack.


#1216647 [PS3] Le qCFW (BadWDSD) entièrement fonctionnel, fin du HEN

Posté par shadow256 - 22 janvier 2026 - 15:36

Pour Linux le souci c'est surtout l'architecture PPC qui est pénible, il y a bien moins d'appli sous cette architecture qu'en X86/X64 ou qu'en ARM.


#1216631 [Switch] switch_AIO_LS_pack 5.23.0 disponible

Posté par shadow256 - 22 janvier 2026 - 07:54

HS: Oui moi aussi ça fonctionne vraiment bien avec homebrews Wii optimisés (l'espèce d'overclock, je crois que ça s'appelle Cafeine ou un truc du genre mais depuis le temps j'ai un peu oublié la scène Wii U) lançables en un clique, le HBMenu Wii U qui permet de lancer les homebrews sans le gamepad, Nintendont lançable en un clique et me permettant d'avoir accès à tous les jeux Gamecube sur la SD (pas 50 forwarders chiants) et Haxchi tout bien configuré avec des raccourcis qui me permettent de lancer les fonctions principales juste en maintenant un bouton durant son démarrage. Donc ouai je me suis bien emmerder à config tout ça, pas envi de tout recommencer en migrant sur Aroma qui au final ne m'apporterait pas grand chose mais oui, belle console pour le hack la Wii U.


#1216630 [PS3] Le qCFW (BadWDSD) entièrement fonctionnel, fin du HEN

Posté par shadow256 - 22 janvier 2026 - 07:41

Ah ouai ça c'est une belle avancée! Bon par contre faut pucer la console donc bon de là à dire que le Hen est mort ça c'est moins sûr mais là pour le coup le gain est réel pour ceux qui souhaitent exploiter une PS3 non CFW classique compatible au maximum. Bravo aux devs encore une fois, c'est beau des travaux comme ça.


#1216614 [Switch] switch_AIO_LS_pack 5.23.0 disponible

Posté par shadow256 - 21 janvier 2026 - 10:29

Après si t'as utilisé mon script il a été très peu testé avec Aroma, comme j'ai un hack type Haxchi qui fonctionne très bien je n'ai jamais migré.


#1216603 [Switch] switch_AIO_LS_pack 5.23.0 disponible

Posté par shadow256 - 21 janvier 2026 - 05:21

Le driver exfat de la Swith est foireux. Tout le monde le sait mais quand tu pars avec ta bibli de vidéos t'es bien content d'avoir qu'un seul fichier au moment des visionnages (Et oui. Fat32 c'est encore et tjs 4 Go par fichier maxi ;) ).


Là oui il n'y a pas de solution simple si tu souhaites absolument embarquer des fichiers de plus de 4 GO (donc des fichiers vidéos car pour tout le reste je ne vois pas vraiment de cas où on a absolument besoin de tels fichiers), le FAT32 sera toujours limité à cette taille max par fichier, c'est une des limites de ce système de fichiers et donc c'est et se sera toujours incontournable. Après là tu me parles d'un cas très spécifique que bien peu de gens ont besoin car tu peux aussi passer par un NAS, un serveur SMB ou même un stockage externe via USB pour lire ce type de contenus, au pire avec un hub USB + alimentation USB C si vraiment tu veux lire des vidéos en chargeant la console c'est toujours possible, bref c'est vraiment pour ceux qui font beaucoup de déplacements que ça peut être pénible d'utiliser autre chose que la SD mais sinon on a l’embarra du choix pour contourner.

En fait moi se que je ne veux pas c'est que les gens disent qu'ils n'ont jamais eu de problèmes en ne précisant rien d'autre, comme l'EXFAT est vraiment problématique sur Switch (mais pas que, c'est de toutes façons un système de fichiers merdique car non journalisé entre autres) il faut vraiment être précis en parlant aussi des problèmes potentiels que ce choix induit sinon les gens passent en EXFAT et après on galère à diagnostiquer/dépanner.


#1216575 [Switch] La mise à jour système 19.0.2 déployée en Chine

Posté par shadow256 - 20 janvier 2026 - 08:38

Quant on y pense c'est vrai qu'on ne pense pas aux versions des firmwares chinois dans nos divers outils, notamment dans les outils utilisant des bases de données NCA comme NXNandManager ou FuseCheck mais même dans mon AIO_LS_pack_Updater pour savoir s'il faudrait utiliser le downgrade fix ou pas, je me demande même si c'est vraiment possible de savoir si on est sur une version chinoise du firmware ou pas (les langues chinoises sont sur les firmwares classiques ou pas?). Au début quand j'ai vu cette new je me suis dit qu'elle n'était pas franchement pertinente mais au final elle fait réfléchir sur des points auxquels je n'avais jamais pensé.