Can you run Kismet on the QNAP TS-231P-US?

The ethernet is faster then the USB adapter I’m using on the Pi. It has USB 3.0 too. No adapter will make it faster on the Pi, it’s only 2.0.

The CPU is probably better on that NAS too. I could get a RockPro64, that can run Kismet. But I’m to lazy to assemble a NAS, and the QNAP doesn’t cost much more.

Copying almost 20 GB from the Pi to my computer, using FileZilla. Might be causing some packet loss. SSH is encrypted, so probably using the CPU. Nope, not as much CPU as Kismet.

Why is the download speed so low then? 10.1 GB left. Got to delete all the stuff after I download it. Delete it from the Pi so it doesn’t run out of space.

There’s an App center for it. Not seeing Kismet.

Is the OS using Linux? That is the kernel. If so, you might be able to compile it, you’ll probably need the driver too though.

The one bad thing about iOS

It’s easiest to make iOS apps on a Mac. Don’t have a Mac, so if I wanted to make an app, I can’t.

Not enough money to buy a Mac mini. Got to keep at least $200 in my savings, so I can pay PayPal back, when the scammers dispute the charge. Claiming whatever they claim.

Why do I need SX OS anyways?

I don’t use my Switch. I just update SX OS on it, but don’t actually play games on it.

I should sell it, problem is you can’t do that without getting scammed.

The scammers keep on buying stuff. I should leave feedback for one of them, that says possible scammer, search their address on Google, they use the wrong zip code.

How to restore your SX OS EmuNAND files to your hidden partition

If using Linux, you can use dd. Oh and the sysNAND version doesn’t matter, it won’t boot if it’s to low, but if your EmuNAND is updated, it’ll boot right up.

sudo dd if=boot0.bin of=/dev/sdj bs=1024K count=4 seek=1024 oflag=seek_bytes status=progress
sudo dd if=boot1.bin of=/dev/sdj bs=1024K count=4 seek=4195328 oflag=seek_bytes status=progress
sudo dd if=full.00.bin of=/dev/sdj bs=1024K count=4294836 seek=8389632 oflag=seek_bytes status=progress
sudo dd if=full.01.bin of=/dev/sdj bs=1024K count=4294836 seek=4303225856 oflag=seek_bytes status=progress
sudo dd if=full.02.bin of=/dev/sdj bs=1024K count=4294836 seek=8598062080 oflag=seek_bytes status=progress
sudo dd if=full.03.bin of=/dev/sdj bs=1024K count=3213230 seek=12892898304 oflag=seek_bytes status=progress

Those are the commands I used. The boot0 and boot1 is probably the same for everybody, you might not need the bs and count.

To get the seek value you add the previous file size in bytes to the previous seek, so for full.00.bin the previous was 4195328, and the file size of boot1.bin is 4194304, 4195328 + 4194304 =  8389632.

You could make a Python script to do it easily.

Copying all the data to the TXNAND partition. That’s the non hidden partition.

To get the first seek, for boot0.bin, I used a hex editor, wxHexEditor can open drives. Somebody on GBAtemp said offset 3, which is 1024 in bytes.

You also might want to backup the first 30 GB on the micro SD card, so if you screw up, you don’t have to recreate it.

sudo dd if=/dev/sdj of=EmuNAND.bin bs=1024M count=30 status=progress

Oh and /dev/sdj will probably be different, you can get it by “sudo fdisk -l”.

It’s funny, the one time I backup part of the micro SD card, it works.

Somebody else has instructions on GBAtemp, they put all the files in one big file.

How can you tell when anything ends in a hex editor? Oh wait, wxHexEditor might. I like one file at a time better, because you have to use seek.

Might not work if you have more full files then me, you might need their method. Or maybe macOS has dd limitations.

Purple screen

When trying to boot my EmuNAND on my Switch. I tried restoring my EmuNAND files to the hidden partition. Looks like it didn’t work.

The funny thing is,  I didn’t wipe out the non hidden partition.

Might mean the GPT is fucked, except it’s using MBR. Probably copied boot0 and 1 to the wrong location.

Formatted the card, remaking the EmuNAND. Then I’ll back up the entire SD card before messing with it again. Or at least the first 30 GB or whatever.

The non hidden partition isn’t important, all that’s on it is boot.dat and license.dat. And a Nintendo folder if I boot it. I don’t need the blank Nintendo folder, I backed up the one that matters.

Doesn’t look like hidden partition EmuNAND works, just recreated it, and I get a black screen.

Is it super slow at the first boot? Maybe.

Team Xecuter have posted on their forum that 2.4 doesn’t run on OFW 4.1.0 and below. you can check it out at the link below…


Good job TX. So the EmuNAND won’t work either if I figure out how to restore my backup?

Use count instead of bs, bs is how much it copies at a time. That’s kind of what I thought -bs did. You need bs too, otherwise it’ll copy way more then 30 GB. “bs=1024M count=30”, might do the trick.

Social Security went up again

Seems to go up every year. That means my rent is going up sometime next year too.

On another note, I took a nice size dump before my shower.

She doesn’t think they are scamming me

Look up that address, and you’ll see scammers use that address, the second line being different, but the wrong zip code for the address.

Bless is better then wxHexEditor

It shows the decimal, you need that for dd. So the new method, will be copying the entire drive to a file, and opening it with Bless. You can’t open the device directly.

Not sure that’ll work though. Probably won’t work, the file will be over 200 GB.

Actually, use wxHexEditor. The offset is a decimal. I almost got it, once the boot0 is identical to the backup, I’ll try writing it. Lucky for me, I have a backup of the original boot files. Just reading from the specified offset, you need “iflag=fullblock,skip_bytes” in the dd command.

There we go, it might be the same now.

sudo dd if=/dev/sdj of=boot0.bin bs=4194304 skip=1024 count=1 iflag=fullblock,skip_bytes

Change if to boot0.bin and of to /dev/sdj, to write. Got to check the shasum first. No need to do a full backup, just the parts you are writing, you probably need to change skip to seek too. The checksums don’t match.

Eh close enough, they look the same. I have a backup anyways. Now how do I get the next offset? Does it matter if there’s a bunch of 0s before it?

It’s probably semi f’d. Supposed to put seek_bytes when writing. Yup, blue screen.

Black screen that time. I should restore my backed up boot0.

Nope, got to remake the EmuNAND. Can I make it myself, with the RAW NAND backup? Don’t want to plug Switch in. And if I do it on the computer, I can go to bed. I think I wiped out some MBR info maybe. Except, I can still mount it.

I give up. I’ll try remaking the EmuNAND from my complete backup. First copy the beginning of the drive, including the TX header. Then write everything one by one. Actually, you might not need to copy the beginning. Unless you decide to be a weak man and make a backup. If I can’t get it to work, I’ll just recreate the EmuNAND, and update the EmuNAND again, restore my saves using Checkpoint.


You need Atmosphere for that, boohoo.

Streams PC games to the Switch. Wouldn’t use it though, it over clocks the Switch. Good way to fry it.