[Tutorial] How to dump Switch NAND using Linux

Discussion in 'Switch - Tutorials' started by kombos, Apr 27, 2018.

  1. kombos

    kombos GBAtemp Regular

    Apr 24, 2018

    Until no one published working NAND Dumper payload I wanted to share this quick tutorial how to dump encrypted NAND content to the SD card simply using Linux method and f0f exploit. Running Linux that way doesn't affect or touch your original Switch NAND and just in case you mess something up, you will have a backup copy you can restore later, or use other tools you can find around to further research about your Switch filesystem.

    I tried to make to whole process as easy as I can so everyone can make a safety dump of console filesystem. The whole tutorial probably need more work and any suggestions are welcome.

    *** Edit ***

    Currently I've released 3rd version of Arch Linux SD Image. Same as previously, mesa hw acceleration, browser, development environment, git, base-devel, and some other tools.
    You'll definitely not find any pre-installed emulators there it also might not be compatible with OSX. I have nothing to do with OSX, and I've touched Mac like twice - at store.
    Don't ask my why something not work. Either you are Pro user and you are able to sort out things yourself or use dedicated forums to resolve your issues.

    Below is a link to arch linux v3:

    Thanks to fantastic work of @rajkosto who developed a toolset to fetch keys needed to mount and encrypt our dumped NAND's (https://github.com/rajkosto/biskeydump) and @eliboa who point me where to start with keydumper.
    Also guys from the other other threads who work on making linux better everyday @natinusala & @Gigaa feel free to visit this threas if you have Linux related questions - https://gbatemp.net/threads/quick-tuto-how-to-boot-linux-on-your-switch.501918/

    With that knowledge I was able to update github repo:
    https://github.com/SoulCipher/sw_nand_dump (If you want to use github repo running on your own linux distro take a notice that there is hardcoded paths to biskeydump inside the script and it might not work straightforward for you so change accordingly to your environment)

    But I also included the script in arch3_switch Image ! ;-) So what is implemented so far ?
    Some cool features for all non technical people or all struggling to get biskeydump payload working on their switches ! Happy days !
    • You can simply boot distro, execute dump_nand command and script do everything for you !
    • It's actually dumping BOOT0, BOOT1, and main (big) NAND device to file
    • It's checking MD5 sums automatically to make sure your dumps are not corrupted (And probably the best below ;-))
    • It's extracting TSEC Firmware required by @rajkosto biskeydump. Not enough ?
    • It's automatically format the file into C Array format (tsecfw.inl)required if you want to compile biskeydump fusee-loader payload yourself. Still not enough ?!!
    • It can generate ready to use biskeydump v3 (fresh git pull from repo with QRCode so you don't have to retype keys from screen - thanks @rajkosto !!! ) payload for you, so you don't care about compiling stuff anymore !! :toot:
    Of course it's not ready to use payload, it doesn't contain firmware part, but well... script will inject firmware from your dumps for you automatically :}
    Remember: That you can participate in this project. If you don't have time or skill just post your ideas there. Some of them might be implemented in future releases.

    How does the script works ?

    Use *at least 64GB SD Card* as NAND image itself has 32 gigabytes !! Otherwise script wont work for you if you doesn't have enough free space on your SD Card. (well until you tinker around :rofl2:)
    There are alternative ways of dumping NAND over network rather than dumping it on SD Card, however that doesn't work for me. Follow this thread, there is a lot of smart asses around so they will able to help you or point you.

    Basically follow the guide below to get and flash SD Card image, use f0f exploit to get kernel running, reboot & reexploit to get WiFi working. Log in straight using root:root credentials and run dump_nand command
    • First there is a check if all required block devices are available under system (mmcblk1boot0,mmcblk1boot1,mmcblk1)
    • Then it checks if you have enough free space to fit 32GB dump. If not unfortunately it quits with error.
    • When everything is fine it just prepare commands set to start dumping process, you will be asked if you want to proceed
    • After dumping process (usually takes less than 10 minutes on 64 sdXC SanDisk card) checksums are calculated to make sure everything went fine. If there is a checksum mismatch you'll see an error
    • Next it will ask you if you tempted to get your BIS Keys to decrypt your NAND if you select yes again:
      • TSEC Firmware will be extracted automatically from BOOT0
      • tsecfw.inl file in proper format will be generated
      • new version (v3) of biskeydump payload will be served for you in /root/biskeydump_armed.bin and I hope you know what to do with it.

    I'll do my best to update this tutorial as things will be progressing if there is someone willing to help I appreciate that.

    Want to get your savegames ? Wanna play around ? Give it a go, and let me know what you thinking.
    Also visit @rajkosto website and github page for more information https://github.com/rajkosto/biskeydump

    As for now few screenshots to get your attention or idea how does it looks like:




    Below is a list of initial prerequsites:

    • Way to get into RCM mode
    • f0f linux exploit + kernel
    • Linux SD Card image (around 10 GB free disk space needed)
    • at least 64GB SD Card (sdxc cards work wery well for me)

    In the meantime download:

    First thing you have to do is getting exploit environment ready. Currently available tools works only under Linux and OSX. As I have nothing to do with OSX you have to compile and prepare everything by yourself. This guide is strictly for using it with so called PC instead of Mac.

    Considering you are using native linux runing on your host computer or virtualised linux running under VMware (VirtualBox was reported as not working) the easiest method to get f0f exploit with kernel without need to compile anything is to get precompiled binaries from git repo:

    root@vmk:~# git clone https://github.com/SoulCipher/shofel2_linux.git
    Cloning into 'shofel2_linux'...
    remote: Counting objects: 66, done.
    remote: Compressing objects: 100% (59/59), done.
    remote: Total 66 (delta 25), reused 21 (delta 2), pack-reused 0
    Unpacking objects: 100% (66/66), done.
    To check if it's working fine execute ./boot_linux.sh script as shown below:

    root@vmk:~# cd shofel2_linux/
    root@vmk:~/shofel2_linux# ./boot_linux.sh
    1) Turn off Switch
    2) Ground right JoyCon rail PIN10 using paperclip JIG or JoyCon mod
    3) Press VOL+ and connect USB cable to the Switch
    Waiting for NVidia APX (Switch in RCM mode).
    Then you have to find your own way to enter RCM mode (using, JoyCon mod, 3D printed JIG, paperclip, whatever.)
    1. Power off your switch first
    2. With JoyCon pin's shorted press VOL+ button
    3. Keeping it pressed connect USB cable to Switch

    It should automatically power up your Switch and you should see NVidia APX device detected (which means you are in RCM mode). If you see Nintendo logo booting it means that you did something wrong and you have to start process again.

    If everything went fine you should see logs as below on your host computer Linux terminal:

    File descriptor: 9
    entry 400168ed
    throwing more
    Performing hax...
    Size: 0x6c68
    URB address: 0x1137220
    URB status: -2
    >>> Switching to cbfs mode...
    sending 0x7000 bytes @0x0
    sending 0x4 bytes @0xffffc
    sending 0x20 bytes @0x20138
    sending 0x18 bytes @0x20100
    sending 0x20 bytes @0x20118
    sending 0x18 bytes @0x20180
    sending 0x20 bytes @0x20198
    sending 0x1c bytes @0x201b8
    sending 0x533e bytes @0x201d4
    sending 0x100000 bytes @0x0
    you have been served
    Detected. Waiting 5 seconds
    config file <conf//imx_usb.conf>
    vid=0x0955 pid=0x701a file_name=switch.conf
    config file <conf//switch.conf>
    parse conf//switch.conf
    conf//switch.conf: syntax error: _direct 0x8e000000
     {image/switch.scr.img:load 0x8e000000,jump_direct 0x8e000000
    Trying to open device vid=0x0955 pid=0x701a
    Interface 0 claimed
    HAB security state: development mode (0x56787856)
    == work item
    filename kernel/Image.gz
    load_size 0 bytes
    load_addr 0x83000000
    dcd 0
    clear_dcd 0
    plug 0
    jump_mode 0
    jump_addr 0x00000000
    == end work item
    loading binary file(kernel/Image.gz) to 83000000, skip=0, fsize=8433b7 type=0
    <<<8663991, 8664064 bytes>>>
    succeeded (status 0x88888888)
    HAB security state: development mode (0x56787856)
    == work item
    filename dtb/tegra210-nintendo-switch.dtb
    load_size 0 bytes
    load_addr 0x8d000000
    dcd 0
    clear_dcd 0
    plug 0
    jump_mode 0
    jump_addr 0x00000000
    == end work item
    loading binary file(dtb/tegra210-nintendo-switch.dtb) to 8d000000, skip=0, fsize=a040 type=0
    <<<41024, 41984 bytes>>>
    succeeded (status 0x88888888)
    HAB security state: development mode (0x56787856)
    == work item
    filename image/switch.scr.img
    load_size 0 bytes
    load_addr 0x8e000000
    dcd 0
    clear_dcd 0
    plug 0
    jump_mode 1
    jump_addr 0x00000000
    == end work item
    loading binary file(image/switch.scr.img) to 8e000000, skip=0, fsize=162 type=aa
    <<<354, 1024 bytes>>>
    succeeded (status 0x88888888)
    jumping to 0x8e000000
    Done. You should see kernel booting on switch soon
    -//- kombos.org -//-
    Then you should see penguins and kernel bootlog on the Switch.

    If nothing happened try again. Actually this method is very accurate for me and other people around. If you have no luck here it might be problem with your USB connection either USB controller or USB cable. It has been proven that USB3.0 on host PC natively running linux work best.

    When you get SD Card image, just unzip it to your hard drive (~8GB), insert your SD Card and run etcher oh host PC

    Select image file and destination drive
    !!! Make sure you've selected proper destination drive, otherwise you can damage your native host OS. !!!



    Then hit Flash button and wait flashing finish.



    When flashing & verification process finish, it's a good time to configure WiFi on your switch.
    Of course you can do that later on Switch using onscreenkeyboard but while you have your SD Card in your host PC it's easier to edit file here.

    Considering you have your host serving exploit linux running anyway, mount the SD card root ext4 filesystem (rootfs), and edit
    etc/NetworkManager/system-connections/Gigaspot file.

    All you need to change is ssid and psk environment in the file.

    You also have to use gparted to resize ext4 rootfs partition on your card so you will have enough space to fit Switch NAND Dump.

    Run gparted on your host PC and choose your SD card in top right corner:


    Choose Resize/Move and move slider over unused space till the end.


    Click Resize and Apply pending changes:

    When partition is resized and your own WiFi is configured, save it, do sync command, and unmount from host OS.
    Finally you can insert your card into Switch and try to boot exploit once again with the actual root filesystem on SD card. To get WiFi working you have to reexploit into linux once again.

    When you get LXDE environment on your switch for the first time, press Menu button on the bottom left corner then Logout button at the bottom and then choose Reboot on newly opened window.



    You don't have to enter RCM mode again, just run ./boot_linux.sh on your host PC once again and reinsert USB cable once again to boot it into Linux with WiFi network support.
    When it booted once again you should see small icon on bottom right part of the screen showing that your Switch is connected to network.


    Now you have to figure out what is console IP address to connect using SSH.

    First you have to run onscreen keyboard:
    Bottom left Menu -> Universal Access -> Onboard

    and terminal windows
    Bottom left Menu -> System Tools -> LXTerminal
    When both running you have to click on terminal window and use onscreen keyboard to execute ip address command:
    Then you're looking for 5th entry which is wlp1s0 interface and line below starting from inet reveals Switch ip address


    Use ssh client of your choice to login to the Switch (I'm using PuttYSSH here) and login to your console over SSH.


    Use Arch3_switch privileged credentials straight, so you will not issue any problems related to user permissions
    Username: root
    Password: root

    (You can still login as unprivileged user alarm:alarm)

    In the meantime you can have window popup with ssh key, just click ok to accept it.
    When you logged in successfully enter privileged user by executing sudo bash command


    When you connect to your Switch make sure that partition has been resized:

    [alarm@kombos ~]$ sudo bash
    [root@kombos alarm]# fdisk -l /dev/mmcblk0
    Disk /dev/mmcblk0: 59.5 GiB, 63864569856 bytes, 124735488 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disklabel type: dos
    Disk identifier: 0x41cd9893
    Device         Boot  Start       End   Sectors  Size Id Type
    /dev/mmcblk0p1        2048    411647    409600  200M  b W95 FAT32
    /dev/mmcblk0p2      411648 124735487 124323840 59.3G 83 Linux <- Notice that size of partition is 59.3GB right now
    [root@kombos alarm]# df -H
    Filesystem      Size  Used Avail Use% Mounted on
    /dev/root        63G  4.1G   56G   7% / <- We are good to go !
    devtmpfs        1.8G     0  1.8G   0% /dev
    tmpfs           1.8G     0  1.8G   0% /dev/shm
    tmpfs           1.8G  488k  1.8G   1% /run
    tmpfs           1.8G     0  1.8G   0% /sys/fs/cgroup
    tmpfs           1.8G  4.1k  1.8G   1% /tmp
    tmpfs           360M  4.1k  360M   1% /run/user/1000
    Using default Arch Linux package manager pacman install dcfldd utility:

    [root@kombos alarm]# pacman -Ss dcfldd
        DCFL (DoD Computer Forensics Lab) dd replacement with hashing
    [root@kombos alarm]# pacman -S dcfldd
    resolving dependencies...
    looking for conflicting packages...
    Packages (1) dcfldd-
    Total Download Size:   0.03 MiB
    Total Installed Size:  0.10 MiB
    :: Proceed with installation? [Y/n]
    :: Retrieving packages...
     dcfldd-    31.5 KiB   242K/s 00:00 [######################] 100%
    (1/1) checking keys in keyring                     [######################] 100%
    (1/1) checking package integrity                   [######################] 100%
    (1/1) loading package files                        [######################] 100%
    (1/1) checking for file conflicts                  [######################] 100%
    (1/1) checking available disk space                [######################] 100%
    :: Processing package changes...
    (1/1) installing dcfldd                            [######################] 100%
    :: Running post-transaction hooks...
    (1/1) Arming ConditionNeedsUpdate...
    So... We almost there. Having all the tools and enough space for the whole 32GB Switch NAND we can simply dump it.

    First, I'd like to warn you that if you fuck up something later you can damage your Switch filesystem permanently. So be extra careful in what you're doing.

    Your Switch NAND is accessible as a block device named /dev/mmcblk1. You can simple check that by executing command which will do nothing else but print partition table on your Switch NAND

    [root@kombos alarm]# fdisk -l /dev/mmcblk1
    Disk /dev/mmcblk1: 29.1 GiB, 31268536320 bytes, 61071360 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disklabel type: gpt
    Device            Start      End  Sectors  Size Type
    /dev/mmcblk1p1       34     8191     8158    4M unknown
    /dev/mmcblk1p2     8192    16383     8192    4M unknown
    /dev/mmcblk1p3    16384    32767    16384    8M unknown
    /dev/mmcblk1p4    32768    49151    16384    8M unknown
    /dev/mmcblk1p5    49152    65535    16384    8M unknown
    /dev/mmcblk1p6    65536    81919    16384    8M unknown
    /dev/mmcblk1p7    81920    98303    16384    8M unknown
    /dev/mmcblk1p8    98304   114687    16384    8M unknown
    /dev/mmcblk1p9   114688   245759   131072   64M unknown
    /dev/mmcblk1p10  245760  5488639  5242880  2.5G unknown
    /dev/mmcblk1p11 5488640 60014591 54525952   26G unknown
    Credits goes to @rajkosto for hint:
    Then simply to create 1:1 dump execute below commands
    Be extremally carefull not to swap if and of parameters! if is input file which is in out case eMMC containing Switch NAND, and of means output file which have to be backup file stored somewhere on your SD Card!

    dcfldd if=/dev/mmcblk1 of=/home/alarm/SwitchNAND_dump.bin bs=512
    dcfldd if=/dev/mmcblk1boot0 of=/home/alarm/SwitchBOOT0_dump.bin bs=512
    dcfldd if=/dev/mmcblk1boot1 of=/home/alarm/SwitchBOOT1_dump.bin bs=512

    After around 5 minutes (well it depends on your SD card speed) you've got your NAND dumped !

    Just as a extra step I personally recommend generating md5 checksum after completion and generate checksum to compare from /dev/mmcblk1.
    If they differ, that means something went wrong and the files are differ. Unfortunately getting md5 sum from such a big file will take some time so you have to be patient. Just if you want to be sure everything went ok and you have working dump I recommend to do that.

    [root@kombos alarm]# md5sum /home/alarm/SwitchNAND_dump.bin
    3240be0611dbe624c481f1df23fba894  /home/alarm/SwitchNAND_dump.bin
    [root@kombos alarm]# md5sum /dev/mmcblk1
    3240be0611dbe624c481f1df23fba894  /dev/mmcblk1
    (do the same for BOOT0 & BOOT1 as well)

    Another golden tips from @cherryduck about saving space when you manually dumping NAND's on smalled cards.

    There is an alternative method for transfering files straight to your Host PC over network. However in my case WiFi drivers are very unreliable and it's basically easier and faster for me to transfer them on the SD Card.

    Credits go to @cherryduck
    Voila ! If checksums match you've just dumper your Switch NAND. The last thing you have to do is to transfer NAND backup file somewhere and store it securely. You can do it either through network using WiFi and WinSCP or just shutdown Switch remove card from there, mount it under linux and copy SwitchNAND_dump.bin file to other device for safety.

    Using WiFi to transfer 30GB NAND Dump is pain in the ass so I would recommend to power off your switch, remove card and just copy it over using your host OS.

    Just remember, that the NAND dump you just made contain files on it's filesystem you currently have on your switch. If you add something, buy a new game, make a save or upgrade firmware it doesn't mean that you would be able to downgrade Switch FW using this method or anything like that. The whole content of the NAND is **encrypted**

    It's more likely a backup when you going to do some changes on your NAND, or for further research.

    If you want to build it yourself there is a lot of information around. Very good thread on gbatemp forums about getting linux working on Switch:
    Original fail0verflow blogpost:
    Last edited by kombos, Apr 28, 2018
  2. Taffy

    Taffy If specified, this will replace the title that...

    Mar 3, 2017
    United States
    Hooray, now to find a way to store a 30+GB file! Whee!

    jokes aside, woohoo.
  3. gabru

    gabru Advanced Member

    Aug 22, 2016
    Can't wait for the "wow and nowadays we just go to the gallery and press on a corrupted IMG to get the nandbackup and cfw on switch" within 2 years
  4. kombos

    kombos GBAtemp Regular

    Apr 24, 2018
    And video guides on youtube :}
  5. Xyphoseos

    Xyphoseos Hack or no games

    Jun 29, 2016
    where I get it *,?
  6. BelmontSlayer

    BelmontSlayer Pokémon Princess

    May 11, 2006
    Memememe Island
    Excellent guide, been waiting for something like this. Thanks!
  7. kombos

    kombos GBAtemp Regular

    Apr 24, 2018
  8. TR_mahmutpek

    TR_mahmutpek medic

    Jul 28, 2015
    Dayum... That' s some hardwork..

  9. snoofly

    snoofly GBAtemp Advanced Fan

    Aug 18, 2015
    United States
    Nice job dude.
    So great to see everyone chipping in with stuff to try out.
    It really is in my opinion the most fun part of the scene - the scenes golden age you could say as everything is fresh and new.
    People trying new flavours of Linux etc, albeit finding and ironing out the cracks along the way. That Tuto thread is great.
    Just fun stuff to read up on and try out yourself.
    Can't wait to see what Atmosphere will bring.
    Won't be long before the loaders come and the P word dominates and the whole vibe will change.

    Anyhoo, I ramble on..I had to laugh at this line though:

    Be extremally carefull ...

    As the memes go, in before a brick occurs... :)
    kombos likes this.
  10. Darklinkreturns

    Darklinkreturns GBAtemp Regular

    Feb 12, 2014
    United States
    The only SD cards I have are all SDXC, which I cannot use on my switch without updating to 5.0.2. am I SOL unless I update?
  11. kombos

    kombos GBAtemp Regular

    Apr 24, 2018
    Weird. You don't have to update anything. I'm using SanDisk 64GB sdXC and it works flawlessly for me on 3.0.1 (which don't even boot in that case because you are using liunx)
  12. Maximilious

    Maximilious *whistles his distinct tune*

    GBAtemp Patron
    Maximilious is a Patron of GBAtemp and is helping us stay independent!

    Our Patreon
    Nov 21, 2014
    United States
    The driver is a separate download, BUT it will cause the FW to update to latest version when it's downloaded/installed. You can format your card with guiformat using FAT32 and your SDXC will still work fine without the need to update/install the driver.
    d4mation likes this.
  13. bedbug1226

    bedbug1226 Advanced Member

    Dec 1, 2014
    United States
    Looks awesome kombos. Thanks for your work.
  14. aut0mat3d

    aut0mat3d GBAtemp Regular

    Mar 15, 2017
    The dumping is done with Linux running on the switch, so exfat should be no problem.
  15. SomeSHET

    SomeSHET Member

    Apr 27, 2018
    United States
    Can we use this method with an SD card that is already in use by the Switch? I only have a 256 gb SD card, but my Switch is using it to store downloaded games. Can we just shrink the partition that the Switch is using to store the games and create a new ext4 partition for linux, and have the Switch be able to read the SD card normally and still have the linux filesystem on the SD card as well?
  16. aut0mat3d

    aut0mat3d GBAtemp Regular

    Mar 15, 2017
    Will try that the next days, thanks a lot.
    Is there a known way to decrypt the dump?
    I hardly want to salvage a gamesave of my sons console..
  17. TerraPhantm

    TerraPhantm GBAtemp Fan

    Jul 27, 2007
    United States
    Does the USB port work in Linux? Can I dump the nand to my USB-C flash drive instead of an SD card?
  18. kombos

    kombos GBAtemp Regular

    Apr 24, 2018
    Not yet.
  19. isoboy

    isoboy GBAtemp Advanced Fan

    Dec 23, 2016
    United States
    I would totally do this if I wasn't dumb as hell.
    Deletedmember331810 likes this.
  20. ballcity

    ballcity Member

    Apr 16, 2016
    United States
    Thanks kombos. This is awesome, worked perfectly. Hashes matched between the NAND md5sum and the binary dump, woot woot. Now if only we could decrypt it... :mellow:

    EDIT: On an unrelated note, does anyone know if you can put this Linux distro to sleep and such? And/or does charging work / is that something I should be worried about?
    Last edited by ballcity, Apr 27, 2018
    kombos likes this.