6,264
edits
Changes
Jump to navigation
Jump to search
Line 29:
Line 29: − + + + + + + + +
→loader
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.
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.
Regarding chunk size calculation:
* s32 maxval = (codebin_totalrequiredpages - pagepos) >> 4;
* The above maxval field is set to 15 if it's >=15.
* pagecount = L_14001730(maxval);
* pagecount = (pagecount+1) << 4;
* chunksize = pagecount << 12;
This is an attempt at randomizing the layout of physmem .text, due to gspwn.
===NS===
===NS===