Physical memory.

I was looking into porting Loadiine GX to 4.0.0.

Yes, I know that it's pointless and not so straightforward as for 410+, but the main goal of this project is learning.

So, first big problem is physical memory layout. Seems like 410+ have similar memory layout that looks like this: http://wiiubrew.org/wiki/Physical_Memory. At least 4.1.0-5.4.0 have coreinit + loader at 0x32000000 to 0x327FFFFF. 4.0.0 has that stuff at 0x4D000000 - 0x4D7FFFFF.

So, my questions:
1. Is physical memory layout of old firmwares documented somewhere?
2. How can we find physical location of module that does not export any functions (i.e root.rpx)?
3. What is the best way to dump memory?

 

I was more interested in physical memory dump. But it seems like that is not possible. From other hand dumping virtual ranges might also be useful. Does TCPGecko allow me to download dumps of address ranges?

Are you talking about virtual addresses? loader and coreinit seem to be 0x01000000 - 0x18000000 on every fw version, but physical address is different (at least for <= 400).

 

From what I see it matters a lot.
1. Installer writes jump hook into coreinit func by using 0xA0000000 -> 0x10000000 rw mapping. For firmwares 4.1-5.4 coreinit + laoder are at 0x32000000 physical, so virtual rw address is 0xC2000000, or if want to reuse address from readonly mapping - 0xC1000000 + readonly virtual address. For 400 fw phys address is 0x4D000000, so to hook coreinit we need to change those addresses (luckily they are still before the end of writable mapping).
2. Installer loads sd_loader into some adress that it search starting from 0xC0000000 and then it loads rpx into 0xC0800000. From what I see this area is reserved for root.rpx. But I have no idea what it is for 400.
3. I can not keep up with the offset by just changing 0xA0 mapping to 0x10000000 + (0x4D000000-0x32000000), because if I do this, browser fails on second start. It fails on loading (before it shows address bar / html page), so this just setting such mapping already breaks browser.

Thanks for hint with TCPGecko. That should help a lot.

 

I don't want to make more threads, so I'll add my new question here.

I couldn't make tcpGecko work on 4.0.0. It load good, but after pressing any button it blackscreens and client app does not connect while in browser.
Then I remembered that libwiiu has similar thing. They call it rpc and it does pretty much similar thing.
So I tried to run it on top of kernel that maps 0xA... to 0x30000000 to be able to access memory ranges that are interesting to me (those are actually 0x30000000-0x50000000). I've tested several things just to check if this works. Then I decided to dump memory in 0x10000000 ranges. First range (0xA0000000 - 0xAFFFFFFF) dumped without problems and looks good. But the second range (0xB0000000-0xBFFFFFFF) is mostly zeroes with several very small intervals that are filled with random stuff that does not make any sense. The problem is I know for sure that 0xBD000000+ in such mapping is coreinit. It resolves correctly to physical in IDLE. The address of the function in coreinit was ‭4D01C76C‬. This area was filled in zeroes in prev dump. But when I tried to dump and read ‭(0xBD01C76C‬, 0x100) it showed me correct values (the same as coreinit lib from NUS). All of this one done in one IDLE/rpc session. I tried to dump that second area two time - one after dumping first range, second - after i checked if (0xBD01C76C‬, 0x100) is correct.

So, today I'll test this with fresh connection/rpc session (maybe dumping first 256 MB block messed up python memory) and then I'll test with smaller ranges.

But has someone experienced something like this? This is super annoying and I have no idea were the problem is.

 

I've specified it several times. I'm on 4.0.0.

 

Ok, finally i managed to find those physical address changes and successfully managed to port HBL/Loadiine to 4.0.x. I'll provide a brief explanation of my investigation since it might help someone in porting HBL to even earlier firmwares.

So first of all look at this page http://wiiubrew.org/wiki/Physical_Memory HBL uses physical addresses of root.rpx and loader+coreinit.rpl and relies on fact that they are always the same. But that's true only for 4.1.0+ firmwares.

To experiment with these thing best instrument is rpc from libwiiu. It allows us to call OSEffectiveToPhysical form python shell, making experiments with addresses simple since we don't need to recompile app to test other addresses. Other great thing about this tool that it does not require kernel access, so it makes our work so much faster.

So, first of all, we need to understand that physical layout was actually changed. Go here http://wiiubrew.org/wiki/Cafe_OS and look through the virtual mapping table. Virtual range 0x01000000 - 0x01800000 is always mapped to loader and coreinit. So we simply call OSEffectiveToPhysical(0x01000000) and for 4.0.x we receive 0x4D000000 (it's 0x32000000 for 4.1+, so that's a pretty big difference).

But I still needed to find toot.rpx since hbl uses free space reserved for root.rpx to load elfs/rpls. My first idea was really horrible. I decided to map physical memory that is interesting for me to 0xA0000000 and then dump it using rpc. The problem was - dumps were inconsistent. Occasionally memory that was reserved for coreinit returned me dump full of zeroes or some garbage. Moreover the process of dumping is very slow. So I wasted several days with 0 result.

So i decided to be smarter. I've found an interesting virtual range - 0x10000000 - 0x50000000. It seems like it is mapped to different parts of MEM2 region depending on the running process RAMPID (All of this is described on those two links that I specified previously). The problem here is that we run our rpc from browser, so we can find out only the address of "Background app" area (according to Cafe OS page). But that's at least something. So we do OSEffectiveToPhysical(0x10000000) and receive 0x30000000 (address of root.rpx for 4.1+ lol). Then I made a desperate move. I knew for sure that mapping for static regions like 0x01000000 to coreinit and that 0xA0000000 stuff is specified in the kernel in the table and we know addresses of those tables (since kernel exploit updates this table to change mapping of 0xA0000000). So I was pretty sure that there should be similar table for 0x10000000 that specifies where should we map that area depending on RAMPID. So I simply searched kernel for value 0x30000000 and to my surprise there were only two occurrences of that value and one of them was actual map table.

So now let's look into this table and see what happened to those physical layouts. First of all - it seems like table contains of 3-property tuples (RAMPID, PhysicalAddressStart, RangeLength). And there are two very similar tables one after the other. The only difference between them is last entry - that's probably that difference in memory size for devkits. Next let's see into the actual tables for different firmwares. I provide (RAMPID, PhysicalAddressStart, RangeLength) and for the last entry alternative value from the second table in parentheses.

Let's start with 5.3.2.
5, 0x28000000, 0x8000000 - Home Menu
1, 0x30000000, 0x2000000 - root.rpx
6, 0x33000000, 0x1000000 - Error display
4, 0x34000000, 0x1C000000 - Background app memory
7, 0x50000000, 0x80000000 (7, 0x50000000, 0x40000000) - Foreground app memory
Nothing special here. Everything is the same as in Physical memory page, so we can use names from there to have a better understanding of who is who. The only range that is not in the table is 0x32000000, 0x1000000 - loaer + coreinit.

Next let's continue with 4.1.0
4.1.0
4, 0x28000000, 0x8000000 - Home Menu
2, 0x30000000, 0x2000000 - root.rpx
6, 0x32000000, 0x1000000 - loader + coretinit.rpl
3, 0x33000000, 0x1000000 - Error display
1, 0x34000000, 0x1C000000 - Background app memory
7, 0x50000000, 0x80000000 (7, 0x50000000, 0x40000000) - Foreground app memory
As you can see sizes, addresses and order of areas are the same. But there is a loader+coreinit section here. And it seems like later firmware changed RAMPIDs.

And finally 4.0.0
4, 0x28000000, 0x8000000 - Home Menu
1, 0x30000000, 0x1C000000 - Background app memory
3, 0x4C000000, 0x1000000 - Error display
6, 0x4D000000, 0x1000000 - loader + coretinit.rpl
2, 0x4E000000, 0x2000000 - root.rpx
7, 0x50000000, 0x80000000 (7, 0x50000000, 0x40000000) - Foreground app memory
As you can see that even though addresses and order (they seem to be actually ordered by address) were changed, RAMPIDs are the same as for 4.1.0, so we can easily identify the areas.

Big thanks to everyone who replied to this thread. And special thanks to @dimok for helping me in IRC.

 

By the time I saw your pr, I already ported it myself. It didn't help me though. The only difference between your and mine ports are addresses where codehandler is copied. It seems like that area contains some data. So I used the same as for 3.2.1 (it's full of zeroes on 4.0.x).