Homebrew RAM editing glitch on any 3DS, might lead to an exploit?

[Mrrraou]

not possible because of memory mapping: you can sure read executable memory but not write into it
you need a rop or a way to be even able to use gspwn

fucking read this
this is a bit "more educated" than most of the things i've seen (like prohax/fateshaxx/this has qrcode pls exploit), but this won't lead to anything
the op doesn't even know what part of the ram is loaded, why, and how
and it's unlikely to be code, too; it could just be sprites, music or something
anyway, this won't lead to an exploit.

 

[shinyquagsire23]

fucking read this
this is a bit "more educated" than most of the things i've seen (like prohax/fateshaxx/this has qrcode pls exploit), but this won't lead to anything
the op doesn't even know what part of the ram is loaded, why, and how
and it's unlikely to be code, too; it could just be sprites, music or something
anyway, this won't lead to an exploit.

If you can edit memory, the only thing you need to know is what the memory *is*. It's very well possible that there's values out there which could be useful. It's also possible that it's just VRAM allocations and not exploitable at all.

Yeah. Shinyquagsire was doing something but I don't think that it is an exploit.
https://twitter.com/ShinyQuagsire/status/745627215006556160

When you can shove random data into a QR and it actually interprets it without crashing, it's probably not exploitable, and that was my point there.

 

[Mrrraou]

If you can edit memory, the only thing you need to know is what the memory *is*. It's very well possible that there's values out there which could be useful. It's also possible that it's just VRAM allocations and not exploitable at all.

however, if it's code, isn't code rx mapped ? i'm sure that some values could be edited and overflowed to lead to something, but these would still have to be exploitable
the issue here is that i doubt there is a way to edit that ram using smilebasic

 

[Roomsaver]

however, if it's code, isn't code rx mapped ? i'm sure that some values could be edited and overflowed to lead to something, but these would still have to be exploitable
the issue here is that i doubt there is a way to edit that ram using smilebasic

Can't you edit RAM with NTR? I think I saw some plugin but I forget where.

 

[Mrrraou]

Can't you edit RAM with NTR? I think I saw some plugin but I forget where.

uh... that defeats the whole point of it, luma3ds-dev also sets some memory regions as rwx but still, that's not useful for what the op wants

 

[Seedbon]

however, if it's code, isn't code rx mapped ? i'm sure that some values could be edited and overflowed to lead to something, but these would still have to be exploitable
the issue here is that i doubt there is a way to edit that ram using smilebasic

BGGET can be used to get the two bytes at each tile and BGPUT can be used to write a new value.
RAM editors have already been made, but aren't on the SmileBASIC servers for secrecy. One can be downloaded here and injected into your extdata to be used.

I'm doubtful, but that was stated earlier, I do believe.

 

[Mrrraou]

I'm doubtful, but that was stated earlier, I do believe.

so the memory region isn't code then; now, as shinyquagsire23 stated, you have to find what is stored in there, and if it's any useful to edit it

 

[Seedbon]

so the memory region isn't code then; now, as shinyquagsire23 stated, you have to find what is stored in there, and if it's any useful to edit it

Well, yeah. That's a given.

 

[Trinitro21]

Using NTR Debugger, I found that the accessible memory with this glitch extends from 0x087E8CEC to 0x0CAF8D20 in process 0x29. Does that help in any way?

 

[Deleted User]

Using NTR Debugger, I found that the accessible memory with this glitch extends from 0x087E8CEC to 0x0CAF8D20 in process 0x29. Does that help in any way?

If you can arbitrarily write on this region, you have to find what are the datas stored there. But that's a pretty big extension.

 

[Trinitro21]

The only interesting portion that I know of starts at 0x08812FEC. This is where all the functions, variables, labels, and string values seem to be stored, along with any information associated with them, like lengths and what I assume are pointers.
Both pointers and lengths are signed 32-bit integers that don't seem to be checked. Altering pointers or lengths and then using the variables they're associated with in a way that would try to alter the memory in a place where it can't be altered (like calling CLEAR after changing a pointer to 0xFFFFFFFF) crashes the game.

 

[IzeC0ld]

before this thread,I was thinking about using smilebasic as a exploit. "SmileHaxx"

 

[Deleted User]

The only interesting portion that I know of starts at 0x08812FEC. This is where all the functions, variables, labels, and string values seem to be stored, along with any information associated with them, like lengths and what I assume are pointers.
Both pointers and lengths are signed 32-bit integers that don't seem to be checked. Altering pointers or lengths and then using the variables they're associated with in a way that would try to alter the memory in a place where it can't be altered (like calling CLEAR after changing a pointer to 0xFFFFFFFF) crashes the game.

You could try to edit a pointer and write on the stack.

 

[Pokéidiot]

If someone get do discover where PC points to when some basic function is called, the final thing to do is run arbitrary code from there. So we get homebrew launcher (or another thing) along with a fresh keksploit, since we can write in readonly portions of RAM.

 

[The Real Jdbye]

If someone get do discover where PC points to when some basic function is called, the final thing to do is run arbitrary code from there. So we get homebrew launcher (or another thing) along with a fresh keksploit, since we can write in readonly portions of RAM.

You can't write to read only portions of RAM without already having a kernel exploit.
I can see this glitch being useful for ROP which could lead to another userland entrypoint, but we won't be able to directly overwrite code with it.

 

[Deleted User]

I think I got something like an arbitrary write, I have to investigate that a little bit more.

 

[Swiftloke]

The only interesting portion that I know of starts at 0x08812FEC. This is where all the functions, variables, labels, and string values seem to be stored, along with any information associated with them, like lengths and what I assume are pointers.
Both pointers and lengths are signed 32-bit integers that don't seem to be checked. Altering pointers or lengths and then using the variables they're associated with in a way that would try to alter the memory in a place where it can't be altered (like calling CLEAR after changing a pointer to 0xFFFFFFFF) crashes the game.

Oooh! What if we modified the function of some code in our program, then returned to it? But it's read only isn't it...

 

[Deleted User]

Oooh! What if we modified the function of some code in our program, then returned to it? But it's read only isn't it...

I think it is only interpreted.

 

[TuxSH]

You can't write to read only portions of RAM

Depends where in memory and which mapping (if any) you're using.

i.e. You can use gspwn to write to the APPLICATION memregion and part of the SYSTEM one (using physical addresses of course), see 3dbrew.

 

[Swiftloke]

I think it is only interpreted.

Then mess with the interpreter, if we can access it.