11.0.0 33

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

🔗 Official USA change-log:

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

<fill this in (manually) later>

The ARM9 FIRM section is larger.

The only updated FIRM sysmodules are loader and pm.

svcBackdoor has been removed (on ARM11).

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.

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.

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`](Memory_Management#regiondescriptor "wikilink")`.
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`](Memory_Management#regiondescriptor "wikilink")`.
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:

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.

The arm9loader wasn’t changed at all.

Nothing New3DS-only changed in Process9.

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.

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.

The 1-byte content of “romfs:/dummy.txt” was changed from ‘2’ to ‘3’.

System update report(s):

• 🔗 1
• 🔗 2

Category:Firmware Versions