Understanding memory mapping and adress calculations

Discussion in 'Wii U - Hacking & Backup Loaders' started by FunThomas, Mar 11, 2016.

  1. FunThomas
    OP

    FunThomas GBAtemp Fan

    Member
    404
    82
    Jan 10, 2016
    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
     
  2. NWPlayer123

    NWPlayer123 GBAtemp Addict

    Member
    2,629
    6,226
    Feb 17, 2012
    United States
    The Everfree Forest
    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
    Warning: Spoilers inside!
    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 and VinsCool like this.
  3. FunThomas
    OP

    FunThomas GBAtemp Fan

    Member
    404
    82
    Jan 10, 2016
    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 ?
     
  4. NWPlayer123

    NWPlayer123 GBAtemp Addict

    Member
    2,629
    6,226
    Feb 17, 2012
    United States
    The Everfree Forest
    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 :\)
     
    BullyWiiPlaza and FunThomas like this.