Tutorial  Updated

How to dump Switch NAND using Linux

Intro

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:
https://drive.google.com/open?id=1zBct-YVVBPYLQN5G9NA-YKUjaKdOXt2p

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:
dumper1.png


dumper2.png


dumper3.png



Requirements

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:

Code:
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:

Code:
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:

Code:
File descriptor: 9
b'400205050000000841763c6401101062'
entry 400168ed
throwing more
Performing hax...
Size: 0x6c68
b'820000000000686c'
b'0200000000000000000000000000000080d3160100000000716c000000000000000000000000000000000000000000000f0f00000000000000'
URB address: 0x1137220
URB status: -2
b'CBFS\n'
>>> 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
load_addr=83000000
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
load_addr=8d000000
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
load_addr=8e000000
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.
penguins.jpg


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

etcher1.png



etcher2.png


Then hit Flash button and wait flashing finish.

etcher3.png


etcher4.png


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.

Code:
[connection]
id=kombos
uuid=d58b2c66-a1cd-4ac3-b513-4773dae8d0de
type=wifi
permissions=user:alarm:;
timestamp=1524733286
[wifi]
mac-address-blacklist=
mode=infrastructure
seen-bssids=30:B5:C2:08:20:29;
ssid=Your_Access_Point_Name
[wifi-security]
key-mgmt=wpa-psk
psk=Pa$$w0rd
[ipv4]
dns-search=
method=auto
[ipv6]
addr-gen-mode=stable-privacy

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:

gparted1.png


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

gparted2.png


Click Resize and Apply pending changes:
gparted3.png


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.

reboot1.jpg


reboot2.jpg


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.

network.jpg


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
onboard.jpg


and terminal windows
Bottom left Menu -> System Tools -> LXTerminal
lxterminal.jpg

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

ipaddress.jpg


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

putty1.png


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

putty2.png


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

Code:
[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:

Code:
[root@kombos alarm]# pacman -Ss dcfldd
community/dcfldd 1.3.4.1-5
    DCFL (DoD Computer Forensics Lab) dd replacement with hashing
[root@kombos alarm]# pacman -S dcfldd
resolving dependencies...
looking for conflicting packages...
Packages (1) dcfldd-1.3.4.1-5
Total Download Size:   0.03 MiB
Total Installed Size:  0.10 MiB
:: Proceed with installation? [Y/n]
:: Retrieving packages...
 dcfldd-1.3.4.1-5-aa...    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

Code:
[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
Disk identifier: 4EXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
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:
You should also dump /dev/mmcblk1boot0 and /dev/mmcblk1boot1 into separate files (they are 4MB each) because they are not part of the main 29GiB area (which is /dev/mmcblk1), and contain very device specific data that you would be very sore if you lost.
(Also, boot0 is needed to extract tsec fw out of, in order to run payloads like biskeydump right now)
All the other partitions mentioned by dump_bis.js are in the main 29GiB area, so no need to worry about those.
(PRO TIP: if your dumping destination is an ext4 partition for the large area, use a transfer program that supports sparse writes (like ddrescue with --sparse option) to make your 29GiB dump use up much much less space on disk)

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!

Code:
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.


Code:
[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.
You should be able to run something like:

dcfldd if=/dev/mmcblk1 | gzip -c --fast | dcfldd of=/root/nand.bin.gz

to dump locally without taking up a buttload of space and needing a bigger SD card. Of course you can't directly compare checksums, but you could uncompress the image on your main PC and run a checksum there. Other people's compressed images will be different sized to mine depending on how much they have on their internal NAND. My digital games are installed to my SD card. Check the Data Management section in the Switch settings to get an idea of our big your final compressed image will be.


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
You don't need a large SD card to dump this, you can do it via SSH.

Run the below on the Switch as root, changing the bolded items to match your own details of course:

dcfldd if=/dev/mmcblk1 | gzip -c --fast | ssh user@ip 'dcfldd of=/directory/on/remote/machine/nand.bin.gz'

My compressed dump came to 1.24GB, and works perfectly fine when uncompressed. You might be able to do this and specify a local directory on the Switch instead of SSHing into a remote computer if you have a smaller SD card, but I decided to send it straight to my PC as that's where I'll be storing and accessing the NAND dump.

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:
https://gbatemp.net/threads/quick-tuto-how-to-boot-linux-on-your-switch.501918/
Original fail0verflow blogpost:
https://fail0verflow.com/blog/2018/shofel2/
 
Last edited by kombos,

NightsEkim

Well-Known Member
Member
Joined
Mar 28, 2015
Messages
166
Trophies
0
XP
316
Country
United States
yeah, still haven't been able to get v3 to boot with wifi

Has anyone been able to get wifi working with the new image?

I have I had to do a trick to pick up my wifi though, it wouldn't connect just by tapping it, but I had that issue on my linux netbook as well, what you do is you add a hidden wifi network, and (if you're using WPA2 on your router) select wpa2 on the dropdown for security, enter your wifi name (case sensitive) and password (case sensitive) and boom it connects. It's worked through reloading linux as well.
 

subcon959

@!#?@!
Member
Joined
Dec 24, 2008
Messages
5,845
Trophies
4
XP
10,108
Country
United Kingdom
I flashed the sd card with arch3_swich.img and resized the ext4 partition to full (my sd card is 128gb), after that I inserted the card to Switch and do the hack, it just keep stuck at "Timeout waiting for hardware interrupt." , did I do something wrong in the process?
I have the same issue, also using 128gb card. Gonna try something smaller tonight as the previous image worked well on 32gb card.

I have the same issue, also using 128gb card. Gonna try something smaller tonight as the previous image worked well on 32gb card.

@darkomega9408 It just occured to me that it could also be related to the usb port not supplying enough voltage. Probably not, but worth keeping in mind.
 
  • Like
Reactions: darkomega9408

darkomega9408

Member
Newcomer
Joined
Mar 14, 2018
Messages
8
Trophies
0
Age
45
XP
227
Country
United States
I have the same issue, also using 128gb card. Gonna try something smaller tonight as the previous image worked well on 32gb card.



@darkomega9408 It just occured to me that it could also be related to the usb port not supplying enough voltage. Probably not, but worth keeping in mind.
Thanks subcon959, tonight I will try other ports as well.
 

kombos

Well-Known Member
OP
Member
Joined
Apr 24, 2018
Messages
140
Trophies
0
Location
Universe
XP
167
Country
Ukraine
My NAND dump only came to 4.2MB that doesn't seem correct, i used a fresh pull of the git into /opt/ did you implement compression on the bin file?
I only have my save for zelda stored on the switch mind.

Code:
[root@kombos /]# cd /opt/sw_nand_dump/
[root@kombos sw_nand_dump]# ./sw_nand_dump.sh
 ___
|[_]| Nintendo Switch NAND dumper
|+ ;|  -//- [email protected] -//-        
`---' -=-=-=-=-=-=-=-=-=-=-=-=-=-

Checking if your SD Card root partition can fit NAND backup:
You have 115 GB free space on your SD ! It's enough to fit NAND dump.

Checking if enhanced version of GNU dd is installed:
Yes. We are going to use /usr/bin/dcfldd then

We are going to execute below commands now:
dcfldd if=/dev/mmcblk1boot0 of=/root/SwitchBOOT0_dump_20180428_201958.bin bs=512
dcfldd if=/dev/mmcblk1boot1 of=/root/SwitchBOOT1_dump_20180428_201958.bin bs=512
dcfldd if=/dev/mmcblk1p1 of=/root/SwitchNAND_dump_20180428_201958.bin bs=512

8192 blocks (4Mb) written.
8192+0 records in
8192+0 records out
BOOT0 Done.
8192 blocks (4Mb) written.
8192+0 records in
8192+0 records out
BOOT1 Done.
7936 blocks (3Mb) written.
8158+0 records in
8158+0 records out
NAND  Done.

It took 0 seconds to dump your BOOT0, BOOT1 & NAND

  ((
   ))   We are going to generate checksums of NAND and NAND dump.
  |~~|  It will take a while.
 C|__|  Make a coffe and be patient.

 BOOT0  a0f0614044541ebd3c668bac447c4cca
 DUMP0  a0f0614044541ebd3c668bac447c4cca
 BOOT1  a876f650792d6e0f8a4c972e99dd8460
 DUMP1  a876f650792d6e0f8a4c972e99dd8460
 NAND   6256b895ecedbb400d1bf020d6866e75
 DUMP   6256b895ecedbb400d1bf020d6866e75

It took 0 seconds to generate MD5 checksums
Checksums status: OK

Hmm. Take a look at script I think for some reason it’s dumping small partition rather than whole band. It can be leftover from testing. Script is I /opt folder. Or just do git clone straight from the repo, you should get correct one.
 

aut0mat3d

Well-Known Member
Member
Joined
Mar 15, 2017
Messages
212
Trophies
0
XP
568
Country
Australia
hmmmm thats odd:
When trying to resize the ext4 partition e2fsck quits with:
unsupported feature(s): metadata_csum

Never faced that Problem on a ext4 partition. I am using LInux Mint 18.3, tried also a more recent e2fsck (1.43.4-2)
 

kombos

Well-Known Member
OP
Member
Joined
Apr 24, 2018
Messages
140
Trophies
0
Location
Universe
XP
167
Country
Ukraine
Hmm. Take a look at script I think for some reason it’s dumping small partition rather than whole band. It can be leftover from testing. Script is I /opt folder. Or just do git clone straight from the repo, you should get correct one.

Actually script was dumping /dev/mmcblk1p1 instead of /dev/mmcbkl1 . For these who experience this issues do

Code:
cd /opt/sw_nand_dump
sed -i -e 's/mmcblk1p1/mmcblk1/g' sw_nad_dump.sh

Or get a fixed clone from repo

Code:
git clone https://github.com/SoulCipher/sw_nand_dump.git

Sorry bout that ! I was extremely tired & busy yesterday.

Actually you can use any other switch linux distro with that scrip if that works for you. I just used gparted on my Host PC running linux to extend partition and it works fine all the time.

Cheers
Soul
 

aut0mat3d

Well-Known Member
Member
Joined
Mar 15, 2017
Messages
212
Trophies
0
XP
568
Country
Australia
hmmmm thats odd:
When trying to resize the ext4 partition e2fsck quits with:
unsupported feature(s): metadata_csum

Never faced that Problem on a ext4 partition. I am using LInux Mint 18.3, tried also a more recent e2fsck (1.43.4-2)
OK, got it with gparted live-CD. weird
 

Centergaming

Well-Known Member
Member
Joined
Apr 17, 2016
Messages
695
Trophies
0
XP
923
Country
United States
Anyone have insight as to what's going wrong here?

View attachment 121699

Initial step seems to work fine. Then the Switch reconnects as a "NVidia download gadget", and then the script hangs for a little bit until the OS force disconnects the device. I'm doing this in a virtual machine. I'm using a USB 3 USB-C->A cable, vmware is set to enable USB3, and xhci appears to be enabled based on "lsusb -t"

For whatever it's worth fusee works.

Are you using Windows or Mac for the VMware? Do you have USB 3.0 ports and USB 3.0 C->A cable? Make sure you have installed all the required dependancies.

--------------------- MERGED ---------------------------

OK, got it with gparted live-CD. weird

You don't have to use gparted live-CD, if gparted automatically crashes in Ubuntu, try this command: "xhost +local:" This worked for me, don't know if it would work for others.
 

Centergaming

Well-Known Member
Member
Joined
Apr 17, 2016
Messages
695
Trophies
0
XP
923
Country
United States
Has anyone tried this Joy-Con driver for emulators? https://github.com/riking/joycon

Also, I'm going to look into the audio driver in the next few hours. Has anyone tried yet so I have a better starting point?

Besides that, we pretty much just need USB working for an OTG adapter and an Android style keyboard would be nice. I have an iMac keyboard and mouse connected via Bluetooth at the moment.

Edit: This should come in handy: http://developer.download.nvidia.co...odUZqb6yshX7pJHIa5eqJwimxqXtggJ121LgVz9r4KkVQ

This should help if you don't have it (audio driver package, automatic download): https://developer.nvidia.com/embedded/dlc/l4t-jetson-tx1-driver-package-28-2-ga
 
  • Like
Reactions: gbazone and kombos

darkomega9408

Member
Newcomer
Joined
Mar 14, 2018
Messages
8
Trophies
0
Age
45
XP
227
Country
United States

TerraPhantm

Well-Known Member
Member
Joined
Jul 27, 2007
Messages
498
Trophies
0
XP
680
Country
United States
Are you using Windows or Mac for the VMware? Do you have USB 3.0 ports and USB 3.0 C->A cable? Make sure you have installed all the required dependancies.

Tried it on my mac. Can try a windows pc later. USB 3.0 ports with a USB 3.0 cable (confirmed by using the same cable on a USB-C SSD).
 

cherryduck

Well-Known Member
Member
Joined
Jul 1, 2007
Messages
331
Trophies
1
Age
34
Location
The far side of the moon
Website
Visit site
XP
1,616
Country
Is there a reason why the backup nand is so large because 32gb is quiet a lot, is it because there’s no program made to only extract only the important stuff for a reduced size like the 3ds?

It does a direct read of the entire nand, if you run it through gzip as outlined near the bottom on the first post you'll get a much smaller compressed image which you can extract elsewhere.
 

TheMCNerd2017

Well-Known Member
Member
Joined
Jun 21, 2017
Messages
200
Trophies
0
XP
514
Country
United States
Actually you can open terminal on your switch and run command from there using on screen keyboard
OK, thanks for telling me. I have very unreliable internet where I live(entire neighborhood is hooked up via phone lines from the late 1990s) which makes SSH not an option for me.
 

TerraPhantm

Well-Known Member
Member
Joined
Jul 27, 2007
Messages
498
Trophies
0
XP
680
Country
United States
View attachment 121737

Ok make sure in VMware that these options are checked.
Yeah that's what I've got. I don't think it's a USB issue since Linux sees the ports as xhci and I am able to launch fusee payloads.

I think I'll hold off anyway since it seems like Linux is fucking up something with the battery management for a few people.
 

Tilde88

Well-Known Member
Member
Joined
Feb 16, 2015
Messages
295
Trophies
0
Age
36
XP
1,068
Country
United States
OK, got it with gparted live-CD. weird
You need to replace the e2fsck binary in /sbin (iirc, could be /bin, wherever dir its in). Im on 16.04, and couldnt get it to resize any of these images. was because gparted calls the system e2fsck. download the bionic release (1.44 i think) and replace in /sbin. worked like a charm. 16.04 is capped at v1.43 or something similar. sorry about fuzzy details... long night. youll get it though
 
  • Like
Reactions: aut0mat3d

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
    Psionic Roshambo @ Psionic Roshambo: Lol