[Switch] Atmosphere 0.7.0 disponible
0.7.0 is Atmosphère's first official release.It supports the following featureset:- Fusée, a custom bootloader.> Supports loading/customizing of arbitrary KIPs from the SD card.> Supports loading a custom kernel from the SD card ("/atmosphere/kernel.bin").> Supports compile-time defined kernel patches on a per-firmware basis.> All patches at paths like /atmosphere/kip_patches/<user-defined patch name>/<SHA256 of KIP>.ips will be applied to the relevant KIPs, allowing for easy distribution of patches supporting multiple versions.> Both the IPS and IPS32 formats are supported.> All patches at paths like /atmosphere/kernel_patches/<user-defined patch name>/<SHA256 of Kernel>.ips will be applied to the relevant KIPs, allowing for easy distribution of patches supporting multiple versions.Both the IPS and IPS32 formats are supported.> Configurable by editing BCT.ini on the SD card.- Atmosphère should also be launchable by the alternative hekate bootloader, for those who prefer it.> Exosphère, a fully-featured custom secure monitor.> Exosphere is a re-implementation of Nintendo's TrustZone firmware, fully replicating all of its features.> In addition, it has been extended to provide information on current Atmosphere API version, for homebrew wishing to make use of it.- Stratosphère, a set of custom system modules. This includes:> A loader system module.> Reimplementation of Nintendo's loader, fully replicating all original functionality.> Configurable by editing /atmosphere/loader.ini> First class support for the Homebrew Loader.> An exefs NSP (default "/atmosphere/hbl.nsp") will be used in place of the victim title's exefs.By default, HBL will replace the album applet, but any application should also be supported.Extended to support arbitrary redirection of executable content to the SD card.Files will be preferentially loaded from /atmosphere/titles/<titleid>/exefs/, if present.Files present in the original exefs a user wants to mark as not present may be "stubbed" by creating a .stub file on the SD.If present, a PFS0 at /atmosphere/titles/<titleid>/exefs.nsp will fully replace the original exefs.Redirection is optionally toggleable by holding down certain buttons (by default, holding R disables redirection).Full support for patching NSO content is implemented.All patches at paths like /atmosphere/exefs_patches/<user-defined patch name>/<Hex Build-ID for NSO to patch>.ips will be applied, allowing for easy distribution of patches supporting multiple firmware versions and/or titles.Both the IPS and IPS32 formats are supported.Extended to support launching content from loose executable files on the SD card, without requiring any official installation.This is done by specifying FsStorageId_None on launch.- A service manager system module.Reimplementation of Nintendo's service manager, fully replicating all original functionality.Compile-time support for reintroduction of "smhax", allowing clients to optionally skip service access verification by skipping initialization.Extended to allow homebrew to acquire more handles to privileged services than Nintendo natively allows.Extended to add a new API for installing Man-In-The-Middle listeners for arbitrary services.API can additionally be used to safely detect whether a service has been registered in a non-blocking way with no side-effects.Full API documentation to come.- A process manager system module.Reimplementation of Nintendo's process manager, fully replicating all original functionality.Extended to allow homebrew to acquire handles to arbitrary processes, and thus read/modify system memory without blocking execution.Extended to allow homebrew to retrieve information about system resource limits.Extended by embedding a full, extended implementation of Nintendo's boot2 system module.Title launch order has been optimized in order to grant access to the SD card faster.The error-collection system module is intentionally not launched, preventing many system telemetry error reports from being generated at all.Users may place their own custom sysmodules on the SD card and flag them for automatic boot2 launch by creating a /atmosphere/titles/<title ID>/boot2.flag file on their SD card.- A custom fs.mitm system module.> Uses Atmosphère's MitM API in order to provide an easy means for users to modify game content.Intercepts all FS commands sent by games, with special handling for commands used to mount RomFS/DLC content to enable easy creation and distribution of game/DLC mods.> fs.mitm will parse the base RomFS image for a game, a RomFS image located at /atmosphere/titles/<title ID>/romfs.bin, and all loose files in /atmosphere/titles/<title ID>/romfs/, and merge them together into a single RomFS image.When merging, loose files are preferred to content in the SD card romfs.bin image, and files from the SD card image are preferred to those in the base image.> Can additionally be used to intercept commands sent by arbitrary system titles (excepting those launched before SD card is active), by creating a /atmosphere/titles/<title ID>/fsmitm.flag file on the SD card.> Can be forcibly disabled for any title, by creating a /atmosphere/titles/<title ID>/fsmitm_disable.flag file on the SD card.> Redirection is optionally toggleable by holding down certain buttons (by default, holding R disables redirection).- A custom crash report system module.> Serves as a drop-in replacement for Nintendo's own creport system module.> Generates detailed, human-readable reports on system crashes, saving to /atmosphere/crash_reports/<timestamp>_<title ID>.log.> Because reports are not sent to the erpt sysmodule, this disables all crash report related telemetry.- General system stability improvements to enhance the user's experience.
Si j'ai bien lu tout le changelog, nul part il n'est fait mention que le custom firmware reste en place même un fois la console éteinte.c'est surtout que c'est un vrai custom firmware et qu'il ne s'efface pas tout seul dès qu'on éteint la console ...
oui un tuto serait bienvenus , il supporte les .xci ? je supposes enfin a verifierSi j'ai bien lu tout le changelog, nul part il n'est fait mention que le custom firmware reste en place même un fois la console éteinte.c'est surtout que c'est un vrai custom firmware et qu'il ne s'efface pas tout seul dès qu'on éteint la console ...
Par contre, il est fait mention que le custom kernel peu être lancé depuis la µsd (donc si je comprend bien, le payload est stocké sur la µsd et il suffit juste de rentrer en mode rcm pour pouvoir l'injecter sans avoir besoin de pc/smartphone ou autre).
A confirmer
Nul part il n'est fait mention d'un firmware minimal, donc j'en déduis que c'est compatible tout firmware.La grande question c'est surtout le firmware requis , perso je suis un peu largué avec la scène switch , il y a tellement de changement que c'est pas simple a suivre , pas comme d'autre scènes ^^
Si j'ai bien lu tout le changelog, nul part il n'est fait mention que le custom firmware reste en place même un fois la console éteinte.c'est surtout que c'est un vrai custom firmware et qu'il ne s'efface pas tout seul dès qu'on éteint la console ...
Par contre, il est fait mention que le custom kernel peu être lancé depuis la µsd (donc si je comprend bien, le payload est stocké sur la µsd et il suffit juste de rentrer en mode rcm pour pouvoir l'injecter sans avoir besoin de pc/smartphone ou autre).
A confirmer
Non, après, il faut bien faire attention de prendre une switch de 1ère gen (bien vérifier les numéro de série), mais les pack smash et diablo auront des consoles patché, ça c'est clair (tout comme tout les futurs pack).C'est ce que je me suis dit aussi mais dans l'optique d'un futur achat j'aimerais bien en être sur, car si compatible tout firmware je me prend la switch en neuf en version collector smash ou diablo 3 ou si le CFW tient la route face Nintendo peut être prendre le nouveau modèle prévu pour 2019 , bref je suis en pleine réflexion la ^^
Si j'ai bien lu tout le changelog, nul part il n'est fait mention que le custom firmware reste en place même un fois la console éteinte.c'est surtout que c'est un vrai custom firmware et qu'il ne s'efface pas tout seul dès qu'on éteint la console ...
Par contre, il est fait mention que le custom kernel peu être lancé depuis la µsd (donc si je comprend bien, le payload est stocké sur la µsd et il suffit juste de rentrer en mode rcm pour pouvoir l'injecter sans avoir besoin de pc/smartphone ou autre).
A confirmer
ça serait étonnant puisque ça voudrait dire qu'on le coldboot grâce à l'autorcm
Concernant l'autorcm, moi aussi j'aimerai m'en passer pour ne pas risquer de démonter ma switch si la batterie venait à se vider... Mais si je peut pouvoir jouer aux derniers jeux tout en conservant la possibilité un jour de revenir en 3.0.0 pour un éventuel coldboot, je n'ai pas pas le choix !Ba écoute, perso, c'est ce que je lis sur le changelog, après, tout le monde ne veux pas de l'autorcm (comme moi) et est ce que ça peu vraiment s'apparenter à un "vrai" exploit coldboot? J'en doute.
Maintenant, il faut tester pour vérifier si c'est effectivement ça ou pas.
Atmosphère n'a jamais été conçu dans le but de pirater les jeux...Ha si le sciresM n’avais pas perdu son temps à critiquer la team xecuter et sortit son os au mois de juin comme prévue son os aurait cartonné.
Mais aujourd’hui atsmophere n’a vraiment aucun intérêt pour la grosse majorité des utilisateurs car SX OS , ReiNX ou RajNX s’en sorte vraiment mieux sur le lancement des jeux .
Dommage ....
Le soit disant saint graal est tombé à l’eau .
. Ça a été le cas après chaque maj de LayeredFS.
MerciRegardez http://www.logic-sun...aller-des-jeux/, j'explique comment mettre en place la base du CFW. Après pour les fonctions annexes du CFW elle seront utilisées en temps voulu.
Merci
Quand la console s’ éteint il faut relancer le payload comme les autres?
Oui et cela n'a rien à voir avec Atmosphère ni aucun autre CFW. Cette contrainte est due au fait que la faille exploitée pour appliquer fusée-gelée est située dans la bootROM du SoC Tegra X1 qui équipe la Switch, une mémoire non réinscriptible qui contient le code qui permet "en gros" de booter sur le système d'exploitation mais qui gère aussi le mode recovery. L'exploit permet d'injecter du code non signé (le fameux payload), dans le cas d'Atmosphère il s'agit du custom bootloader : fusee-primary.bin (ou hekate, ou encore SX Loader)
Quelques explications sur l'exploit fusée gelée (extrait d'un guide) :
Nous avons ce qu’il nous faut : une console, un câble USB et un PC (ou autre) pour appliquer l’exploit. C’est parti, je vous montre :
Je démarre la console (en mode RCM). J’ai préalablement appliqué le court-circuit. Le courant arrive de la batterie jusqu’au processeur.
Le programme contenu dans la boot ROM est exécuté. Il détecte une combinaison de touche (POWER + VOLUME UP) ainsi qu’un court-circuit au niveau des pins du joycon. Il se met alors en mode RCM, c’est-à-dire qu’il se met à l’écoute de commandes RCM arrivant via le port USB.
Depuis mon PC, j’applique l’exploit Fusée gelée en envoyant une commande RCM à la console (et en y ajoutant le code non signé à exécuter).
Le programme de la boot ROM reçoit ma commande RCM, mais comme son développeur n’a pas pensé à mettre une limite à la taille du paquet de données transmises avec la commande (c’est LA FAILLE), j’en ai également profité pour lui envoyer mon code non signé (par buffer overflow).
Le code non signé est injecté en RAM et s’exécute sur la console. TA DAM !
Cet exploit présente toutefois un défaut majeur. Etant donné qu’une console en mode RCM ne peut recevoir de commandes qu'à travers le port USB, l’exploit ne peut être appliqué que depuis un périphérique tiers capable de transmettre des commandes via USB, et ce à chaque démarrage de la console (je parle d'un démarrage à froid, pas d’une simple sortie de veille).
Mais qu’importe ! Car l'exploit nous donne un accès total au système, c’est le graal du hackeur…
Oui et cela n'a rien à voir avec Atmosphère ni aucun autre CFW. Cette contrainte est due au fait que la faille exploitée pour appliquer fusée-gelée est située dans la bootROM du SoC Tegra X1 qui équipe la Switch, une mémoire non réinscriptible qui contient le code qui permet "en gros" de booter sur le système d'exploitation mais qui gère aussi le mode recovery. L'exploit permet d'injecter du code non signé (le fameux payload), dans le cas d'Atmosphère il s'agit du custom bootloader : fusee-primary.bin (ou hekate, ou encore SX Loader)
Quelques explications sur l'exploit fusée gelée (extrait d'un guide) :
Nous avons ce qu’il nous faut : une console, un câble USB et un PC (ou autre) pour appliquer l’exploit. C’est parti, je vous montre :
Je démarre la console (en mode RCM). J’ai préalablement appliqué le court-circuit. Le courant arrive de la batterie jusqu’au processeur.
Le programme contenu dans la boot ROM est exécuté. Il détecte une combinaison de touche (POWER + VOLUME UP) ainsi qu’un court-circuit au niveau des pins du joycon. Il se met alors en mode RCM, c’est-à-dire qu’il se met à l’écoute de commandes RCM arrivant via le port USB.
Depuis mon PC, j’applique l’exploit Fusée gelée en envoyant une commande RCM à la console (et en y ajoutant le code non signé à exécuter).
Le programme de la boot ROM reçoit ma commande RCM, mais comme son développeur n’a pas pensé à mettre une limite à la taille du paquet de données transmises avec la commande (c’est LA FAILLE), j’en ai également profité pour lui envoyer mon code non signé (par buffer overflow).
Le code non signé est injecté en RAM et s’exécute sur la console. TA DAM !Cet exploit présente toutefois un défaut majeur. Etant donné qu’une console en mode RCM ne peut recevoir de commandes qu'à travers le port USB, l’exploit ne peut être appliqué que depuis un périphérique tiers capable de transmettre des commandes via USB, et ce à chaque démarrage de la console (je parle d'un démarrage à froid, pas d’une simple sortie de veille).
Mais qu’importe ! Car l'exploit nous donne un accès total au système, c’est le graal du hackeur…
Donc au final l'attente d'une possible façon de lancer une fois la console en Mode RCM puis ne plus jamais à devoir le refaire même après extinction de la Switch est tout bonnement infaisable ? Quel intérêt il y a t'il alors à garder un CFW assez bas si le seul exploit Coldboot disponible nécessite une manipulation HW à chaque "Vrai Boot" ??
Non c'est possible qu'il existe un exploit coldboot untethered qui n'ait pas encore été trouvé ou qui est gardé privé donc l'intérêt de rester sur un firmware bas est toujours là (ou plus exactement l'intérêt de ne pas cramer d'eFuses). Mais bon ce n'est pas lié au CFW, c'était ça mon propos. Actuellement tous les CFW (et distrib Linux) sont lancés via l'exploit fusée-gelée mais on ne sait pas ce que l'avenir nous réserve
Bonjour à tous,
Désolé si la question a déja été posé mais j'aimerais savoir quelle est la différence avec SXOS pour l'utilisation.
On est d'accord qu'il s'agit de la même faille que pour SXOS.
En clair, on utilise un jig + payload USB et on copie sur la carte SD atmosphere à la place de SXOS?
Oui c'est la même faille utilisée : fusée gelée (découverte par K.Temkin et fail0verflow).
Après chaque CFW possède ses propores features mais ce n'est pas lié à la faille mais au custom firmware ou à des modifications de l'OS (Horizon).
Dans la chronologie, pour lancer un homebrew/backup, tu as :
1 - Le mode RCM qui doit être appliqué (Le jig + combinaison de touche)
2 - L'exploit fusée gelée qui doit être appliqué (via TegraRCM, rekado, SX Pro par ex)
3 - Un payload (code non signé) qui doit être exécuté. Dans notre cas, un bootloader comme hekate, Fusée d'Atmosphère, ReiNX chainloader ou SX Loader)
4 - Le bootloader (payload) lance un CFW présent sur la SD (ou déjà contenu dans le payload), comme Atmosphère, ReiNX, RajNX ou SX OS
5 - Le bootloader lance le Kernel et Horizon OS qui peuvent être patchés ou pas. L'OS peut proposer de nouvelle features comme le SX Menu et lancer des homebrews
Donc en gros, beaucoup nous parlaient d'attendre ceci, en parlant du 'messi'
Mais en fait, ça a juste quelques mois de retard sur les solutions.
Sans compter sur la mise en place vraiment pas userfriendly...
Super déçu
Toutes les autres solutions utilisent au moins en partie du code d'Atmosphère...
Et c'est aussi user friendly que ReiNX ou RajNX, tu injectes le payload fusee-primary.bin après avoir copié les fichiers du CFW sur ta microSD
Pour continuer dans les suppositions (car je n'affirme rien), les exploits coldboot existent mais sans doute que leur libération arrivera au dernier moment pour les versions 1.0.0 à 4.1.0. Dans tous les cas, pour lancer le jailbreak, la faille fusée gelée sera toujours nécessaire. À l'issu, Deja vu et Jamais vu apporteront un complément. Sauf erreur et si j'ai loupé un détail dans le ChangeLog, il n'en parle pas donc évitons de fausses suppositions. Encore une fois, je n'affirme rien et ne sais pas comment va se dérouler la suite mais soyons patients. Et dans tous les cas, si cela ne convient pas, il y a les alternatives qui fonctionnent et sont utilisées jusqu'à maintenant. Elles répondent aux besoins.
Çà pourrait passer par plusieurs exploits, c'est souvent le cas. Comme un exploit Webkit qui te permet d'injecter du code en user-land puis trouver un nouvelle exploit, kernel-land cette fois-ci et remonter comme ça jusqu'à la TrustZone (spéculation ^^). Après est-ce que ça nous permettrait de lancer Atmosphère (tel que) facilement depuis Horizon en OFW, je sais pas...
ScriresM n'a jamais concentré son travail sur la gestion de backups, il faut le garder en tête. À d'autres d'adapter ces possibilités et de l'intégrer dans atmosphère-NX.
hallelujah, certains ont trop tendance à l'oublier ^^ Son projet il me semble est de réécrire complètement le firmware de la Switch en open-source. Et vu son passé de modder sur pokemon j'imagine que sa première envie était d'implémenter LayeredFS pour modifier ses jeux 
Aboshi2011 de chez Rebug n’a pas l’air très réactif !!!Salut Fatiguant j'aimerais bien savoir ou chopper les puces j'ai contacté la team rebug aucune réponse :/
les 1.0.0 ont droit a un reboot_to_rcm...
Bonne nouvelle !
par contre ils ne doivent pas être bien nombreux ...
Dans le pire des cas c’est pas les alternatives qui manques !Aboshi2011 de chez Rebug n’a pas l’air très réactif !!!
J’ai balancé un gros billet pour en avoir une quantité suffisante pour Noël
Notre 1er deal a été correcte donc j’espere qu’il va faire son job sinon je vais pas lui faire de la bonne pub !
Bonne nouvelle !
par contre ils ne doivent pas être bien nombreux ...
Tu en aurais une à céder Fatiguant ?Dans le pire des cas c’est pas les alternatives qui manques !Aboshi2011 de chez Rebug n’a pas l’air très réactif !!!
J’ai balancé un gros billet pour en avoir une quantité suffisante pour Noël
Notre 1er deal a été correcte donc j’espere qu’il va faire son job sinon je vais pas lui faire de la bonne pub !
Perso j’ai recu mes 10 trinkets aujourd hui vu que les switchMe sont pas vraiment trouvable a bon prix sans avoir a attendre des lustres.
Tu en aurais une à céder Fatiguant ?
C'est sans risque d'utiliser un CWF? tout est installé sur la carte SD ou bien il y a des choses qui vont dans la mémoire de la console?
Donc en gros, beaucoup nous parlaient d'attendre ceci, en parlant du 'messi'
Mais en fait, ça a juste quelques mois de retard sur les solutions.
Sans compter sur la mise en place vraiment pas userfriendly...
Super déçu
Bof sa ne reboot pas la switch vraiment une perde de temps vivre la Team sxospro
Moi je reproche rien à atmosphère et je dis merci à son développeur
je préfère attendre et avoir quelques chose qui ne soit pas remplie de beug ou qui brique les console
Merci pour la news , a enfin super boulot !