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

[Trinitro21]

TL;DR there's an oversight in SmileBASIC that leads to RAM viewing and editing on any 3DS, hacked or unhacked. It could lead to a primary exploit, but it probably won't. I don't know for sure though, so I'm posting it here to see what comes of it.

In the SmileBASIC interpreter, there's a bug with the BGSCREEN command, which resizes the background layer. The area of the background layer isn't supposed to exceed 16383, but the checks the interpreter performs on the parameters are insufficient and can be bypassed with large enough numbers.

The game will crash if the area is too large; however, there's a window where the game doesn't crash and the BG layer occupies sizes never meant to be possible. Because of this, it contains memory allocated for other purposes by the interpreter, like variable and function storage and the current program's code.

With the BG commands, this area of memory can be edited by any 3DS, hacked or unhacked.

All that is needed to trigger this glitch is this one line of code:

BGSCREEN 0,134217728,16

Could a primary exploit be made with this bug?

It is an area of RAM allocated for the interpreter, so it's probably not executable and so likely not exploitable. However I know that there are pointers in the memory that can be edited, as well as many unknown segments of memory. Perhaps a variable's pointer could be edited to use executable memory or some other attack could be developed that could lead to an exploit?

EDIT: I'm stupid and forgot to give credit.
This glitch was found by a group of users at smilebasicsource.com, including slackerSnail, 12Me21, and incvoid.
I was somewhat part of it.

 

[proflayton123]

TL;DR there's an oversight in SmileBASIC that leads to RAM viewing and editing on any 3DS, hacked or unhacked. It could lead to a primary exploit, but it probably won't. I don't know for sure though, so I'm posting it here to see what comes of it.

In the SmileBASIC interpreter, there's a bug with the BGSCREEN command, which resizes the background layer. The area of the background layer isn't supposed to exceed 16383, but the checks the interpreter performs on the parameters are insufficient and can be bypassed with large enough numbers.

The game will crash if the area is too large; however, there's a window where the game doesn't crash and the BG layer occupies sizes never meant to be possible. Because of this, it contains memory allocated for other purposes by the interpreter, like variable and function storage and the current program's code.

With the BG commands, this area of memory can be edited by any 3DS, hacked or unhacked.

All that is needed to trigger this glitch is this one line of code:

BGSCREEN 0,134217728,16

Could a primary exploit be made with this bug?

It is an area of RAM allocated for the interpreter, so it's probably not executable and so likely not exploitable. However I know that there are pointers in the memory that can be edited, as well as many unknown segments of memory. Perhaps a variable's pointer could be edited to use executable memory or some other attack could be developed that could lead to an exploit?

Finally, a thread with a theory of possible hax with good explanation with it

 

[seijinshu]

TL;DR there's an oversight in SmileBASIC that leads to RAM viewing and editing on any 3DS, hacked or unhacked. It could lead to a primary exploit, but it probably won't. I don't know for sure though, so I'm posting it here to see what comes of it.

In the SmileBASIC interpreter, there's a bug with the BGSCREEN command, which resizes the background layer. The area of the background layer isn't supposed to exceed 16383, but the checks the interpreter performs on the parameters are insufficient and can be bypassed with large enough numbers.

The game will crash if the area is too large; however, there's a window where the game doesn't crash and the BG layer occupies sizes never meant to be possible. Because of this, it contains memory allocated for other purposes by the interpreter, like variable and function storage and the current program's code.

With the BG commands, this area of memory can be edited by any 3DS, hacked or unhacked.

All that is needed to trigger this glitch is this one line of code:

BGSCREEN 0,134217728,16

Could a primary exploit be made with this bug?

It is an area of RAM allocated for the interpreter, so it's probably not executable and so likely not exploitable. However I know that there are pointers in the memory that can be edited, as well as many unknown segments of memory. Perhaps a variable's pointer could be edited to use executable memory or some other attack could be developed that could lead to an exploit?

Excellent. I think one of these games would be better for hacking than my theory with FE:Fates.

 

[PF2M]

Just tested the crashing version of it and it worked. Reminds me of that one line of Petit Computer code that crashed the game. My question is, how can the line of code you provided be used to edit the RAM? Is there other commands you can type in to do so?

 

[Trinitro21]

Just tested the crashing version of it and it worked. Reminds me of that one line of Petit Computer code that crashed the game. My question is, how can the line of code you provided be used to edit the RAM? Is there other commands you can type in to do so?

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.

 

[Thee_BaBs]

edit:ninja'd

 

[seijinshu]

Prolly via programs and scripts. Would be VERY suprising if you wouldnt, since it would not allow you to debug your programs.

 

[seijinshu]

Prolly via programs and scripts. Would be VERY suprising if you wouldnt, since it would not allow you to debug your programs.

 

[Trinitro21]

You mentioned ram viewing was possible, how is that done?

The glitch makes the background layer data extend into the rest of the RAM, so simply triggering it and offsetting the background layer is enough to view the RAM. The data can also be retrieved with the BGGET command.

 

[seijinshu]

The glitch makes the background layer data extend into the rest of the RAM, so simply triggering it and offsetting the background layer is enough to view the RAM. The data can also be retrieved with the BGGET command.

Hmm. This would actually work with more investigating. Getting the ability to edit RAM would be such an excellent approach. If I successfully get my exploit working, we might be able to do a dual release kinda similar to IronHax/TubeHax.

 

[proflayton123]

Hmm. This would actually work with more investigating. Getting the ability to edit RAM would be such an excellent approach. If I successfully get my exploit working, we might be able to do a dual release kinda similar to IronHax/TubeHax.

.-.


Sent from my iPhone using Tapatalk

 

[seijinshu]

.-.


Sent from my iPhone using Tapatalk

Yeah, ik. I'm determined. If I don't work out, this one will do the trick
This one prolly exploitable

 

[proflayton123]

Yeah, ik. I'm determined. If I don't work out, this one will do the trick
This one prolly exploitable

Many people have already said on your thread many reasons behind it, although this looks more promising


Sent from my iPhone using Tapatalk

 

[Damon_girl]

Can this RAM editing be used for games too? Like on SSB or Hyrule Warriors Legends to make it play better on the old 3DS?

 

[KaduPSE]

Can this RAM editing be used for games too? Like on SSB or Hyrule Warriors Legends to make it play better on the old 3DS?

RAM editing means changing the code/values stored on RAM. The goal would be to replace them with exploitable code. It's not related to performance at all. RAM editing could be used to cheat on games, but since in this case the RAM is filled with data for this title it wouldn't be possible.

 

[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

 

[Pandaxclone2]

It's a shame that smileBASIC isn't even released in european countries. Anyway it'd be neat if this got anywhere; we need all the exploits we can get.

 

[Salamencizer]

It's a shame that smileBASIC isn't even released in european countries. Anyway it'd be neat if this got anywhere; we need all the exploits we can get.

Especially another primary one.

 

[seijinshu]

If you can, get smilebasic before it is gone... You will want it.

Sent from my LG-H811 using Tapatalk

 

[Clector]

Then buy it, no?

 

[Pandaxclone2]

It's worth getting anyway considering the open coding nature of it.

 

[Clector]

Well I was going to buy it, but because some things I wanted to buy before I will buy a eShop card this Thursday, but if there"s going to be an exploit it will be better to know so then I will buy it before since we know what Nintendo uses to do whit 3rd Party exploitable games.