Homebrew LoadCode.S Question

Am I a derp?

  • Yes

    Votes: 5 45.5%
  • Beyond a doubt

    Votes: 2 18.2%
  • By all means

    Votes: 3 27.3%
  • Definitely

    Votes: 1 9.1%

  • Total voters
    11

gudenau

Largely ignored
OP
Member
Joined
Jul 7, 2010
Messages
3,821
Trophies
1
Location
/dev/random
Website
www.gudenau.net
XP
4,154
Country
United States
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!
 

yifan_lu

@yifanlu
Member
Joined
Apr 28, 2007
Messages
663
Trophies
0
XP
1,671
Country
United States
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

Well-Known Member
Member
Joined
Dec 8, 2014
Messages
5,145
Trophies
2
Location
Ohio
XP
4,615
Country
United States
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

Largely ignored
OP
Member
Joined
Jul 7, 2010
Messages
3,821
Trophies
1
Location
/dev/random
Website
www.gudenau.net
XP
4,154
Country
United States
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?
 

Helper

Well-Known Member
Member
Joined
Sep 14, 2009
Messages
136
Trophies
0
XP
227
Country
United States
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 ^_^
 
  • Like
Reactions: VinsCool

gudenau

Largely ignored
OP
Member
Joined
Jul 7, 2010
Messages
3,821
Trophies
1
Location
/dev/random
Website
www.gudenau.net
XP
4,154
Country
United States
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.
 
  • Like
Reactions: Helper

Helper

Well-Known Member
Member
Joined
Sep 14, 2009
Messages
136
Trophies
0
XP
227
Country
United States
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!
 
General chit-chat
Help Users
  • No one is chatting at the moment.
    KenniesNewName @ KenniesNewName: https://www.cnn.com/2022/09/27/business/mcdonalds-adults-happy-meal/index.html