Changes

Jump to navigation Jump to search
1,549 bytes added ,  07:21, 6 June 2016
→‎Process9: (Finally verified, there appears to be no other install-commit commands.)
Line 18: Line 18:     
====loader====
 
====loader====
Exactly one function was updated: L_140022b8(same addr as previous version).
+
Exactly one function was updated: L_140022b8 (same addr as previous version).
   −
The codebin physical-memory randomization code introduced with [[10.4.0-29]] was updated so that it's now used for OoT3D and Cubic Ninja(checked in the same aforementioned order), for the USA+EUR+JPN titles. This means oot3dhax and ninjhax need updated to handle this. Using the pre-sysupdate exploit versions will result in the title randomly crashing, if you retry enough times it should run fine however.
+
The codebin physical-memory randomization code introduced with [[10.4.0-29]] was updated so that it's now used for OoT3D and Cubic Ninja (checked in the same aforementioned order), for the USA+EUR+JPN titles. This means oot3dhax and ninjhax need to be updated to handle this. Using the pre-sysupdate exploit versions will result in the title randomly crashing. However, if you retry enough times, it should run fine.
    
====pm====
 
====pm====
 
Two functions were updated for calling a new function for exheader handling.
 
Two functions were updated for calling a new function for exheader handling.
   −
This new function at L_101cfc immediately returns when the input programID isn't a CTR title / Cubic Ninja(USA/EUR/JPN uniqueID). This function removes all services in the exheader service-access-control which match services from a blacklist stored in pm-module. This blacklist contains two services: "http:C" and "soc:U".
+
This new function at L_101cfc immediately returns when the input programID isn't a CTR title / Cubic Ninja (USA/EUR/JPN uniqueID). This function removes all services in the exheader service-access-control which match services from a blacklist stored in pm-module. This blacklist contains two services: "http:C" and "soc:U".
    
This breaks QR-code ninjhax with the version available at the time of sysupdate release, since the QR-code build downloads the payload via HTTPC.
 
This breaks QR-code ninjhax with the version available at the time of sysupdate release, since the QR-code build downloads the payload via HTTPC.
    
====ARM11-kernel====
 
====ARM11-kernel====
57 functions were updated, 47 of these are the actual functions used for handling SVCs(see below). The lone function updated with v10.4 was updated with this version again.
+
57 functions were updated, 47 of these are the actual functions used for handling SVCs (see below). The lone function updated with v10.4 was updated with this version again: Checks were added to make sure all the previously allocated memchunks are actually located within the requested memory region. This was implemented with the following checks which are done for each memchunk separately - right before clearing and mapping each one to the requested vaddr.
 +
if((region_base > memchunk_addr) || ((region_base + region_size) < (memchunk_addr + memchunk_size<<12))) { kernel_panic(); }
 +
The actual ToCToU race has not been fixed (see [[3DS System Flaws|memchunkhax2.1]]).
   −
3 new functions used for validation with memory management were added (kernelpanic() on failure). This is a new security feature for the kernel heaps. By adding a MAC to the kernel heap [[Memory_Management#MemoryBlockHeader|memchunkhdr]] they can detect when it is modified by an outside DMA device ([[3DS_System_Flaws|gspwn]]).
+
3 new functions used for validation with memory management were added (kernelpanic() on failure). This is a new security feature for the kernel heaps. By adding a MAC to the kernel heap [[Memory Management#MemoryBlockHeader|memchunkhdr]] they can detect when it is modified by an outside DMA device ([[3DS System Flaws|gspwn]]).
    
The MAC itself is custom based on xor-rot-sub-mul, and is calculated as follows (pseudo-code):
 
The MAC itself is custom based on xor-rot-sub-mul, and is calculated as follows (pseudo-code):
   −
  u32* crypto_state = (u32*) r4; // Safe kernel memory. This is actually the [[Memory_Management#RegionDescriptor|RegionDescriptor]].
+
  u32* crypto_state = (u32*) r4; // Safe kernel memory. This is actually the [[Memory Management#RegionDescriptor|RegionDescriptor]].
 
  u32* data_ptr = (u32*) lr; // Unsafe FCRAM pointer.
 
  u32* data_ptr = (u32*) lr; // Unsafe FCRAM pointer.
 
   
 
   
Line 46: Line 48:  
  for(size_t i=0; i<2; i++) {
 
  for(size_t i=0; i<2; i++) {
 
     for(size_t j=0; j<5; j++) {
 
     for(size_t j=0; j<5; j++) {
         r0 -= data_ptr[j] + (r1 >>> 3)
+
         r0 -= (r1 >>> 3) - data_ptr[j]
         r1 -= (r3 >>> (r2 & 0xf + 3)) ^ (r2 >>> (r0 & 0xf + 13))
+
         r1 -= (r3 >>> ((r2 & 0xf) + 3)) ^ (r2 >>> ((r0 & 0xf) + 13))
 
         r3 -= (r2 >>> r0) * r1
 
         r3 -= (r2 >>> r0) * r1
 
         r2 -= (r0 >>> r1) * r3
 
         r2 -= (r0 >>> r1) * r3
Line 60: Line 62:  
The function which initializes a memalloc heap had a major update (used for FCRAM memregions and the SlabHeap container). It generates a random MAC key based on svcGetSystemTick, like this:
 
The function which initializes a memalloc heap had a major update (used for FCRAM memregions and the SlabHeap container). It generates a random MAC key based on svcGetSystemTick, like this:
   −
  crypto_state[16/4] = 0 //This is actually the [[Memory_Management#RegionDescriptor|RegionDescriptor]].
+
  crypto_state[16/4] = 0 //This is actually the [[Memory Management#RegionDescriptor|RegionDescriptor]].
 
  crypto_state[20/4] = 0
 
  crypto_state[20/4] = 0
 
  crypto_state[24/4] = 0
 
  crypto_state[24/4] = 0
Line 82: Line 84:  
The function handling the arm11kernel exheader descriptors was updated, if anything changed besides the kernel-version value it seems minor.
 
The function handling the arm11kernel exheader descriptors was updated, if anything changed besides the kernel-version value it seems minor.
   −
The first 47 updated functions are used for the actual SVC handling. It seems each change just added code at the start of the function for initializing the output data. This includes SVCs which were already stubbed. Updated SVCs for this, in the same order as the arm11kernel code binary:
+
The first 47 updated functions are used for the actual SVC handling. It seems each change just added code at the start of the function for initializing the output data. This includes SVCs which were already stubbed. All of the updated SVCs for this, in the same order as the arm11kernel code binary:
 
{| class="wikitable" border="1"
 
{| class="wikitable" border="1"
 
|-
 
|-
Line 140: Line 142:  
|-
 
|-
 
| svcGetHandleInfo
 
| svcGetHandleInfo
| The code which clears the variables that get written into the output 8-byte buffer, was moved to before the code which checks the input type value(previously this was only executed for type 0x32107).
+
| The code which clears the variables that get written into the output 8-byte buffer, was moved to before the code which checks the input type value (previously this was only executed for type 0x32107).
 
|-
 
|-
 
| svcGetSystemInfo
 
| svcGetSystemInfo
Line 191: Line 193:  
|-
 
|-
 
| svcGetThreadPriority
 
| svcGetThreadPriority
 +
| None
 +
|-
 +
| svcDebugActiveProcess
 +
| None
 +
|-
 +
| svcQueryProcessMemory
 +
| None
 +
|-
 +
| svcCreateResourceLimit
 +
| None
 +
|-
 +
| svcCreateSessionToPort
 +
| None
 +
|-
 +
| svcCreateAddressArbiter
 +
| None
 +
|-
 +
| svcGetProcessIdOfThread
 +
| None
 +
|-
 +
| svcWaitSynchronizationN
 +
| None
 +
|-
 +
| svcGetThreadIdealProcessor
 +
| None
 +
|-
 +
| svcQueryDebugProcessMemory
 +
| None
 +
|-
 +
| svcGetProcessIdealProcessor
 +
| None
 +
|-
 +
| svcControlPerformanceCounter
 +
| None
 +
|-
 +
| svcStartInterProcessDma
 
| None
 
| None
 
|}
 
|}
    
====Process9====
 
====Process9====
Various data was moved around in the .data section(.data is  0x99C-bytes smaller than before).
+
Various data was moved around in the .data section (.data is  0x99C-bytes smaller than before).
   −
Before installing titles, including NATIVE_FIRM, AMPXI will now check the version of the title to install against a hard-coded list of (titleID, minimumVersionRequired) pairs. This applies to  MSET, Home Menu, spider, ErrDisp, SKATER, NATIVE_FIRM, and every retail system module.
+
The only actual change in .text was that only one function was updated. This function is only called by [[AMPXI:InstallTitlesFinish]] and [[AMPXI:InstallTitlesFinishFIRM]]. Right after the mediatype validation at the very beginning of the function, a code block was added for the functionality described below which is only executed on [[CONFIG_Registers#CFG_UNITINFO|retail]].
   −
This effectively prevents downgrading.
+
This AMPXI function will now check the high 6-bits of the title-version(major-version) of the title to finish-install against a hard-coded list of (titleID, minimumVersionRequired) pairs. This list is identical for Old3DS/New3DS Process9. This applies to  MSET, Home Menu, spider, ErrDisp, SKATER, NATIVE_FIRM, and every retail system module. When the title-version is invalid, this returns the invalid title-version error(0xD8E08027).
   −
AMPXI_InstallFIRM's firm-writing code has changed, though it seems it is only a refactor.
+
This prevents downgrading on the ARM11 side via AM-service access.
    
====New3DS====
 
====New3DS====
 
The arm9loader wasn't changed at all.
 
The arm9loader wasn't changed at all.
 +
 +
Nothing New3DS-only changed in Process9.
    
===friends-sysmodule===
 
===friends-sysmodule===
Only the value used for fpdver changed in the codebin, from 5 to 6.
+
Only the value used for fpdver changed in the codebin, from 5 to 6. This is not required server-side yet, last checked on May 11, 2016.
    
===IR-sysmodule===
 
===IR-sysmodule===

Navigation menu