On retail the 8-bytes at ARM9 address On retail the 8-bytes at ARM9 address 0x01FFB808 are XORed with hard-coded data, to
generate the TWL console-unique keys, including TWLNAND. On Old3DS the
high u32 is always 0x0, while on New3DS that u32 is always 0x2. On top
@@ -108,7 +108,7 @@ generation is 8-bytes(all bytes actually set).
CFG11_GPUPROT allowing acccess to
AXIWRAM/FCRAM-BASE-memregion
-
CFG11_GPUPROT can be configured by anything with
access to it to allow the GPU to access the entire AXIWRAM+FCRAM. For
example, this is an issue for any sysmodule that gets exploited and has
@@ -178,7 +178,7 @@ below).
The FIRM
partitions are encrypted with AES-CTR without a MAC. Since this
works by XOR'ing data with a static (per-console in this case)
keystream, one can deduce the keystream of a portion of each FIRM
@@ -220,13 +220,13 @@ partitions.
The FIRM
partitions are signed with RSA-2048 using SHA-256 and PKCS #1 v1.5
padding. Boot9, however, improperly validates the padding in three
ways:
@@ -272,11 +272,11 @@ one week to find a match.
Boot9's FIRM loading
blacklists Boot9 data regions, but forgets to do other important
regions, including Memory-mapped I/O. Combined with sighax, a malicious
FIRM can be used to overwrite: a) boot9 data-abort handler, coupled with
@@ -287,9 +287,9 @@ runs)
Boot9 decrypts the
+0x100-byte OTP using
AES-CBC with keydata stored in Boot9. If hash verification is
successful, the plaintext of the first 0x90-bytes are copied into ITCM. This is the
+{{% href "../Memory_layout" %}} title="wikilink">ITCM. This is the
exactsame region hashed by arm9loader when generating
the console-unique keys for decrypting the keysector, except arm9loader
uses the raw encrypted OTP.
@@ -366,7 +366,7 @@ keysector(which is dangerous).
Retrieving this keydata and the Retrieving this keydata and the NAND keystore of the same device allows calculating
the decrypted New3DS NAND keystore (non-unique, common to all New3DS
units), which contains AES normal keys, also set on keyslot 0x11, which
-are then used to derive all current New3DS-only AES keyXs including the newer batch
-introduced in 9.6.0-X. From there, it is trivial to perform the
same key derivation in order to initialize those keys on any system
version, and even on Old3DS.
@@ -411,7 +411,7 @@ section-loading fail is not relevant here, this attack was performed
without OTP data by brute-forcing keys), and using this to dump the
SHA_HASH register. This attack works on any FIRM version shipping a
vulnerable version of K9L, whereas OTP dumping required a boot of <3.0.0-X.
+{{% href "../3.0.0-6" "broken" %}} title="wikilink">3.0.0-X.
This attack results in obtaining the entire (0x200-bytes) NAND
keystore - it was confirmed at a later date that this keystore is
encrypted with the same key (by comparing the decrypted data from
@@ -425,13 +425,13 @@ the moment people dumped a New3DS OTP.
Derivation of all New3DS keys generated via the NAND keystore
(0x1B "Secure4" etc.)
Starting with 9.6.0-X a
new set of NAND-based keys were introduced. However, no verification
block was added to verify that the new key read from NAND is correct.
-This was technically an issue from 9.5.0-X with the original sector+0 keydata, however
-the below is only possible with 9.6.0-X since keyslots 0x15 and 0x16 are generated
from different 0x11 keyXs.
Writing an incorrect key to NAND will cause arm9loader to decrypt the
@@ -474,8 +474,8 @@ various input keydata, eventually you'll find some garbage that jumps to
your code.
This gives very early ARM9 code execution (pre-ARM9 kernel). As such,
it is possible to dump RSA keyslots with this and calculate the 6.x save, and
-7.x NCCH keys. This cannot be used
+{{% href "../Savegames" %}} title="wikilink">save, and
+7.x NCCH keys. This cannot be used
to recover keys initialized by arm9loader itself. This is due to it
wiping the area used for its stack during NAND sector decryption and
keyslot init.
@@ -483,15 +483,15 @@ keyslot init.
can be exploited on Old3DS as well, but only if one already has the
actual plaintext normalkey from New3DS NAND sector 0x96 offset-0 and has
dumped the OTP area of the Old3DS.
Originally the New3DS FIRM
arm9bin loader only cleared keyslot 0x11 when it gets executed at
-firmlaunch. This was fixed with 9.5.0-X by completely clearing keyslot 0x11
immediately after the loader finishes using keyslot 0x11. This means
that any ARM9 code that can execute before the loader clears the keyslot
@@ -522,16 +522,16 @@ keyslot 0x11, which then allows one to generate all <=v9.5 New3DS
keyXs which are generated by keyslot 0x11.
Therefore, to completely fix this the loader would have to generate
more keys using different keyslot 0x11 keydata. This was done with 9.6.0-X.
Last FIRM system version this
flaw was checked for
Timeframe this was discovered
Public disclosure timeframe
@@ -556,11 +556,11 @@ flaw was checked for
Leak of normal-key matching a key-scrambler key
-
New 3DS firmware versions 8.1.0 through 9.2.0 set the encryption key for New 3DS firmware versions 8.1.0 through 9.2.0 set the encryption key for Amiibo data using a hardcoded normal-key in
-Process9. In firmware 9.3.0,
+Process9. In firmware 9.3.0,
Nintendo "fixed" this by using the key scrambler instead, by calculating
the keyY value for keyslot 0x39 that results in the same normal-key,
then hardcoding that keyY into Process9.
@@ -570,20 +570,20 @@ key scrambler using an insecure scrambling algorithm (see "Hardware"
above), the key scrambler function could be deduced.
Deducing the keyX for keyslot 0x39 and the key scrambler
algorithm
During the 3DS' development (June/July 2010) Nintendo added
-support installing encrypted content (CIA). Common-key index1 was intended to be a hardware generated key. However while
+{{% href "../AES" %}} title="wikilink">hardware generated key. However while
they added code to generate the key in hardware, they forgot to remove
the normal-key for index1 (used elsewhere, likely old debug code).
Nintendo later removed the normal key sometime before the first
@@ -596,12 +596,12 @@ common-key keyX is recovered.
the retail key-generator.
Deducing the keyX for keyslot 0x3D and hardware key-generator
algorithm. Generate remaining devkit common-keys.
O3DS & O2DS SAFE_FIRM is still vulnerable to the
-PXIAM:ImportCertificates flaw fixed in 5.0.0-11 and to SSLoth fixed in 11.14.0-46. It makes it possible
+{{% href "../11.14.0-46" %}} title="wikilink">11.14.0-46. It makes it possible
to spoof the official NUS update server and remotely trigger the
vulnerability in SAFE_FIRM.
@@ -676,12 +676,12 @@ PrepareArm9ForTwl function.
updated for vuln fixes), this can be noticed by just checking
3dbrew/ninupdates title-listings.
The fix for firmlaunch-hax was only applied to NATIVE_FIRM in 9.5.0-X, leaving SAFE_FIRM
+{{% href "../9.5.0-22" %}} title="wikilink">9.5.0-X, leaving SAFE_FIRM
exploitable. With ARM11-kernel execution, one can trigger FIRM-launch in
to SAFE_FIRM, do Kernel9 <=> Kernel11 sync, PXI sync and then
repeat the original attack on SAFE_FIRM instead.
When a title is *already* installed, Process9 will compare the
installed title-version with the title-version being installed. When the
one being installed is older, Process9 would return an error.
However, this can be bypassed by just deleting the title first via
the service command(s) for that: with the title removed from the Title_Database, Process9
+{{% href "../Title_Database" %}} title="wikilink">Title_Database, Process9
can't compare the input title-version with anything. Hence, titles can
be downgraded this way.
11.0.0-X fixed this for key
system titles (MSET, Home Menu, spider, ErrDisp, SKATER, NATIVE_FIRM,
and every retail system module), by checking the version of the title to
install against a hard-coded list of (titleID, minimumVersionRequired)
pairs.
Bypassing title version check at installation, which then allows
downgrading any title.
Anti-downgrade list did not include all system titles
initially
The anti-downgrade list did not include legacy FIRMs until 11.8.0-X. Therefore, legacy FIRMs
+{{% href "../11.8.0-41" %}} title="wikilink">11.8.0-X. Therefore, legacy FIRMs
could still be downgraded.
Downgrading legacy FIRMs; allowing to exploit bugs in older
legacy FIRMs (of which at least one exists, see below).
In 1.0.0-X's TWL_FIRM,
cmds 8 and 9 were not stubbed (whereas in the corresponding NATIVE_FIRM,
they were). Command 8 does the Process9 initialisation for NTR carts if
an NTR cart is inserted (NTR, not TWL, judged by chipid).
@@ -778,24 +778,24 @@ arm9mem, NTR secure area in fcram, TWL secure area in fcram], to
offset_write is not checked at all, thus this leads to ARM9 code
execution as long as any NTR cart, including flashcarts that would
normally be blocked by TWL_FIRM, is inserted.
When executing a FIRM launch, Process9 doesn't validate that the
target FIRM isn't an old version. This allows booting an exploitable
FIRM from a newer FIRM, if you can get the exploitable FIRM installed.
-(11.0.0-X now prevents
+(11.0.0-X now prevents
installing old versions of system titles, but this doesn't affect titles
already installed.)
-
This had a use after 9.6.0-X:
on a compromised 3DS running 9.2.0, you could install the 9.6.0
NATIVE_FIRM to FIRM0/FIRM1, but avoid putting it into the NATIVE_FIRM
title. This would boot the 9.2.0 system software but with the 9.6.0
@@ -811,11 +811,11 @@ keystore was dumped, this became moot.
Decrypting 9.6.0 NCCH files without dumping New3DS
keystore
FS:EnumerateExtSaveData crashes process9 when
trying to parse a file as an extdata directory in Data Management
(MSET9)
In the implementation for FSPXI:EnumerateExtSaveData (called by
-MSET to parse 3DS extdata
+MSET to parse 3DS extdata
IDs for Data Management), the return value of the P9 internal function
call to open a directory (when enumerating contents of the extdata
directory) was not checked. Therefore, if the call fails, an
@@ -874,7 +874,7 @@ dirname and take control of the ARM9, and thus, full control of the
3DS.
@@ -882,7 +882,7 @@ dirname and take control of the ARM9, and thus, full control of the
RSA signature padding checks
The TWL_FIRM RSA sig padding check code used for all TWL RSA
-sig-checks has issues, see here. The
+sig-checks has issues, see here. The
main 3DS RSA padding check code(non-certificate, including NATIVE_FIRM)
uses the function used with the above to extract more padding + the
actual hash from the additional padding. This isn't really a problem
@@ -890,15 +890,15 @@ here because there's proper padding check code which is executed prior
to this.
When the input DSiWare section index is higher than
, Process9 uses
keyid 0x40 for calculating the AESMAC, which translates to keyslot 0x40.
@@ -912,15 +912,15 @@ this. This is basically a different form of the pxips9 keyslot vuln,
except with AESMAC etc.
This requires access to the This requires access to the ps:ps/pxi:ps9 services. One way to get access to
this would be snshax on system-version <=10.1.0-X(see 32c3 3ds talk).
When an invalid key-type value is passed to any of the PS commands,
@@ -931,46 +931,46 @@ continue to do crypto with whatever AES keyslot was selected before the
PS command was sent.
Reusing the previously used keyslot, for crypto with PS.
This can't be exploited from ARM11 userland. During FIRM launch, the only FIRM header the
+{{% href "../FIRM" %}} title="wikilink">FIRM launch, the only FIRM header the
ARM9 uses at all is stored in FCRAM, this is 0x200-bytes(the actual used
FIRM RSA signature is read to the Process9 stack however). The ARM9
doesn't expect "anything" besides the ARM9 to access this data. With 9.5.0-22 the address of this FIRM
+{{% href "../9.5.0-22" %}} title="wikilink">9.5.0-22 the address of this FIRM
header was changed from a FCRAM address, to ARM9-only address
0x01fffc00.
Uninitialized data output for (PXI) command replies
PXI commands for various services(including some here and many
+{{% href "../Filesystem_services_PXI" %}} title="wikilink">here and many
others) can write uninitialized data (like from ARM registers) to the
command reply. This happens with stubbed commands, but this can also
occur with certain commands when returning an error. Certain ARM11
service commands have this same issue as well.
Process9 does not use the exheader ARM9 access-mount permission
flag for SD at all. This would mean ARM11-kernelmode code / fs-module
@@ -979,13 +979,13 @@ for SD access, but this is rather useless since a process is usually
running with SD access(Home Menu for example) anyway.
Process9 allocates memory on Process9 heap for the export path
then verifies that the actual allocated size matches the input size.
@@ -998,14 +998,14 @@ NUL-terminator to the end of the buffer.
"nand:/" etc. This isn't really useful since the data which gets
written can't be controlled.
Just like DSi originally did, 3DS verifies the APCert for DSiWare
on SD with the CTCert also in the DSiWare .bin. On DSi this was fixed
with with system-version 1.4.2 by verifying with the actual
@@ -1021,12 +1021,12 @@ SD .bin files.
seedminer: movable.sed keyY vulnerable to brute-force
Half of the movable.sed keyY's 128 bits are leaked through the LFCS, which
+{{% href "../Nandrw/sys/LocalFriendCodeSeed_B" %}} title="wikilink">LFCS, which
is available in userland and below. The LFCS itself also leaks almost
half of the remaining bits by following the ratio: u32
keyY[3]=1/5(LFCS). The remaining keyY[3] uncertainty of about ±2000 can
@@ -1077,57 +1077,57 @@ execution.
The u8 REG_CTRCARDCNT transfer-size parameter for the Gamecard_Services_PXI
+{{% href "../Gamecard_Services_PXI" %}} title="wikilink">Gamecard_Services_PXI
read/write CTRCARD commands is used as an index for an array of u16
-values. Before 5.0.0-X this u8
+values. Before 5.0.0-X this u8
value wasn't checked, thus out-of-bounds reads could be triggered(which
is rather useless in this case).
Out-of-bounds read for a value which gets written to a
register.
The Process9 code responsible The Process9 code responsible PXI communications didn't verify the size of the
incoming command before writing it to a C++ member variable.
When handling this command, Process9 allocates a 0x2800-byte heap
buffer, then copies the 4 FCRAM input buffers to this heap buffer
without checking the sizes at all(only the buffers with non-zero sizes
-are copied). Starting with 5.0.0-X, the total combined size of the input data
must be <=0x2800.
pxips9 cmd1(not accessible via ps:ps) and VerifyRsaSha256:
unchecked copy to a buffer in Process9's .bss, from the input FCRAM
@@ -1136,18 +1136,18 @@ SignRsaSha256 also has a buf overflow, but this isn't exploitable. The
buffer for this is the buffer for the signature data. With v5.0, the
signature buffer was moved to stack, with a check for the signature data
size. When the signature data size is too large, Process9 uses svcBreak.
Old versions of Kernel9 never set bit1 of CFG9_SYSPROT9. This leaves the 0x10012000-region unprotected
+{{% href "../OTP_Registers" %}} title="wikilink">0x10012000-region unprotected
(this region should be locked early during boot!). Since it's never
locked, you can dump it once you get ARM9 code execution.
-
From 3.0.0-X this was fixed by
setting the bit in Kernel9 after poking some registers in that region.
On New3DS arm9loader sets this bit instead of Kernel9, which is
exploitable through a hardware + software vulnerability (see
@@ -1205,17 +1205,17 @@ OTP data for a New3DS console in order to decrypt the key data used in
arm9loader (see enhanced-arm9loaderhax / description). This was
performed by downgrading to a vulnerable system version. By accounting
for differences in CTR-NAND crypto (0x05 -> 0x04, see partition
-encryption types here) and using an Old3DS NCSD Header, it is possible
+{{% href "../NCSD" %}} title="wikilink">NCSD Header, it is possible
to boot a New3DS using Old3DS firmware 1.0-2.x to retrieve the required
OTP data using this flaw.
svcBindInterrupt and svcUnbindInterrupt give special treatment to
irqId 15 (FIQ helper): the access control list is bypassed and the
@@ -1252,36 +1252,36 @@ inside a singleton static object after having its refcount increased by
stored in the singleton and will decref the user-provided
KInterruptEvent twice, causing a use-after-free if the attacker didn't
actually provide an handle to the same event or semaphore.
-
This was "fixed" on This was "fixed" on 11.14.0-X by preventing irqId 15 to be bound on
retail units altogether (in both functions).
Calling svcGetResourceLimit
afterwards triggers a use-after-free. This is rather difficult to
exploit, however: there is one slot left in the reslimit slabheap. An
attacker either has to map the NULL page as R(W)X
-(svcControlProcessMemory vuln fixed on 11.8.0-X), or use one of the map-null exploits
above while having access to svcCreateResourceLimit (with the only one
that is easy enough to use in that context having been fixed on 11.14.0-X, anyway).
+{{% href "../11.14.0-46" %}} title="wikilink">11.14.0-X, anyway).
The SVC receive two arguments: handle and idealprocessor. The
handle is used to get the KProcess object and the KProcess->refCnt
@@ -1328,41 +1328,41 @@ gets incremented,later the function check if the KProcess->mem_type
won't meet any condition and return the error 0xD9001BEA without
decrement the reference count. It can be abused to overflow the KProcess
reference count that will lead to an Use-after-free.
When given a valid process handle (including
0xFFFF8001), svcGetThreadList forgets to decrement the
-reference count of the underlying KProcess instance, after having finished using
it.
@@ -1372,8 +1372,8 @@ is locked for that core to avoid race conditions, but another core can
call CloseHandle on the timer and free it, leading to a UAF vtable
call.
The table of function pointers for SVC's only contains entries up
to 0x7D, but the biggest allowed SVC for the table is 0x7F. Thus,
executing SVC7E or SVC7F would make the SVC-handler read after the
@@ -1420,18 +1420,18 @@ SVC-access-control. Even if you could get these to execute, they would
still jump to memory that isn't mapped as executable.
This backdoor allows executing SVC-mode code at the
user-specified code-address. This is used by Process9, using this on the
ARM11 (with NATIVE_FIRM) required patching the kernel .text or modifying
SVC-access-control.
This is completely different from the
kernelmode-code-execution vuln described in the below separate
entry.
-
When updating the kernel global PID counter under When updating the kernel global PID counter under svcCreateProcess the kernel does not check for
wraparound to 0x0(the PID for the very first process). This only matters
-because SM-module allows
+because SM-module allows
processes with PID value less than to access
all services, without checking exheader service-access-control;
and because Kernel11 checks for the PID to be 1 (loader) to use the
input mem-region value on ControlMemory. This alone does not affect
-access the SVCs access table at
+access the SVCs access table at
all.
Inlined ldrex+strex code is used for updating the above counter. 11.2.0-X had changes for similar
+{{% href "../11.2.0-35" %}} title="wikilink">11.2.0-X had changes for similar
code, but it was only for dedicated ldrex+strex functions(mainly for
kernel objects) and hence this PID code was not affected.
With launching+terminating a sysmodule repeatedly with this via ns:s,
it would take weeks to finish(if not at least about a month?).
@@ -1473,14 +1473,14 @@ valid handles in an array before returning an error when it encounters
an invalid handle. This allows one to (slowly) overflow the reference
count for a handle object to zero.
The ARM11 kernel-mode 0xEFF00000/0xDFF00000 virtual-memory(size
@@ -1491,13 +1491,13 @@ this never seems to be used after that, however. This is never unmapped
either.
Nintendo's fix for memchunkhax2 in Nintendo's fix for memchunkhax2 in 10.4.0-X did not fix the GPU case: one may cause
the requisite ToCToU race using gspwn, bypassing the new validation.
derrek's original 32c3 presentation for memchunkhax2 commented that a
@@ -1505,19 +1505,19 @@ GPU-based attack was possible, but would be difficult. However,
memchunkhax2.1 showed that it was possible to do fairly
reliably.
ARM11 kernel code execution
-
11.0.0-X, via the new 11.0.0-X, via the new memchunkhdr MAC which prevents modifying
memchunkhdr data with DMA.
When allocating a block of memory, the "next" pointer of the memchunkhdr is accessed without being checked after
being mapped to userland. This allows a race condition, where the
process can change the next pointer just before it's accessed. By
@@ -1525,11 +1525,11 @@ pointing the next pointer to a crafted memchunckhdr in the kernel
SlabHeap, some of the SlabHeap is allocated to the calling process,
allowing to change vtables of kernel objects.
With 10.0.0-X the
following functions were updated: svcGetThreadAffinityMask,
svcGetProcessAffinityMask, svcSetProcessAffinityMask, and
svcCreateThread. The code changes for all but svcCreateThread are
@@ -1577,7 +1577,7 @@ identical. The original code with the first 3 did the following:
In theory the latter should catch everything that the former did, so
it's unknown if this was really a security issue.
Original code: "if(s32_processorid > )return
@@ -1587,7 +1587,7 @@ title="wikilink">10.0.0-X definitely did fix a security issue.
s32_processorid <= -4)return 0xd8e007fd;" This fixed an
off-by-one issue: if one would use processorid=total_cores, which isn't
actually a valid value, svcCreateThread would accept that value on
-<10.0.0-X. This results in
+<10.0.0-X. This results in
data being written out-of-bounds(baseaddr = arrayaddr +
entrysize*processorid), which has the following result:
@@ -1605,22 +1605,22 @@ anything(meaning no crash) besides the thread not running / thread not
running for a while(besides triggering a kernelpanic with certain
s32_processorid value(s)).
svcCreateThread issue: May 31, 2015. The rest: September 8, 2015,
via v9.6->v10.0 ARM11-kernel code-diff.
memchunkhax
The kernel originally did not validate the data stored in the
-FCRAM kernel heap memchunk-headers for free-memory at all. Exploiting
this requires raw R/W access to these memchunk-headers, like
physical-memory access with gspwn.
There are multiple ways to exploit this, but the end-result
for most of these is the same: overwrite code in AXIWRAM via the
0xEFF00000/0xDFF00000 kernel virtual-memory mapping.
This was fixed in 9.3.0-X by
checking that the memchunk(including size, next, and prev ptrs) is
located within the currently used heap memory. The kernel may also check
that the next/prev ptrs are valid compared to other memchunk-headers
@@ -1628,44 +1628,44 @@ basically. When any of these checks fail, kernelpanic() is
called.
When combined with other flaws: ARM11-kernelmode code
execution
The ARM11-kernel did access the 'key' field of KLinkedListNode objects,
+{{% href "../KLinkedListNode" %}} title="wikilink">KLinkedListNode objects,
which are located on the SlabHeap, after freeing them. Thus, triggering
-an allocation of a new KLinkedListNode object at the right time could
result in a type-confusion. Pseudo-code: SlabHeap_free(KLinkedListNode);
KObject *obj = KLinkedListNode->key; // the object there might have
changed! This bug appeared all over the place.
Originally the ARM11-kernel didn't check permissions for PXI
-input/output buffers for commands. Starting with 6.0.0 PXI input/output buffers must have RW
permissions, otherwise kernelpanic is triggered.
For svcStartInterProcessDma, the kernel code had the following
flaws:
@@ -1678,28 +1678,28 @@ instruction.
Integer overflows for srcaddr+size and dstaddr+size are now
-checked(with 6.0.0-11), which
+checked(with 6.0.0-11), which
were not checked before.
The kernel now also checks whether the srcaddr/dstaddr (+size) is
within userland memory (0x20000000), the kernel now (with 6.0.0-11) returns an error when the
+{{% href "../6.0.0-11" %}} title="wikilink">6.0.0-11) returns an error when the
address is beyond userland memory. Using an address >=0x20000000
would result in the kernel reading from the process L1 MMU table, beyond
the memory allocated for that MMU table(for vaddr->physaddr
conversion).
Originally the kernel did not check the word-values from the
-command-header. Starting with 5.0.0-11, the kernel will trigger a kernelpanic()
when the total word-size of the entire command(including the cmd-header)
is larger than 0x40-words (0x100-bytes). This allows overwriting
@@ -1741,13 +1741,13 @@ with controlled data this way, one could then use a command with a
buffer-header of ((size<<14) | 2) to write arbitrary memory to any
RW userland memory in the destination process.
svcControlMemory with MemoryOperation=MAP allows mapping the
already-mapped process virtual-mem at addr1, to addr0. The lowest
@@ -1780,28 +1780,28 @@ didn't check memory permissions for addr1. Therefore .text as addr1
could be mapped elsewhere as RW- memory, which allowed ARM11 userland
code-execution.
Originally the ARM11 kernel didn't check memory permissions for
-the input/output buffers for commands. Starting with 4.0.0-7 the ARM11 kernel will trigger a
kernelpanic() if the input/output buffers don't have the required memory
permissions. For example, this allowed a FSUSER file-read to .text,
which therefore allowed ARM11-userland code execution.
Originally the kernel only checked the first page(0x1000-bytes)
@@ -1809,10 +1809,10 @@ of the src/dst buffers, for svcReadProcessMemory and
svcWriteProcessMemory. There is no known retail processes which have
access to these SVCs.
Originally any process had access to the port "srv:pm". The PID's
used for the (un)registration commands are not checked either. This
allowed any process to re-register itself with "srv:pm", and therefore
allowed the process to give itself access to any service, bypassing the
exheader service-access-control list.
-
This was fixed in 7.0.0-13:
+starting with 7.0.0-13 "srv:pm"
is now a service instead of a globally accessible port. Only processes
with PID's less than 6 (in other words: fs, ldr, sm, pm, pxi modules)
-have access to it. With 7.0.0-13
+have access to it. With 7.0.0-13
there can only be one session for "srv:pm" open at a time(this is used
by pm module), svcBreak will be executed if more sessions are opened by
the processes which can access this.
@@ -1854,41 +1854,41 @@ the processes which can access this.
vulnerabilities from ARM11 userland ROP, since most applications don't
have access to those service(s).
FS-module may
crash in some cases when handling directory reading. The trigger seems
-to be due to using FSDir:Close without closing the dir-handle
afterwards?(Perhaps this is caused by out-of-memory?) This seems to be
useless since it's just a null-deref.
After accepting a new session, After accepting a new session, SM writes a (handler ID (0 for srv: sessions (max.
64), 1 for the srv:pm one), pointer to session context structure in BSS)
pair in a global array. However that array is only 64-entry-big instead
of 65 (as it ought to be), and no bound check is done in that
regard.
-
Unfortunately, as of Unfortunately, as of 11.4.0-37, the overwritten fields are totally
unused after their initialization by
__libc_init_array.
@@ -1899,28 +1899,28 @@ done on the service table. One can simply call RegisterPort repeatedly
to overflow that table: it will overflow into the command replay
structure.
Combined with a other minor bugs in the sysmodule, it is possible to
-take over SM with this nevertheless
+take over SM with this nevertheless
difficult-to-exploit vulnerability.
-
Like its Arm9 counterpart, before version Like its Arm9 counterpart, before version 5.0.0-X, the PXI system module did not check the
command sizes. This makes it possible to get ROP under the PXI sysmodule
from a pwned Process9. safecerthax uses it to takeover the Arm11
processor after directly getting remote code execution on the Arm9 side.
Though, is useless in classic Arm11 -> Arm9 chains.
CSND sysmodule crash
due to out of bounds parameters.
-
The CSND command The CSND command PlaySoundDirectly (0x00040080) takes a channel ID
as the first parameter. Any value outside the range [0-3] makes the
system module become unstable or crash due to an out of bounds memory
@@ -1955,13 +1955,13 @@ read.
Out of bounds memory read, probably not exploitable. More
research needed.
Initially, the SSL sysmodule missed the R_VERIFY_RES_SIGNATURE
entry in the "resource list" provided to the RSA BSAFE library.
@@ -1969,28 +1969,28 @@ Consequently, it did not check signatures when validating certificate
chains.
Forge fake certificates, spoof official servers and perform MitM
attacks on SSL/TLS connections.
CECD allows any process to write to any message box, thus
allowing to write Streetpass data to the message box of any
@@ -2005,7 +2005,7 @@ vulnerability).
When parsing Streetpass packets of type 0x32 and 0x34, CECD
copies a list without checking the number of entries. The packet length
@@ -2014,16 +2014,16 @@ stack frame and overwrite the return address. However, the buffer
located just next to the packet buffer is actually filled with data sent
just before, hence actually allowing to overwrite the whole stack frame
with conrolled data.
When parsing "TMP_XXX" files, CECD does not check the number of
messages contained in the file. This allows to overflow the array of
@@ -2043,16 +2043,16 @@ since the previous TMP file buffer is reused for the new TMP file in
memory. Thus the message pointers actually points to controlled data.
This allows to get a bunch of fake heap chunk freed, thus a bunch of
unsafe unlink arbitrary writes.
When creating a new block it checks the size of the block is
<= 0x8000, but it doesn't check that the block size is less than the
@@ -2067,15 +2067,15 @@ buf_start+0x10000 (cannot write backward).
Theoritically ROP under CFG services, but BSS section is to small
(size <= 0x10000) so it only results in a crash.
MP:SendDataFrame
doesn't validate the input index at cmdreq[1], unless the function for
flag=non-zero is executed. This is used to calculate the following,
without validating the index at all: someptr = stateptr + (index*0x924)
@@ -2088,14 +2088,14 @@ loaded from someptr+someotheroffset.
MP-sysmodule handles the input parameter for cmd1 as a s32. It
checks for >=16, but not <0. With <16 it basically does the
@@ -2106,16 +2106,16 @@ doesn't really have any service handles of interest however(can be
obtained from elsewhere too).
After writing the output-info structure to stack, it then copies
that structure to the output buffer ptr using the size from the command.
The size is not checked. This could be used to read data from the
@@ -2123,11 +2123,11 @@ AM-service-thread stack handling the command + .bss.
The input total_entries is not validated when initially
processing the input entry-list. This fixed-size input entry-list is
@@ -2160,23 +2160,23 @@ the out-of-bounds total_entries is smaller than that, it will crash due
accessing address 0x0, hence this useless.
Hence, overwriting sharedmem with gspwn then using NWMUDS:Unbind results in the
+{{% href "../NWMUDS:Unbind" %}} title="wikilink">NWMUDS:Unbind results in the
usual controlled CTRSDK memchunk-header write, similar to
HTTP-sysmodule.
This could be done by creating an UDS network, without any other
@@ -2185,14 +2185,14 @@ nodes on the network.
this sharedmem.
ROP under NWM-module.
None (need to check, but CTRSDK heap code is vulnerable)
DLP: Out-of-bounds
-memory access during spectator DLP: Out-of-bounds
+memory access during spectator data-frame checksum calculation
DLP doesn't validate the frame_size when receiving spectator
data-frames at all, unlike non-spectator data-frames. The actual
@@ -2210,15 +2210,15 @@ useful either).
"connection interrupted" error eventually then a fatal-error via
ErrDisp.
The total_entries and out_entryindex fields for the titlelist DLP
spectator data-frames are not validated. This is parsed during DLP
network scanning. Hence, the specified titlelist data can be written
@@ -2235,32 +2235,32 @@ linked-list code involves writes zeros(with a controlled start
ptr).
Originally IR sysmodule used the read value from the I2C-IR
registers TXLVL and RXLVL without validating them at all. See here for the fix. This is the size
+{{% href "../10.6.0-31" %}} title="wikilink">here for the fix. This is the size
used for reading the data-recv FIFO, etc. The output buffer for reading
is located on the stack.
This should be exploitable if one could successfully setup the custom
hardware for this and if the entire intended sizes actually get read
from I2C.
HTTP: Using CTRSDK
heap with sharedmem from the user-process.
The data from httpcAddPostDataAscii and other commands is stored
under a CTRSDK heap. That heap is the sharedmem specified by the
@@ -2275,16 +2275,16 @@ then be used to get ROP going under HTTP-sysmodule.
href="https://github.com/yellows8/ctr-httpwn/ctr-httpwn">ctr-httpwn.
Multiple NIM service commands(such as NIMS:StartDownload) use a
+{{% href "../NIMS:StartDownload" %}} title="wikilink">NIMS:StartDownload) use a
title-version value specified by the user-process, NIM does not validate
that this input version matches the latest version available via SOAP.
Therefore, when combined with AM(PXI)
eventually smea implemented it in HANS for the 32c3 release.
cmd1 has out-of-bounds write allowing overwrite of some static
variables in .data.
Code execution under spi sysmodule; access to CFG11_GPUPROT and
+{{% href "../CONFIG11_Registers" %}} title="wikilink">CFG11_GPUPROT and
ultimately kernel code execution.
NFC module copies data with certain commands, from command input
buffers to stack without checking the size. These commands include the
@@ -2333,34 +2333,34 @@ New3DS NFC module.
services.
NEWSS service
command notificationID validation failure
This module does not validate the input notificationID for
"news:s" service commands. This is an out-of-bounds array index bug. For
-example, NEWSS:SetNotificationHeader could be used to
exploit news module: this copies the input data(size is properly
checked) to: out = newsdb_savedata+0x10 +
(someu32array[notificationID]*0x70).
input_size = 0x1E * <value the u8 from input_networkstruct+0x1D>. Then
+{{% href "../NWM_Services" %}} title="wikilink">networkstruct+0x1D>. Then
input_tag0 is copied to a heap buffer. When input_size is larger than
0xFA-bytes, it will then copy input_tag1 to
, with size=input_size-0xFA.
@@ -2380,27 +2380,27 @@ in process termination(process crash). This breaks *everything*
involving wifi comms, a reboot is required to recover from
this.
HID module does not validate the index values in sharedmem(just changes
+{{% href "../HID_Shared_Memory" %}} title="wikilink">sharedmem(just changes
index to 0 when index == maxval when updating), therefore large values
will result in HID module writing HID data to arbitrary
addresses.
ROP under HID module, but this is *very* unlikely to be
exploitable since the data written is HID data.
@@ -2409,71 +2409,71 @@ allows a user-mode application/applet to read/write to a large part of
physical FCRAM using GPU DMA. From this, you can overwrite the .text
segment of the application you're running under, and gain real
code-execution from a ROP-chain. Normally applets' .text(Home Menu, Internet Browser, etc) is
+{{% href "../Home_Menu" %}} title="wikilink">Home Menu, Internet Browser, etc) is
located beyond the area accessible by the GPU, except for CROs used by applets(Internet Browser for
+{{% href "../RO_Services" %}} title="wikilink">CROs used by applets(Internet Browser for
example).
FCRAM is gpu-accessible up to physaddr 0x26800000 on Old3DS, and
0x2D800000 on New3DS. This is BASE_memregion_start(aka
SYSTEM_memregion_end)-0x400000 (0x800000 with New3DS) with the default
-memory-layout on Old3DS/New3DS. With 11.3.0-X the cutoff now varies due to the new SVC 0x59. The New3DS
+{{% href "../SVC" %}} title="wikilink">SVC 0x59. The New3DS
"normal"(non-APPLICATION) cutoff was changed to 0x2D000000 due to the
-new SVC 0x59.
+new SVC 0x59.
Using gspwn, it is possible to overwrite a loaded CRO0/CRR0 after
-its RSA-signature has been validated. Badly validated Using gspwn, it is possible to overwrite a loaded CRO0/CRR0 after
+its RSA-signature has been validated. Badly validated CRO0 header leads to arbitrary read/write of memory
in the ro-process. This gives code-execution in the ro module, who has
-access to syscalls 0x70-0x72,
+access to syscalls 0x70-0x72,
0x7D.
-
This was fixed after ninjhax
-release by adding checks on This was fixed after ninjhax
+release by adding checks on CRO0-based pointers before writing to
them.
Only Home Menu itself
checks gamecards' region when launching them. Therefore, any application
-launch that is done directly with NS
+launch that is done directly with NS
without signaling Home Menu to launch the app, will result in region
checks being bypassed. This essentially means launching the gamecard
-with the "ns:s"
+with the "ns:s"
service. The main way to exploit this is to trigger a FIRM launch with
an application specified, either with a normal FIRM launch or a hardware
-reboot.
The NWMUDS service command code loads a ptr from .data, adds an
offset to that, then passes that as the state address for the actual
@@ -2484,10 +2484,10 @@ services besides NWMUDS have this issue.
This is rather useless since it's only a crash caused by a state
ptr based at 0x0.
When parsing streetpass messages, "nn::cec::CTR::Message::InputMessage" calls
+{{% href "../Message::InputMessage" "broken" %}}>Message::InputMessage" calls
"nn::cec::CTR::Message::SetExHeaderWithoutCalc"
+{{% href "../Message::SetExHeaderWithoutCalc" "broken" %}}>Message::SetExHeaderWithoutCalc"
for each exheader entry in the input message. The number of entries
should not exceed 16 but remains unchecked, leading to a
stack-buffer-overflow.
ROP under any application parsing Streetpass messages Remote code
-execution under CECD
Originally CTRSDK did not validate the UDS additional-data size
before using that size to copy the additional-data to a networkstruct. This was
+{{% href "../NWM_Services" %}} title="wikilink">networkstruct. This was
eventually fixed. This was discovered while doing code RE with an old
dlp-module version. It's unknown in what specific CTRSDK version this
was fixed, or even what system-version updated titles with a fixed
@@ -2545,7 +2545,7 @@ all
diff --git a/content/3DS_Userland_Flaws.md b/content/3DS_Userland_Flaws.md
index 0d3b2f3c..048ac056 100644
--- a/content/3DS_Userland_Flaws.md
+++ b/content/3DS_Userland_Flaws.md
@@ -27,14 +27,14 @@ can then for example try exploiting
@@ -73,22 +73,22 @@ then mainly because doing so would (presumably) result in the vuln being
fixed. The following old exploit was released on March 14, 2015: 1.
@@ -108,11 +108,11 @@ one allows for arbitrary writes of linear heap pointers when the next
buffer is allocated or arbitrary writes of any pointer within writable
memory when the corrupted buffer is freed.
@@ -129,10 +129,10 @@ the level save worldmap tag array should be parsed into to be
overwritten with a stack address, allowing for ROP from within the XML
array parsing function on the next level load.
@@ -149,10 +149,10 @@ high (descending) on the stack - when exploiting this, one would likely
need to move SP due to almost instantly overflowing the physical
stack.
@@ -165,12 +165,12 @@ write a significant chunk of the interpreter's address space. With a
series of carefully-designed BGPUT commands, one can build a ROP chain
and cause it to be executed.
CTRSDK CTPK buffer overflow combined with game's
usage of SpotPass
During the very first screen displayed by the game during
boot("Loading..."), just seconds after title launch, the game loads CTPK
-from the stored SpotPass
+from the stored SpotPass
content. Hence, this game could be exploited via the vulnerable CTRSDK
CTPK code if one could get custom SpotPass data into extdata
somehow(ctr-httpwn >=v1.2 with bosshaxx allows this).
@@ -217,7 +217,7 @@ href="https://github.com/yellows8/ctpkpwn">ctpkpwn_tfh.
@@ -227,11 +227,11 @@ file is read to a fixed size buffer but the file length remains
unchecked, so with a large enough file, one can overwrite pointers in
memory and gain control of the execution flow.
@@ -241,11 +241,11 @@ string key makes the game overwrite a memcpy source/destination
addresses and size arguments. So one can actually memcpy a rop on the
stack and gain control of the execution flow.
@@ -275,11 +275,11 @@ the heap, however its length is not verified. So with a large enough
team name one can overwrite some pointers and get two arbitrary jumps
and then get control of the execution flow.
@@ -354,11 +354,11 @@ and unfortunately this isn't exploitable because of a 4 bytes
uncontrolled value (in each entry) that gets written on sensitive
data.
Too long or corrupted strings (01Ah 2 Nickname length in
characters 050h 2 Message length in characters) in the NVRAM DS user
@@ -617,14 +617,14 @@ not vulnerable to this, DSi launcher(menu) and DSi System Settings will
reset the NVRAM user-settings if the length field values are too
long(same result as when the CRCs are invalid). TWL_FIRM also resets the
NVRAM user-settings when the string-length(s) are too long.
DSiWare export banners contain 16 consecutive 0x100 byte, utf-16
game title strings for different languages. Nintendo correctly limits
@@ -638,16 +638,16 @@ href="https://github.com/zoogie/Bannerbomb3">here.
Interesting note: A line feed wchar (00 0A) at any point in the
string before the crash offset will prevent the crash from
occurring.
During Recovery Mode
and after all 3 wifi slots fail to find an access point for sysupdate, a
user is permitted to access the wifi settings mode to make changes.
Here, if the proxy-url field string's NULL terminator had been altered
@@ -665,32 +665,32 @@ exploit with cfg:s/i access to modify the wifi slot. A demonstration can
be viewed here.
When a .m4a is loaded, the song name is copied to a 256 byte
buffer. When the song name begins with a Unicode BOM marker, it memcpy's
the tag using the user-provided length. This gives an arbitrary write
which can be used to achieve ROP.
When creating an audio decoder object for the moflex movie
player, if the audio codec is PCM16, the application uses an
uninitialized value as a pointer. One can spray the heap to get control
of that pointer and achieve ROP.
When the browser-version-check code runs where the savedata for
it was never initialized(such as when the user used the "Initialize
@@ -738,16 +738,16 @@ browser-version-check will be skipped. This includes January 1, 2000,
timestamp.
@@ -755,11 +755,11 @@ pages were initially updated server-side)
ids are not checked, this results in an OOB write on the stack, but only
the value 0x01 can be written.
MicroSD Management - malformed security blob causes stack buffer
@@ -771,9 +771,9 @@ longer, a stack buffer overrun occurs, leading to a ROP chain and
complete control of the mcopy application.
The malformed security blob can be sent by an attacker within the
SMB_COM_SESSION_SETUP_ANDX (0x73) packet.
After successfully loading After successfully loading extended-banner data(done when selecting an icon),
-Home Menu attempts to load "CBMD"
-data into a 0x100000-byte heap buffer from the CBMD"
+data into a 0x100000-byte heap buffer from the stored SpotPass content. When successful and the
magic-number is CBMD, Home Menu then decompresses the exbanner sections
into another fixed-size heap buffer, without checking the outsize at
all. The main CBMD CGFX code with ExeFS checks the size, but this code
doesn't(however this is exbanner "CBMD", not a "normal" CBMD).
@@ -839,24 +839,24 @@ doesn't(however this is exbanner "CBMD", not a "normal" CBMD).
functions are identical minus the file-buffer offsets.
Exploitation is different due to different heap-buffer location though.
Unlike nandiconhax, the icon buffer for SD is located in linearmem(with
-recent Home Menu versions at least). This is used by menuhax.
-
The homemenu code processing the titleid list @ launcherdat+8
copies those titleIDs to another buffer, where the offset relative to
that buffer is calculated using the corresponding s8/s16 entries. Those
two values are not range checked at all. Hence, one can use this to
write u64(s) with arbitrary values to before/after this allocated output
-buffer. See here regarding
+buffer. See here regarding
Launcher.dat structure.
This can be exploited(with Launcher.dat loading at startup at least)
by using a s16 for the icon entry with value 0xFFEC(-20)(and perhaps
@@ -884,15 +884,15 @@ state where it no longer crashes anymore. However, note that any
exploits using this which hang/etc without crashing will still brick the
system. Hence, attempting anything with this on physnand without
hw-nand-access isn't really recommended.
The only func-call size parameter used by the theme decompression
function is one for the compressed size, none for the decompressed size.
@@ -911,31 +911,31 @@ code calling the other function, not in the function itself). Unlike the
other function, the theme function supports multiple LZ algorithms, but
the one which actually gets used in official themes is the same one
supported by the other function anyway.
-
With 10.2.0-X Home Menu, the
only code change was that the following was added right after theme-load
and before actual decompression:
"if((compressed_buf) >
0x150000);". This fixed the vuln.
@@ -953,12 +953,12 @@ this is done with v2.0 Home Menu, a kernelpanic occurs when processing
an AM command(it appears a buffer ptr which is then passed to a command
was overwritten with 0x0 - of course other SaveData.dat filesizes may
result in different behaviour).
-
Save type (see below for supported values and here for
+{{% href "../ARM7_Registers" %}} title="wikilink">here for
details)
@@ -227,7 +227,7 @@ details)
0x00E
0x2
Sleep mode button combo (utilizes the same bit masks as the HID_PAD register, with
+{{% href "../HID_Registers" %}} title="wikilink">HID_PAD register, with
flipped bits).
If the GBA title supports a button-combo based sleep mode and it's set
here, Agbbg spoofs this combo when closing the 3DS' lid to enter proper
@@ -237,7 +237,7 @@ sleep mode.
0x010
0x10
Flash and EEPROM configuration (see the target registers here)
diff --git a/content/AES_Registers.md b/content/AES_Registers.md
index 5ffd22b1..c6f8d063 100644
--- a/content/AES_Registers.md
+++ b/content/AES_Registers.md
@@ -229,9 +229,9 @@ the contents of a keyslot.
Keyslot is determined by NCSD
partition FS type and encryption type. The New3DS Process9 sets the keyY
for keyslot 0x05 (New3DS CTRNAND) to a key from .(ro)data. Its keyX is
console-unique and set by the bootloader.
@@ -244,7 +244,7 @@ console-unique and set by the bootloader.
0x0A
DSiWare export key.
Used for encrypting the all-zero 0x10-byte block in the DSiWare_Exports header.
+{{% href "../DSiWare_Exports" %}} title="wikilink">DSiWare_Exports header.
Console-unique.
See above keyslot info.
See above keyslot info.
@@ -254,8 +254,8 @@ Console-unique.
0x0B
This is console-unique. This keyslot is used for the NAND dbs images AES-CMACs, and the
-dbs images AES-CMACs, and the
+Nand/private/movable.sed AES-CMAC(when
used).
Used/initialized by the New3DS arm9 binary loader starting with
-9.5.0-X, see 9.5.0-X, see here.
Arm9Loader.
Arm9Loader.
@@ -316,9 +316,9 @@ title="wikilink">here.
0x18..0x1F
These are the New3DS keyslots, where the keyX is generated with
-keyslot 0x11 by the New3DS arm9 binary loader. As of FIRMloader. As of FIRM9.6.0-X keyslots 0x1C..0x1F are not yet used by
Process9.
This is the keyslot used for movable.sed encryption + AES-CBC MAC
-with the import/export commands. The keyYs used for crypto/CMAC are
different, but both can be found in process9 rodata.
Bootrom.
@@ -497,7 +497,7 @@ different, but both can be found in process9 rodata.
Download Play key, and the actual NFC key for generating retail
-Amiibo keys.
+Amiibo keys.
This keyslot is used for two different keys. Both are available via
-EncryptDecryptAes. NATIVE_FIRM sets this keyY to
the same one used for keyslot 0x2E.
Bootrom.
@@ -539,9 +539,9 @@ the same one used for keyslot 0x2E.
Last 3-bytes here are used with the following HMAC where the size
is 0x1DF-bytes. The u16 starting at byte1 is used for the first two
bytes in the 0x40-byte input buffer for Amiibo crypto init.
+{{% href "../Process_Services_PXI" %}} title="wikilink">crypto init.
diff --git a/content/CiTRUS.md b/content/CiTRUS.md
index 91680c45..26e49f30 100644
--- a/content/CiTRUS.md
+++ b/content/CiTRUS.md
@@ -113,5 +113,5 @@ Version 0.2:
diff --git a/content/Circle_Pad_Pro.md b/content/Circle_Pad_Pro.md
index f39b54e8..b737d444 100644
--- a/content/Circle_Pad_Pro.md
+++ b/content/Circle_Pad_Pro.md
@@ -13,7 +13,7 @@ contents](http://what-games.golog.jp/archives/1350330.html).
diff --git a/content/Crappy_Tiny_Reader.md b/content/Crappy_Tiny_Reader.md
index 8875d32a..d1599e3d 100644
--- a/content/Crappy_Tiny_Reader.md
+++ b/content/Crappy_Tiny_Reader.md
@@ -128,5 +128,5 @@ v0.06
diff --git a/content/DISA_and_DIFF.md b/content/DISA_and_DIFF.md
index a2d78e7f..9af1a4e3 100644
--- a/content/DISA_and_DIFF.md
+++ b/content/DISA_and_DIFF.md
@@ -483,5 +483,5 @@ container format essentially contains.
diff --git a/content/DSP_Binary.md b/content/DSP_Binary.md
index 5f1c9fb3..b12f66f5 100644
--- a/content/DSP_Binary.md
+++ b/content/DSP_Binary.md
@@ -34,9 +34,9 @@ categories = ["File formats","DSP"]
represents a memory region. The region is always 0x8000 bytes in size
(the first region starts at 0x1FF00000; the next is a 0x1FF08000 and so
on). The HW registers for DSP memory configuration are CFG11_SHAREDWRAM_32K_DATA and CFG11_SHAREDWRAM_32K_CODE, located at physical
address 0x10140000 (mapped to 0x1EC40000).
diff --git a/content/Extdata.md b/content/Extdata.md
index 632b1f03..f4ac2987 100644
--- a/content/Extdata.md
+++ b/content/Extdata.md
@@ -181,7 +181,7 @@ Usually the ExtdataID low is in the format '00'
Nintendo Video Extra Data This is where the video files are
-stored, and includes the
+stored, and includes the
thumbnail, the description, and possibly some checksum info in each
video file stored in the extdata images. There are always 9 files within
the subdirectory "00000000" of this folder, even without any videos
@@ -477,7 +477,7 @@ Pokémon Alpha Sapphire
diff --git a/content/FIRM.md b/content/FIRM.md
index af0c2e37..84a68e02 100644
--- a/content/FIRM.md
+++ b/content/FIRM.md
@@ -181,7 +181,7 @@ Thus, the ARM9 binary has the following header:
NCSD header, this contains the offsets/sizes of the below CTR-NAND partitions. This block also contains the TWL-NAND MBR partition table.
Yes
Yes
0x00000000
0x0B100000
0x01
0x01
0x00
0x03
TWL NAND region
No
Yes
0x00012C00
0x200
See below.
Console-unique encrypted New3DS key-storage, see below.
Yes
Yes
twln
0x00012E00
0x08FB5200
0x03
TWL-NAND FAT16 File System. (DSi)
Yes
Yes
twlp
0x09011A00
0x020B6600
0x03
TWL-NAND PHOTO FAT12 File System. (DSi)
Yes
Yes
0x0B100000
0x00030000
0x04
0x02
0x01
0x07
By default this partition is empty(only contains 0x00/0xFF bytes since it was never written to), when AGB_FIRM was never launched. This contains the AGB_FIRM GBA savegame.
diff --git a/content/Friend_code.md b/content/Friend_code.md
index 5ad11915..7d1c7821 100644
--- a/content/Friend_code.md
+++ b/content/Friend_code.md
@@ -25,7 +25,7 @@ This is a list of friend codes of different users.
Event handle signaled by HID-module, when the sharedmem+0(PAD/circle-pad)/+0xA8(touch-screen)
region was updated.
5
Event handle signaled by HID-module, when the sharedmem+0(PAD/circle-pad)/+0xA8(touch-screen)
region was updated.
6
Event handle signaled by HID-module, when the sharedmem accelerometer
+{{% href "../HID_Shared_Memory" %}} title="wikilink">sharedmem accelerometer
state was updated.
7
Event handle signaled by HID-module, when the sharedmem gyroscope state
+{{% href "../HID_Shared_Memory" %}} title="wikilink">sharedmem gyroscope state
was updated.
8
Event handle signaled by HID-module, when the sharedmem DebugPad state
+{{% href "../HID_Shared_Memory" %}} title="wikilink">sharedmem DebugPad state
was updated.
diff --git a/content/Hardware.md b/content/Hardware.md
index 451e6d10..219ff8c6 100644
--- a/content/Hardware.md
+++ b/content/Hardware.md
@@ -157,7 +157,7 @@ Block diagram of an ULTRAY2000 based architecture PICA200:
File:Pica200BlockDiagram.png
+{{% href "../File:Pica200BlockDiagram.png" %}}>File:Pica200BlockDiagram.png
PICA200 is compatible with OpenGL ES 1.1. It furthermore provides unique
diff --git a/content/Home_Menu.md b/content/Home_Menu.md
index a3110c6f..8b5d5419 100644
--- a/content/Home_Menu.md
+++ b/content/Home_Menu.md
@@ -833,26 +833,26 @@ handling [SD_Savedata_Backups](SD_Savedata_Backups "wikilink").
srv_init(), then srv_GetServiceHandle is used to initialize the
service handles for the following services: ns:s, ptm:sysm, and cfg:s.
+{{% href "../NS_and_APT_Services" %}} title="wikilink">ns:s, ptm:sysm, and cfg:s.
FSUSER:GetCardType is used here. AM commands are
then used to get the inserted gamecard programID, when successful the
gamecard ExeFS:/icon is then read to check the auto-boot flag(see the
@@ -966,7 +966,7 @@ and CountryInfo.
@@ -1036,16 +1036,16 @@ frequently(presumably from a separate thread).
Home Menu opens the archive for the Home Menu System_SaveData here. Then
+{{% href "../System_SaveData" %}} title="wikilink">System_SaveData here. Then
Home Menu attempts to open "/Launcher.dat" for reading, when successful
Home Menu just closes the file.
Home Menu first tries to use Home Menu first tries to use FS:CreateFile with this, which will fail when the
file already exists. This file is then opened with openflags=RW. After
-reading this file, Home Menu then uses PTM:GetTotalStepCount, then uses FSFile:GetSize. Then the
-service handle for "ndm:u"
+{{% href "../FSFile:GetSize" %}} title="wikilink">FSFile:GetSize. Then the
+service handle for "ndm:u"
is initialized with srv_GetServiceHandle(done from a separate thread
perhaps?). Then Home Menu writes to the already opened gamecoin.dat
file.
@@ -1166,9 +1166,9 @@ file.
-
FSUSER:CardSlotIsInserted and FSUSER:GetCardType is
+{{% href "../Filesystem_services" %}} title="wikilink">FSUSER:GetCardType is
used here. AM commands are then used to get the inserted gamecard
programID, when successful the gamecard ExeFS:/icon is then
read.
"boss:P" service
handle initialization with srv_GetServiceHandle is done here. Then srv_Subscribe is used with various
-noticationIDs. Home Menu then uses FS:IsSdmcDetected and srv_Subscribe is used with various
+noticationIDs. Home Menu then uses FS:IsSdmcDetected and FS:IsSdmcWritable. Home Menu then loads the cfg data for blkID
+{{% href "../Config_Savegame" %}} title="wikilink">cfg data for blkID
0x000D0000. Home Menu uses boss:P command 0x4010082, then uses
srv_GetServiceHandle for initializing service handles with the following
-services: "news:s" and "cecd:s".
@@ -1194,15 +1194,15 @@ title="wikilink">"news:s" and "cecd:s".
srv_GetServiceHandle is used to initialize the service handle for
-service "frd:a", then
+service "frd:a", then
various service commands are used for that.
Home Menu first attempts to use Home Menu first attempts to use FS:CreateFile with "/bashotorya.dat", which
normally fails since that file already exists. Home Menu then repeats
this with "/bashotorya2.dat".
This is used to read the cached icon data for the currently
inserted gamecard, if any. Prior to doing the read, Home Menu uses FSFile:GetSize. After opening
-the file and before FSFile:GetSize. After opening
+the file and before FSFile:GetSize is used, Home Menu uses AM commands
0x10070102(for theme DLC) and 0x30084(gamecard
"title-listing").
@@ -1254,14 +1254,14 @@ title="wikilink">FSFile:GetSize is used, Home Menu uses AM commands
0x150000
Before opening the file, Home Menu firsts opens this archive
under a new archive-handle again, then closes it. Prior to doing the
-read, Home Menu uses FSFile:GetSize.
Home Menu first tries to use FS:CreateFile with this, which will
fail when the file already exists. This file is then opened with
openflags=RW. After reading this file, Home Menu then uses PTM:GetTotalStepCount, then
+{{% href "../PTM_Services" %}} title="wikilink">PTM:GetTotalStepCount, then
uses FSFile:GetSize. Then Home Menu writes to the already opened
gamecoin.dat file.
At the same time as doing the above, Home Menu also uses(probably
-from a different thread) AM:GetTitleIDList3 with mediatype=NAND and
-maxTIDs=0x2000. Then Home Menu uses AM:ListTitles with the NAND promotional-video
titleID. Then Home Menu attempts to open the ExeFS:/icon in the NAND
promotional-video title.
AM:ReloadDBS, AM
command 0x10070102(for theme DLC), AM command 0x00130040, and AM command
0x10050084(for theme DLC) are used here. At the same time(from a
different thread?), the "act:u" service handle is initialized with
@@ -1380,7 +1380,7 @@ used.
@@ -1403,7 +1403,7 @@ then MICU initialization is done here(separate thread maybe?).
-
ACU:GetWifiStatus is used, the NAND shared-extdata
0xf000000b archive is then opened here.
@@ -1412,9 +1412,9 @@ title="wikilink">ACU:GetWifiStatus is used, the NAND shared-extdata
"/idb.dat"
0x2008
This first opens the file for writing, then uses FSFile:GetSize(output
+{{% href "../FSFile:GetSize" %}} title="wikilink">FSFile:GetSize(output
filesize is 0x6d4000). Then it writes to the file using size 0, then
-closes the file. Then PTM:GetStepHistory is used. Then Home Menu opens
"/idbt.dat", then reads 0x2008-bytes.
@@ -1422,18 +1422,18 @@ title="wikilink">PTM:GetStepHistory is used. Then Home Menu opens
diff --git a/content/Homebrew_Exploits.md b/content/Homebrew_Exploits.md
index 3b8c042a..6d4985cf 100644
--- a/content/Homebrew_Exploits.md
+++ b/content/Homebrew_Exploits.md
@@ -86,16 +86,16 @@ could still prove useful by chaining to exploits with higher privileges.
System Updater)
diff --git a/content/I2C_Registers.md b/content/I2C_Registers.md
index 9bff0adc..ba43d0ff 100644
--- a/content/I2C_Registers.md
+++ b/content/I2C_Registers.md
@@ -142,7 +142,7 @@ event, set to 3 by mcuMainLoop on reset if reset source is Watchdog
bit1: ShellState bit3: AdapterState bit4: BatteryChargeState
@@ -245,7 +245,7 @@ If no interrupt was received this register is 0
bit05: Shell close bit06: Shell open bit07: Fatal hardware condition(?) (sent when the MCU gets reset by the Watchdog timer) bit08: Charger removed bit09: Charger plugged in
@@ -283,13 +283,13 @@ href="https://github.com/profi200/libn3ds/blob/083c8ffa3f56a49802fa74b6afe45a968
System power control:
bit0: power off bit1: full reboot (unused). Discards things like CFG9_BOOTENV - Asserts RESET1 via PMIC command (?) (deasserts nRESET1). This could be the reset that controls some CFG9 registers - Asserts RESET2 (P0.1 = 0, PM0.1 = 0 (output)) (deasserts nRESET2) - Asserts FCRAM_RESET (P3.0 = 0) (deasserts nFCRAM_RESET) bit2: normal reboot. Preserves CFG9_BOOTENV, etc. - Asserts RESET2 (P0.1 = 0, PM0.1 = 0) - If in NTR emulation mode (see reg 0x02), asserts FCRAM_RESET (P3.0 = 0)
@@ -419,9 +419,9 @@ wide
0x2D
0x64
wo
-
This is used for This is used for controlling the notification LED (see MCURTC:SetInfoLEDPatternHeader as well), when this
register is written. It's possible to write data here with size less
than 0x64, and only that portion of the pattern data will get
@@ -433,7 +433,7 @@ do nothing.
0x2E
s
ro
-
This This returns the notification LED status when read (1
means new cycle started)
Various system state information (debug pointer table)
byte 0x00: Console type, see here byte 0x01: PMIC vendor code byte 0x02: Battery vendor code (determined from battery middle pin)
@@ -693,7 +693,7 @@ title="wikilink">here byte 0x05: RCOMP(?) byte 0x06: On-board battery slot NTC reading (more heat causes this value to go *down*, and cooling off will make this value go back up) byte 0x09: system model (see Cfg:GetSystemModel for values) byte 0x0A: Red Power LED mode (0 = off, 1 = on) byte 0x0B: Blue Power LED intensity (0x00 - 0xFF)
diff --git a/content/Inner_FAT.md b/content/Inner_FAT.md
index e7a5995a..9ac4655c 100644
--- a/content/Inner_FAT.md
+++ b/content/Inner_FAT.md
@@ -42,7 +42,7 @@ diagram:
### Savegame, `duplicate data = true`
@@ -390,7 +390,7 @@ Here is an example:
For extdata, because only two "files" (directory and file entry tables)
diff --git a/content/Internet_Browser.md b/content/Internet_Browser.md
index 8ff7b7ea..13598291 100644
--- a/content/Internet_Browser.md
+++ b/content/Internet_Browser.md
@@ -602,42 +602,42 @@ User-agent format: `Mozilla/5.0 (Nintendo 3DS; U; ; ) Version/.
diff --git a/content/Kernel_ABI.md b/content/Kernel_ABI.md
index 281b8cdc..f477e33d 100644
--- a/content/Kernel_ABI.md
+++ b/content/Kernel_ABI.md
@@ -18,12 +18,12 @@ back to the same registers (also starting with r0).
diff --git a/content/Memory_layout.md b/content/Memory_layout.md
index a1001031..fad95e8f 100644
--- a/content/Memory_layout.md
+++ b/content/Memory_layout.md
@@ -182,7 +182,7 @@ to the bootroms.
0x3800
0x100
This is the first 0x90 bytes of plaintext OTP
+{{% href "../OTP_Registers" %}} title="wikilink">plaintext OTP
when OTP hash verification is successful. The remaining 0x70 bytes are
cleared.
@@ -207,7 +207,7 @@ keys or the OTP hash in ITCM.
0x3B00
0x200
This is the 0x200-bytes from the plaintext FIRM header for the
-FIRM which was loaded by Boot9. This is the only location Boot9 uses for
storing the loaded FIRM headers internally, it's not stored anywhere
else.
@@ -252,7 +252,7 @@ Slot+0 is the modulus, slot+0x100 is the private exponent. This can be
confirmed by RSA-decrypting a message into a signature, then
RSA-encrypting the signature back into a message, and comparing the
original message with the output from the last operation.
-
FIRM doesn't seem to ever use
these. None of these are related to RSA-keyslot0 used for v6.0/v7.0 key
generation. These moduli are separate from all other moduli used
elsewhere.
@@ -265,7 +265,7 @@ elsewhere.
The unprotected ARM9-bootrom copies data to 0x07FFC900(mirror of
0x01FFC900) size 0x400. This data is copied from AXI WRAM, initialized
by ARM11-bootrom(the addr used for the src is determined by REG_UNITINFO). These are
+{{% href "../CONFIG_Registers" %}} title="wikilink">REG_UNITINFO). These are
RSA moduli: retailsrcptr = 0x1FFFD000, devsrvptr = 0x1FFFD400.
The first 0x100-bytes here is the RSA-2048 modulus for the CFA NCCH
@@ -273,7 +273,7 @@ header, and for the gamecard NCSD header.
0x01FFCA00 is the RSA-2048 modulus for the CXI accessdesc signature,
written to rsaengine keyslot1 by NATIVE_FIRM.
0x01FFCB00 size 0x200 is unknown, probably RSA related, these aren't
-used by FIRM(these are not
+used by FIRM(these are not
console-unique).
Unknown, not used by FIRM.
This isn't console-unique. The first 0x10-bytes are checked by the
v6.0/v7.0 NATIVE_FIRM keyinit function, when non-zero it clears this
block and continues to do the key generation. Otherwise when this block
@@ -358,7 +358,7 @@ retail DSis.
diff --git a/content/NWM_Services.md b/content/NWM_Services.md
index 01c8a51d..bd0b1dcb 100644
--- a/content/NWM_Services.md
+++ b/content/NWM_Services.md
@@ -389,7 +389,7 @@ for the MAC address, when the u8 at offset 0x8 in the network-struct is
0x0
0x6
This is the MAC address of the host. This is used for when connecting to the
+{{% href "../NWMUDS:ConnectToNetwork" %}} title="wikilink">connecting to the
network.
@@ -429,12 +429,12 @@ is 001F32.
0x10
0x4
wlancommID. Local-WLAN communication ID, normally this is:
-(user_process uniqueID
+(user_process uniqueID
<< 8) | val. Where val is 0x10 on retail(ENVINFO bit0
+{{% href "../Configuration_Memory" %}} title="wikilink">ENVINFO bit0
set), 0x90 for devunit. Official software includes an input bool flag
parameter for setting bit0 in this wlancommID, normally that flag isn't
-set. For Download Play,
+set. For Download Play,
this is always 0x2810 on retail(0x2890 on devunit).
This wlancommID can have the side affect of region-locking when the
title uses the uniqueID for the current title(hard-coded in .text
@@ -444,7 +444,7 @@ the title.
id8. ID, for Download
Play this is 0x55. 0x55/'U' seems to be used for networks where Wii
U can host it(Download Play, Smash Bros, ...) - this value isn't known
to be actually checked anywhere however.
@@ -458,12 +458,12 @@ to be actually checked anywhere however.
0x1: When set, spectators are not allowed to connect(see here). Checked by
-official user-processes before using here). Checked by
+official user-processes before using NWMUDS:ConnectToNetwork, when connecting as a
Spectator. Must be clear otherwise that code returns error 0xE10113EA.
If the initialized_flag at offset 0x8 is zero, this code handles it the
diff --git a/content/News_Services.md b/content/News_Services.md
index 0c03e398..bc5dfbc2 100644
--- a/content/News_Services.md
+++ b/content/News_Services.md
@@ -114,10 +114,10 @@ The actual main function called by main() does the following:
See here regarding the
updated CTRSDK function code.
This function is eventually called by newss_cmdf, newss_cmd10, and
. When calling a certain function fails in here, this
diff --git a/content/Nintendo_3DS_Sound.md b/content/Nintendo_3DS_Sound.md
index 871a3ddb..34373d17 100644
--- a/content/Nintendo_3DS_Sound.md
+++ b/content/Nintendo_3DS_Sound.md
@@ -19,7 +19,7 @@ storage](Twln/shared2/0000 "wikilink") is for DSi-mode software, and the
### File naming pattern
- 01: folder (page) number
diff --git a/content/Nintendo_Badge_Arcade/PrizeCollection.md b/content/Nintendo_Badge_Arcade/PrizeCollection.md
index 1ae372b8..e1b65886 100644
--- a/content/Nintendo_Badge_Arcade/PrizeCollection.md
+++ b/content/Nintendo_Badge_Arcade/PrizeCollection.md
@@ -326,7 +326,7 @@ background:
## Fixed Object (fob)
diff --git a/content/OTP_Registers.md b/content/OTP_Registers.md
index 6a316e98..5a9301b0 100644
--- a/content/OTP_Registers.md
+++ b/content/OTP_Registers.md
@@ -80,7 +80,7 @@ for "LocalFriendCodeSeed", etc.
0x19
0x1
This determines if the OTP is for a dev system; it indicates the
-CTCert issuer type: 0 = retail
+CTCert issuer type: 0 = retail
"Nintendo CA - G3_NintendoCTR2prod", non-zero = dev "Nintendo CA -
G3_NintendoCTR2dev".
@@ -88,7 +88,7 @@ G3_NintendoCTR2dev".
0x1A
0x6
Manufacturing date (of the SoC?). Usually month(s) before the
-dates in the logs stored in TWLNAND. Each byte is one field: year, month, day,
hour, minute, second. Year is encoded as year-1900 so that it fits in
one byte. This order matches up with the layout of a
@@ -119,7 +119,7 @@ specified in big endian if the OTP version is <5.
0x90
0x70
Used by Boot9 for generating the console-unique AES keyXs. However, due to a
+{{% href "../AES_Registers" %}} title="wikilink">keyXs. However, due to a
bug(?) in Boot9, only the first 0x1C-bytes here actually affect
console-unique key generation. The rest of the data is used for hashing,
but that output hash only gets overwritten without being used
diff --git a/content/PSPXI:EncryptDecryptAes.md b/content/PSPXI:EncryptDecryptAes.md
index 378a1e65..77a47376 100644
--- a/content/PSPXI:EncryptDecryptAes.md
+++ b/content/PSPXI:EncryptDecryptAes.md
@@ -41,7 +41,7 @@ title = 'PSPXI:EncryptDecryptAes'
This is used by NS for the APT
AES-CCM Wrap/Unwrap commands. These two NS commands are used by the Mii Maker application for the
+{{% href "../Mii_Maker" %}} title="wikilink">Mii Maker application for the
encrypted Mii data in the Mii QR codes.
@@ -79,7 +79,7 @@ encrypted Mii data in the Mii QR codes.
5
0x39
-
This is used by the This is used by the Download Play module for calculating a 32bit
checksum over the entire UDS application data-fames, stored in the DLP
data-frame header.
@@ -87,9 +87,9 @@ data-frame header.
6
0x2E
-
This is used by the This is used by the StreetPass CECD module to generate the CCMP key
-passed to nwm::CEC commands,
+passed to nwm::CEC commands,
when beginning StreetPass communications.
@@ -102,7 +102,7 @@ when beginning StreetPass communications.
0x36
This is used by the friends module.
Support for this keytype was added with the NATIVE_FIRM updated with
-2.2.0-X. When the running
+2.2.0-X. When the running
NATIVE_FIRM doesn't support this keytype, the result is the same as
using keytype7.
@@ -111,7 +111,7 @@ using keytype7.
0x39
This is used by the NFC module.
Support for this keytype was added with the NATIVE_FIRM updated with
-9.3.0-X. When the running
+9.3.0-X. When the running
NATIVE_FIRM doesn't support this keytype, the result is the same as
using keytype7. Before selecting this keyslot, Process9 writes a keyY
from the Process9 .(ro)data section(keydata is different for retail/dev
diff --git a/content/RO_Services.md b/content/RO_Services.md
index 8d89f9fd..44eeb41f 100644
--- a/content/RO_Services.md
+++ b/content/RO_Services.md
@@ -67,9 +67,9 @@ done.
Arguments : u64 firmTitleID (the high 32-bits of
that title ID (0 when using N3DS pm) have a special meaning on N3DS,
they're otherwise ignored, see below). This initializes the programID
-for launching FIRM, then triggers
-launching FIRM. With New3DS kernel,
+for launching FIRM, then triggers
+launching FIRM. With New3DS kernel,
it forces the firm title ID to be the New3DS NATIVE_FIRM, when the input
firm title ID is 2. The high firm title ID is always set to 0x40138. On
New3DS, the kernel disables the additional New3DS cache hw prior to
@@ -507,7 +507,7 @@ enabled, prior to executing the rest of the code from the
No
Arguments: 0, void* address or 1 This
used for initializing the 0x1000-byte buffer used by the launched FIRM. When the first parameter is 1,
+{{% href "../FIRM" %}} title="wikilink">FIRM. When the first parameter is 1,
this buffer is copied to the beginning of FCRAM at 0xE0000000. When it
is 0, this kernel buffer is mapped to the process address specified by
the second argument.
@@ -548,16 +548,16 @@ specified exception info buffer is 1, sp_usr - 0x5c is used instead, and
if it is 0, - 0x5c is used (0x5c is the size of the
exception info structure that is being pushed). Configured by NS on
startup on dev-units (default being 0 on non-debugger/jtag units) using
-the 0x000F0000 configuration block in the config savegame.
If 2, kernelpanic will be called when svcBreak is used by a
non-attached process. Configured by NS on startup on dev-units (default
being 0 on non-debugger/jtag units) using the 0x000F0000 configuration
-block in the config
+block in the config
savegame.
If 3, this changes the scheduling/preemption mode (when no threads
are being preempted, otherwise returns error 0xC8A01414), see KResourceLimit for more
+{{% href "../KResourceLimit" %}} title="wikilink">KResourceLimit for more
details.
@@ -565,7 +565,7 @@ details.
Yes
No
This triggers an MCU (hard) reboot. This reboot is triggered via
-device address 0x4A on the second I2C
+device address 0x4A on the second I2C
bus (the MCU). Register address 0x20 is written to with value 4. This
code will not return. On New3DS, the kernel disables the additional
New3DS cache hw prior to calling the reboot function from the
@@ -587,7 +587,7 @@ v4.5.
the process has a non-zero TID equal to the parameter above (which is
stored in a global variable), then KProcessHwInfo+0x32 ("process is the
currently running app") is set to true. Used by NS
-conditionally based on the contents of the NS CFA.
@@ -595,14 +595,14 @@ title="wikilink">NS CFA.
Yes
?
Arguments: u32 config ConfigureNew3DSCPU. Only
-available for the New_3DS kernel.
+available for the New_3DS kernel.
The actual code for processing this runs under the
, which runs on
all ARM11 cores. Only bit0-1 of the argument are used here. Bit 0
enables higher core clock, and bit 1 enables additional (L2) cache. This
-configures the hardware register for the flags listed here, among other
+{{% href "../NCCH/Extended_Header" %}} title="wikilink">here, among other
code which uses the MPCore private memory region registers.
diff --git a/content/Services_API.md b/content/Services_API.md
index ccadda8c..7a0a1710 100644
--- a/content/Services_API.md
+++ b/content/Services_API.md
@@ -33,248 +33,248 @@ List of services (grouped by the process which provides them):
app: am for applications, net: network installation (nim), u: local installation,
+{{% href "../NIM_Services" %}} title="wikilink">nim), u: local installation,
sys: am for system titles, pipe: not an actual port (internally used to
-represent the FSFile-like interface)
Mostly inherited from the Wii/DSi algorithm which used CRC-32
@@ -155,12 +155,12 @@ then used for the master key.
master key only being valid on a particular day, though this is
trivially defeated by setting the system time to the correct date that
the key was generated on.
-
Introduced a new scheme using HMAC-SHA-256. The HMAC key is
@@ -175,14 +175,14 @@ little-endian word is read from the start of the output hash. The low 5
decimal digits of this word are used as the master key.
Extension of v1 featuring a number of changes which serve to
obscure the HMAC key used.
The HMAC key is now stored in a separate file stored in the CVer
-RomFS, called masterkey.bin. This is used to update the key
independently of the mset title. In order to make this possible, a
scheme was devised to encode the required key within the inquiry number
diff --git a/content/YouTube.md b/content/YouTube.md
index b1d4c8cb..a52aff4e 100644
--- a/content/YouTube.md
+++ b/content/YouTube.md
@@ -39,8 +39,8 @@ Version/.". is "en", "fr", etc. is
First app update. This build uses the v7.0NCCH
encryption for the main CXI, this was the first retail title to use
this.
@@ -51,7 +51,7 @@ this.
This update fixed the vuln used for tubehax.
This version was built with the latest CTRSDK, so NATIVE_FIRM 9.6.0-X is now required.
+{{% href "../9.6.0-24" %}} title="wikilink">9.6.0-X is now required.
Plaintext HTTP is still used.
The RomFS is empty, and accessinfo is still 0x0. Strings related to
RO are still in the codebin, but during application startup ldr:ro isn't
@@ -70,14 +70,14 @@ Version/1.7498.US" and "Mozilla/5.0 (Nintendo 3DS New3DS; U; Factory
Media Production; en) Version/1.7499.US".
None of the public Old3DS/New3DS browserhax which were public at
+{{% href "../Browserhax" %}} title="wikilink">browserhax which were public at
the time this YouTube app was updated, affect the YouTube app at all (no
crashes).
The "range" html no longer displays: the page
background-color is displayed where the slider would have been. Hence,
unless there's a way to get this to actually display, sliderhax isn't usable with this
+{{% href "../Browserhax" %}} title="wikilink">sliderhax isn't usable with this
YouTube app version.