Hacking [Release] rxTools - Roxas75 3DS Toolkit [fw 2.0 - 9.2]

[urherenow]

Nope, I'm just tired of someone mentioning DS and GBA on emunand every single day. It's not a priority. And it's an illusion in the first place.

 

[Aroth]

Nope, I'm just tired of someone mentioning DS and GBA on emunand every single day. It's not a priority. And it's an illusion in the first place.

Then please take it up with the people who ask about it. I merely answered the dude's question.

 

[Zidapi]

Are there plans to integrate Gateway's cheat engine?

No. Not now, or any time soon.

There's already a lengthy todo list to get through before we see an official 3.0 release. Let's focus on that instead of moving the goal posts further down the field.

Edit: See my post here if you want a Gateway free in-game cheat engine, then go harass cell9/smealum.

 

[Aroth]

No. Not now, or any time soon.

There's already a lengthy todo list to get through before we see an official 3.0 release. Let's focus on that instead of moving the goal posts further down the field.

Edit: See my post here if you want a Gateway free in-game cheat engine, then go harass cell9/smealum.

Glad to see someone else agree with my sentiment from a few months ago. My personal opinion (which granted matters for little as I am not a member of the team developing this) is that the immediate goal for 3.0 should be bringing emunand based features of the N3DS support in line with the O3DS support. If it works for the O3DS the team should work towards making it work for the N3DS, though I would personally limit this to FW features. Porting the extensive toolset that made rxTools popular to the N3DS should ostensibly wait until after core features of the CFW (like DS card support and twl_firm and agb_firm patches) are working across the board. Things like title decryption and injection/extraction, while nice and relatively important, should probably be secondary to making sure what is supposed to work inside the emunand does work, and that it boots reliably.

edit: Having said all of that, if someone can figure out how in the hell Gateway is doing their on-the-fly kernel version check patching, then for the love of all things holy port that shit already.

 

[urherenow]

@Aroth... I'm glad you said that. I just realized that the sd tool not working on an O3ds with rxtools (but it does using GW), is the damn kernel check, not any special encryption (as was stated to me before... Well, something about zero key or... I forgot ). Because the same .cia runs under rxtools on an n3ds.

The secondary stuff at the bottom of your post is actually all working already, as far as I know. Not necessarily FBI injection on all systems, but the decrypting stuff. Anything more fancy with that can be done with decrypt9wip anyway.

 

[Aroth]

@Aroth... I'm glad you said that. I just realized that the sd tool not working on an O3ds with rxtools (but it does using GW), is the damn kernel check, not any special encryption (as was stated to me before... Well, something about zero key or... I forgot ). Because the same .cia runs under rxtools on an n3ds.

The secondary stuff at the bottom of your post is actually all working already, as far as I know. Not necessarily FBI injection on all systems, but the decrypting stuff. Anything more fancy with that can be done with decrypt9wip anyway.

Do you mean the network transfer one? I actually thought that was something that was only included in the N3DS. And yeah, I think like 90% of the tools work, and the ones that don't actually don't work at all with the O3DS or N3DS. Except injecting FBI into the H&S app. Afaik that only works on the O3DS in the first place.

Last I checked the only "tool" that didn't work was dumping/injecting the NAND itself, no idea if it was ever fixed. Personally I just use the GW menu to dump the NAND and format EmuNAND.

As for the kernel check, I am only going off of a set of observations. I know that all games and updates require a minimum firmware, usually whatever the latest FW was at the time the cart was manufactured (and said fw is included on the cart) or when the update was released. I also know if you try to run a game or update on a lower firmware than the "minimum" (and manage to bypass the "update or else" message, the title hangs on the 3DS logo. This is what happens when you launch an unmodified copy of Triforce Heroes on a N3DS with rxTools, Pasta, or Reinand. This is also what happens when you update the eShop to the latest version and run it on one of those CFWs.

However if you decrypt and repack the game and patch the exheader to change the "minimum fw" in the process, the game will run, assuming it doesn't actually NEED something from a later firmware or sdk. (like trying to patch a SDK7 game to run on 4.x). Yet for some reason if you are running GW Mode, you do not need to do the stupid exheader patch. This suggests that GW is patching the title on the fly as it is loaded. That or maybe they are patching the version reported by the system? Actually this is probably the case and would explain a few things. If I can find/remember the keypress to disable the FW spoof I will see what happens if i try loading the updated eShop while doing it. I suspect it will hang on the 3DS logo.

 

[Deleted-19228]

Doesn't matter anyway. No one really needs gateway anymore just for Emunand setup when you don't have an actual gateway and can just use Emunand9 now.

Gateway is still the only one that has a real patch for firm so you don't need to patch every individual game.

 

[Aroth]

That or maybe they are patching the version reported by the system? Actually this is probably the case and would explain a few things. If I can find/remember the keypress to disable the FW spoof I will see what happens if i try loading the updated eShop while doing it. I suspect it will hang on the 3DS logo.

Well disabling the basic spoof that prevents it from prompting card updates doesn't disable whatever is done in the background to ensure cias load regardless of the minimum fw/kernel listed in the exheader. Tbh its probably a dual patch. One patch probably spoofs the kernel version to FF FF so that the exheaders never cause an issue and the other spoofs whatver the update on the card looks at.

 

[urherenow]

You're right about the sd tool, but it runs on an o3ds anyway using a GW. It's quite convenient.

 

[DjoeN]

Yes!, got latest rxtools github compiled with latest devkitarm r45 and lictru 1.0 without errors (in a frankenstein way)
(Thanks for the tip @mariogamer 's post https://gbatemp.net/threads/release...olkit-fw-2-0-9-2.382782/page-775#post-5901871 )
Since CakesCFW compiles without errors with latest devkitarm r45 and libctru 1.0 (and i have it already on my hdd gitcloned and compiled))

- Gitcloned rxtools
- run make release to compiled rxtools, this gives an error in the end
- Removed \rxtools\rxtools\build\CakeHax
- Removed \rxtools\rxtools\CakeHax and replaced it with the folder from CakesCFW in it's place \CakesForeveryWan\CakeHax\*.* (including all subfolders)
- Removed \rxtools\CakeBrah and replaced it with the folder from cakesCFW -> \CakesForeveryWan\CakeBrah\*.* (including all subfolders)(including all subfolders)
- Do NOT run "make clean"
- Just run make release in \rxtools again and see it compile without errors

 

[wurstpistole]

Yes!, got latest rxtools github compiled with latest devkitarm r45 and lictru 1.0 without errors (in a frankenstein way)
(Thanks for the tip @mariogamer 's post https://gbatemp.net/threads/release...olkit-fw-2-0-9-2.382782/page-775#post-5901871 )
Since CakesCFW compiles without errors with latest devkitarm r45 and libctru 1.0 (and i have it already on my hdd gitcloned and compiled))

- Gitcloned rxtools
- run make release to compiled rxtools, this gives an error in the end
- Removed \rxtools\rxtools\build\CakeHax
- Removed \rxtools\rxtools\CakeHax and replaced it witht the folder from CakesCFW in it's place \CakesForeveryWan\CakeBrah\*.* (including all subfolders)
- Removed \rxtools\CakeBrah and replaced it with the folder from cakesCFW -> \CakesForeveryWan\CakeHax\*.* (including all subfolders)(including all subfolders)
- Do NOT run "make clean"
- Just run make release in \rxtools again and see it compile without errors

What's the difference to just downloading nightly from lavanoid?

 

[DjoeN]

What's the difference to just downloading nightly from lavanoid?

I really don't know!

I like to compile my own versions + latest github changes is from a few hours ago, while lavanoid is still 05-12-2015 (12-05-15 in US date)

 

[ShadowOne333]

I really don't know!

I like to compile my own versions + latest github changes is from a few hours ago, while lavanoid is still 05-12-2015 (15-12-05 in US date)

Check if the latest already has AGB and TWL support for N3DS' emunand

 

[DjoeN]

Check if the latest already has AGB and TWL support for N3DS' emunand

I don't have an exploitable N3DS :/

 

[mariogamer]

Ok,here are some final instruction to build rxTools:

1.Install latest devkitARM
2.Install latest ctrulib
3.Add devkitARM to path
4.Clone CakeHax/CakeBrah:

git clone --recursive https://github.com/mid-kid/CakeHax
git clone --recursive https://github.com/mid-kid/CakeBrah

5.Run make in all folder (CakeBrah >make, CakeHax >make)
6.Clone rxTools without --recursive like this: git clone https://github.com/roxas75/rxTools
7.Delete CakeBrah and rxtools/CakeHax from rxTools (there are a folder who is named rxtools in rxTools folder)
8.Copy past CakeBrah in your cloned rxTools folder
9. Copy past CakeHax in rxTools/rxtools folder
10.Run make release in your rxTools folder

Thank @urherenow

 

[Aroth]

Check if the latest already has AGB and TWL support for N3DS' emunand

How would one check this?

 

[urherenow]

Actually, I never said to do a separate clone of cakesrop. It's probably best to change only what's needed, otherwise, you may end up bugging the devs about a bug that doesn't actually exist in the build they intend everyone to use.

Not much is different, but the .3dsx file for HBL is a good bit smaller than before. Like over 20k smaller. The latest change actually takes care of a situation where launching BBM a couple of times, then entering system settings would show VER, instead of RX-E or whatever.

How would one check this?

Easiest way? Create an account on github and "watch" the rxtools repo. Otherwise listen to the people that do (all of whom said it is not even being worked on). Actually the easiest way would be to simply try running a gba VC game. But don't waste your time...

 

[Aroth]

Easiest way? Create an account on github and "watch" the rxtools repo. Otherwise listen to the people that do (all of whom said it is not even being worked on). Actually the easiest way would be to simply try running a gba VC game. But don't waste your time...

I assume trying to run a gba VC game would verify agb support, so what about twl support? Is that what prevents DS carts from loading in the latest builds?

Also, what about VC games that aren't gba or DSiware? Like old NES or SNES stuff?

 

[Shadow#1]

I assume trying to run a gba VC game would verify agb support, so what about twl support? Is that what prevents DS carts from loading in the latest builds?

Also, what about VC games that aren't gba or DSiware? Like old NES or SNES stuff?

NES and SNES doesn't use/run on a FIRM

 

[ShadowOne333]

How would one check this?

By trying to run a GBA VC game or DSiWare from emunand