89 replies to this topic

[nicky]

on va attendre les explications et surtout la reprise par tout les autres acteurs de la scène switch pour voir l’intérêt de la chose !

dire que ça n'apporte rien alors que c'est la base de tout, c'est pas malin ...

[captain2k20]

jbam tu va faire une video pour nous explique ?

[shadow256]

Regardez ce tuto, 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.

[choupisaumon]

ça deviens le bordel a force , on ne sais plus quoi faire et quoi mettre sur notre switch tellement il existe de programme

[davidcampbelle]

Regardez 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?

[Shadomage]

Comme à chaque nouveautés les gens sont pressé. Attendons les tests, les améliorations et les projets qui viennent se greffer à Atmosphère.

La patience est légion.
Chacun à ses attentes par rapport à tel où tel hack

[eliboa]

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 :

1. 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.

2. 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.

3. 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).

4. 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).

5. 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…

Ce message a été modifié par eliboa - 17 octobre 2018 - 12:50.

[Shadomage]

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 !

[/size]

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" ??

[eliboa]

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

[nicky]

Scirces a t'il déjà parler d'un exploit cold boot ?

[nicky]

Quel intérêt a garder secret un cold boot quand la majorité des personnes utilisant le hack switch dont tous passés en 5.1 si ce n'est pas 6.1

[shadow256]

Oui, un exploit Cold Boot a déjà été évoqué (firmware 3.0.0 maximum probable mais peut-être jusqu'au 4.1.0) et on a aussi les exploits Dejavu et Jamaivu qui sont des exploits de l'OS de la Switch dispo jusqu'au 4.1.0. Que permettront ces exploits par contre, je n'en sais rien mais selon la doc d'Atmosphere, l'exploitation des deux derniers exploits que j'ai cité permettraient de booter Atmosphere sans avoir besoin de passer par le mode RCM mais comment, avec quelles limitations... là aucune idée. Le fait est que sans vrai emunand, cet exploit aura peut d'intérêt pour les utilisateurs car le firmware requis sera la 4.1.0 (donc lancement des jeux limités à ce firmware maximum) si on relance le CFW avec ce firmware sur sysnand et si on souhaite profiter du online, cela ne sera pas possible non plus car l'emunand lancé sera en CFW et donc probablement bannie par Nintendo et impossible de mettre le dernier firmware sur la sysnand sans perdre les exploits.

Après, je le redis, je ne fais que spéculer car on ne sais pas comment ces exploits fonctionnent vraiment. Peut-être qu'en utilisant un kernel patché il sera possible de jouer aux derniers jeux sur un firmware inférieur par exemple et donc on aura une emunand clean pour le online et le CFW en 4.1.0 sur la sysnand pour relancer l'exploit, lancer les jeux et les homebrews.

[mathls]

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?

Ce message a été modifié par mathls - 17 octobre 2018 - 14:06.

[Manuto]

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

[Z0rP]

Voici le ChangeLog traduit avec mes petits moyens.

ChangeLog

Spoiler

Fusée, un chargeur de démarrage personnalisé

• Prend en charge le chargement / la personnalisation de KIP arbitraires à partir de la carte SD.
• Prend en charge le chargement d’un noyau personnalisé à partir de la carte SD ("/atmosphere/kernel.bin").
• Prend en charge les correctifs de noyau définis à la compilation, par microprogramme.
• Tous les correctifs dans les chemins tels que / atmosphere / kip_patches / <nom du correctif défini par l'utilisateur> / <SHA256 de KIP> .ips seront appliqués aux KIP appropriés, permettant ainsi une distribution aisée des correctifs prenant en charge plusieurs versions.
  
  • Les formats IPS et IPS32 sont pris en charge.
• Tous les correctifs dans les chemins tels que / atmosphere / kernel_patches / <nom du correctif défini par l'utilisateur> / <SHA256 du noyau> .ips seront appliqués au noyau, permettant ainsi une distribution aisée des correctifs prenant en charge plusieurs versions.
  
  • Les formats IPS et IPS32 sont pris en charge.
• Configurable en modifiant BCT.ini sur la carte SD.
• Atmosphère devrait également être lancé par le chargeur alternatif hekate, pour ceux qui le préfèrent.

Exosphère, un moniteur sécurisé personnalisé complet

• Exosphere est une nouvelle implémentation du micrologiciel
• TrustZone de Nintendo, qui reproduit intégralement toutes ses fonctionnalités.
• En outre, il a été étendu pour fournir des informations sur la version actuelle de l’API Atmosphere, à l’intention des homebrews souhaitant l’utiliser.

Stratosphère, un ensemble de modules système personnalisés. Ceci comprend:

• Un module de système de chargeur.
  
  • Réimplémentation du chargeur de Nintendo, en reproduisant intégralement toutes les fonctionnalités d'origine.
  • Configurable en éditant /atmosphere/loader.ini
  • Support de première classe pour Homebrew Loader.
    
    • Un NSP exefs (par défaut "/atmosphere/hbl.nsp") sera utilisé à la place des exefs du titre de victime.
    • Par défaut, HBL remplacera l'applet d'album, mais toute application devrait également être prise en charge.
  • Étendu pour prendre en charge la redirection arbitraire du contenu exécutable sur la carte SD.
    
    • Les fichiers seront chargés de préférence à partir de / atmosphere / titres / <titleid> / exefs /, le cas échéant.
    • Les fichiers présents dans les fichiers originaux qu'un utilisateur souhaite marquer comme non présents peuvent être "stubés" en créant un fichier .stub sur le SD.
    • S'il est présent, un fichier PFS0 dans /atmosphere/titles/<titleid>/exefs.nsp remplacera complètement les fichiers exef originaux.
    • La redirection est éventuellement permutable en maintenant certains boutons enfoncés (par défaut, en maintenant R désactivant la redirection).
  • La prise en charge complète du correctif du contenu NSO est implémentée
    
    • Tous les correctifs dans les chemins tels que / atmosphere / exefs_patches / <nom du correctif défini par l'utilisateur> / <Hex Build-ID de NSO à correctif> .ips seront appliqués, permettant ainsi une distribution aisée des correctifs prenant en charge plusieurs versions de firmware et / ou titres.
    • Les formats IPS et IPS32 sont pris en charge.
  • Extension pour prendre en charge le lancement de contenu à partir de fichiers exécutables perdus sur la carte SD, sans nécessiter d'installation officielle.
    
    • Ceci est fait en spécifiant FsStorageId_None au lancement.
• Un module système de gestionnaire de service.
  
  • Réimplémentation du gestionnaire de services de Nintendo, en reproduisant intégralement toutes les fonctionnalités d'origine.
  • Prise en charge à la compilation pour la réintroduction de "smhax", permettant aux clients d'ignorer éventuellement la vérification de l'accès aux services en ignorant l'initialisation.
  • Étendu pour permettre à l’homebrew d’acquérir plus de poignées de services privilégiés que ce que Nintendo autorise nativement.
  • Étendu pour ajouter une nouvelle API permettant d'installer des écouteurs Man-In-The-Middle pour des services arbitraires.
  • L'API peut également être utilisé pour détecter en toute sécurité si un service a été enregistré de manière non bloquante sans effets secondaires.
  • Documentation complète de l'API à venir.
• Un module de système de gestionnaire de processus.
  
  • Réimplémentation du gestionnaire de processus de Nintendo, en reproduisant intégralement toutes les fonctionnalités d'origine.
  • Étendu pour permettre à homebrew d'acquérir des descripteurs de processus arbitraires et ainsi de lire / modifier la mémoire système sans bloquer l'exécution.
  • Étendu pour permettre à homebrew de récupérer des informations sur les limites des ressources du système.
  • Extension en intégrant une implémentation complète et étendue du module système boot2 de Nintendo.
  • L'ordre de lancement du titre a été optimisé afin de permettre un accès plus rapide à la carte SD.
  • Le module système de collecte des erreurs n'est pas lancé intentionnellement, ce qui empêche la génération de nombreux rapports d'erreur de télémétrie système.
  • Les utilisateurs peuvent placer leurs propres modules système personnalisés sur la carte SD et les marquer pour le lancement automatique de boot2 en créant un fichier / atmosphere / titres / <title ID> /boot2.flag sur leur carte SD.
• Un module système fs.mitm personnalisé.
  
  • Utilise l'API MitM d'Atmosphère afin de fournir aux utilisateurs un moyen simple de modifier le contenu du jeu.
  • Intercepte toutes les commandes FS envoyées par les jeux, avec une gestion spéciale des commandes utilisées pour monter le contenu RomFS / DLC afin de permettre la création et la distribution faciles de mods jeu / DLC.
    
    • fs.mitm analysera l'image RomFS de base d'un jeu, une image RomFS située dans / atmosphere / titres / <titre ID> /romfs.bin, ainsi que tous les fichiers volants dans / atmosphere / titres / <titre ID> / romfs /, et les fusionner en une seule image RomFS.
    • Lors de la fusion, les fichiers en vrac sont préférés au contenu de l'image romfs.bin de la carte SD, et les fichiers de l'image de la carte SD sont préférés à ceux de l'image de base.
  • Peut en outre être utilisé pour intercepter des commandes envoyées par des titres système arbitraires (à l'exception de celles lancées avant que la carte SD soit active), en créant un fichier / atmosphere / titres / <title ID> /fsmitm.flag sur la carte SD.
  • Peut être désactivé de force pour n’importe quel titre en créant un fichier / atmosphere / titres / <ID du titre> /fsmitm_disable.flag sur la carte SD.
  • La redirection est éventuellement permutable en maintenant certains boutons enfoncés (par défaut, en maintenant R désactivant la redirection)
• Un module système de rapport d'incident personnalisé.
  
  • Sert de remplacement instantané au module de système Creport de Nintendo.
  • Génère des rapports détaillés et lisibles par l'homme sur les pannes système en enregistrant dans / atmosphere / crash_reports / <timestamp> _ <titre ID> .log.
  • Comme les rapports ne sont pas envoyés au sysmodule erpt, cela désactive toute télémétrie liée aux rapports de blocage.

Améliorations générales de la stabilité du système pour améliorer l'expérience de l'utilisateur.

Ensuite, gardez à l'esprit qu'il s'agit d'une Pre-Release et que SciresM a bien indiqué que jusqu'à la v1.0 (supposée finale), il y aurait des réajustements.

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.

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.

D'ailleurs, le développeur tumGER va proposer prochainement la v10 de sa compilation SDFiles Switch qui prendra correctement en charge le CFW.

Pour les impatients qui souhaitent passer par Hekate pour lancer le bin fusee-primary et profiter de atmosphère, il vous faudra faire ainsi:
1. Supprimez fusee-primary.bin dans bootloader / payloads
2. Placez fusee-secondary.bin à la racine.
Enjoy!

Pour ce qui est de tinfoil et autres, les update vont arriver. Faut juste être patient ou continuer à utiliser votre moyen actuel

Ce message a été modifié par Z0rP - 17 octobre 2018 - 14:20.

[eliboa]

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

Ce message a été modifié par eliboa - 17 octobre 2018 - 14:24.

[eliboa]

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

Ce message a été modifié par eliboa - 17 octobre 2018 - 14:37.

[Fatiguant]

Poir ceux qui veulent un demarrage sans manipulations installez vous un trinket m0 ou switchMe tout simplement.

Sinon yes c’est bon ca premiere release d’atmosphere.

Ce message a été modifié par Fatiguant - 17 octobre 2018 - 14:50.

[Av3nger]

Salut Fatiguant j'aimerais bien savoir ou chopper les puces j'ai contacté la team rebug aucune réponse :/

[shadow256]

Le HBLoader se met également à jour en 2.0 pour l'occasion avec quelques évolutions intéressantes comme l'accès aux 3,2 GB de ram de la console pour les homebrews, voir cette page.