Homebrew Official [Release] EmuNAND9 - Open Source EmuNAND Formatter & Manager

[d0k3]

If you want to load the bootstrap.bin, you have to inject that to another location in the CakeHax.dat file (look in the readme). Also you'd have to fix the framebuffer offsets (look here).

I meant there's trouble loading it when CakeBrah is used as a submodule. I'll need to look deeper into this, though. Will write in your thread if I find something.

To just fix the gateway payload, I think:

#define BOT_SCREEN0 (u8*)(*(u32*)0x080FFFD0)

should do it.

No, that didn't do the job. The bottom screen is never accessed in the text version anyways... The TOP_SCREEN define should be okay, though... think the issue could be in the .s file (as I wrote, I have not the slightest knowledge of asm)?

 

[mid-kid]

I meant there's trouble loading it when CakeBrah is used as a submodule. I'll need to look deeper into this, though. Will write in your thread if I find something.


No, that didn't do the job. The bottom screen is never accessed in the text version anyways... The TOP_SCREEN define should be okay, though... think the issue could be in the .s file (as I wrote, I have not the slightest knowledge of asm)?

The issue is certainly how the top screen is accessed, then. Not completely sure what may be going wrong. The .s file has no problems.

 

[d0k3]

The issue is certainly how the top screen is accessed, then. Not completely sure what may be going wrong. The .s file has no problems.

Alright, thank you. I'll need to investigate this further, will possibly come back about it later.

 

[d0k3]

@mid-kid I further investigated to get to the root cause behind this problem.

There are only three relevant chages (vs previous commit) in this commit. The only one of these three changes that breaks Cakehax for EmuNAND9 and Decrypt9 is the one relating to the bottom framebuffer.

So, if I change this:

    // This is mostly to adhere to the gateway "standard",
    //   so existing gateway payloads don't have to be modified.
    // Write the framebuffer offsets to the places where gateway expects them
    *(uint32_t *)0x080FFFC0 = (uint32_t)framebuffers->top_left;
    *(uint32_t *)0x080FFFC8 = (uint32_t)framebuffers->top_right;
    *(uint32_t *)0x080FFFD0 = (uint32_t)framebuffers->bottom;

    // Select the first framebuffer for each screen, since we only write that one.
    *(uint32_t *)0x080FFFD8 = 0;
    *(uint32_t *)0x080FFFDC = 0;

... to this...

    // This is mostly to adhere to the gateway "standard",
    //   so existing gateway payloads don't have to be modified.
    // Write the framebuffer offsets to the places where gateway expects them
    *(uint32_t *)0x080FFFC0 = (uint32_t)framebuffers->top_left;
    *(uint32_t *)0x080FFFC8 = (uint32_t)framebuffers->top_right;
    // *(uint32_t *)0x080FFFD0 = (uint32_t)framebuffers->bottom;
    *(uint32_t *)0x080FFFD4 = (uint32_t)framebuffers->bottom;

    // Select the first framebuffer for each screen, since we only write that one.
    *(uint32_t *)0x080FFFD8 = 0;
    *(uint32_t *)0x080FFFDC = 0;

... it will work again.

This is the old offset for the bottom framebuffer. And, as I wrote, the bottom screen is not even used. If I change BOT_SCREEN0 (in my draw.h) to anything else, it doesn't have an effect at all.

Any idea?

 

[mid-kid]

@mid-kid I further investigated to get to the root cause behind this problem.

There are only three relevant chages (vs previous commit) in this commit. The only one of these three changes that breaks Cakehax for EmuNAND9 and Decrypt9 is the one relating to the bottom framebuffer.

So, if I change this:

    // This is mostly to adhere to the gateway "standard",
    //   so existing gateway payloads don't have to be modified.
    // Write the framebuffer offsets to the places where gateway expects them
    *(uint32_t *)0x080FFFC0 = (uint32_t)framebuffers->top_left;
    *(uint32_t *)0x080FFFC8 = (uint32_t)framebuffers->top_right;
    *(uint32_t *)0x080FFFD0 = (uint32_t)framebuffers->bottom;

    // Select the first framebuffer for each screen, since we only write that one.
    *(uint32_t *)0x080FFFD8 = 0;
    *(uint32_t *)0x080FFFDC = 0;

... to this...

    // This is mostly to adhere to the gateway "standard",
    //   so existing gateway payloads don't have to be modified.
    // Write the framebuffer offsets to the places where gateway expects them
    *(uint32_t *)0x080FFFC0 = (uint32_t)framebuffers->top_left;
    *(uint32_t *)0x080FFFC8 = (uint32_t)framebuffers->top_right;
    // *(uint32_t *)0x080FFFD0 = (uint32_t)framebuffers->bottom;
    *(uint32_t *)0x080FFFD4 = (uint32_t)framebuffers->bottom;

    // Select the first framebuffer for each screen, since we only write that one.
    *(uint32_t *)0x080FFFD8 = 0;
    *(uint32_t *)0x080FFFDC = 0;

... it will work again.

This is the old offset for the bottom framebuffer. And, as I wrote, the bottom screen is not even used. If I change BOT_SCREEN0 (in my draw.h) to anything else, it doesn't have an effect at all.

Any idea?

https://github.com/d0k3/Decrypt9/blob/master/source/main.c#L203
https://github.com/d0k3/Decrypt9/blob/master/source/draw.c#L29
How does the bottom screen define not matter again? (Dunno if you make depfiles during compilation but if you don't you should run make clean to make sure everything that uses draw.h is up to date)

 

[d0k3]

https://github.com/d0k3/Decrypt9/blob/master/source/main.c#L203
https://github.com/d0k3/Decrypt9/blob/master/source/draw.c#L29
How does the bottom screen define not matter again? (Dunno if you make depfiles during compilation but if you don't you should run make clean to make sure everything that uses draw.h is up to date)

Missed that, thank you! Still no progress, though. And, yes, I'm always doing a clean when switching build goals, and the release build goal (which builds multiple binaries) does clean itself where appropriate.

Now, I tried that: https://github.com/d0k3/HelloEntryPoint
This is as minimal as it gets, it only writes some text to the display (starting at the upper left of the top screen) and allows to move that text around with (L+) arrow keys or switch the screen with R. All unneeded source code was removed, leaving only a reduced draw.h/.c, hid.h/.c, i2c.h/.c and a very small main.c. Boot rates with BrahmaLoader and the bootstrap.bin are fine, but for CakeHax (with CakeBrah, I can't test the browser entry point or CakesROP) it is the same again: Not working, or really, really abysmal boot rates. I'm using the new offset for the bottom screen.

 

[mid-kid]

Missed that, thank you! Still no progress, though. And, yes, I'm always doing a clean when switching build goals, and the release build goal (which builds multiple binaries) does clean itself where appropriate.

Now, I tried that: https://github.com/d0k3/HelloEntryPoint
This is as minimal as it gets, it only writes some text to the display (starting at the upper left of the top screen) and allows to move that text around with (L+) arrow keys or switch the screen with R. All unneeded source code was removed, leaving only a reduced draw.h/.c, hid.h/.c, i2c.h/.c and a very small main.c. Boot rates with BrahmaLoader and the bootstrap.bin are fine, but for CakeHax (with CakeBrah, I can't test the browser entry point or CakesROP) it is the same again: Not working, or really, really abysmal boot rates. I'm using the new offset for the bottom screen.

I can't test for myself right now because my console's bricked at the moment, so I can oly tell you which things to try:
Modify CakeBrah to draw something on the bottom screen before loading the payload. If the initial payload loads correctly, the screens should be black (or modify this to make them white). This way we can know for sure everything up to that point is right.
Try writing to the bottom screen instead from the arm9 payload. I write to both the left and right top screens so I don't care which is which, but since you're only writing the left one, I could've flipped them around by accident.
Try using the CakeHax offsets instead of the Gatway ones: 0x23FFFE00 for top_left, 0x23FFFE04 for top_right and 0x23FFFE08 for bottom.

 

[d0k3]

I can't test for myself right now because my console's bricked at the moment, so I can oly tell you which things to try:
Modify CakeBrah to draw something on the bottom screen before loading the payload. If the initial payload loads correctly, the screens should be black (or modify this to make them white). This way we can know for sure everything up to that point is right.
Try writing to the bottom screen instead from the arm9 payload. I write to both the left and right top screens so I don't care which is which, but since you're only writing the left one, I could've flipped them around by accident.
Try using the CakeHax offsets instead of the Gatway ones: 0x23FFFE00 for top_left, 0x23FFFE04 for top_right and 0x23FFFE08 for bottom.

Okay, I tried modifying the screen clear function in CakeHax (replaced zeroes with 0xFF), and the screen does not change to white. This means the initial payload (the one that loads the bigger one from the SD) already fails, and trying other stuff will not lead to any results, correct? Now, I have the latest DevKitPro and CTRUlib installed, so that can't be the problem.

Still, to exclude that possibility, could someone else compile this with the release goal (make release) and upload the results? @Shadowtrance or @dark_samus3 maybe?

 

[Shadowtrance]

Okay, I tried modifying the screen clear function in CakeHax (replaced zeroes with 0xFF), and the screen does not change to white. This means the initial payload (the one that loads the bigger one from the SD) already fails, and trying other stuff will not lead to any results, correct? Now, I have the latest DevKitPro and CTRUlib installed, so that can't be the problem.

Still, to exclude that possibility, could someone else compile this with the release goal (make release) and upload the results? @Shadowtrance or @dark_samus3 maybe?

Compile Messenger? Sure, I'll try. haha (link is broken...well it takes me to messenger).

 

[d0k3]

Compile Messenger? Sure, I'll try. haha (link is broken...well it takes me to messenger).

Oooops, I meant this .

 

[Shadowtrance]

And done.

 

[mid-kid]

Okay, I tried modifying the screen clear function in CakeHax (replaced zeroes with 0xFF), and the screen does not change to white. This means the initial payload (the one that loads the bigger one from the SD) already fails, and trying other stuff will not lead to any results, correct? Now, I have the latest DevKitPro and CTRUlib installed, so that can't be the problem.

Still, to exclude that possibility, could someone else compile this with the release goal (make release) and upload the results? @Shadowtrance or @dark_samus3 maybe?

I don't see any reference to anything building a CakeBrah.3dsx in your Makefile. Are you sure CakeBrah is loading the right payload (at "Decrypt9WIP.dat" in your case)? Also take a look at this.
But I don't get how modifying the location where the bottom framebuffer offset is written to worked yet now it doesn't. Try doing that again, do the screens clear to white?

 

[d0k3]

I don't see any reference to anything building a CakeBrah.3dsx in your Makefile. Are you sure CakeBrah is loading the right payload (at "Decrypt9WIP.dat" in your case)? Also take a look at this.
But I don't get how modifying the location where the bottom framebuffer offset is written to worked yet now it doesn't. Try doing that again, do the screens clear to white?

In Decrypt9, EmuNAND9 and HelloEntryPoint, I'm using BrahmaLoader instead of Cakebrah. For this round of tests, I'm using most recent bootctr, which in turn uses most recent CakeBrah. I guess I'll also set up a proper CakeBrah build goal, just to be safe.

@Shadowtrance , your build didn't work for me either... could you try the CakeHax HelloEntryPoint on your own console, just to make sure my N3DS is not at fault?

 

[osaka35]

Having difficulties, will try a few things then provide a full report.

 

[fr3quency]

Having difficulties, will try a few things then provide a full report.

Hadn't you made a backup of your entire SDcard(most importantly of the Nintendo 3DS folder)?

 

[osaka35]

Hadn't you made a backup of your entire SDcard(most importantly of the Nintendo 3DS folder)?

I have, as well as my NAND. I make backups every month or so.

 

[fr3quency]

I have, as well as my NAND. I make backups every month or so.

So you pasted the Nintendo 3DS folder after the format and those games didn't work? Huh?

 

[osaka35]

So you pasted the Nintendo 3DS folder after the format and those games didn't work? Huh?

I'm trying a few things, to make sure it wasn't user error I'm as surprised as you that it didn't work, so I'm going to a different backup and seeing if I did something dumb and backed up the wrong 3ds to the wrong folder, or something silly. I'll try and make sure that I'm not doing something dumb, then try and figure out what went wrong. I generally just assume I did something wrong first, then go from there. I was just a bit upset as I've spend most of my entire month playing animal crossing game.

 

[d0k3]

I'm trying a few things, to make sure it wasn't user error I'm as surprised as you that it didn't work, so I'm going to a different backup and seeing if I did something dumb and backed up the wrong 3ds to the wrong folder, or something silly. I'll try and make sure that I'm not doing something dumb, then try and figure out what went wrong. I generally just assume I did something wrong first, then go from there. I was just a bit upset as I've spend most of my entire month playing animal crossing game.

Before you copy your old "Nintendo 3DS" folder back, delete the one created after the EmuNAND9 format. I think that's the issue you're having here.

 

[osaka35]

Before you copy your old "Nintendo 3DS" folder back, delete the one created after the EmuNAND9 format. I think that's the issue you're having here.

thanks, that did it. That was pretty stupid oversight on my part.

I'm not really sure why the browser exploit stopped working, but it could have just been a coincidence. It also hasn't asked me to update again. I think that's what made me think something had gone terribly wrong.