6,264
edits
Changes
Jump to navigation
Jump to search
Line 26:
Line 26: + + + +
→loader
* L_140025f0(L_140024e4 in previous loader version) now calls another function(L_14002670) instead of svcControlMemory directly, for mapping the codebin memory. The insp4 flag from the L_140025f0 input is passed to L_14002670 as sp0.
* L_140025f0(L_140024e4 in previous loader version) now calls another function(L_14002670) instead of svcControlMemory directly, for mapping the codebin memory. The insp4 flag from the L_140025f0 input is passed to L_14002670 as sp0.
* L_14002670: New function used for mapping the codebin. When the insp0 flag is zero, this does the normal memory-mapping, otherwise a special memory-mapping codepath is used. This codepath still uses the same memregion specified in the exheader.
* L_14002670: New function used for mapping the codebin. When the insp0 flag is zero, this does the normal memory-mapping, otherwise a special memory-mapping codepath is used. This codepath still uses the same memregion specified in the exheader.
The special memory-mapping codepath is basically a method of mapping the codebin with svcControlMemory using up to 8 chunks, each with a random size. Each chunk is done in a random order. Since the allocation order is random, this also means the order of each .text chunk in physmem is random too. When the total size of the randomized page-count is less than the required amount, an 8th chunk is used to pad the total size to the exact required size. It appears the total combined size used with svcControlMemory is ''always'' exactly the same as what's required for the codebin.
This is an attempt at randomizing the layout of physmem, due to gspwn.
===NS===
===NS===