Homebrew LoadCode.S Question

[gudenau]

There is one small part of Yifan's LoadCode.S that I can not understand, I think it has to do with how the GPU sees the memory verses the CPU. It loads the code to 0x19592000 with gspwn, then jumps to 0x009D2000. How does this execute the code exactly? Am I missing a part of the memory mapping, some rop gadget 0x009D2000?

Any help would be greatly appreciated!

 

[Myria]

The GPU uses physical addresses whereas processes use virtual addresses.

 

[gudenau]

The GPU uses physical addresses whereas processes use virtual addresses.

So, on what is the mapping for 9.2?

 

[yifan_lu]

The GPU uses physical addresses whereas processes use virtual addresses.

Close. It translates virtual addresses to physical addresses. FCRAM physical address 0x20000000 is mapped to 0x14000000 (*but not really. it isn't mapped but the address is sitting there waiting to be mapped. the reason we need gspwn is because we normally can't tell the kernel to map any address we want in this range). However, 0x009D2000 is mapped to FCRAM physical address 0x25592000. As you can see, it is accessible by two different addresses.

Source: http://3dbrew.org/wiki/Memory_layout

 

[DarkFlare69]

Close. It translates virtual addresses to physical addresses. FCRAM physical address 0x20000000 is mapped to 0x14000000 (*but not really. it isn't mapped but the address is sitting there waiting to be mapped. the reason we need gspwn is because we normally can't tell the kernel to map any address we want in this range). However, 0x009D2000 is mapped to FCRAM physical address 0x25592000. As you can see, it is accessible by two different addresses.

Source: http://3dbrew.org/wiki/Memory_layout

Btw yifan_lu I can't get it to dump my memory even when I uncommrnt the FCRAM dump parts. (Off topic ^)

 

[gudenau]

Close. It translates virtual addresses to physical addresses. FCRAM physical address 0x20000000 is mapped to 0x14000000 (*but not really. it isn't mapped but the address is sitting there waiting to be mapped. the reason we need gspwn is because we normally can't tell the kernel to map any address we want in this range). However, 0x009D2000 is mapped to FCRAM physical address 0x25592000. As you can see, it is accessible by two different addresses.

Source: http://3dbrew.org/wiki/Memory_layout

So, add 0x24BC0000 to get the physical address?

 

[yifan_lu]

No. It depends on how the 3DS allocates the memory.

 

[gudenau]

No. It depends on how the 3DS allocates the memory.

On 9.2 in SPIDER.

 

[Helper]

I've been analyzing LoadCode.S, too, trying to better 'understand' ROP.

I have a dump of the spider applet RAM (made with MemoryDump.S, of course).

I started with the third word of the ROP chain (0x0019CA34) which is supposed to perform "FS_MOUNTSDMC()". Using the value as a function pointer, I followed a process of
1.) disassembling data at the current address
2.) finding the first flow-control instruction (in this case, always a BL instruction)
3.) following the address, setting my new "current address" to the target address.

After a few cycles of this, I reached the "end"--a span of code which does not perform any flow control before returning. Specifically, I followed the execution path to virtual address 0x002443e4 (RAM dump offset 0x001443e4). At this address is the instruction "SVC 0x32", immediately followed by a "BX lr".

I have not yet analyzed any other part of this execution path--that is, any code after the first flow-controlling instruction in a code block. Perhaps this would help my understanding further.

I suppose I'm looking for a sanity check. If I had one question, (nebulous as it is) it would be "am I on the right track?".
Other, more specific questions would include:
* Are SVC instructions the main method by which userland code accesses system functions?
* Should userland code ever attempt to branch outside of the 0x00100000 process region?
* Does userland code ever interact "directly" with NATIVE_FIRM code?
* Is a decrypted set of the (in this case, 9.2) NATIVE_FIRM titles needed to fully understand the ROP chain process?

Many thanks in advance to anybody who reads this atrocity of a post

 

[gudenau]

I've been analyzing LoadCode.S, too, trying to better 'understand' ROP.

I have a dump of the spider applet RAM (made with MemoryDump.S, of course).

I started with the third word of the ROP chain (0x0019CA34) which is supposed to perform "FS_MOUNTSDMC()". Using the value as a function pointer, I followed a process of
1.) disassembling data at the current address
2.) finding the first flow-control instruction (in this case, always a BL instruction)
3.) following the address, setting my new "current address" to the target address.

After a few cycles of this, I reached the "end"--a span of code which does not perform any flow control before returning. Specifically, I followed the execution path to virtual address 0x002443e4 (RAM dump offset 0x001443e4). At this address is the instruction "SVC 0x32", immediately followed by a "BX lr".

I have not yet analyzed any other part of this execution path--that is, any code after the first flow-controlling instruction in a code block. Perhaps this would help my understanding further.

I suppose I'm looking for a sanity check. If I had one question, (nebulous as it is) it would be "am I on the right track?".
Other, more specific questions would include:
* Are SVC instructions the main method by which userland code accesses system functions?
* Should userland code ever attempt to branch outside of the 0x00100000 process region?
* Does userland code ever interact "directly" with NATIVE_FIRM code?
* Is a decrypted set of the (in this case, 9.2) NATIVE_FIRM titles needed to fully understand the ROP chain process?

Many thanks in advance to anybody who reads this atrocity of a post

First some basics on ROP, just in case. ROP is an abbreviation for Return Oriented Programming. What this means in a nutshell is you corrupt the return path of the code to change it, making it do what you want. This gets around the Execute Never bit because it is not executing in the stack, like "classic" stack smashing.

In order to get the values to make a ROP chain you need to get a RAM dump or an executable to find the gadgets. Then you write some assembly with the gadgets.


You really do not need to worry about the functions like fs_mountsdmc, you just need to know how to return to them in a way that you can use them. The more important ones are pops, str, ldr, mov. With these you can do just about anything you want, provided you find the correct ones.

SVC is an special instruction, SuperVisor Call. What this means is it calls the kernel (in this case the ARM11 kernel). It then jumps to a function in kernel land based on it's parameter. Here is a list.

So, to answer the bullets:

• Yes.
• Yes, it is bigger than the area that memdump dumps. It can be upto 0x03F00000 in size. Other than that the and the svc, it should never leave that region under 'normal' operation.
• Kinda, svc.
• You just need a memory dump that contains your ROP gadgets.

Your post was not that bad.

 

[Helper]

Excellent. Yeah, I already knew the generalities of ROP, that was probably poorly worded. Even so, I appreciate the explanation and I'm sure it'll help somebody else sooner or later.

I understand that the 'user' doesn't need to know about things like fs_mountsdmc, I'm just trying to get a better understanding of how the entire exploit works, under the hood, so-to-speak. For a while, I had no idea where the name "FS_MOUNTSDMC" even came from. Somehow, I assumed it was a library function or something. Now, I'm assuming it's just an ad-hoc name 'invented' for a function in spider itself. Which makes much more sense, actually.

If I can safely make the assumptions that (well-behaved) userland code 1.) only jumps to addresses within its own memory region 2.) only interfaces with kernel-land via SVC instructions, understanding everything becomes much easier (for my current purposes, at least).

All very interesting, very useful. Thanks!