cesura / nxsh Goto Github PK

Would you also add a password to protect it?

i recommend storing nxsh's files in the switch folder along with nxsh.nro in a subfolder so like /switch/nxsh/nxsh.pw and /switch/nxsh/nxsh.nro

The tool hangs when loading alongside sys-ftpd.

System OS Version 13.0.0
Atmosphere 1.1.1

Launching via hbmenu immediately results in the standard crashed app screen, with a close button that takes you back to the home menu.

Now that libnx has hardware accelerated crypto stuff, including sha256, I think it makes more sense to use sha256 for the password checking. Though, it wouldn't make too much of a difference since to find out the hash of the password, you'd have to have a level of access that means an attacker could already have done nasty stuff to your Switch.

I'm just making this issue to make sure there's no reason @Cesura specifically used MD5

I would've added this in the latest commit, but I would largely be using code from Atmosphere, which has a GPL license, which I think means we would have to switch ours to GPL, which I'm fine with, but it requires every contributor's (@Cesura) consent, which is why I didn't include it in the last commit.

Aside from the license issues, we would also have to detect the user's CFW, since rebooting to a payload only works on Atmosphere. I would prefer everything to be CFW agnostic, but rebooting to a payload is pretty useful.

Can we make the console feel like bash? And print out the log on the switch's screen too

Missing curl

Sysmodules have moved to using pm loading i think this is the only kip i still have.

I've been working on a proof of concept for loading NROs through an NRO for the last few days. You can see it here. I'm making this issue so that I can dump my knowledge here and for the possibility of help.

The way the homebrew menu loads NROs is by using envSetNextLoad and then returning. This simply tells hbloader what NRO to load next, and requires the current NRO to exit. This would not be ideal for nxsh, where you would want to keep the connection while loading an NRO so that you could still send commands afterwards. It also would return to hbmenu after the NRO is loaded, unless the loaded NRO also uses envSetNextLoad. So, in short, this won't work for us.

hbloader never stops running until you close whatever it's running though (i.e. the album). This seems like a step up from using envSetNextLoad, but it also has its drawbacks. If nxsh were to use my proof of concept as is, it might be able to launch an NRO and keep running, but it would never be able to stop launching NROs. It could launch itself after it's done launching NROs without any assistance, but there would need to be some way of detecting that an NRO just launched so that the user doesn't have to establish a connection and enter their password again. That seems hacky though, and is worse than envSetNextLoad since we would be starting another instance of nxsh without exiting the first one. There is also the fact that I was unable to figure out how to not override the libnx functions __appInit, __appExit, and __libnx_initheap. It might not end up being a big deal, but I think it would be cleaner if that weren't necessary.

So, if we could get hbloader to exit, that would be great. But it's not that simple. In fact, hbloader is so adamant about not exiting that it calls the error 2347-0008 if you somehow get it to stop launching NROs (which I have not been able to fully do). The reason hbloader never returns is that it calls loadNro, which eventually calls nroEntrypointTrampoline (marked as a function that doesn't return so the compiler knows no code after it can be reached), an assembly function. That function resets the stack, calls the NRO, saves the return value of that NRO, resets the stack again, and calls loadNro, creating an infinite loop. If you return from loadNro after it's been called from nroEntrypointTrampoline though, you get an error, since it's simply branched to, and not branched with a link. But if you branch with a link, you still get an error, and I have tried everything I can think of (storing the link register at the beginning so that we can return there once loadNro returns, saving the stack to a buffer on the heap and loading that buffer back in once nroEntrypointTrampoline returns, among some other small things that didn't work), and the closest I have gotten is getting to one printf after nroEntrypointTrampoline, and then it gives up with a 2168-0002 error. If you call exit from nroEntrypointTrampoline once loadNro returns, then it will return to the normal hbloader, but then we might as well be using envSetNextLoad, as nxsh would have to exit once it's done loading NROs.

There is also the problem of the kip version. If loadng NROs through a kip is even possible, I don't think there would be enough memory. As I mentioned in #9, sysmodules have a pretty limited memory, and many NROs will extend over the allotted memory for nxsh (2.5 MB). And even if you could put the NRO on the heap, it would have basically no heap left for itself. All that pretty much ensures NRO loading would be exclusive for the NRO version.

There is also the smaller problem of what to do with stdio. Ideally, nxsh would be able to redirect stdio to the socket so that the user could see all the printf's and stuff, but looking at the code for nxlink and twili, it seems like redirecting the stdio has to be explicitly done by the loaded NRO. nxsh could do it like twili does, by having a service running that listens for NROs trying to link their stdio, but that seems like a lot of overhead for something like nxsh.

So there are a few options: we could settle for simply using envSetNextLoad at the cost of having to exit, we could do it the way hbloader does it so that we never have to exit, but at the cost of never being able to exit, or we could wait until I or someone else figures out how to make my proof of concept exit normally without throwing an error, and cannibalize that. Obviously the last one is most ideal, but that could simply be impossible, so I think the next best thing would be to use envSetNextLoad, or possibly a combination of envSetNextLoad and my proof of concept, where my proof of concept always loads nxsh (maybe from /nxsh/nxsh.nro ?) and then nxsh can use envSetNextLoad to tell my proof of concept to load another NRO before eventually loading nxsh.

Is there any possible way to transfer files?

I saw another issue that wanted to transfer files in a specific way, does that imply that there is another functional way?

Is there any homebrew that allows for files to be sent over network to a Switch, via command line?

it would be nice to be able to use telnet/ssh to make files with commands like touch and echo, and to edit them with something like nano. Or use > and >> to have the output of a command be made into a new file or append it to an existing one.

i would really like to see some way to get acces to temperature sensors in the switch

With Android devices, you can use adb to push files to the device. A similar feature for nxsh could be an interesting and useful alternative to a full ftpd.

If nxsh's cat implementation supported reading from standard input to files, you could potentially script this as something like the following:

$ (echo "cat - > file_on_switch.txt"; cat file_on_pc.txt) | nc 192.168.1.2 5050

Unfortunately, it doesn't seem like nxsh cat supports this yet, nor did I spot an obvious way to read input from a duktape script.

Switch on 5.1.0, PC on Windows 10 using PuTTY - the shell works well but each time I enter a command (or enter the shell) I have an "Error: command not found" message :

https://puu.sh/BV22U/ca84966245.png

this does not compile against libnx 3.0.0
https://gist.github.com/fennectech/69fc12b6e9a41411916577832b426c10

Switch on 10.2.0. libnx master. Built from source.

nxsh loads but fails to bind to port 23

This would give a few advantages:

• We would be able to reduce a bit of code for the sysmodule version, like some functions that would be handled by the CFW.
• We wouldn't have to wait 10 seconds in __appInit and hope that everything we need has been initialized
• We wouldn't be limited by the maximum file size of kips (note: this doesn't mean we would be able to use more RAM, just take up a larger portion of the SD card)
• We would be able to know where on the SD card our files are stored, if that ever matters in the future
• Nxsh could theoretically be turned on and off

I wanted to see your (@Cesura) opinion on this before I start working on it. If you think we should switch, I could probably get it done pretty quick

Would it be possible to add a service management utility such as found on linux to debug or manually disable unwanted/needed services?

I recomend not displaying the charicters when the user enters their password Its usually done to foil shoulder surfers but with telnet its like making your lock out of paper.