eliboa

Ha la par contre c pas encore explicable pour le moment . Mais la chose qui est certaine c que la fusée lance linux on peu avoir accès au homebrew luncher . Donc un boot de ISO est forcément possible sous peu . Je ne suis pas devs non plus mais actuellement j ai une Switch en 3.0 et une en 5.0.2 c plus stable sur ce que j' ai fait tourner comme le fba pour le 5.0.2 pour moi

Non mais sérieux je veux pas être méchant mais tu racontes n'importe quoi, fusée launcher, linux et les homebrew c'est quoi le rapport ? Et encore plus, c'est quoi le rapport avec les efuses ?

Alors que tu puisses booter sur n'importe quel fw c'est une chose mais que tu puisses downgrader un fw en est une autre. Aujourd'hui sur FW > 3.0 le seul point d'entée est l'exploit TegraRCM aka fusée gelée aka Shofel2. Il existe surement des points d'entrée pour les FW 3.0 à <5.0 qui ont été fermés dans le FW 5.0 et aucune solution de downgrade n'existe à l'heure actuelle. Tous les devs dignes de ce nom disent qu'il ne faut pas uprgrader. A bon entendeur.

On a un accès nand on aura forcément un downgrade avec le tegra ne durent pas de bêtise

C'est toi qui dit des bêtises, tu as deja entendu parler des efuses ?

J'ai une question... Je sais je dois rester en 4.0.1

Mais est-il possible de mettre une switch à jour manuellement dans une version bien spécifique ? J'ai la mise à jour par cartouche de jeu en tête mais Exemple je suis en 4.0.1 et plus tard si on nous conseil de passer en 5.0.0 et pas plus haut, il y a d'autres façon ?

 

Oui je confirme et tu as une liste non exhaustive des jeux et fw associés ici : https://gbatemp.net/...version.485959/

Pour le HBL 5.0x,il s'avère que la plupart des homebrews ne fonctionne pas, comme retroarch. (Seul Tetris fonctionne)

 

REminiscence fonctionne bien et c'est le premier que je teste :

Je viens de tester HBL via hekate sur FW 5.0.2 et ça marche du feu de dieu

 

La release :l https://github.com/J...pl-50x/releases

Mettre le contenu de "sdfiles" à la racine de votre carte SD (celle qui est utilisée par votre switch d'habitude) puis lancer le payload.bin avec TegraRcmSmash (ou fusee launcher). Faire comme dans la vidéo dans l'article et voilà

Attention, FW 5 seulement, les >3.0 ou < 5.0 c'est pas encore possible. Perso j'ai deux switchs sous la main dont une en 5.0.2 c'est pratique.

Salut. Voici un article que j'ai publié sur mon blogrécemment et que je recopie ici pour ceux qui veulent en savoir plus sur le fonctionnement de l'exploit bootROM récemment rendu public.

 

Fin avril (2018) la team fail0verflow a liberé son exploit ShofEL2 permettant de lancer Linux sur une console Nintendo Switch (toutes versions de FW confondues). Le même jour, Kate Temkin de la team ReSwitched libérait le lanceur de payload nommé "Fusée Gelée". Ces deux exploit n'en sont en fait qu'un seul, ils utilisent même faille située dans la BootROM du SoC Tegra X1 de la Nintendo Switch (pour rappel la console utilise une puce Tegra de NVIDIA). Les deux teams ont liberé leur exploit suite au leak du code source (comme bien souvent).

 

L'exploit utilise une vulnérabilité du mode recovery de la Switch (appelé mode RCM) qui permet d'utiliser la technique, très répandue dans le monde du hack, du dépassement de tampon (buffer overflow). Voici quelques explications fournies par Kate Temkin que j'ai traduites et synthétisées.

 

Le coreboot du processeur Tegra X1 applique le pseudo code suivant au démarrage, obtenu après reverse-engineering de la bootROM  :

// If this is a warmboot (from "sleep"), restore the saved state from RAM.
if (read_scratch0_bit(1)) {
  restore_warmboot_image( & load_addr);
}
// Otherwise, bootstrap the processor.
else {
  // Allow recovery mode to be forced by a PMC scratch bit or physical straps.
  force_recovery = check_for_rcm_straps() || read_scratch0_bit(2);
  // Determine whether to use USB2 or USB3 for RCM.
  determine_rcm_usb_version( & usb_version);
  usb_ops = set_up_usb_ops(usb_version);
  usb_ops - > initialize();
  // If we're not forcing recovery, attempt to load an image from boot media.
  if (!force_recovery) {
    // If we succeeded, don't fall back into recovery mode.
    if (read_boot_configuration_and_images( & load_addr) == SUCCESS) {
      goto boot_complete;
    }
  }
  // In all other conditions
  if (read_boot_images_via_usb_rcm( < snip > , & load_addr) != SUCCESS) {
    /* load address is poisoned here */
  }
}
boot_complete:
  /* apply lock-outs, and boot the program at address load_address */ 

.

On peut voir que le mode RCM peut être activé sous certaines conditions :

- Si le processeur n'arrive pas à trouver une BTC (Boot Control Table) valide
- Si une combinaison de touche est activée (PCM scratch bit of physical straps)
- Si le processeur est rebooté alors qu'une valeur spécifique a été écrite dans le registre du PMC (Power Managment Controller)

 

Le mode recovery est présent dans toutes les appareils équipés d'une puce Tegra X1 (pas uniquement les Switch donc) et permet donc d'injecter dans la RAM un bout de code signé (appelé applet ou miniloader) présent sur un media USB.
Evidemment ce mode RCM n'accepte que des commandes qui sont chiffrées via RSA ou AES-CMAC :

// Significantly simplified for clarity, with error checking omitted where
unimportant.
while(1) {
  // Repeatedly handle USB standard events on the control endpoint EP0.
  usb_ops - > handle_control_requests(current_dma_buffer);
  // Try to send the device ID over the main USB data pipe until we succeed.
  if (rcm_send_device_id() == USB_NOT_CONFIGURED) {
    usb_initialized = 0;
  }
  // Once we've made a USB connection, accept RCM commands on EP1.
  else {
    usb_initialized = 1;
    // Read a full RCM command and any associated payload into a global buffer.
    // (Error checking omitted for brevity.)
    rcm_read_command_and_payload();
    // Validate the received RCM command; e.g. by checking for signatures
    // in RSA or AES_CMAC mode, or by trivially succeeding if we're not in
    // a secure mode.
    rc = rcm_validate_command();
    if (rc != VALIDATION_PASS) {
      return rc;
    }
    // Handle the received and validated command.
    // For a "load miniloader" command, this sanity checks the (validated)
    // miniloader image and takes steps to prevent re-use of signed data not
    // intended to be used as an RCM command.
    rcm_handle_command_complete(...);
  }
}

.

La principale vulnérabilité se trouve dans la fonction rcm_read_command_and_payload, qui permet de lire les commande RCM et les données du payload via le dispositif d'accès USB (endpoint).  Plusieurs bugs sont présents dans cette fonction mais un est particulièrement exploitable : 

uint32_t total_rxd = 0;
uint32_t total_to_rx = 0x400;
// Loop until we've received our full command and payload.
while (total_rxd < total_to_rx) {
  // Switch between two DMA buffers, so the USB is never DMA'ing into the same
  // buffer that we're processing.
  active_buffer = next_buffer;
  next_buffer = switch_dma_buffers();
  // Start a USB DMA transaction on the RCM bulk endpoint, which will hopefully
  // receive data from the host in the background as we copy.
  usb_ops - > start_nonblocking_bulk_read(active_buffer, 0x1000);
  // If we're in the first 680-bytes we're receiving, this is part of the RCM
  // command, and we should read it into the command buffer.
  if (total_rxd < 680) {
    /* copy data from the DMA buffer into the RCM command buffer until we've
    read a full 680-byte RCM command */
    // Once we've received the first four bytes of the RCM command,
    // use that to figure out how much data should be received.
    if (total_rxd >= 4) {
      // validate:
      // -- the command won't exceed our total RAM
      // (680 here, 0x30000 in upper IRAM)
      // -- the command is >= 0x400 bytes
      // -- the size ends in 8
      if (rcm_command_buffer[0] >= 0x302A8 u || rcm_command_buffer[0] < 0x400 u || (rcm_command_buffer[0] & 0xF) != 8) {
        return ERROR_INVALID_SIZE;
      } else {
        left_to_rx = * ((uint32_t * ) rcm_command_buffer);
      }
    }
  }
  /* copy any data _past_ the command into a separate payload
  buffer at 0x40010000 */
  /* -code omitted for brevity - */
  // Wait for the DMA transaction to complete.
  // [This is, again, simplified to convey concepts.]
  while (!usb_ops - > bulk_read_complete()) {
    // While we're blocking, it's still important that we respond to standard
    // USB packets on the control endpoint, so do that here.
    usb_ops - > handle_control_requests(next_buffer);
  }
}

.

Il est important de comprendre qu'une commande RCM est lue 1) dans un buffer global et 2) à l'adresse cible (target load adress) avant même qu'une quelconque signature ne soit vérifiée ce qui laisse à tout intrus une porte grande ouverte à une partie conséquente de la mémoire (non validée).

Pour trouver la vulnérabilité il faut s'enfoncer encore plus profondément dans le code, dans la partie qui gère les demandes de contrôle USB (handle_control_requests). Une "control request" est initiée lorsqu'un hôte envoie une commande dont la structure est décrite comme ceci :

 

 

 

Par exemple, l'hôte peut envoyer une demande pour connaître le statut de l'appareil en envoyant une commande GET_STATUS à laquelle il se verra répondre par un paquet dont la taille maximale est définie par le champ "length". Selon la commande envoyée, l'appareil devrait donc retourner un paquet dont la taille maximale est soit la taille indiquée par ce champ soit la taille maximale de données disponibles qui correspondent à la réponse (logique). Admettons qu'il s'agisse d'un statut, ça ne devrait pas prendre plus d'un ou deux octets donc même si l'hôte indique 32b pour le champ "length", le réponse ne devrait pas être supérieure à 1b ou 2b.

 

L'implémentation de ce comportement dans le bootloader peut être décrite comme ceci :

// Temporary, automatic variables, located on the stack.
uint16_t status;
void * data_to_tx;
// The amount of data available to transmit.
uint16_t size_to_tx = 0;
// The amount of data the USB host requested.
uint16_t length_read = setup_packet.length;
/* Lots of handler cases have omitted for brevity. */
// Handle GET_STATUS requests.
if (setup_packet.request == REQUEST_GET_STATUS) {
  // If this is asking for the DEVICE's status, respond accordingly.
  if (setup_packet.recipient == RECIPIENT_DEVICE) {
    status = get_usb_device_status();
    size_to_tx = sizeof(status);
  }
  // Otherwise, respond with the ENDPOINT status.
  else if (setup_packet.recipient == RECIPIENT_ENDPOINT) {
    status = get_usb_endpoint_status(setup_packet.index);
    size_to_tx = length_read; // <-- This is a critical error!
  } else {
    /* ... */
  }
  // Send the status value, which we'll copy from the stack variable 'status'.
  data_to_tx = & status;
}
// Copy the data we have into our DMA buffer for transmission.
// For a GET_STATUS request, this copies data from the stack into our DMA buffer.
memcpy(dma_buffer, data_to_tx, size_to_tx);
// If the host requested less data than we have, only send the amount requested.
// This effectively selects min(size_to_tx, length_read).
if (length_read < size_to_tx) {
  size_to_tx = length_read;
}
// Transmit the response we've constructed back to the host.
respond_to_control_request(dma_buffer, length_to_send); 

.

Dans la plupart des cas, le système limite correctement la taille des réponses à la taille maximale de données disponibles selon la demande. Mais, dans ces cas précis, la taille maximale est systématiquement définie par la taille fournie par l'hôte (champ "length") :
- Lors d'une demande GET_CONFIGURATION avec un contexte (recipient) à "DEVICE"
- Lors d'une demande GET_INTERFACE avec un contexte à "INTERFACE"
- Lors d'une demande GET_STATUS avec un contexte à "ENDPOINT"

 

Il s'agit là d'une faille majeure de sécurité car dans ces conditions l'hôte peut recevoir jusqu'à 65,535 octects par "control request" ! Dans les cas où cette taille max est définie directement dans "size_to_tx" alors cette valeur décrit la taille du memcpy qui va s'appliquer et pourra donc copier jusqu'à 65535b  directement dans le buffer DMA. Et le fait que les buffers DMA utilisés par la stack USB sont -comparativement- beaucoup plus petits va provoquer des dépassements de tampon (buffer overflow).

 

Et voilà! Je ne m'attarde pas sur la technique du dépassement de tampon car on la retrouve dans beaucoup d'exploit mais c'est bien cette méthode qui permet de charger notre payload qui comprend donc les commandes RCM, les valeurs qui iront écraser la stack USB et le payload final (programme) à charger !

 

Mais revenons aux deux versions de notre exploit...

Alors que Fusée Gelée se "contente" de lancer un payload (du code binaire pur, sans headers ni metadonnées), ShofEL2 de fail0verflow offre une bootchain complète permettant de lancer le kernel Linux : BootROM Exploit → coreboot loader → coreboot → ARM trusted firmware → coreboot → u-boot → Linux.

 

Cette bootchain est basée sur celle du  Pixel C et est libre à 99%. Plus d'info ici => https://fail0verflow...g/2018/shofel2/

 

 

Plus d'info sur Fusée Gelée par Kate Temkin

Superbe V4 du tuto, il ne manque vraiment plus grand chose maintenant mis à part l'utilisation de Partition Guru sous Windows pour redimensionner la partition ext4 et éventuellement évoquer la possibilité d'utiliser le payload Hekate pour ceux qui souhaite juste dumper la nand simplement (en plus ça fonctionne soit en fat32 soit en Extfat et une carte de 32 GB suffit pour effectuer le dump complet).

 

merci shadow. Oui je voulais attendre car je ne se sais pas encore quelle solution retenir pour le dump. Partition Guru chez moi a complètement détruit la partition ext4 lors du redimensionnement. et pour le payload Hekate c'est sans doute une bonne solution mais je pense que'elle mériterait son propre tuto (enfin ça m'embête de la mettre dans ce tuto qui concerne Linux et qui est déjà très long lol).... problème existentiels du lundi matin, n'est-ce pas ?

Ah super top merci tu geres. J'attends ca avec impatience du coup

 C'est fait => http://www.logic-sun...-v4-pc-windows/

dois je pleurer ou bien ce n'est pas si grave ?

 

Pleurer non quand même pas car ta console est EXPLOITable (TegraRCM) mais évidemment ça aurait été mieux de rester en 4.1 car on sait que des exploits privés existent pour cette version de fw. Tu risques d'attendre plus longtemps pour le CFW ou du moins pour avoir une solution sans passer par le mode RCM (joycon hax).

Mais pourquoi diable avoir accepté une maj ? Faut pas connecter sa console à internet quand on veut hacker sa console, non non non.

Personnellement je préfèrerais une switch totalement portable pour la nouvelle revision:

Avec la sortie de Nintendo Labo je vois mal Big N sortir prochainement une version de la console incompatible (de base) avec leur grande nouveauté.
Après le principe, pourquoi pas, ça pourrait trouver son public mais je crois pas à une nouvelle version de la switch pour bientôt. Une révision hardware de la puce Tegra, au minimum pour corriger les bugs dans la bootrom, ça c'est sûr (ou alors ils sont devenus fous). 

Super, merci shadow256 pour tes remarques, ça fait aussi plaisir d'avoir des retours quand on passe du temps sur un tuto. Je vais prendre le temps de traiter tous ça quand je serai chez moi. Arf, satanées fautes j'en ai pourtant corrigé plein, merci

Pour biskeyload oui je pense qu'il y a des mise à jour à faire, déjà faudrait que je teste à nouveau car le projet à eu plusieurs commit depuis. Dès que tu mets à jour une partie du tuto, c'est l'autre qu'il faut changer lol.

 

Erko, oui très bien ton lien, je l'ajouterai aussi. merci.

Je me disais qu'il faudrait peut-être prévoir un tuto à part pour booter en mode RCM car finalement cette technique est déjà et sera commune à plusieurs tutos. Un simple lien vers ce tuto spécifique suffirait dans chaque tuto concerné. 

Pour en revenir a la news, c'est une grande avancé ou cela veut dire que peut importe le firmware, le lancement du HBL sera possible, pour rappel : La version 3.0.0 est pour l'instant la seul a pouvoir le faire ce qui est dommage, la on aurais un accès instantané au HBL avec le FW qu'on veut a partir du moment ou on a un CFW, c'est génials, de plus en haut j'ai dit qu'il suffirais simplement de lancé le mode RCM une seul fois pour installer le CFW, je le pense car la news nous explique que l'on peut lancé des exploit / .bin (je suppose) directement de la carte SD, le CFW doit s'installer dans une partie de l'OS est j'imagine qu'il copie une sorte de configuration pour qu'au démarrage, l'OS charge direct le fichier CFW Atmosphère dans la carte SD est bim le CFW ce lance comme si la console démarrais normalement, c'est mon avis mais y'a des chances, sinon styler dans la video les news Nintendo qui devienne des news hack comme ReSwitched :| Ou même des raccourcies (j'ai vu Launch) La switch commence a avoir des modfif intéressante qui vos le coup, espérons que Nintendo commence pas a nous faire chier avec leurs pu**** de mise a jour a la ***

Oui tu auras une emuNAND (sur emmc ou sd je sais pas) en plus de ta sysNAND. Tu pourras donc booter au choix sur le fw officiel ou sur le cfw j'imagine, comme sur 3DS si je me souviens bien. Donc pas de problème en cas d'upgrade de fw par Nintendo, tu pourras upgrader ton emuNAND sans upgrader ta sysNAND.
On peut pas rêver mieux

edit : corrigé, j'avais inversé sysNAND et emuNAND

Un émulateur wii? je pence que c'est impossible vu que la switch ne gere pas les wiimote
Le seul moyen serai d'installé linux et de faire tourné dolphin si compatible avec linux et rendre les wiimote compatible avec la switch grace à linux...
Perso je te conseille encore de prendre une wii u pour ca

 

 

Salut. Sauf contrainte hardware je ne vois pas pourquoi un CFW ne pourrait pas gérer les wiimote ? Si linux sait le faire (avec l'exploit bootRom Shofel2), alors Atmosphère devrait pouvoir aussi puisqu'il ont le même niveau d'autorisation au niveau du système, c'est à dire un contrôle total.

Le seul truc ou je vois pas comment il serait possible de faire, c'est un pour émulateur wiiU (là tu es vraiment limité par le hardware pour le coup )

Peut on espérer avec cette méthode un Dump de sa Nand comme ton Tuto avec Linux.

 

Non pour le moment il n'est pas possible de booter lancer sur Switch depuis un PC sous Windows. Il faut forcément passé par une machine linux (ou mac) ou bien en installant Ubuntu sur une machine virtuelle sur Windows (avec WMware c'est très simple > tuto ici : https://www.windows8...untu-francais/)

Je vais bientôt mettre à jour le tuto concerné avec des explications sur le lancement depuis une VM et avec une procédure encore plus simplifiée pour lancer linux et dumper sa NAND.

edit : c'est fait le tutoest mis à jour

ça c'est notre bon chinoi red je c pas quoi .... tu peut pas changer de site ? le type qui vient nous pourir les news avec les commentaires pourries mdr ^^

Sinon pour la news excellent ça avance

Du coup via un dump ça récupère toutes les données décrypté ?

 

ah ah j'attendais que quelqu'un le rembarre bien celui là

sinon pour répondre à ta question, oui toutes les données sont décryptées mais après ça reste des fichiers binaires qu'ils faut s'avoir exploiter.

Si tu veux en savoir plus sur la structure et le contenu de la NAND, une seule adresse (mise à jour par les devs) => http://switchbrew.or...lash_Filesystem

 

Sinon pour ceux qui veulent tester l'exploit sur Windows sans installer linux j'ai rédigé un tuto => http://www.logic-sun...ee-sur-windows/