Hacking libnx now public

  • Thread starter Thread starter TheCyberQuake
  • Start date Start date
  • Views Views 26,308
  • Replies Replies 96
  • Likes Likes 14
It doesn't "work" with any firmware. This isn't to run homebrew, it's merely the libraries used to write and build homebrew. Even with this we would still need code execution and an entry point, which isn't currentely available (at least not publicly).
It will work on whatever firmrwares we have code execution on.
Well, I am pretty sure the private builds of CTU are capable of debugging NRO binaries.
 
It doesn't "work" with any firmware. This isn't to run homebrew, it's merely the libraries used to write and build homebrew. Even with this we would still need code execution and an entry point, which isn't currentely available (at least not publicly).
It will work on whatever firmrwares we have code execution on.
Understandable, I will probably get a Switch from the 1st wave made in March made so I don't know on which firmware would that even be or if the games ask for a newer firmware if they are new like the 3DS and Wii U did and if it really is the wisest decision to keep the console on 3.0.0 from what I'm reading in here being like 5.3.2 on Wii U some time ago.
 
Heh I'll believe homebrew when I see it. It took other consoles forever to have homebrew so it must be the case here. Also a mod this thread should be closed.
/s
 
  • Like
Reactions: Deleted User
Someone asked this before but it was never answered.

`Makefile:9: /opt/devkitpro/devkitA64/base_rules: No such file or directory`

Been searching the internet for a while and can't figure out where to get base_rules from. It's not in devkitpro's sourceforge.

EDIT: Found it! They're in libnx's buildscripts folder.
 
Last edited by BtheDestroyer,
Someone asked this before but it was never answered.

`Makefile:9: /opt/devkitpro/devkitA64/base_rules: No such file or directory`

Been searching the internet for a while and can't figure out where to get base_rules from. It's not in devkitpro's sourceforge.

EDIT: Found it! They're in libnx's buildscripts folder.

Run "make install" from the libnx top folder after installing devkitA64 and setting thr DEVKITA64 variable, end everything will be copyed in the right position. Beware that there are a couple of things to be fixed (already sent a PR)
 
  • Like
Reactions: peteruk
Again, no one in this thread has stated anything about backup loaders. So far we've only talked about homebrew.
BULLSHIT mate that's what it's always about! no one gives a rats ass about actual homebrew. all people care about is can't wait to play ma pirated gaems :rofl:
 
Last edited by Bladexdsl,
Run "make install" from the libnx top folder after installing devkitA64 and setting thr DEVKITA64 variable, end everything will be copyed in the right position. Beware that there are a couple of things to be fixed (already sent a PR)

Yeah the problem I had with that was I forgot to use `-E` with `sudo` so `sudo make install` was installing to `/` rather than `$DEVKITA64`
 
Plus, the Switch has eFuses, so no downgrading... It's gonna be interesting to see what comes of Switch homebrew, and if the system will ever get a hack as amazing as A9LH/B9S that Nintendo can't patch out.
I don't think A9LH would have even been possible at all had efuses been in the 3DS, possibly B9S too, at least as far as running software past a certain FW you're not on.

It's going to take a long long time to see software post 3.0.1 run on a 3.0.0 unit as far as I'm aware and could very well never happen.

Anyone looking for backup loaders for new games on 3.0.0 are in for just as rocky road as 3.0.1+ looking for homebrew I reckon. But I'm by no means an authority on the situation.
 
If anybody needs help setting this up and compiling the "simple" example, I wrote up the steps I took to compile it here: https://gist.github.com/vgmoose/8844a812c4bf50889e3f2b65359a6930

Like someone else said earlier in the thread, there's no way (even privately I think) to run these on a retail switch, but CageTheUnicorn should allow it to be emulated. I haven't tried it yet, though. Their "simple" example just sleeps for 5 seconds then exits, there's no graphical functions that are included in libnx at this time.

I think that the next steps would be to have something similar to the Wii U's OSScreen library RE'd, and then also of course a way to run it on the console. That should put the switch at the 5.5.1/Userland homebrew days of the Wii U.
 
Ok. "make install" fails on creating "/aarch64-none-elf/lib", even with sudo. After a manual create i have three files in there:

switch_crt0.o
switch.ld
switch.specs

Is this correct?
 
Last edited by WiiFoundLove,
I think that the next steps would be to have something similar to the Wii U's OSScreen library RE'd, and then also of course a way to run it on the console. That should put the switch at the 5.5.1/Userland homebrew days of the Wii U.

Will be much more limited than 5.5.1 WiiU due to the lack of software compatibility of lower than 3.0.1 firmware going forward (and already if digital or DLC) and inability to spoof FW. This was discovered too early, too, so the compliant Switches will be irrelevantly small if not already except for those few who are paying attention to the current scene which, unfortunately, won't be many since there's nothing for the general low-end user.

It will still be a bit until we get public retail code execution and get actual software development going for it.
 
Last edited by V-Temp,
Ok. "make install" fails on creating "/aarch64-none-elf/lib", even with sudo. After a manual create i have three files in there:

switch_crt0.o
switch.ld
switch.specs

Is this correct?
Are you using my instructions? For me, the "/aarch64-none-elf/lib" is included from extracting the devkitA64 .7z file in step 1.

Will be much more limited than 5.5.1 WiiU due to the lack of software compatibility of lower than 3.0.1 firmware going forward (and already if digital or DLC) and inability to spoof FW. This was discovered too early, too, so the compliant Switches will be irrelevantly small if not already except for those few who are paying attention to the current scene which, unfortunately, won't be many since there's nothing for the general low-end user.

It will still be a bit until we get public retail code execution and get actual software development going for it.
By 5.5.1/Userland days, I'm referring to the period of time when 5.3.2 had a kernel exploit and could run gx2 apps, but 5.5.1 only had a userland exploit and could run small, simple OSScreen homebrews. Forgot that 5.5.1 went on to be the champion of the Wii U scene :)

So basically libnx could become something like this with a bit more RE-ing and a way to execute the userland apps: https://github.com/wiiudev/libwiiu . I agree all of those things you said would be needed eventually and the road ahead is long, but this is at least a foot in the door.
 
Last edited by vgmoose,
Will be much more limited than 5.5.1 WiiU due to the lack of software compatibility of lower than 3.0.1 firmware going forward (and already if digital or DLC) and inability to spoof FW. This was discovered too early, too, so the compliant Switches will be irrelevantly small if not already except for those few who are paying attention to the current scene which, unfortunately, won't be many since there's nothing for the general low-end user.

It will still be a bit until we get public retail code execution and get actual software development going for it.
*cough* Wii U IOSU *cough* this is just like that *cough*
 

Site & Scene News

Popular threads in this forum