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

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

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.

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 -= data_ptr[j] + (r1 >>> 3)
        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. 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

Process9

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.

This effectively prevents downgrading.

AMPXI_InstallFIRM's firm-writing code has changed, though it seems it is only a refactor.

New3DS

The arm9loader wasn't changed at all.

friends-sysmodule

Only the value used for fpdver changed in the codebin, from 5 to 6.

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

• [1]
• [2]