Hacking Understanding memory mapping and adress calculations

FunThomas

Well-Known Member
OP
Member
Joined
Jan 10, 2016
Messages
652
Trophies
0
XP
2,016
Country
Gambia, The
Hi,

i have a question regarding memory mapping and the calculations for the pointers.
I will describe what i think about it and please correct me if i'm wrong.

with the following lines we set the mapping of the adress 0xA0000000

for loadiine to adress 0x10000000 with
kern_write((void*)(KERN_ADDRESS_TBL + (0x12 * 4)), 0x10000000);

and for Saviine, Dumpiine ... to 0x31000000 with
kern_write((void*)(KERN_ADDRESS_TBL + (0x12 * 4)), 0x31000000);

and set the permissions for this memory area to 0x28305800 (whatever that means)
kern_write((void*)(KERN_ADDRESS_TBL + (0x13 * 4)), 0x28305800);


When i look at
http://wiiubrew.org/wiki/Cafe_OS#Virtual_Memory_Map

i see for loadiine it is set to the same physical and virtual adress 0x10000000

but why it it set to 0x31000000 for the other tools ?
i see at physical adress 0x32000000 starts the Loader and system libraries but why map this to 0x31000000 ?


then i have a question about the following block of code taken from pygecko

/* Our main writable area */
unsigned int physWriteLoc = (unsigned int)OSEffectiveToPhysical((void*)RW_MEM_MAP);

/* Install codehandler */
unsigned int phys_codehandler_loc = (unsigned int)OSEffectiveToPhysical((void*)INSTALL_ADDR);
void *codehandler_loc = (unsigned int*)(RW_MEM_MAP + (phys_codehandler_loc - physWriteLoc));

...

/* Patch coreinit jump */
unsigned int phys_main_jmp_loc = (unsigned int)OSEffectiveToPhysical((void*)MAIN_JMP_ADDR);
unsigned int *main_jmp_loc = (unsigned int*)(RW_MEM_MAP + (phys_main_jmp_loc - physWriteLoc));

*main_jmp_loc = doBL(INSTALL_ADDR, MAIN_JMP_ADDR);
DCFlushRange(ALIGN_BACKWARD(main_jmp_loc, 32), 0x20);
ICInvalidateRange(ALIGN_BACKWARD(main_jmp_loc, 32), 0x20);

with the following defines:
#define INSTALL_ADDR 0x011DD000
#define MAIN_JMP_ADDR 0x0101C55C
#define RW_MEM_MAP 0xA0000000

why is the RW_MEM_MAP recalculated to physWriteLoc (same for phys_codehandler_loc or phys_main_jmp_loc)

normally when using pygecko
RW_MEM_MAP 0xA0000000 is mapped to 0x31000000 so the result maybe physWriteLoc = 0x31000000
INSTALL_ADDR 0x011DD000 is mapped to 0x321DD000 so the result maybe phys_codehandler_loc = 0x321DD000

so the difference of these maybe (phys_main_jmp_loc - physWriteLoc) == INSTALL_ADDR 0x011DD000 ?

is at 0x011DD000 or 0x0101C55C some special Loader and system libraries on 5.3.2 ?


and then there is the function
*main_jmp_loc = doBL(INSTALL_ADDR, MAIN_JMP_ADDR);

as is see it makes sure the adress (0x001C0AA4) will be lower than 0x03FFFFFC
and the adds 0x48000001 to the adress and the result will be 0x481C0AA5

why ?

i hope someone of you can make my vision some kind more clear :)

thx in advance
 

NWPlayer123

Well-Known Member
Member
Joined
Feb 17, 2012
Messages
2,642
Trophies
0
Location
The Everfree Forest
XP
6,693
Country
United States
It's 0xA0000000 -> 0x31000000 because that's the original value we mapped it to with the OSDriver exploit, somewhere into making loadiine, dumpiine, saviine, golden45 made the kernel exploit map 0xA0000000 -> 0x10000000 and made his apps require it. Basically it lets us write to that area, in my TCPGecko installer, the patch_addr that jumps to run the codehandler when an app is started is 0xA101C56C, since 0x0101C56C (or C55C in 5.3.2) is the bctrl in start in coreinit before it calls exit, since coreinit itself starts 0x0101C400
Screenshot_59.png
All you need to do to write to 0x010000000 is add the 0xA0 to offset so we can read/write to it, which is why it's the "base". The 0x11DD000, from my memdumps, looks like the first free section we can install something without overwriting other libraries in the section. The 0x48000001 is the base opcode for the bl instruction, so it branches to our code and then links. it ORs it with the address to branch to the address we want.
 

FunThomas

Well-Known Member
OP
Member
Joined
Jan 10, 2016
Messages
652
Trophies
0
XP
2,016
Country
Gambia, The
the jump from the coreinit -> is it always made whatever i start -> no difference between miimaker or smashbros ? or are there other apps it is started ?
 

NWPlayer123

Well-Known Member
Member
Joined
Feb 17, 2012
Messages
2,642
Trophies
0
Location
The Everfree Forest
XP
6,693
Country
United States
the jump from the coreinit -> is it always made whatever i start -> no difference between miimaker or smashbros ? or are there other apps it is started ?
As far as I know the "app entry" address I've seen somewhere, I think in Cafiine, is universal. And the coreinit jump should also be universal since coreinit is technically always loaded, even after IM_Close. It just doesn't work from normal apps to quick launch apps (EG loading Splatoon and trying to load the Friends List will softlock everything for whatever reason :\)
 

Site & Scene News

Popular threads in this forum

General chit-chat
Help Users
  • No one is chatting at the moment.
    Maximumbeans @ Maximumbeans: butte