Difference between revisions of "11.0.0-33"

From 3dbrew
Jump to navigation Jump to search
(→‎Process9: (Finally verified, there appears to be no other install-commit commands.))
(29 intermediate revisions by 6 users not shown)
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, at least 48 of these are the actual functions used for handling SVCs. 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 48 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. 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
 +
| None
 +
|-
 +
| svcGetThreadInfo
 +
| None
 +
|-
 +
| svcGetThreadList
 +
| None
 +
|-
 +
| svcSignalAndWait
 +
| None
 +
|-
 +
| svcGetProcessInfo
 +
| None
 +
|-
 +
| svcGetProcessList
 +
| None
 +
|-
 +
| svcCreateSemaphore
 +
| None
 +
|-
 +
| svcDuplicateHandle
 +
| None
 +
|-
 +
| svcReplyAndReceive
 +
| None
 +
|-
 +
| svcGetResourceLimit
 +
| None
 +
|-
 +
| svcReleaseSemaphore
 +
| None
 +
|-
 +
| svcReplyAndReceive1
 +
| None
 +
|-
 +
| svcReplyAndReceive2
 +
| None
 +
|-
 +
| svcReplyAndReceive3
 +
| None
 +
|-
 +
| svcReplyAndReceive4
 +
| None
 +
|-
 +
| svcCreateMemoryBlock
 +
| None
 +
|-
 +
| 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===

Revision as of 07:21, 6 June 2016

The Old3DS+New3DS 11.0.0-33 system update was released on May 9, 2016. This Old3DS update was released for the following regions: USA, EUR, JPN, CHN, KOR, and TWN. This New3DS update was released for the following regions: USA, EUR, JPN, CHN, and KOR.

Security flaws fixed: <fill this in manually later, see the updatedetails page from the ninupdates-report page(s) once available for now>.

Change-log

Official USA change-log:

  • Further improvements to overall system stability and other minor adjustments have been made to enhance the user experience

System Titles

<fill this in (manually) later>

NATIVE_FIRM

The ARM9 FIRM section is larger.

The only updated FIRM sysmodules are loader and pm.

svcBackdoor has been removed (on ARM11).

loader

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 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

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 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

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 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 memchunkhdr they can detect when it is modified by an outside DMA device (gspwn).

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 RegionDescriptor.
u32* data_ptr = (u32*) lr; // Unsafe FCRAM pointer.

r0 = crypto_state[16/4] // Load "key".
r1 = crypto_state[20/4]
r2 = crypto_state[28/4]
r3 = crypto_state[24/4]

for(size_t i=0; i<2; i++) {
    for(size_t j=0; j<5; j++) {
        r0 -= (r1 >>> 3) - data_ptr[j]
        r1 -= (r3 >>> ((r2 & 0xf) + 3)) ^ (r2 >>> ((r0 & 0xf) + 13))
        r3 -= (r2 >>> r0) * r1
        r2 -= (r0 >>> r1) * r3
    }
}
    
// Verify MAC.
if(data_ptr[5] != (r0 ^ r1)) {
    kernel_panic()
}

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 RegionDescriptor.
crypto_state[20/4] = 0
crypto_state[24/4] = 0
crypto_state[28/4] = 0

u32* key = &crypto_state[16/4];

for(size_t i=0; i<0x40; i++) {
    for(size_t j=0; j<4; j++) { 
        r0 = key[j] - GetSystemTick()
        key[j] = r0 ^ ((r0 >>> 7) - (key[(i+j) % 4] >>> 17))
    }
}

However, it's unknown how much the svcGetSystemTick() output really varies if anything(?) for each hard-boot during initialization of the heaps.

6 memory management functions were updated to use the above new functions, these func-calls replaced the validation code previously used in these functions in some cases. These were also updated for the above heap security implementation. One function had a validation func-call added where previously there wasn't any validation done in the beginning of the function for previous versions.

Another function(L_fff13b68 previously at L_fff13b68) was updated for offsets it uses, nothing else.

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. All of the updated SVCs for this, in the same order as the arm11kernel code binary:

SVC Additional changes if any
svcCreatePort None
svcOpenThread None
svcCreateEvent None
svcCreateMutex None
svcCreateTimer None
svcGetThreadId None
svcRandomStub (SVC 0x74) None
svcOpenProcess None
svcQueryMemory None
svcCreateThread None
svcGetProcessId None
svcAcceptSession None
svcConnectToPort None
svcControlMemory None
svcCreateCodeSet (SVC 0x73) None
svcCreateProcess (SVC 0x75) None
svcCreateSession None
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).
svcGetSystemInfo None
svcGetThreadInfo None
svcGetThreadList None
svcSignalAndWait None
svcGetProcessInfo None
svcGetProcessList None
svcCreateSemaphore None
svcDuplicateHandle None
svcReplyAndReceive None
svcGetResourceLimit None
svcReleaseSemaphore None
svcReplyAndReceive1 None
svcReplyAndReceive2 None
svcReplyAndReceive3 None
svcReplyAndReceive4 None
svcCreateMemoryBlock None
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

Process9

Various data was moved around in the .data section (.data is 0x99C-bytes smaller than before).

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 retail.

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).

This prevents downgrading on the ARM11 side via AM-service access.

New3DS

The arm9loader wasn't changed at all.

Nothing New3DS-only changed in Process9.

friends-sysmodule

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

Exactly two functions were updated with the same changes: L_1053b0 and L_10547c.

When the input value is zero, this now requires bitmask 0x2 to be clear in a certain state field before passing a ptr to a function, instead of 0x0.

0004001B00010802

The 1-byte content of "romfs:/dummy.txt" was changed from '2' to '3'.

See Also

System update report(s):