Yet Another Firmware Update has rolled-out for the Nintendo Switch console, as such until more reports are in DON'T UPDATE if you hoping for future easy 'exploits' or CFW, but already it seems big 'N' has patched out the trick to 'youtube' videos playing, etc.
If you lucky enough to have 'two 3DS consoles' there is simple way to get CFW on one them using a combo method of the previous Seedminer exploit and DSiWare Injection system, but his tutorial posted below makes it clear how to do the complex transfer setup.
Go to GodMode9 then press "HOME", then go to "Scripts" and "Backup Sysnand", do the requested actions (Unlock the write if requested), then save the NAND from gm9 / out in the computer, then reinsert the SD card into the source console.
Go to Parameter and others then format the console, your NNID will be untied but can be used at the end of the hack.
Go to Parameter and Others then go to Data Transfer then from a 3DS and receive data via another console.
Do the same thing on the target console except that you select Send data instead of receiving.
Save the contents of the SD card of the source console in the computer, then reinsert it in the console, if you want to keep your friends on the source console they will be automatically put back in place thanks to the restoration of the NAND, on the target console will need to be added, make the data transfer.
Once the transfer is finished, finish the initiation of the console and then connect directly to the internet, then go to the Nintendo Eshop and normally as you get the account of the source console you must have the compatible DSiWare, download then once the download is complete you will have to go to settings and in Data Management and DSiWare to copy it to the SD card.
Then go to this thread: https://gbatemp.net/threads/seedmine...g-help.496114/ and follow the instructions for all steps.
Contact Nintendo and tell them that you no longer have access to the old console and then follow their information.
Once the NNID untied you can put it back on the source console.
For the target console, reformat it (you will not lose the hack) then re-download the CIAS required software on 3DS.guide and finally connect your NNID account, everything should go for the best without contacting Nintendo on the target console.
Go to Godmode9 with Start at the start of the console then press HOME and go to Scripts / Restore SysNAND, do the required actions then wait, then restart the console, you will then need to return the contents of the SD card previously saved in the computer .
Go to setting and network then spotpass and Sending system information to No.
If necessary, re-add to the target console any friends lost during the transfer and formatting.
If your Mii or your nickname is different, go to the mii editor and put everything back in order.
You can now enjoy all this hack that I myself tested with my friend and it's worked successfully!
The main difference with the official hekate - ipl is support for automatic partial dumping for your Switch's eMMC. Additionally, there are some other quality of life small changes.
It automatically starts partial dumping (even in exFAT formatted SD Cards), based on the available free space. Supports both FAT32 and exFAT.
If you have enough space and an exFAT formatted partition, it will automatically choose to dump the raw eMMC as one big file.
This release lets you dump the USER partition, or the whole RAW eMMC.
The automatic partial dump is only activated if you don't have enough space in your SD card to dump the whole eMMC.
The partial dumping is done in 15 2GB parts.
This way you can even use a 4GB sd card to dump the whole eMMC.
Normal dumping Procedure: If you have enough space, it will automatically dump your eMMC as one big file.
Don't move the partial.idx file!
Notice 1: Users that only have a 2GB or 4GB SD card, use the hekate-ipl_ctcaer_1.2_GBparts payload.
Notice 2: If you have an unfinished partial dumping and want to start anew, delete the partial.idx file first.
Warning: When dumping the eMMC, in parts, you should not power on the switch normally and boot to Switch OS before done. Otherwise your finished backup will probably corrupt, because Switch OS writes on your eMMC even if it seems you done nothing.
There are also windows and linux scripts provided, that join these 15 2GB files into one. In windows, you can then use @rajkosto biskeydump and HacDiskMount to manipulate your raw eMMC dump.
Nintendo is being sued again by Gamevice on the claim the design of the Nintendo Switch and its Joy-Con controllers infringes the design of Gamevice patents for controllers that also slide onto handheld gaming devices.
Additionally, Reuters on Tuesday reported that Gamevice had lodged a complaint against Nintendo with the U.S. International Trade Commission. In a statement, the ITC said it had begun an investigation into “certain portable gaming console systems with attachable handheld controllers and components,” naming Nintendo.
The nature of the complaint is the same as one Gamevice filed in August 2017 and withdrew two months later. It alleges that Nintendo was fully aware of two patents Gamevice held for designs that affix joystick controllers to opposite sides of a mobile device. In 2015, Gamevice launched this device (also called the Gamevice, pictured at top) and it supports Apple and Samsung smartphones and tablets. Nintendo announced the Switch in late 2016 and launched it in March 2017.
Nintendo 'scene' is on fire today, and @fail0verflow has decided to release their GITHub Repo pages to the public for viewing, most are still 'work-in-progress' and no official tweet has been announced yet by the team, but they do say to 'stay tuned' to after April 25th.
So from the looks of it, soon we will have full disclosure after their 90-day window closes in the next few days, so Stay Tuned!
@fail0verflow decided to have the 'last word' in the on-going 'scene drama', by releasing things 48 hours early, and at same time taking one more 'dig/poke' at the other teams, saying they 'found this bootrom bug first', but at same time saying others found it also!
… is what we were planning to say, but then someone published the 0day bug two days before our 90-day disclosure window was set to expire on April 25th. Oh well. Yes, this is the same bug that is exploited by fusée gelée, and that was just leaked by some other group (but we found it first).
This is going to be a bit rough since we didn’t have the blogpost/repos ready (procrastinators as we are), but without further ado, here’s the scoop.
The Tegra X1 (also known as Tegra210) SoC inside the Nintendo Switch contains an exploitable bug that allow taking control over early execution, bypassing all signature checks. This bug is in the RCM mode, which is a USB-based rescue mode intended for initial flashing of Tegra devices and recovery of bricked devices. Normally, RCM mode only allows signed images to be loaded, but thanks to the bug, arbitrary code execution is possible.
Each can be accomplished in several independent ways. Note that this is what iPhone users would call a “tethered jailbreak”, in that it needs to be performed on every boot via USB.
If you hold the Volume Up, Home, and Power buttons on the Switch (not joy-cons) at the same time.
Note that the Joy-Con home button won’t work here. You may be wondering about the secret home button on the Nintendo switch itself. As it turns out, what Tegra calls the Home button is actually connected to Pin 10 (the rearmost pin) on the right hand side Joy-Con connector. You can just use a simple piece of wire to bridge it to e.g. a screw on the rail (easiest), or pins 10 and 7 (or 1) together (10 and 9 won’t work). You can also 3D print a little jig to do this easily, using the innards of a Micro USB connector (which has the same pin pitch as Joy-Con connectors), or use a disemboweled Joy-Con as a donor for the connector. The latter is also useful, because the Joy-Con rails are UARTs and we use the right hand joy-con port as the console for coreboot, u-boot, and Linux.
The USB exploit requires a USB host. The exploit also requires using very long control transfers, which unfortunately some OSes are not happy with. You can either use vanilla Linux on a PC with an xHCI controller (USB 3.0, or any USB port on most recent systems), or a PC with an EHCI (USB 2.0) controller and this kernel patch.
This could conceivably also be executed from an Android phone (at least those with xHCI controllers), although porting the exploit to Android is left as an exercise to the reader. Bonus points for doing it from another Tegra device. Like another Switch.
Although this blob contains hardcoded tables and a “do everything” entrypoint for the Pixel C, it is possible to jump in one level deeper into the call tree and pass in custom tables, which is what our patched coreboot does to configure DDR4 on the Switch. Without this blob, the stack will still work, but the memory will run at ~200Mhz, which needless to say rather cripples performance.
The Tegra starts up the Boot ROM on the BPMP (arm7) core, and enters RCM mode.
The host-based USB exploit code puts a small (~2.5K) loader (cbfs.bin) into SRAM memory, using an RCM command.
The exploit is triggered, causing the ROM to jump into cbfs.bin.
The host code then goes into CBFS server mode, dynamically serving coreboot.rom via the USB RCM pipe to the Tegra.
cbfs.bin uses this CBFS server to request the first 28KiB of coreboot, which is the coreboot bootblock, into SRAM, then jumps into it.
The coreboot bootblock initializes basic peripherals, then loads the romstage into SRAM using the CBFS service from USB and jumps to it.
The coreboot romstage initializes SDRAM (at the basic fixed boot speed) and other peripherals.
The romstage then downloads the entire coreboot ROM into SDRAM (still using the Boot ROM RCM mode USB routines) and switches to RAM-backed CBFS.
The romstage now loads the ramstage (from the RAM CBFS), starts up the CCPLEX (Cortex-A57), and shuts down the BPMP.
Now on the CCPLEX (at EL3), the coreboot ramstage performs the rest of the basic system initialization, including DDR4 training if the MTC blob is available.
The ramstage now jumps into ARM Trusted Firmware, which initializes the TrustZone implementation. This is required to provide certain OS services.
ARM Trusted Firmware returns to the coreboot ramstage, now running in EL2 mode.
The ramstage loads and jumps to its final payload, U-Boot.
U-Boot starts, initializes some more hardware, and, by default, goes into USB download mode, with its own USB driver.
Using imx_usb_loader on the PC side, you can load arbitrary U-Boot payloads, such as a Linux kernel and its initramfs, and run them.
Sorry, we don’t have a guide for the Average User to use this, nor should they, most likely, since a lot of things are very rough around the edges. If you’re serious about developing, you should be able to figure things out yourself or ask questions on IRC.
The Git history is quite ugly, as we haven’t had a chance to clean things up yet. Please do not stare too hard.
Proper write-up on the exploit, stories of porting Linux (yes, there’s more to it than a panel driver ;-) ), upstreaming status, how batshit insane DDR4 is, and more. Probably, anyway. We’re pretty bad at writing blogposts.
¹ There are actually many Boot ROM bugs, several of which have been found by multiple people.
Version v0.6: added write-protect flag to the .tmd file (avoiding Data Management to delete it).
It's gaining control with full SCFG_EXT access rights immediately after power-up (before even starting the launcher).
Installation requires a working DSiware exploit with SD/MMC access, or a hardmod.
The exploit works with all retail DSi models, regardless of region and firmware version.
Once when installed, it will start the file 'bootcode.dsi' from SD card (if present).
Or, otherwise, it will resume booting nintendo's launcher (with disturbing healthsafety and bootmusic disabled, and removed RSA, whitelist and region checks).
CAUTION: This is still in mostly untested beta stage.
Currently, this should be used only if you have an eMMC backup & an installed hardmod - so you can unbrick if something goes wrong. Further how-to-use info is shown in the .dsi file's installer menu.
Note: The background GIF's are showing Herzogin Cecilie. I've also considered Principessa Jolanda for actual launch failures, and the Skyluck for intentionally grounded vessels. But then, the photo with the half sunken ship's figurehead nearly kissing the waves is so strong that I've chosen that one.
The 100th Warez Release like their previous 50th Release is special in two ways, one it mentions how big 'N' is changing their games to make it easier to do DMCA takedowns on sites that host the dumps, and also at the same time they released a set of useful KeyBlobs.
Wow, its Game 100 release time, and boy did we pick one this XCI is different than all the others so far how can that be you wonder.
Well let's begin first we have a new Partition on the Cart previously its was Update.Normal.Secure this one is Update.Logo.Normal.Secure this new Partition Logo contains a Plaintext Logo so guessing this means they want to go after people hosting and file a copyright claim.
Secondly, the Normal Partition is Completely Blank still there but Blank, assuming this is the force the new ASIC, so no displaying on <4.x Firms. So that sums up this strange XCI. Switch tools will need to update to support.
Thanks Level 5 for this different ROM, please release in English. Here's to the next 100 releases. Enjoy as Always!
There are 32 keyblobs written to NAND at factory, with each keyblob encrypted with a console-unique key derived from the console's SBK, the console's tsec key, and a constant specific to each keyblob. Despite being encrypted with console unique keys, though, the decrypted keyblob contents are shared for all consoles.
It is easy to dump a 'binary', but then how do you study it, normally you use a program like IDA PRO, but then its still hard, but when scene developers like @SciresM releases IDC scripts, then it makes it a ton easier, you can start almost right away, studying the flow of coding!
For anyone who's interested in REing the Nintendo Switch's "Loader" sysmodule, here are my IDCs (which I used to reimplement the module the past week): https://gist.github.com/SciresM/5f43...17dd3e43e656d0 (1.0.0, 3.0.0, and 5.0.0).
GBATemp Forum Member @ksamj202 has been kind enough to setup two 'web-friendly' domains for accessing the Web Fusée Launcher released earlier this week be scene developer @altas44 on his GITHub, and it works great except only on Chromebooks and most Android phones, but not on Windows Chrome, but at least it gives you another option to launch the payloads via USB.