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

  • Thread starter Thread starter Trinitro21
  • Start date Start date
  • Views Views 56,660
  • Replies Replies 445
  • Likes Likes 34
I don't think there's any possibility of Petit Computer being similarly exploitable. It doesn't have resizable background layers like SmileBASIC does, and so BGSREEN doesn't even exist there.
Very true. I know people are already looking into it though. IIRC, we can view memory in PTC. If so, it could be limited.
 
As trinitro said, there's pretty much a 0% chance of exploiting PTC via this method, because BGSCREEN doesn't exist.
Though, this being gbatemp people run off on the slightest piece of info. Good job staying on topic, guys.

TL;DR: don't try to exploit PTC you're wasting everyone's time.
Yep. We cannot use that method. But there are already people looking into PTC. I myself am too (I also like to screw around in it, so I'm not wasting time).
 
I don't want to be Debbie downer, but having used PTC on and off for around 3 years, I'm not convinced there's any exploit potential anywhere. Not gonna stop you from trying, though.
 
I wonder how many people have dumped their RAMs/WAMs :P

Here's my method:

First, open up SmileBASIC, and somehow get this code into it:

https://gist.github.com/MarcuzD/412da8fcf74a75b50ac357c6a5ccae9f

Usage:
- DPAD LEFT/RIGHT - move one pixel
- DPAD UP/DOWN - move one tile
- L/R - scroll really fast
- Y - set position to start of function list
- hold X - set starting position to dump RAM
- release X - set ending position to dump RAM


Now, get yourself a homebrew that can dump ExtData, and dump it, and somehow get the "###" folder on your PC

Download this code, and run `gcc b2bin.c -o b2bin`
https://gist.github.com/MarcuzD/dd2fee1b0f8725a4f167d1e37efc9665

Run `./b2bin BRAMDUMP`, and a few seconds later it should create a file named "BRAMDUMP.bin". This is your RAM dump converted to an analyzable format.
97226e6072.png
 
Last edited by Sono,
I would like to state first that I fully support this project in terms of being an ARM11 userland entrypoint. However, I would also like to state that the way to which Native_FIRM and TWL_FIRM operate is vastly different. While TWL_FIRM is still relatively unexplored, or rather documented for the majority, there are some known factors. I have minorly read into it, so if anything I state is incorrect, feel free to correct. I just can't stand by and read all these replies about using PetitComputer to take control of the ARM9 kernel.

The first factor being that the NTR base of TWL_FIRM is extremely bare minimum. It was written to execute from Slot-1 to interact with the cartridge, and little more was done. Nintendo did all they needed, and did not make it anymore luxurious. Interaction with other pieces of hardware, such as the SD card from the NTR base are sandboxed. Secondly, the way that the NTR base is able to affect FCRAM, or really any part of memory, is again, limited. This gives a limited space and limited options to actually view from the BGLayer overflow. Finally, the NTR base of TWL_FIRM does not interact with any kernel, rather each cartridge has baremetal code needed for each of its purposes. Each cartridge is dependent solely on itself, and contained inside of a sandbox that the ARM9 kernel is unreachable from. These factors all make the concept of taking control of everything needed become more and more implausible.

Again, I may totally incorrect, so feel free to correct me. Edit: I was under the impression that Petit Computer was a cartridge, not DSiware.
 
Last edited by Seedbon,
  • Like
Reactions: VegaRoXas
I would like to state first that I fully support this project in terms of being an ARM11 userland entrypoint. However, I would also like to state that the way to which Native_FIRM and TWL_FIRM operate is vastly different. While TWL_FIRM is still relatively unexplored, or rather documented for the majority, there are some known factors. I have minorly read into it, so if anything I state is incorrect, feel free to correct. I just can't stand by and read all these replies about using PetitComputer to take control of the ARM9 kernel.

The first factor being that the NTR base of TWL_FIRM is extremely bare minimum. It was written to execute from Slot-1 to interact with the cartridge, and little more was done. Nintendo did all they needed, and did not make it anymore luxurious. Interaction with other pieces of hardware, such as the SD card from the NTR base are sandboxed. Secondly, the way that the NTR base is able to affect FCRAM, or really any part of memory, is again, limited. This gives a limited space and limited options to actually view from the BGLayer overflow. Finally, the NTR base of TWL_FIRM does not interact with any kernel, rather each cartridge has baremetal code needed for each of its purposes. Each cartridge is dependent solely on itself, and contained inside of a sandbox that the ARM9 kernel is unreachable from. These factors all make the concept of taking control of everything needed become more and more implausible.

Again, I may totally incorrect, so feel free to correct me.
NTR has nothing to do with PTC. If we were able to exploit arm9, we get arm9 kernel. There is nothing below arm9 kernel in arm9 which is what TWL runs on. If we exploit TWL, we get arm9 Kernel. And TWL also is DSiWare. If we got arm9 code execution, even in twl, we could (just a theory) make a firm launch like the 9.2 arm9 exploit.
 
NTR has nothing to do with PTC. If we were able to exploit arm9, we get arm9 kernel. There is nothing below arm9 kernel in arm9 which is what TWL runs on. If we exploit TWL, we get arm9 Kernel. And TWL also is DSiWare. If we got arm9 code execution, even in twl, we could (just a theory) make a firm launch like the 9.2 arm9 exploit.
No, when you get twl (dsiware) execution, you don't get 3ds mode arm9 -- it's completely locked out by that point.

You can, however, access raw 3ds NAND. All of it, including FIRM0 and FIRM1. This currently enables known-plaintext attacks to downgrade any version of native_firm from 9.6 - 10.7.

So IF someone got control of PTC, they could downgrade if they're at 11.0. They, of course, would need 3ds user hax too to perform the actual downgrade from the 11.0/10.7 hybrid firmware to 9.2.
 
Last edited by zoogie,
NTR has nothing to do with PTC. If we were able to exploit arm9, we get arm9 kernel. There is nothing below arm9 kernel in arm9 which is what TWL runs on. If we exploit TWL, we get arm9 Kernel. And TWL also is DSiWare. If we got arm9 code execution, even in twl, we could (just a theory) make a firm launch like the 9.2 arm9 exploit.
I was under the impression that Petit Computer was a cartridge based game. I never owned a DSi, so I am unfamiliar with DSiwarw. From what I've read, DSi (TWL) software and DS (NTR) hardware+software act in much different ways from inside of TWL_FIRM, which is why I referred to it as the NTR base. I may, again, be completely incorrect in stating that. That was the premise of my reply, though.
 
I was under the impression that Petit Computer was a cartridge based game. I never owned a DSi, so I am unfamiliar with DSiwarw. From what I've read, DSi (TWL) software and DS (NTR) hardware+software act in much different ways from inside of TWL_FIRM, which is why I referred to it as the NTR base. I may, again, be completely incorrect in stating that. That was the premise of my reply, though.
Nope it's dsiware
 

Site & Scene News

Popular threads in this forum