CakeHax.

[mid-kid]

There's been 3 people asking me questions and having trouble getting CakeHax to work with rxTools.
So I figured I should do it myself instead.

rxinstaller.nds will not work with this. I leave fixing that to someone else. (I recommend merging when that's cleared)

[ApacheThunder]

I've recompiled Cakesrop.nds to launch rxtools.dat, so I have that taken care of once I get rxTools compiled. :P

Here's my fork of CakesROP that should launch rxTools.dat (assuming what mid-kid added works). I still can't get mid-kid's changes to compile correctly on my fork of rxTools. :(

https://github.com/ApacheThunder/rxToolsCakeROP

EDIT: Renamed the repository to prevent confusion among the public.

[Syphurith]

@mid-kid data.bin is itself a save file for rxTools, which is used currently only to avoid multiple install. Other files within rxTools folder are decrypted FIRMs.
Also i don't know if using relocatable Buffer Address instead of those obsolute addresses now, as described in #54, would be better.. (See it at almost bottom).

[mid-kid]

@Syphurith Well, the data.bin is still in the same place. It should work, though I admit I haven't tested it throughly, and the "inital setup" thingy shows up every time I boot (I don't have a correct firmware.bin I believe).
I don't know what you mean by Obsolute addresses (you want to change the GPU regs on boot?), but whenever you've got a change that needs to be in CakeHax, I'm open to pull requests.

[Syphurith]

@mid-kid Not all of them GPU related. For example when decrypting titles:

#define BUF1 (u8*)0x21000000
#define TITLES (u8*)0x22000000

You know sometimes the memory area isn't R/W mapped, that may differ from entrypoints.
So in draw.c and draw.h multiple ones:

#define TOP_SCREEN  (u8*)(*(u32*)((u32)0x080FFFC0 + 4 * (*(u32*)0x080FFFD8 & 1)))
#define TOP_SCREEN2 (u8*)(*(u32*)0x080FFFC4)
#define BOT_SCREEN  (u8*)(*(u32*)0x080FFFD4)

Eh.. And sometimes it still cause weird UI or TOP_SCREEN2 not working. Ha.
I think these should be relocatable so that entrypoint tells where the VRAM, BUF would be. That may avoid some freeze problem, and help with customization and stability.

[mid-kid]

If you mean MPU regions, these are remapped here (and in the old msethax too).
Here's the defaults: http://3dbrew.org/wiki/Memory_layout#ARM9_MPU_regions (And I don't think any entrypoint remaps them.)
I don't know what other memory area mapping you mean, otherwise.

[Syphurith]

@mid-kid Well ok. I still remember when @nop90 said that his mset for pasta fails when loading a binary big enough, and he tried hard to make it work - not too good. Hope yours be better.

[ApacheThunder]

I got a compiled dat from midkid since it wasn't compiling correctly for me. So I can confirm that rxTools boots from MSET 9.x now. So my forked CakesRop for the NDS rop installer works with this. That or just use ropcustom.txt. Which ever is easier for folks I guess. :P

EDIT: Also the initial install only happens once for me. So mid-kid just isn't using the right firmware.bin file when he tested it. data.bin is working perfectly fine it looks like.

[kot2002]

Does it work with 4.x devices? I compiled rxtools.dat without errors and it doesn't work.. (4.5.0-8E)
Spider : lower screen glitches and hangs
MSET : just hangs

[mid-kid]

Hm. Apache had the same results when building. Maybe I failed to update the submodule correctly?
EDIT: Nope. That's updated correctly. Maybe windows users have to add bs=512 because someone decided it should be different or something. Dunno. Just make sure rxTools is correctly injected at 0x22000 with a hex editor or something, some parameters may need to be adjusted.

[mid-kid]

Apparently CakeHax' makefile needed some reordering to play nice with MinGW.
This is now fully working. Now for someone to fix rxinstaller.

[kot2002]

It works like charm! even on firmwares (4.5.0-K, etc..) which were not supported.

[motezazer]

rxInstaller seems to do some decryption stuff. That could be why it's broken with CakeHax.

[mid-kid]

@motezazer rxInstaller's ROP chain does decryption, yes. That's why it's broken. Also, MSET 9.x is loaded on a different offset.

[motezazer]

The decryption snippet is :
.word pop_r0_r4
.word ssl_dec+4
.word 0x144cbc
.word load_addr
.word 0x9000
.word pop_r1
.word ssl_dec+4
.word ssl_dec+4
.word pop_r3
.word 0x1460
.word 0x143D60
.word 0x9000
.word pop_pc

[ApacheThunder]

Once somone gets rxInstaller and draw code fixed, I'd say we are ready to add CakeHAX:

https://github.com/ApacheThunder/rxTools-Cakes/tree/merged

This is my alternate branch with the current official rxTools branch with CakeHaX added. That branch also has filepack stored unencrypted (which there are no negative side effects to. It's just an unnecessary layer of encryption at this point since CakeHax loads unencrypted payloads except for spider rop for compatibility reasons)

I'll be keeping that branch up to date with this one so when you guys want to get CakeHaX added it won't be a big pain. It all depends on how different your makefile is in the end. So far you haven't altered it beyond the original makefile that mid-kid pulled when he originally added CakeHaX in his fork. (This branch has data.bin xoring stuff removed to store filepack data.bin unencrypted with filepack.c adjusted accordingly).

I gave rxInstaller a new top screen logo. You can use it or use your own if you want. :P

Brahma code is already fixed to load CakeHaX in that branch. ;)

The original pull request by midkid is maybe out of date. Might need to do a new one.

[mid-kid]

Tried to rebase it, but fucked something up - hang on.

[mid-kid]

Sorry for the inconvenience, new pull is #69.