Homebrew supermysterychunkhax - Savegame Exploit for Super Mystery Dungeon

[linuxares]

nice work! I love that you can update it from the game itself. Very clever!

 

[DjoeN]

Ok, found a store that was open on sunday and had plenty of stock, (€39,99)
Just to make sure: You can't use it on a system lower then 10.2 in Europe, the game needs firmware 10.2.
I did the mistake of setting it up for 9.2, but when i ran it, it told me it needed a firmware update to 10.2 and crached back to the homemenu.

So it's a nice extra entrypoint in Europe for 10.2+ users.

[EDIT]
- So far, it's the fastest entrypoint to go to the HBL
- So far, (20+ tries) 100% boot HBL

 

[Ricken]

It sucks that the games with exploits are hardly cheap (excluding ocarina of time)

Reminder that it's easy to find a copy of PSMD to rent (In America)

 

[JustAKirby]

Reminder that it's easy to find a copy of PSMD to rent (In America)

Completely forgot about that.... hehe

 

[regnad]

- So far, it's the fastest entrypoint to go to the HBL
- So far, (20+ tries) 100% boot HBL

Nice! I've used OoT on my Sky as my go to when I help friends set up CFW, but I may just switch to SMCHax now.

 

[GhostLatte]

meh i just think supermysterchunkhax is a bit too long

how bout smdhax

"Smd" means something vulgar.

 

[DjoeN]

Nice! I've used OoT on my Sky as my go to when I help friends set up CFW, but I may just switch to SMCHax now.

Yupz, Once set up, you just boot the game and it loads the hack and brings you straight to the HBL, no need for any other interaction.

The nice thing about secondairy exploits, you can configure it very easy for any FW, boot the installer, choose your FW and ready.

 

[regnad]

Completely forgot about that.... hehe

You should leave it set up for the next rent

Yupz, Once set up, you just boot the game and it loads the hack and brings you straight to the HBL, no need for any other interaction.

The nice thing about secundaire exploits, you can configure it very easy for any FW, boot the installer, choose your FW and ready.

I also like the reliability of this one. BrowserHax was always such a pain in the ass, and when it failed you had to go through all of it again.

--------------------- MERGED ---------------------------

secundaire exploits

You must be Dutch/Flemish!

 

[shinyquagsire23]

So, to my understanding the payload does this:
An overflowed compressed buffer is loaded into memory. That overflow overwrites a memchunk pointer, which (somehow? Explain please) overwrites a function in the decompression method. The modified function copies the entire compressed buffer directly into the stack. This data is (somehow? More explanation please) interpreted as ROP which gspwn's the payload into .text, executing it (somehow).
I'm not a very good programmer, so if @shinyquagsire23 or someone else can explain the holes in my interpretation that'd be nice.

SMD loads save files into linear memory, which has it's own (possibly custom rolled) allocation methods, which includes storing memchunks before each allocation. A 0x32000 buffer is allocated for the compressed file to be read, then a 0x3e800 buffer for the decompressed file. Then the save file is read, but while it reads it takes no regard to the size of the buffer, so the file can overwrite past it's allocation into the next allocation's memchunk. Then a 0x1BCC buffer is allocated for some zlib structure stuff, and during this malloc the previously allocated memchunk is read. Normally it would read that memchunk's next_memchunk, and if it's zero just write the 0x1BCC memchunk address into the last allocation's next_memchunk, but since next_memchunk isn't 0 it writes the 0x1BCC memchunk address at next_memchunk+8. In this case, this overwrites a portion of the stack passed to zlib which specifies the max decompression size with a linear heap pointer (0x31xxxxxx), which is more than enough for a maximum size. Then it's just rinse and repeat: The compressed file decompresses into the 0x1BCC memchunk and sets prev_memchunk to a stack address, next_memchunk to another stack address (minus 8) which is read for a memcpy, and in addition to corrupting the memchunk it overwrites the entire zlib buffer causing it to return a failed decompression and trigger the fallback memcpy, which will just straight copy the entire compressed file over the stack.

 

[DjoeN]

You should leave it set up for the next rent


I also like the reliability of this one. BrowserHax was always such a pain in the ass, and when it failed you had to go through all of it again.

--------------------- MERGED ---------------------------



You must be Dutch/Flemish!

Oeps, secondairy!

 

[DKB]

Why didn't you reveal this exploit right after 10.8 came out? Is there a reason for that?

Anyways, nice damn job.

 

[Swiftloke]

SMD loads save files into linear memory, which has it's own (possibly custom rolled) allocation methods, which includes storing memchunks after each allocation. A 0x32000 buffer is allocated for the compressed file to be read, then a 0x3e800 buffer for the decompressed file. Then the save file is read, but while it reads it takes no regard to the size of the buffer, so the file can overwrite past it's allocation into the memchunk. Then a 0x1BCC buffer is allocated for some zlib structure stuff, and during this malloc the previously allocated memchunk is read. Normally it would read that memchunk's next_memchunk, and if it's zero just write the 0x1BCC memchunk into the last allocation's next_memchunk, but since next_memchunk isn't 0 it writes the 0x1BCC memchunk address at next_memchunk+8. In this case, this overwrites a portion of the stack passed to zlib which specifies the max decompression size with a linear heap pointer (0x31xxxxxx), which is more than enough for a maximum size. Then it's just rinse and repeat: The compressed file decompresses into the 0x1BCC memchunk and sets prev_memchunk to a stack address, next_memchunk to another stack address (minus 8) which is read for a memcpy, and in addition to corrupting the memchunk it overwrites the entire zlib buffer causing it to return a failed decompression and trigger the fallback memcpy, which will just straight copy the entire compressed file over the stack.

Ah. So the corrupted memchunk overwrites the maximum decompressed buffer size, allowing itself to set up stack addresses for the fallback mempcy (which we corrupt to our advantage in the process) to screw up on and copy into. But how does the stack trigger gspwn, and how does gspwn copying code into .text enough for code execution? I don't know too much about exploits, but I'm willing to learn .

 

[shinyquagsire23]

Ah. So the corrupted memchunk overwrites the maximum decompressed buffer size, allowing itself to set up stack addresses for the fallback mempcy (which we corrupt to our advantage in the process) to screw up on and copy into. But how does the stack trigger gspwn, and how does gspwn copying code into .text enough for code execution? I don't know too much about exploits, but I'm willing to learn .

Once you control the stack, you can control where things return to, since LR is usually pushed to the stack. So you create a chain of returns, or ROP, in order to execute existing code in whatever fashion you decide. From there you can execute gspwn and then load actual arbitrary code.

 

[Swiftloke]

Once you control the stack, you can control where things return to, since LR is usually pushed to the stack. So you create a chain of returns, or ROP, in order to execute existing code in whatever fashion you decide. From there you can execute gspwn and then load actual arbitrary code.

Though I already know what ROP is, thanks!

 

[Ricken]

You should leave it set up for the next rent

5 year old complaining about how it wont load...
lol

 

[Selim873]

It's also a good idea to stockpile secondary cart exploits because
1. It covers more users that might already have a game.
2. It brings/keeps down the price of existing hax games.
3. Easier to actually find a hax game at a nearby store.
4. More open source exploits for budding hackers to learn from (so maybe less "prohax" garbage).

True. If browserhax were to never work on 10.7, then the only hope I have is Animal Crossing. Someone mentioned it but I'm pretty sure it ended up being fake. There's no way in hell I'm buying Cubic Ninja again. I already have the EUR version for my *hax N3DS, but I personally want A9LH NTR on my main N3DS, because it would be cheaper than giving an arm and leg for a capture card.

 

[Ricken]

Tomorrow (hopefully) I'll be able to make Powersaves save files for this (U)... assuming my dongle doesnt pull an Alpha on me (My AS is the only game i cant get my Powersaves to work on )

EDIT: Wait, i only have to make 1 b/c of that Update feature right?

 

[regnad]

True. If browserhax were to never work on 10.7, then the only hope I have is Animal Crossing. Someone mentioned it but I'm pretty sure it ended up being fake. There's no way in hell I'm buying Cubic Ninja again. I already have the EUR version for my *hax N3DS, but I personally want A9LH NTR on my main N3DS, because it would be cheaper than giving an arm and leg for a capture card.

Yeah, you might as well get a Sky then. With that you can have Cubic Ninja, OoT, and PMD, in any region, and you can still play and save your game on OoT and PMD without sacrificing the hax.

 

[shinyquagsire23]

Tomorrow (hopefully) I'll be able to make Powersaves save files for this (U)... assuming my dongle doesnt pull an Alpha on me (My AS is the only game i cant get my Powersaves to work on )

EDIT: Wait, i only have to make 1 b/c of that Update feature right?

Two, the ROP for o3DS vs N3DS differs.

EDIT: If you did EUR and JPN it'd total to 6 images, but yes, you can just use the updater to change the system version target.

 

[Ricken]

If you did EUR and JPN it'd total to 6 images, but yes, you can just use the updater to change the system version target.

I would if i had other region's gamecarts (tbh i dont even have an American copy, i just plan on renting a copy to downgrade a friend's system then set up A9LH )