3dbrew - User contributions [en]

GPU/External Registers

2024-03-11T12:19:44Z

Vague Rant: /* LCD Source Framebuffer Setup */ Correct typo in mathematical calculation.

This page describes the address range accessible from the ARM11, used to configure the basic GPU functionality. For information about the internal registers used for 3D rendering, see [[GPU/Internal Registers]].

== Map ==
Address mappings for the external registers. GSPGPU:WriteHWRegs takes these addresses relative to 0x1EB00000.
{| class="wikitable" border="1"
! User VA
! PA
! Length
! Name
! Comments
|-
| 0x1EF00000
| 0x10400000
| 4
| Hardware ID
| Bit2: new model
|-
| 0x1EF00004
| 0x10400004
| 4
| ?
|
|-
| 0x1EF00010
| 0x10400010
| 16
| [[#Memory Fill|Memory Fill1]] "PSC0"
| GX command 2
|-
| 0x1EF00020
| 0x10400020
| 16
| [[#Memory Fill|Memory Fill2]] "PSC1"
| GX command 2
|-
| 0x1EF00030
| 0x10400030
| 4
| VRAM bank control
| Bits 8-11 = bank[i] disabled; other bits are unused.
|-
| 0x1EF00034
| 0x10400034
| 4
| GPU Busy
| Bit26 = PSC0, bit27 = PSC1, Bit30 = PPF, Bit31 = P3D
|-
| 0x1EF00050
| 0x10400050
| 4
| ?
| Writes 0x22221200 on GPU init.
|-
| 0x1EF00054
| 0x10400054
| 4
| ?
| Writes 0xFF2 on GPU init.
|-
| 0x1EF000C0
| 0x104000C0
| 4
| Backlight control
| Writes 0x0 to allow backlights to turn off, 0x20000000 to force them always on.
|-
| 0x1EF00400
| 0x10400400
| 0x100
| [[#LCD Source Framebuffer Setup|Framebuffer Setup]] "PDC0" (top screen)
|
|-
| 0x1EF00500
| 0x10400500
| 0x100
| [[#LCD Source Framebuffer Setup|Framebuffer Setup]] "PDC1" (bottom)
|
|-
| 0x1EF00C00
| 0x10400C00
| ?
| [[#Transfer_Engine|Transfer Engine]] "DMA"
|
|-
|colspan="5"| 0x1EF01000/0x10401000 - 0x1EF01C00/0x10401C00 maps to [[GPU/Internal_Registers|GPU internal registers]]. These registers are usually not read/written directly here, but are written using the command list interface below (corresponding to the GPUREG_CMDBUF_* internal registers)
|-
| 0x1EF01000
| 0x10401000
| 0x4
| ?
| Writes 0 on GPU init and before the Command List is used
|-
| 0x1EF01080
| 0x10401080
| 0x4
| ?
| Writes 0x12345678 on GPU init.
|-
| 0x1EF010C0
| 0x104010C0
| 0x4
| ?
| Writes 0xFFFFFFF0 on GPU init.
|-
| 0x1EF010D0
| 0x104010D0
| 0x4
| ?
| Writes 1 on GPU init.
|-
| 0x1EF014??
| 0x104014??
| 0x14
| "PPF" ?
|
|-
| 0x1EF018E0
| 0x104018E0
| 0x14
| [[#Command_List|Command List]] "P3D"
|
|}

== Memory Fill ==
{| class="wikitable" border="1"
! User VA
! Description
|-
| 0x1EF000X0
| Buffer start physaddr >> 3
|-
| 0x1EF000X4
| Buffer end physaddr >> 3
|-
| 0x1EF000X8
| Fill value
|-
| 0x1EF000XC
| Control. bit0: start/busy, bit1: finished, bit8-9: fill-width (0=16bit, 1=3=24bit, 2=32bit)
|}

Memory fills are used to initialize buffers in memory with a given value, similar to memset. A memory fill is triggered by setting bit0 in the control register. Doing so aborts any running memory fills on that filling unit. Upon completion, the hardware unsets bit0 and sets bit1 and fires interrupt PSC0.

These registers are used by [[GSP Shared Memory#GX SetMemoryFill|GX SetMemoryFill]].

== LCD Source Framebuffer Setup ==

All of these registers must be accessed with 32bit operations regardless of the registers' actual bit size.

The naming of these parameters reflects the physical characteristics of the displays, and not the way the 3DS is normally held.

To make sense of these values, the 3DS must be held in a way, so that the bottom screen is in the left hand, and the top screen is in the right hand, and that way the first pixel will be in the top-left corner, as it should be. If the 3DS is held normally, the first pixel is in the bottom-left corner.

All pixel and scanline timing values are 12bits, unless noted. This also applies to those fields where two u16 are combined into one register. Each u16 field is only 12bits in size. timin

The horizontal timing parameter order is as follows (values may overflow through HTotal register value):
0x10 < 0x14 <= 0x60.LO <= 0x04 <= 0x60.HI <= 0x08 <= 0x0C <= 0x10
0x18 <= 0x60.LO

Timing starts from HCount == 0, then each absolute value in the beforementioned register chain triggers when HCount == register, latching the primitive display controller into a new mode.
There is an inherent latch order, where if two simultenaous events occur, one event wins over another.

Known latched modes (in order):
- HSync (triggers a line to the LCD to move to the next line)
- Back porch (area between HSync and border being displayed, no pixels pushed, min 16 pixel clocks, otherwise the screen gets glitchy)
- Left border start (no image data is being displayed, just a configurable solid color)
- Image start (pixel data is being DMA'd from video memory or main RAM)
- Right border start/Image end (border color is being displayed after the main image)
- Unknown synchronization (supposed to be probably right border end, but this mode seems to be broken or not do anything)
- Front porch (no pixels pushed, 68 clock min, otherwise the screen doesn't sync properly, and really glitches out)

{| class="wikitable" border="1"
! Offset
! Name
! Comments
|-
| 0x00
| HTotal
| The total width of a timing scanline. In other words, this is the horizontal refresh clock divider value.

HClock = PClock / (HTotal + 1)
|-
| 0x04
| HStart
| Determines when the image is going to be displayed in the visible region (register 0x60).
|-
| 0x08
| HBR
| Right border start(?). Does nothing.

While this register seems to have no impact on the image whatsoever, it still has to be set to a valid value.
|
|-
| 0x0C
| HPF
| Front porch. The image is blanked during this period, and no pixels are pushed to the LCD.

Unknown why, but a single dot of red is displayed before entering this mode.
|-
| 0x10
| HSync
| Triggers a HSync pulse.

Based on behavior, this needs to last at least a pixel clock for the LCD to register the sync.
|-
| 0x14
| HPB
| Back porch? Has to be at least one bigger than HSync, otherwise HSync never triggers.

The display is blank, and the LCD displays nothing in this period (doesn't push pixels).
|-
| 0x18
| HBL
| Left border trigger treshold. Enables pushing pixels to the display.

If this value is smaller than the back porch, then the back porch period will be zero, and the border will be immediately displayed upon entering the back porch period.

Can be lower than HSync, as the back porch is what takes the controller out of HSync.

Must be <= HDisp start (reg 0x60 low u16), otherwise no pixels will be pushed due to a glitched state.
|-
| 0x1C
| H Interrupt timing
| Made up from two u16 values, PDC interrupt line is asserted when HCount == low u16, and most likely deasserted when HCount == high u16.

There seems to be some limitations though:
* low u16 must be smaller than high u16
* if low u16 is less than HTotal then high u16 must also be smaller than HTotal
* setting low u16 to >= HTotal disables the interrupt ever firing

This is configured by gsp in a way so that low u16 equals to HTotal, meaning the HSync interrupt will never fire.
|-
| 0x20
| low u16: ???
high u16: ???
| ???
|-
| 0x24
| VTotal
| Total height of the timing window. Can be interpreted as the vertical clock divider.

VClock = PClock / (HTotal + 1) / (VTotal + 1)

Setting this to 494 lowers framerate to about 50.040660858 Hz ((268111856 / 24) / (450 + 1) / (494 + 1)).
|-
| 0x28
| ?
| Seems to determine the vertical blanking interval.

Setting this to lower than <code>VTotal - VDisp</code> will cut off the top <code>VTotal - VDisp - thisvalue</code> lines.

Setting this to higher than <code>VTotal - VDisp</code> will make the image be pushed downwards with the overscan color visible.

Setting this to higher than <code>HTotal</code> will make the GPU skip vertical pixel data synchronization (hence filling the screen with the rest of the pixel data past the given screen framebuffer size). Also will skip <code>thisvalue + somevalue - HTotal</code> lines into the "global" pixel buffer.
|-
| 0x30
| ?
| Total amount of vertical scanlines in the pixel buffer, must be bigger than *an unknown blanking-like value*. If this value is less than VDisp then the last two scanlines will be repeated interlaced until VDisp is reached.
|-
| 0x34
| VDisp(?)
| Total amonut of vertical scanlines displayed (only for top screen it seems like). If this value is less than VTotal then the rest of the scanlines will not be updated on the screen, so those will slowly fade out. Must be bigger than *an unknown blanking-like value*, otherwise an underflow will happen.
|-
| 0x38
| Vertical data offset(?)
| ??? Seems to offset the screen upwards if this value is high enough. If this value is higher or equal to *some value* (aka. if less than one scanline is displayed on the screen) then the screen will lose synchronization.
|-
| 0x40
| V Interrupt timing
| Similar to H Interrupt timing (0x1C), except the comparison is done against VCount, the limitations are emposed on VTotal, and the interrupt that fires is VSync.

One important note is that it seems like the VSync interrupt always fires at HCount == 0, and there doesn't seem to be a register to control this behavior.
|-
| 0x44
| ???
| similar functionality to 0x10
|-
| 0x48
| ???
| bit0 seems to disable HSync, bit8 seems to disable VSync, rest of the bits aren't writable.
|-
| 0x4C
| Overscan filler color
| 24bits(? top 8bits ignored)

When the visible region is being drawn, but the timing parameters are set up in a way that the framebuffer is smaller than the visible region, it will be filled by this color.
|-
| 0x50
| HCount
| Horizontal "beam position" counter. Note that this value does not equal to the current pixel being drawn.
|-
| 0x54
| VCount
| Vertical "beam position" counter. Note that the scanline being drawn isn't equal to this value.
|-
| 0x5C
| ???
| low u16: Image width (including some offset?)
high u16: Image height??? (seems to be unused)
|-
| 0x60
| HDisp
| low u16: Image start (border --> pixel data)
high u16: Image end (pixel data --> border)
|-
| 0x64
| ???
| low u16: unknown
high u16: framebuffer total height (amount of scanlines blitted regardless of framebuffer height)
|-
| 0x68
| Framebuffer A first address
| For top screen, this is the left eye 3D framebuffer.
|-
| 0x6C
| Framebuffer A second address
| For top screen, this is the left eye 3D framebuffer.
|-
| 0x70
| Framebuffer format and other settings
| See [[#Framebuffer_format|framebuffer format]]
|-
| 0x74
| PDC control
| Bit 0: Enable display controller.
Bit 8: HBlank IRQ mask (0 = enabled).
Bit 9: VBlank IRQ mask (0 = enabled).
Bit 10: Error IRQ mask? (0 = enabled).
Bit 16: Output enable?
|-
| 0x78
| Framebuffer select and status
| Bit 0: Next framebuffer to display (after VBlank).
Bit 4: Currently displaying framebuffer?
Bit 8: Reset FIFO?
Bit 16: HBlank IRQ status/ack. Write 1 to aknowledge.
Bit 17: VBlank IRQ status/ack.
Bit 18: Error IRQ status/ack?
|-
| 0x80
| Color lookup table index select
| 8bits, write-only
|-
| 0x84
| Color lookup table indexed element
| Contains the value of the color lookup table indexed by the above register, 24bits, RGB8 (0x00BBGGRR)
Accessing this register will increase the index register by one
|-
| 0x90
| Framebuffer stride
| 32bits (bottom 3bits ignored?)

Distance in bytes between the start of two framebuffer rows (must be a multiple of 8).

In other words, this can be interpreted as the amount to add to the framebuffer pointer after displaying a scanline.

Setting this to zero will cause only the first line of the image to be displayed repeated on the entire display. With the HSync interrupt it's possible to "race the beam" to (ab)use this feature.

Because of this simplicity, writing a negative value here VFlips the image, although that requires the framebuffer pointer register to be set to the start of the last scanline, instead of at the start of the framebuffer.
|-
| 0x94
| Framebuffer B first address
| For top screen, this is the right eye 3D framebuffer. Unused for bottom screen in userland.
|-
| 0x98
| Framebuffer B second address
| For top screen, this is the right eye 3D framebuffer. Unused for bottom screen in userland.
|}

=== Framebuffer format ===
{| class="wikitable" border="1"
|-
! Bit
! Description
|-
| 2-0
| [[#Framebuffer_color_formats|Color format]]
|-
| 5-4
| Framebuffer scanline output mode (framebuffer interleave config)

0 - A (output image as normal)
1 - AA (output a single line twice, so framebuffer A is interleaved with itself)
2 - AB (interleave framebuffer A and framebuffer B)
3 - BA (same as above, but the line from framebuffer B is outputted first)

0 is used by bottom screen at all times.
1 is used by the top screen in 2D mode.
2 is used by top screen in 3D mode.
3 goes unused in userland.
|-
| 6
| Scan doubling enable?* (used by top screen)
|-
| 7
| ?
|-
| 9-8
| DMA size

0 - 4 words (32 bytes)
1 - 8 words (64 bytes)
2 - 16 words (128 bytes)
3 - ???

FCRAM doesn't support DMA size 3, as it can only burst up to 16 words (128 bytes), and will show a black screen instead.
|-
| 31-16
| Unknown
|}

* The weird thing about scan doubling, is that it works different between the bottom and top LCD. On the bottom LCD, it doubles the number of outputted pixels (so the same pixel is outputted twice, effectively doing column doubling). However on the top screen, it does scanline doubling instead. Considering that the bottom screen's table doesn't work on the top screen, this could give a hint as to how the top screen receives the pixel data from the PDC.
On a 2DS, it seems to have no effect on the top part of the display, and on the bottom screen it just shifts the framebuffer to the right two pixels.

GSP module only allows the LCD stereoscopy to be enabled when bit5=1 and bit6=0 here. When GSP module updates this register, GSP module will automatically disable the stereoscopy if those bits are not set for enabling stereoscopy.

When both interlacing and scan doubling are disabled, the full resolution of the top screen (240x800) can be utilized if the PDC registers are updated to accomodate this higher resolution. GSP contains tables for this mode (gsp mode == 1). GSP automatically applies this mode if both bit5 and bit6 are cleared. This is also the default, and the only valid mode for the bottom screen in userland.

If only AB interlacing is enabled, gsp detects this as a request to switch to 3D mode (gsp mode == 2), and enables the parallax barrier.
It's unknown how to control this, but some other PDC registers control if interlacing should be done by true interleaving (both framebuffers are treated as 240x400), or skipping lines (both framebuffers are treated as 240x800)

If only scan doubling is enabled, gsp detects it as a request to switch back to 2D mode for the top screen (gsp mode == 0). This is also the default mode for the top screen.

Both interlacing and scan doubling can't be enabled in usermode, but it works as expected in baremetal.

=== Framebuffer color formats ===
{| class="wikitable" border="1"
|-
! Value
! Description
|-
| 0
| GL_RGBA8_OES
|-
| 1
| GL_RGB8_OES
|-
| 2
| GL_RGB565_OES
|-
| 3
| GL_RGB5_A1_OES
|-
| 4
| GL_RGBA4_OES
|}
Color components are laid out in reverse byte order, with the most significant bits used first (i.e. non-24-bit pixels are stored as a little-endian values). For instance, a raw data stream of two GL_RGB565_OES pixels looks like GGGBBBBB RRRRRGGG GGGBBBBB RRRRRGGG.

Color formats 5, 6, and 7 are blocked by gsp, but they behave as pixel-doubled RGBA8 (not line doubling, but instead the same pixel is output twice) if used outside of userland.

== Transfer Engine ==
{| class="wikitable" border="1"
! Register address
! Description
|-
| 0x1EF00C00
| Input physical address >> 3
|-
| 0x1EF00C04
| Output physical address >> 3
|-
| 0x1EF00C08
| DisplayTransfer output width (bits 0-15) and height (bits 16-31).
|-
| 0x1EF00C0C
| DisplayTransfer input width and height.
|-
| 0x1EF00C10
| Transfer flags. (See below)
|-
| 0x1EF00C14
| GSP module writes value 0 here prior to writing to 0x1EF00C18, for cmd3.
|-
| 0x1EF00C18
| Setting bit0 starts the transfer. Upon completion, bit0 is unset and bit8 is set.
|-
| 0x1EF00C1C
| ?
|-
| 0x1EF00C20
| TextureCopy total amount of data to copy, in bytes.
|-
| 0x1EF00C24
| TextureCopy input line width (bits 0-15) and gap (bits 16-31), in 16 byte units.
|-
| 0x1EF00C28
| TextureCopy output line width and gap.
|}

These registers are used by [[GSP_Shared_Memory|GX command]] 3 and 4. For cmd4, *0x1EF00C18 |= 1 is used instead of just writing value 1. The DisplayTransfer registers are only used if bit 3 of the flags is unset and ignored otherwise. The TextureCopy registers are likewise only used if bit 3 is set, and ignored otherwise.

==== Flags Register - 0x1EF00C10 ====
{| class="wikitable" border="1"
! Bit
! Description
|-
| 0
| When set, the framebuffer data is flipped vertically.
|-
| 1
| When set, the input framebuffer is treated as linear and converted to tiled in the output, converts tiled->linear when unset.
|-
| 2
| This bit is required when the output width is less than the input width for the hardware to properly crop the lines, otherwise the output will be mis-aligned.
|-
| 3
| Uses a TextureCopy mode transfer. See below for details.
|-
| 4
| Not writable
|-
| 5
| Don't perform tiled-linear conversion. Incompatible with bit 1, so only tiled-tiled transfers can be done, not linear-linear.
|-
| 7-6
| Not writable
|-
| 10-8
| Input framebuffer color format, value0 and value1 are the same as the [[GPU Registers#Framebuffer_color_formats|LCD Source Framebuffer Formats]] (usually zero)
|-
| 11
| Not writable
|-
| 14-12
| Output framebuffer color format
|-
| 15
| Not writable
|-
| 16
| Use 32x32 block tiling mode, instead of the usual 8x8 one. Output dimensions must be multiples of 32, even if cropping with bit 2 set above.
|-
| 17-23
| Not writable
|-
| 24-25
| Scale down the input image using a box filter. 0 = No downscale, 1 = 2x1 downscale. 2 = 2x2 downscale, 3 = invalid
|-
| 31-26
| Not writable
|}

=== TextureCopy ===

When bit 3 of the control register is set, the hardware performs a TextureCopy-mode transfer. In this mode, all other bits of the control register (except for bit 2, which still needs to be set correctly) and the regular dimension registers are ignored, and no format conversions are done. Instead, it performs a raw data copy from the source to the destination, but with a configurable gap between lines. The total amount of bytes to copy is specified in the size register, and the hardware loops reading lines from the input and writing them to the output until this amount is copied. The "gap" specified in the input/output dimension register is the number of chunks to skip after each "width" chunks of the input/output, and is NOT counted towards the total size of the transfer.

By correctly calculating the input and output gap sizes it is possible to use this functionality to copy arbitrary sub-rectangles between differently-sized framebuffers or textures, which is one of its main uses over a regular no-conversion DisplayTransfer. When copying tiled textures/framebuffers it's important to remember that the contents of a tile are laid out sequentially in memory, and so this should be taken into account when calculating the transfer parameters.

Specifying invalid/junk values for the TextureCopy dimensions can result in the GPU hanging while attempting to process this TextureCopy.

== Command List ==
{| class="wikitable" border="1"
! Register address
! Description
|-
| 0x1EF018E0
| Buffer size in bytes >> 3
|-
| 0x1EF018E8
| Buffer physical address >> 3
|-
| 0x1EF018F0
| Setting bit0 to 1 enables processing GPU command execution. Upon completion, bit0 seems to be reset to 0.
|}

These 3 registers are used by [[GSP_Shared_Memory|GX command]] 1. This is used for [[GPU/Internal_Registers|GPU commands]].

== Framebuffers ==
These LCD framebuffers normally contain the last rendered frames from the GPU. The framebuffers are drawn from left-to-right, instead of top-to-bottom.(Thus the beginning of the framebuffer is drawn starting at the left side of the screen)

Both of the 3D screen left/right framebuffers are displayed regardless of the 3D slider's state, however when the 3D slider is set to "off" the 3D effect is disabled. Normally when the 3D slider's state is set to "off" the left/right framebuffer addresses are set to the same physical address. When the 3D effect is disabled and the left/right framebuffers are set to separate addresses, the LCD seems to alternate between displaying the left/right framebuffer each frame.

==== Init Values from nngxInitialize for Top Screen ====
* 0x1EF00400 = 0x1C2
* 0x1EF00404 = 0xD1
* 0x1EF00408 = 0x1C1
* 0x1EF0040C = 0x1C1
* 0x1EF00410 = 0
* 0x1EF00414 = 0xCF
* 0x1EF00418 = 0xD1
* 0x1EF0041C = 0x1C501C1
* 0x1EF00420 = 0x10000
* 0x1EF00424 = 0x19D
* 0x1EF00428 = 2
* 0x1EF0042C = 0x1C2
* 0x1EF00430 = 0x1C2
* 0x1EF00434 = 0x1C2
* 0x1EF00438 = 1
* 0x1EF0043C = 2
* 0x1EF00440 = 0x1960192
* 0x1EF00444 = 0
* 0x1EF00448 = 0
* 0x1EF0045C = 0x19000F0
* 0x1EF00460 = 0x1c100d1
* 0x1EF00464 = 0x1920002
* 0x1EF00470 = 0x80340
* 0x1EF0049C = 0

==== More Init Values from nngxInitialize for Top Screen ====
* 0x1EF00468 = 0x18300000, later changed by GSP module when updating state, framebuffer
* 0x1EF0046C = 0x18300000, later changed by GSP module when updating state, framebuffer
* 0x1EF00494 = 0x18300000
* 0x1EF00498 = 0x18300000
* 0x1EF00478 = 1, doesn't stay 1, read as 0
* 0x1EF00474 = 0x10501

[[Category:GPU]]

User talk:Yellows8

2017-02-18T13:05:22Z

Vague Rant: /* Nintendo Channel demos */ Many of these were archived.

Thanks for clearing that up about the free space on the "TWL", what confused me about the name was how the dev unit handled ds games. You know how the 3ds's code name is CTR(we don't know what that stands for yet) and the ds's code name is NTR which mean Nitro. When a 3DS game is inserted, the dev menu says a "CTR CARD" is inserted, but when a DS game is inserted it says a "TWL CARD" is inserted instead of what I expected which would be "NTR CARD". I still do not understand this. - 3dsguy
:DS=NTR, DSLite=USG (japanese for thin..), DSi=TWL(Twelve), DSiXL=UTL, 3DS=CTR... DS (on the 3DS) is usually associated with DSi.. --[[User:Elisherer|Elisherer]] 02:32, 19 October 2011 (CEST)
::3dsguy, that game you inserted was released *long* before DSi right?(also, sign your comments with the signature button) --[[User:Yellows8|Yellows8]] 04:02, 19 October 2011 (CEST)
:Elisherer thanks for clearing that up :).--[[User:3dsguy|3dsguy]] 09:46, 19 October 2011 (CEST)
::Yellows8, no that game was not, but just now i tryed it with a game released in 2006 and it still said 'TWL CARD', but what Elisherer said explained this.--[[User:3dsguy|3dsguy]] 09:46, 19 October 2011 (CEST)

:DS = NTR/Nitro
:DSi = TWL/Twilight
:3DS = CTR/Horizon
:Wii = RVL/Revolution

:Yellows8 - if you have DS/Nitro code running on a DSi system, can you escalate to DSi/TWL mode or load a TWL/DSi binary or similar. [[User:Jl12|Jl12]]
::No, that's impossible. When DSi launcher/sysmenu switches to DS-mode, launcher clears the MSB of a DSi register disabling access to the registers controlling what hw is enabled and the clock rate etc. Once those regs are disabled, it's impossible to re-enable them again without resetting the system via I2C etc.(Also, by the time any exploited title is running homebrew code, those regs are already disabled too.) --[[User:Yellows8|Yellows8]] 19:53, 7 November 2011 (CET)
: Is the NAND encrypted as it is on 3DS? Also, does DSi use DLP [for TWL games] at all? [[User:Jl12|Jl12]]
::Yes, DSi NAND is encrypted with AES-CTR. DSiWare uses download-play but the WMB/dlp binaries are DS-mode only.--[[User:Yellows8|Yellows8]] 06:27, 14 November 2011 (CET)

@Yellows8 - I'm sorry for asking this so late, but what does NUS stand for in this context "redistributing copyrighted content, in this case NUS content, is *not* allowed here.". I do not understand why you deleted my page: [[Update Data|Update Data]]
:NUS = Nintendo Update Servers. Those archive(s) you linked to contained files you downloaded from NUS, all of which are copyrighted. Besides, mirroring NUS content without any decryption done at all is *completely* pointless. --[[User:Yellows8|Yellows8]] 16:41, 12 December 2011 (CET)
::So would it be better to provide update logs, so it can point people to which update data is from which version as on the NUS the individual update data for each title is not stored the same way for all titles, providing people with further reference, so they know what they are using. You may ask me what would they use them for, they are still not decrypted and therefore pointless. ATM knowing which version is which on the NUS *maybe* very important, but I can't tell you more until later.--[[User:3dsguy|3dsguy]] 01:19, 13 December 2011 (CET)
:::Yeah a list of titleIDs and versions would be fine. One could grab that info from [[Title_list]] diffs, but that's not the best way to handle this. I have lists of updated titles for each 3DS system update, but of course I never bothered to document which version was from what sysupdate beyond just adding them to the title list page.(obtained from their system update SOAP) --[[User:Yellows8|Yellows8]] 02:20, 13 December 2011 (CET)

@Yellows8 - Thanks for your progress everyday, really. i have questions.. If feeling uneasy please tell me politely (and i will remove these).
* Would you need a tool that can use specified patterns to mark the decrypted binary (certainly it can not be perfect) ? Or have you find a disassembler so powerful that you don't need that a tool any more? please tell me. if that is useful, let me and my friend make that.
:The tool would have such ability in resolving the configuration file. Comment, Include, CmdID (with no params), CmdID (with specified params), CmdID (with no specified params). such as 80001000:0103:4,0102:4,Any:4. (ie this can mark 800010000102 out as a second type).
* Just curious. It has been a long time since neimod's latest update. Have you got a board from him, or you are only using the exploit (not with the board). If the board is helpful, is there any access to get/purchase one? (if no i think i should learn how to diy one then)
it seems to be a long time for you to do all the documentations by yourself. (Orz i forgot my suggestion) --[[User:Syphurith|Syphurith]] 02:35, 15 April 2013 (CEST)
:I don't have any 3DS ramhaxx, I use software savegame haxx of course. "is there any access to get/purchase one? (if no i think i should learn how to diy one then)" You should be asking neimod about that instead, but [https://secure.flickr.com/photos/neimod/6238747088/in/photostream the] [https://secure.flickr.com/photos/neimod/6212627980/in/photostream soldering] for 3DS ramhaxx would be *really* difficult. I'm not sure what you mean regarding that tool either, are you referring to a tool which would locate the code for service commands in a binary? --[[User:Yellows8|Yellows8]] 03:10, 15 April 2013 (CEST)
::Thanks for reply. I will try to contact him for boards. About the tool --sniff--.
::* Cons: can not detect structures; may make mistake; need configuration file (can be made by writing the header code)
::* Pros: can visually color the matched patterns; can load unlimited size of file (result will be divided into segments of 1MB or other)
::It would not be too difficult to make. However may take one or two weeks. --[[User:Syphurith|Syphurith]] 03:49, 15 April 2013 (CEST)
:::I have no need for a tool which searches for service commandIDs, when I can just search for commandIDs etc in my text-editor for disassembled code. --[[User:Yellows8|Yellows8]] 04:04, 15 April 2013 (CEST)
::::Well thanks for reply. I removed the details above. I will left it undone. Have a good day.--[[User:Syphurith|Syphurith]] 04:21, 15 April 2013 (CEST)
I've seen there are users without contributions flew in. There are even some guys cheating (or just making jokes) with your names.. What's your opinion about that? PS3Brew is blocking those without edits (daily). --[[User:Syphurith|Syphurith]] 17:03, 17 April 2013 (CEST)
:I don't care much about either,(neither of those fake accounts were used to edit anything at least) I'm not an admin here though. --[[User:Yellows8|Yellows8]] 17:36, 17 April 2013 (CEST)

Hello Yellows8,
I have a question regarding the release of the hack. You guys said, that you won't release it, because it is very easy to patch. Now the new firmware was released and in fact the exploit was patched. So releasing it now wouldn't change anything, because Nintendo already patched it.

But if you release it now, people could start develloping homebrew and when you guys find a new exploit for the new firmware, we would already have a good base of homebrew applications.

So why still hiding it from the world?

Best regards and thank you for your work

elBirx
:"the exploit was patched" Only the code execution haxx was [[5.0.0-11|fixed]], the savegame haxx was not fixed. "But if you release it now, people could start develloping homebrew" No, currently it's '''only''' useful for reverse engineers. Almost everyone that wants that savegame haxx would have no use for it right now, since "it's '''only''' useful for reverse engineers". --[[User:Yellows8|Yellows8]] 18:46, 21 April 2013 (CEST)
::So i do think only one that want to do Reverse engineering and do have skills in ARM disassembly can ask you for such a thing. Yellows8, what would i need to learn if i want to analyse those (taken ARM references in consideration)? --[[User:Syphurith|Syphurith]] 03:07, 22 April 2013 (CEST)
:::What are you referring to by "those"? --[[User:Yellows8|Yellows8]] 04:26, 22 April 2013 (CEST)
::::I'm so sorry for my poor expression skill. If i want to analyse the ram or anything that you used as a material.. Exefs is ARM code so i think to check those (you can get using exploit/haxx) need arm knowledges. i mean, that is those service APIs. you did say you can check disassembled code. Even i don't know what is left to be done. --[[User:Syphurith|Syphurith]] 07:31, 22 April 2013 (CEST)
:::::"what would i need to learn..." You could learn to read/write ARM assembly, and learn reverse engineering. --[[User:Yellows8|Yellows8]] 07:38, 22 April 2013 (CEST)
::::::Thanks. Confirmed~ That's clear to me now. --[[User:Syphurith|Syphurith]] 11:53, 22 April 2013 (CEST)

Eh. Yellows8, i got some n00b questions about the ARM execution.

There is non-executable sections in the memory layout, but where did these "This can be executed" flags got initialized (I mean that is made of hardware circuits or bios or other software section)? If that is not changable, would all those ARM cores use the same non-execution flags settings(possibly no so we may change the core to keep that work?). Even more, can we sniffer the data app to core and change its execution length then inject.

Also, is there any method to let the core execute those commands (that you detected) and use that to produce something you interested in?
:The ARM11 kernel [[Memory_layout#ARM11_User-land_memory_regions|initializes]] the MMU tables. "Also, is there any method to let the core execute those commands (that you detected) and use that to produce something you interested in?" By running code on a 3DS of course. --[[User:Yellows8|Yellows8]] 17:27, 17 June 2013 (CEST)
::Thanks. But still feeling strange of that strategy. I think at least the Home Menu may be able to re-map or deactive this mark.
::-snip- Sorry for being noob (i would try learning arm soon). Hope you good work.--[[User:Syphurith|Syphurith]] 02:46, 19 June 2013 (CEST)

Home Menu starts application processes via [[NS]], terminating and "suspending" process execution(the process is still running with that, the application threads wait for a [[NS]] notification for resuming actual execution) is done via NS as well. The ARM11 kernel handles mapping the processes' virtual memory for .text, .rodata, and .data. The ARM11 kernel handles terminating processes as well of course. The only process which has access to [[SVC|svcControlProcessMemory]] for mapping memory or changing memory permissions, is [[RO_Services|RO]] module, and of course that module will only map R-X .text pages for the signed [[CRO0|CRO]] .text. --[[User:Yellows8|Yellows8]] 03:16, 19 June 2013 (CEST)
:I can still remember ns/ro is also a title in title list. (if manually start that may fails/cause failure) if you launch a title with those commands manually, would it be exposed (in ram?)(, if so we may dump the firmware/modules)? MPS let multiple processes can share the same resources (with home menu?). or have we to modify the real memory externally? There are just thoughts, if interesting please think for a while; if not just tell me "NONE".--[[User:Syphurith|Syphurith]] 05:17, 19 June 2013 (CEST)
:I saw you update the AES page recently. you can confirm some keyslots are with the same data, but how had you done that (by comparing the data, or just the same memory location)? Can you even fetch those keys to decrypt the CDN TMD key strings? if so that would be a potential way to go.. BTW you're disasm those in-memory content not the decrypted Romfs right?
:I do wonder if contents decrypted succussfully, shall we need any customed disassembler? --[[User:Syphurith|Syphurith]] 16:51, 26 June 2013 (CEST)
::"some keyslots are with the same data" I encrypted an all-zero block with each AES engine keyslot with CTR=0, and encrypted that data again with each keyslot with keyY=0. When the output block for the former is the same for multiple keyslots, those keyslots use the same keyX/keyY. When the latter output block is the same for multiple keyslots, those keyslots use the same keyX. "decrypt the CDN TMD key strings" TMDs have nothing to do with decrypting the ticket titlekey. [[RomFS]] does not contain code(besides [[CRO0]] for web browser), that's stored in [[ExeFS]]:/.code. There's no need to dump code from memory when one can just use the [[AES]] engine. --[[User:Yellows8|Yellows8]] 17:40, 26 June 2013 (CEST)
:::oh well. sorry for been n00b again. then have you ever found something that you can execute to decrypt those CDN data? i badly wanna try it.. ExeFS.. okey.. hope good work--[[User:Syphurith|Syphurith]] 08:04, 27 June 2013 (CEST)
:::-snip- --[[User:Syphurith|Syphurith]] 08:36, 27 June 2013 (CEST)
::::You do not "call" crypto functions here, this is a hardware [[AES]] engine with a hardware key-scrambler. "found something that you can execute to decrypt those CDN data" Not sure what you mean when we had system-version v4.5 total-control code exec haxx since December. --[[User:Yellows8|Yellows8]] 09:52, 27 June 2013 (CEST)
:::::I forgot that hours ago. sorry. I thought we would be able to feed those raw data we got from CDN, and let it decrypt and extract for us. then at least we may be able to find those differences in modules implemented between two nearby versions. Some just fix crash - stablility, and some would fix some vulnerables we may use, and some would indicates those internal logical process of the module's implementation. we can not always rely on those ROP or other black-box methods. when we get the opportunity to build a CFW or a special homebrew that would affect the original behaviours of the system, we may need to modify it right? also that should show us some interesting points if we have ones dedicated on analysing those. --[[User:Syphurith|Syphurith]] 14:51, 27 June 2013 (CEST)
::::::Total-control code exec haxx = access to the [[AES]] engine obviously. "build a 'CFW'" That's not possible because of [[NCCH|RSA]], the only way around that would be to exploit software while the system is booting or exploit Home Menu. And patching the NCCH signature checks(from like savegame haxx with a game) is rather pointless, because you would have to re-patch *every* time you boot your 3DS(there's no need to run a regular homebrew application via NCCH this way either tbh). --[[User:Yellows8|Yellows8]] 16:06, 27 June 2013 (CEST)
:::::Thx. That's exactly how cfw works. (sorry i only have psp and 3ds) procfw on psp, have ipl flashed (psp has one special section inside its battery) can auto-patch the cfw code into the system while booting. But have no news for how those men repair customer's device i definitely have no clubs about the existence of similiar mechism. Besides, patching is not that easy, well. i know you have full access to AES engine, and i just want to know have you ever tried or thought of using contents from CDN and decrypt them and disassemble to seek something interesting. --[[User:Syphurith|Syphurith]] 05:31, 28 June 2013 (CEST)
::::::Using the AES engine is basically the only way to obtain cleartext NCCH for updated titles, without finalizing the install for titles. That's obviously where stuff like the new [[6.0.0-11|savegame]] keyY info came from. --[[User:Yellows8|Yellows8]] 07:16, 28 June 2013 (CEST)
:::::Okey, good. you can take use of that (however still not related to exefs..) have a good day.
::There is ClCertA on CDN. Important keys are stored in hardware key-scrambler right? A.ClCertA's private key stored in hardware and there is api called with write access in the package. B.ClCertA's key stored in NAND or somewhere else so we can eventually grab that and setup a proxy to remote while replacing the original ninty ones to our own self-sign ones (Then we would be able to decode the data transfers between proxy to 3ds and proxy to remote). C.ClCertA.. The workers think their private key can never be leaked so no CRL and just stored in hardware with a package cheating their boss. Which one you think would be the best answer? BTW i do really think there is ones with R/W access to the hardware.. Hope you find new apis.--[[User:Syphurith|Syphurith]] 02:35, 4 July 2013 (CEST)
:::ClCertA contains the SSL client RSA cert/private-key, when one has that one can only access their servers(like with a PC) with that, *nothing* more. I'm not sure why they store that data in a CFA seperate from SSL module, those two files stored in the ClCertA RomFS use additional encryption to begin with. "BTW i do really think there is ones with R/W access to the hardware" I'm not sure what you mean by that. --[[User:Yellows8|Yellows8]] 03:24, 4 July 2013 (CEST)
::::-snip-
:::::I don't think you understand what "SSL client certificate authentication" is, you should google it etc. A fake server would require the SSL server private-key from the real server, which you can't obtain of course. The AES engine has *nothing* to do with this besides being used to decrypt those two files in that CFA RomFS. This CFA is a system title so it's obviously stored in NAND, but of course you can't change any NCCH data due to RSA signing of course(modifying ClCertA is pointless anyway). There's not much point changing the SSL client cert/private-key, each 3DS prior to that update would be using the old ClCertA, and system updates require that SSL client auth for SOAP(besides SOAP that stuff isn't really interesting tbh). SSL module is the only process which uses ClCertA. "... write/read which section of memory" I have no use for that. --[[User:Yellows8|Yellows8]] 17:30, 4 July 2013 (CEST)
::::::oh well thanks. So only SSL module then. Without the ability to modify the original data, even a tunnel proxy would not work properly..(what annoying the rsa signature is - maybe as me to you. i means, 3ds with replaced, child cert and key of a self-signed, connects to a proxy with self-signed cert and key; the proxy takes the original cert and key that of 3ds client, to connects to ninty CDN. the two connections are all connecting with proper key and cert, that client signed by server; but 3ds's original cert and key must be replaced by one signed by our proxy's server cert and key, as what ninty does with 3ds. cause inability to change the content, it is nothing now.)(maybe better quick head to learning disasm and someday to have a try) BTW haven't seen Jl12 for long, seeing someone impeach him for just taking $ away lol. (even i don't think about that before. oh no this is your page and i should not be short to you) --[[User:Syphurith|Syphurith]] 02:16, 5 July 2013 (CEST)
::::::So please let me say that. "Sorry". also hope you find something today.

===Spam attack===
I guess the simple captcha isn't enough, do you have an idea what to do? (i'm asking you because you are the most active admin here). 
I think we should adopt a method of registration and waiting for an admin to approve it. the recent changes page is spammed hard and a lot of google pages, I guess, are being created linking to those pages. --[[User:Elisherer|Elisherer]] 09:40, 31 May 2013 (CEST)
:Mha is the only one that can do anything about anti-spam, I can't do much about it myself. Mha said that he would work on this tomorrow. --[[User:Yellows8|Yellows8]] 22:19, 31 May 2013 (CEST)
::A. Stop registeration for several weeks (NOT GOOD).
::B. Ajax to load captcha (maybe reCAPTCHA?). Not well-made bots will have trouble loading the javascript code or lose the speed (there is ones with javascript but can not act so quickly)(MAYBE USEFUL). This method is widely used ''it may be not so useful'' (against latest tools).
::C. Use auto filter to auto check those suspicious content and block those users, given an access for those by accident closed guys to talk about their opinion. (I do wonder if the wiki admin backdoor provide you such a tool)(Hey Regex~)
::D.find their IP and block the IP section for a while.(Similiar as A)
::E. Use man-made Email to validate (I means, instead of the system writing mail to user to validate, let user write mails to admin or other trusted -- use SPAM filter)(NOT WELL PRATICAL, Haven't tested, SO..)
::F. Calls for someone can trust and give him only those block and delete power (DIFFICULT). Well just a little tries..
::G. Try to update your wiki version first, i mean the version of this website framework. (MAYBE USEFUL? DOUBT..)
::If you tried the actions of blocking and the spam still flow in you need to update or call wiki program's supporters (may be exploit..) But i do wonder why they tried to attack here, a (script) guy (with latest tool)?(if so he should try to improve his skill first).
::Oh well, Recent changes. Guys have a good day (International Children's Day).--[[User:Syphurith|Syphurith]] 09:39, 1 June 2013 (CEST)
:We are able to mark those pages as spam but however no effects in deed if no one comes to remove those spam accounts. Well.--[[User:Syphurith|Syphurith]] 10:17, 17 June 2013 (CEST)

===Fundraiser===
Hello Yellows8,
I know you're not the one that is responsible for the chip decapping fundraiser, but I didn't manage to contact Jl12 via E-Mail (He's not responding). So, have you guys noticed that the donations hit the 2000$ last week? Will the decapping start anytime soon or do you need some more money for buying the 3DS itself?
Best regards
:Jl12 has had a broken 3DS for decapping before the fundraiser even started. And of course we noticed that, however since Jl12 is usually very busy it might be a while before he sends his 3DS for decapping. --[[User:Yellows8|Yellows8]] 00:26, 5 June 2013 (CEST)
Hi again,
anything regarding the chip decapping happened in the past week? Will the images be released to the public?
Best regards
:We still haven't heard anything from Jl12. --[[User:Yellows8|Yellows8]] 19:34, 15 June 2013 (CEST)
So Still no news from Jl12? Seems not seeing him for long.--[[User:Syphurith|Syphurith]] 02:35, 4 July 2013 (CEST)

Hi Yellows8,
sorry to bother you again, but I would like to know, if you heard something from Jl12 since July. As far as I know [http://gbatemp.net/members/mercluke.109574/ mercluke] donated the remaining 300$ months ago. Has this money never arrived or is this whole thing nothing but a scam after all and Jl12 ran off with the money? This would be really disappointing for all donaters and a very sad end for a very promising project.
:"if you heard something from Jl12 since July" Nope, he's very busy. When we do hear anything from him he would presumably update the donate page anyway, so no need to ask here. --[[User:Yellows8|Yellows8]] 17:14, 5 November 2013 (CET)

http://n-dev.net/donate.php is gone.

== I have tried to send you an email ==

I don't know if it will go through though. It is about help with dumping a 3DS kiosk demo, which is an earlier build than the final game. --[[User:Hiccup|Hiccup]] 16:15, 31 May 2015 (CEST)

== Contact ==

Look, I'm sorry to bother you, but I was wondering, how would I get in contact with you? --[[User:MassExplosion213|MassExplosion213]] 06:20, 9 September 2015 (CEST)
:EFNet IRC is preferred. --[[User:Yellows8|Yellows8]] 06:24, 9 September 2015 (CEST)

== The [[Games]] page ==

Could you explain its purpose. Also, I think it needs to be remade, because it seems to be based around the idea that there should only be one row per game, but it doesn't take into account the existence of revisions and region-free games. --[[User:Hiccup|Hiccup]] ([[User talk:Hiccup|talk]]) 21:57, 4 January 2016 (CET)
:Not sure why a homebrew wiki really needs an official-games-list tbh, there's more complete list(s) elsewhere anyway. --[[User:Yellows8|Yellows8]] ([[User talk:Yellows8|talk]]) 23:07, 4 January 2016 (CET)
::Do you think [[Title_list/eShop_Titles]] is needed? If you do, I will continue to add titles to it. --[[User:Hiccup|Hiccup]] ([[User talk:Hiccup|talk]]) 14:59, 6 January 2016 (CET)
:::Likewise for that page, there's much more complete list(s) elsewhere. --[[User:Yellows8|Yellows8]] ([[User talk:Yellows8|talk]]) 15:44, 6 January 2016 (CET)
::::Could you link me to these lists? The only thing I can think of is No-intro, but that probably doesn't cover some system titles and it doesn't list the "v" versions. --[[User:Hiccup|Hiccup]] ([[User talk:Hiccup|talk]]) 15:49, 6 January 2016 (CET)

== Nintendo Channel demos ==

Is it still possible to use [https://code.google.com/archive/p/wmb-asm/wikis/NintendoChannel.wiki these tools] to download Nintendo Channel demos? Or are the servers offline? Did you (or anyone else) ever download any ROMs? It'd be a shame if they were lost. --[[User:Hiccup|Hiccup]] ([[User talk:Hiccup|talk]]) 15:02, 17 February 2017 (CET)
:Don't think so, likewise @ downloading ''all'' of those demos. --[[User:Yellows8|Yellows8]] ([[User talk:Yellows8|talk]]) 16:11, 17 February 2017 (CET)
::Do you still have any download(s) you made to test it? --[[User:Hiccup|Hiccup]] ([[User talk:Hiccup|talk]]) 14:46, 18 February 2017 (CET)
:Many of these were archived and are included in the No-Intro "Nintendo - Nintendo DS (Download Play)" DAT. [[User:Vague Rant|Vague Rant]] ([[User talk:Vague Rant|talk]]) 15:04, 18 February 2017 (CET)

Homebrew Exploits

2016-10-25T15:23:20Z

Vague Rant: /* Standalone Homebrew Launcher Exploits */ General edit spam. (-34 --> -35)

==Payload==
{| class="wikitable" border="1"
|-
! Works on latest fw
! Name
! Description
! Supported firmwares
|-
| style="background: lightgreen" | Yes
| [https://smealum.github.io/3ds/ *hax payload]
| Booted by all of the below non-sysmodule exploits.
| From '''9.0.0-7''' up to and including '''11.2.0-35'''.
|}

For the rest of this page, "Supported firmwares" refers to the exploit ''itself'', not whether *hax payload supports it.

==Standalone Homebrew Launcher Exploits==
The following homebrew exploits can be executed on a previously un-exploited system. ''Please'' see the above Payload section regarding what "Supported firmwares" indicates ''exactly''.

{| class="wikitable" border="1"
|-
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[ninjhax|Ninjhax 1.1b]]
| From '''4.0.0-7''' up to and including '''9.2.0-20'''.
| A cartridge or eShop version (JPN-only) of "Cubic Ninja".
| smea
| [http://smealum.net/ninjhax/ Install]
|-
| style="background: lightgreen" | Yes
| [[ninjhax|Ninjhax 2.x]]
| From '''9.0.0-7''' up to and including '''11.2.0-35'''.
| A cartridge or eShop version (JPN-only, not available anymore for purchase) of "Cubic Ninja".
| smea
| [https://smealum.github.io/ninjhax2/ Install]
|-
| style="background: lightgreen" | Yes
| [http://plutooo.github.io/freakyhax/ freakyhax]
| From '''9.0.0-7''' up to and including '''11.1.0-34'''.
| A cartridge or eShop version (USA/EUR/JAP, not available anymore for purchase) of "Freakyform Deluxe".
| plutoo
| [http://plutooo.github.io/freakyhax/ Install]
|-
| style="background: salmon" | No
| [http://plutooo.github.io/smilehax/ smilehax]
| From '''9.0.0-7''' up to and including '''11.0.0-33'''
| SmileBASIC (JPN all versions up to 3.32 excluded, USA 3.31 only)
| plutoo
| [http://plutooo.github.io/smilehax/ Install]
|-
| style="background: salmon" | No
| [http://mrnbayoh.github.io/basicsploit/ BASICSploit]
| From '''9.0.0-7''' up to and including '''11.0.0-33'''
| SmileBASIC (USA all versions)
| MrNbaYoh
| [http://mrnbayoh.github.io/basicsploit/ Install]
|-
| style="background: lightgreen" | Yes
| [[smashbroshax|smashbroshax]] (beaconhax)
| (New 3DS only) From '''9.0.0-X''' up to and including '''11.1.0-34'''.
| Super Smash Bros 3DS (full-game) and a way to broadcast raw wifi beacons. The demo (prior to the updated November 2015 [https://github.com/yellows8/3ds_smashbroshax version]) isn't usable with the *hax payloads. Game-version v1.1.3 fixed the vuln used with this, see the repo for a workaround for that.
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/3ds_smashbroshax Install]
|-
| style="background: salmon" | No
| [[browserhax]]
| From '''9.0.0-2''' to '''11.0.0-33'''
Note that the browser-version-check bypass is only usable prior to [[10.7.0-32]].
| A USA, EUR, JPN, or KOR system.
| [[User:Yellows8|Yellows8]]
| [http://yls8.mtheall.com/3dsbrowserhax.php Install]
|}

Note that ninjhax 1.x is still not obsolete. Even though ninjhax 2.x can be run on 9.3+, this was made possible (amongst other things) by sacrificing the memory remapping exploit used in ninjhax 1.x (rohax). Therefore, things like JIT engines for emulators can only be supported on ninjhax 1.x. Furthermore, ninjhax 2.x does not run on system versions below 9.0.0-X, while ninjhax 1.x does.

==Secondary Exploits==
Installation of these exploits requires a previously exploited system to install. After installation, they can be used on their own. ''Please'' see the above Payload section regarding what "Supported firmwares" indicates ''exactly''.

{| class="wikitable" border="1"
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[ironhax]]
| From '''9.5.0-X''' up to and including '''10.3.0-X''', for '''X''' up to and including 28.
| A copy of "Ironfall: Invasion" downloaded from eShop before August 11th, 2015. Note the updated version that was released on October 13th, 2015 is not supported.
| smea
| [http://smealum.github.io/3ds/ Install]
|-
| style="background: salmon" | No, exploit update required.
| [http://vegaroxas.github.io/ steelhax]
| From '''9.0.0-X''' up to and including '''11.1.0-X''', for '''X''' up to and including 34.
| A copy of Steel Diver: Sub wars
| Vegaroxas
| [https://github.com/VegaRoXas/vegaroxas.github.io/raw/master/files/steelhax-installer.zip Install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/yellows8/oot3dhax oot3dhax]
| From '''9.0.0-X''' up to and including '''11.1.0-X''', for '''X''' up to and including 34.
| A gamecard or eShop-install of Legend of Zelda: Ocarina of Time 3D. Besides using the installer app, writing raw saveimages with a save dongle for example is another option. Before compression was introduced in the 2016-7-18 release, the size of the *hax payload meant the exploit can't coexist with regular saves on a physical version of the game.
| Yellows8 / smea et al.
| See [https://smealum.github.io/3ds/ here].
|-
| style="background: salmon" | No
| [[menuhax]]
| JPN/USA/EUR: From '''9.0.0-X''' up to and including '''11.0.0-X'''.
KOR: From '''9.6.0-X''' up to and including '''11.0.0-X'''.
| JPN/USA/EUR: Having created [[Home_Menu#Home_Menu_Theme_SD_ExtData|theme extdata]] through opening the official theme selector at least once.
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/3ds_homemenuhax/releases Download]
|-
| style="background: lightgreen" | Yes
| [https://github.com/shinyquagsire23/supermysterychunkhax supermysterychunkhax]
| From '''9.9.0-X''' (USA/JPN) / '''10.2.0-X''' (EUR) up to and including '''11.1.0-X''', for '''X''' up to and including 34.
| A gamecard or eShop-install of Pokémon Super Mystery Dungeon.
| Shiny Quagsire / SALT team
| [https://smd.salthax.org/ Install].
|-
| style="background: salmon" | No
| [https://github.com/shinyquagsire23/v_hax (v*)hax]
| From '''9.0.0-X''' up to and including '''11.0.0-X''', for '''X''' up to and including 33.
Note that '''9.0.0-X''' is only required for the Homebrew Launcher - the game itself only requires '''2.1.0-X''' for primitive userland code execution.
| A copy of VVVVVV downloaded after March 2012 (v1). v1.1 patches out the overflow vulnerability used by (v*)hax.
| Shiny Quagsire / SALT team
| [https://vvvvvv.salthax.org/ Install].
|-
| style="background: salmon" | No, exploit update required.
| [https://github.com/Dazzozo/humblehax humblehax]
| From '''9.0.0-X''' (USA/EUR) up to and including '''11.0.0-X''', for '''X''' up to and including 33.
| An eShop-install of Citizens of Earth (either v1 or v2), featured in the Humble "Friends of Nintendo" Bundle.
| Dazzozo / SALT team
| [https://citizens.salthax.org/ Install].
|-
| style="background: lightgreen" | Yes
| [http://mrnbayoh.github.io/basehaxx/ basehaxx]
| From '''9.0.0-X''' up to and including '''11.1.0-X''', for '''X''' up to and including 34.
| A gamecard or eShop-install of Pokémon Omega Ruby / Alpha Sapphire.
| MrNbaYoh
| [http://mrnbayoh.github.io/basehaxx/ install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/yellows8/stickerhax stickerhax]
| From '''9.0.0-X''' up to and including '''11.2.0-X'''(not including installation).
| A gamecard or eShop-install of Paper Mario: Sticker Star.
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/stickerhax Here]
|}

==Exploits without Homebrew Launcher (Not recommended)==

'''Warning:''' The following exploits can run code, but are missing a 3DSX launcher. They cannot launch any homebrew in the 3DSX format.

{| class="wikitable" border="1"
|-
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[browserhax]] (Without the loader in the 3ds_browserhax_common repo)
| (Old3DS) From '''5.0.0-2''' to '''11.0.0-33''' (Pre-v5.0 is supported for some versions if you manually modify the source)

(New3DS) From '''9.0.0-20''' to '''11.0.0-33'''

Note that the browser-version-check bypass is only usable prior to [[10.7.0-32]].
| An USA, EUR, or JPN system.
| [[User:Yellows8|Yellows8]]
| [[browserhax|Install]]
|-
| style="background: salmon" | No
| Ninjhax (with specialized payloads)
| Up to '''9.2.0-20'''?
|
| smea + independent developers
| N/A
|}

==Previous Exploits==
'''Warning:''' These exploits '''do not work'''. They are exploits which no longer function at all, regardless of software or firmware revision.
{| class="wikitable" border="1"
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[tubehax|Tubehax]]
| None. '''Was''': From '''9.0.0-X''' up to and including '''10.1.0-X''', for '''X''' up to and including 27.
| The YouTube application and an Internet connection. As of October 15, 2015, this is no longer usable due to an update being released which fixes the vuln used by tubehax + app update being forced (see [[YouTube|here]]).
| smea
| [http://smealum.github.io/3ds/ Install]
|}

==Other Homebrew Loaders==
The [https://github.com/yellows8/hblauncher_loader hblauncher_loader] title can be used when running under modded-FIRM which allows running unsigned titles, to boot the *hax payloads.

==Sysmodule Exploits==
This section is for system-module exploits, which can be run from the *hax payloads.

{| class="wikitable" border="1"
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
|-
| style="background: lightgreen" | Yes, that's not the intended default use however.
| [https://github.com/yellows8/ctr-httpwn/releases ctr-httpwn]
| From '''9.6.0-X''' up to and including '''11.1.0-X'''.
| None
| [[User:Yellows8|Yellows8]]
|}

==WebKit vuln testing==
See [https://github.com/yellows8/3ds_browserhax_common/issues/28 here].

FirmwareNews

2016-09-13T04:25:36Z

Vague Rant: New latest firmware.

As of this writing, the latest firmware is ''' 11.1.0-34'''.

There are ways to run homebrew on this version, see [[Homebrew Exploits]].

----

Full system control exploits are only public for system versions up to and including '''9.2.0-X'''.

EShop

2016-04-23T13:19:53Z

Vague Rant: Purely cosmetic change, display lowercase "e" in article title with {{DISPLAYTITLE:eShop}}.

{{DISPLAYTITLE:eShop}}
The Nintendo 3DS eShop was added in the June 2011 update for JP/EUR/USA.

From here, you can download Virtual Console games, 3D Classics, DSiware software, view screenshots, and 3D trailers for upcoming 3DS titles.

While eShop is loading, eShop will use command [[NIMS:CheckSysupdateAvailableSOAP]]. If a system update is available where title installation for system titles still needs finalized (or when the updated titles were not downloaded at all), eShop will then display the "system update is available" message.

The eShop application uses command [[AMNet:FinishInstallToMedia]] to finalize the SD title install (if the whole title is downloaded while eShop is still running), however, before using that command the eShop application also uses [[AMNet:FinishInstallToMedia]] to finalize installing all system titles (from system updates).

== eShop QR Codes ==
eShop QR Codes can be scanned with the camera, allowing one to quickly navigate to the desired eShop title with just two clicks. The QR Codes themselves is a simple text/url QR, started with "ESHOP://" string followed by a decimal eShop content link id(same IDs used internally by eShop for all content) and then some special data, delimited by a dot symbol, which can be ommited.

In order for the QR-code string data to be valid for eShop, it must begin with "ESHOP://5", with the first ID being all decimal.

{| class="wikitable"
|-
! QR Code source
! Region
! Title
! Serial
! Title ID
|-
| ESHOP://50010000000201.PEAALL000000 || EUR || Nintendogs & Cats Demo || ADA/B/C || 0004000200030c01
|-
| ESHOP://50010000007870.PEAALL000000 || EUR || Crush 3D || A??P || 00040002
|-
| ESHOP://50010000008009.PEAALL000000 || EUR || Resident Evil Revelations Demo || ABRE || 000400020005ee01
|-
| ESHOP://50010000008123.J00101Z00095 || JPN || Rhythm Thief And The Emperor's Treasure Demo || ARTJ || 00040002
|-
| ESHOP://50010000008404.PEAALL000000 || EUR || Mario And Sonic At The London 2012 Olympic Games Demo || ACMP [http://mediacontent.nintendo-europe.com/NOE/images/game_content/ACMP-MarioAndSonicAtTheLondon2012OlympicGames-QRCode-EA_ALL_000_001.bmp] || 00040002
|-
| ESHOP://50010000008447.J00101Z00094 || JPN || Resident Evil Revelations Demo || ABRJ || 00040002
|-
| ESHOP://50010000008449.J00101Z00082 || JPN || Swapnote || JFRJ ||?
|-
| ESHOP://50010000008561 || USA || Swapnote || JFRE || 0004000000051700
|-
| ESHOP://50010000008647.J00101Z00096 || JPN || Metal Gear Solid Snake Eater 3D Demo || AMGJ || 0004000200048101
|-
| ESHOP://50010000008648.J00101Z00097 || JPN || Theatrythm Final Fantasy || ATHJ ||?
|-
| ESHOP://50010000008782.PEAALL000000 || EUR || Metal Gear Solid Snake Eater 3D Demo || AMGE || 0004000200082401
|-
| ESHOP://50010000008842.PEAALL000000 || EUR || Rhythm Thief And The Emperor's Treasure Demo || ARTP [http://mediacontent.nintendo-europe.com/NOE/images/game_content/ARTP-RhythmThief_TheEmperorsTreasure-QRCode-EA_ALL_000_001.bmp] || 00040002
|-
| ESHOP://50010000009084.J00101Z00121 || JPN || Hatsune Miku And Future Stars: Project Mirai Demo || AM9J || 00040002
|-
| ESHOP://50010000009102.J00101Z00106 || JPN || Denpa Ningen RPG || JD8J ||?
|-
| ESHOP://50010000009161.J00101Z00118 || JPN || Dillon's Rolling Western || JAMJ || 00040000
|-
| ESHOP://50010000009261 || USA || Dillon's Rolling Western || JAME? || 00040000
|-
| ESHOP://50010000009401.J00101Z00120 || JPN || Kingdom Hearts 3D Video Download || JZ8J ||?
|-
| ESHOP://50010000009403.J00101Z00119 || JPN || DQM 3D Video Download || JZ7J ||?
|-
| ESHOP://50010000009575.PEAALL000000 || EUR || Kid Icarus: Of Myths And Monsters (Virtual Console) ||? ||?
|-
| ESHOP://50010000009846 || USA || Ketzal's Corridors ||? ||?
|}

* New QR Code for Japanese "Photos with Super Mario" has a different code string: ESHOP://50010000013120.J00108Z00001.CD588EAE95A3A68D15C647DA2AC0945FD88F70AB8A31149E51C4B05FB927B0B8

* There is a link in the Japanese eShop <nowiki>[http://www.nintendo.co.jp/3ds/eshop/qrCode.html?####]</nowiki> where you can replace the #### with the Japanese eShop title's serial and you will get it's QR code. (i.e. http://www.nintendo.co.jp/3ds/eshop/qrCode.html?jcaj will get you the pushmo QR code)

* You could use Google's Chart API to create a QR code from the codes above: https://chart.googleapis.com/chart?chs=150x150&cht=qr&chl=ESHOP (replace the ESHOP text with the ESHOP:// link from one of the above)

== NS eShop application parameters ==
This section describes the 0x1C-byte structure stored at the application parameters from [[APT:StartApplication]], under the 0x300-byte buffer listed there.

{| class="wikitable"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x4
| Unknown, usually 0x3?
|-
| 0x4
| 0x4
| Unknown, usually 0x0?
|-
| 0x8
| 0x8
| u64 binary eShop content ID, same ID from the first string in eShop QR-codes except in binary form.
|-
| 0x10
| 0x10
| This is the last string from the QR-code(if any), no NUL-termination.
|}

== ExtData ==
The ExtData [[Extdata#Filesystem|File System]] for eShop is as follows:

root
├── icon
├── boss
│ └── TIGER100.tmp
└── user

{| class="wikitable" border="1"
|-
! File
! Details
! Size
! Firmware Introduced
! Plain text
|-
| icon
| Duplicate from application ExeFS. Always image 00000002
| 0x36C0 Bytes
| [[2.0.0-2]]
| [https://dl.dropboxusercontent.com/u/60710927/CTR/Sample/eShopExtdata/icon Download_EUR]
|-
| TIGER100.tmp
| Always image 00000003.
| 0xCE47 bytes (varies?)
| [[2.0.0-2]]
|
|}

== Music ==
The eShop pulls its music from a static, region-specific link in a format similar to the following:

https:// a248.e.akamai.net/f/248/103046/10m/npdl.c.app.nintendowifi.net/p01/nsa/CtfKXACbUPl8s7lk/BGM1/US_BGM1 ,
where region is one of the primary system regions (JP, US, EU, KR, etc.) Support also exists for 'BGM2', but this seems to be unused.
The music is held in a [[SpotPass|BOSS]] container.

The format consists of a brief XML header describing the audio (including the date it was set as the main eShop theme, loop times, size, etc) followed by a raw AAC stream. Tools such as FFmpeg can handle rebuilding this stream with ADTS headers for proper time info and such.

The [[Home_Menu|Home Menu]] uses nearly the same format for the Theme Shop's background music.

== URLs ==

eShop uses the following domains over HTTPS:

* cp3s-auth.c.shop.nintendowifi.net
* a248.e.akamai.net
* ninja.ctr.shop.nintendo.net
* samurai.ctr.shop.nintendo.net
* ccif.ctr.shop.nintendo.net
* eou.c.shop.nintendowifi.net

These domains are used by [[NIM_Services|NIM]]:

* nus.c.shop.nintendowifi.net
* ecs.c.shop.nintendowifi.net
* cas.c.shop.nintendowifi.net

ninja.ctr.shop.nintendo.net and samurai.ctr.shop.nintendo.net contain the bulk of the eShop information.

=== Common Parameters to ninja and samurai ===

For every request to the ninja and samurai servers, three parameters are always sent, though are not necessarily required:

{| class="wikitable" border="1"
|-
! Parameter
! Required
! Description
! Type
! Normal value
|-
| shop_id
| depends on the URL, usually no
| Describes which eShop instance should be used. 1 indicates the 3DS eShop, 2 indicates the Wii U eShop. 3 seems to yield the same results as 2. Values greater than 3 or less than 1 are invalid. Defaults to 2 or 3 if not given.
| unsigned integer
| 1
|-
| lang
| no
| Describes the language. Seems to be an ISO 639-1 code in lower case. Every eShop region has a default language that is used if this parameter is not given. Some regions have multiple languages, such as CA (en and fr).
| string (two characters)
| depends on region and eShop settings; for US: en
|-
| _type
| no
| Describes whether the client wants to receive JSON or XML. This parameter seems actually unused and the servers always return XML.
| string
| json
|}

=== samurai ===

samurai.ctr.shop.nintendo.net (samurai) provides metadata about titles. The samurai server provides the backend for the eShop title search.

Common parameters described above can always be sent.

{| class="wikitable" border="1"
|-
! Path
! Description
! Parameters
|-
| /samurai/ws/'''region'''/titles
| Fetches the title list, containing the content id (not the 3DS title id), the product code and the localized title name
| All of these are optional.
* genre[]: genre ID (unsigned int)
* publisher[]: publisher ID (unsigned int)
* price_min: minimum price in region currency (signed int)
* price_max: maximum price in region currency (signed int)
* video_format: "moflex"
* freeword: keyword(s?) to look for (string)
* limit: maximum results
* offset: results to skip
* sort: one of "new", "popular" or "score"
* release_date_before: date/time title must have been released before (UNIX timestamp prefixed by +)
* release_date_after: date/time title must have been released after (UNIX timestamp prefixed by -)
|-
| /samurai/ws/'''region'''/news
| eShop news section
| (none)
|-
| /samurai/ws/'''region'''/telops
| Scrolling news on the top screen
| shop_id is required
|-
| /samurai/ws/'''region'''/directory/'''(long long unsigned int)''' and /samurai/ws/'''region'''/directory/~'''(string)'''
| Collections, like sales
| (none)
|-
| /samurai/ws/'''region'''/title/'''content id'''
| Returns information about the title, more verbose than /titles.
| (none)
|-
| /samurai/ws/'''region'''/demo/'''content id'''
| Returns information about a demo. Content ID is available in the main game's /title entry.
| (none)
|-
| /samurai/ws/'''region'''/contents
| Seems identical to /titles.
| see /titles
|-
| /samurai/ws/'''region'''/genres
| Returns a list of human-readable genre names and their corresponding genre id.
| (none)
|-
| /samurai/ws/'''region'''/publishers
| Returns a list of human-readable publisher names and their corresponding publisher id.
| (none)
|-
| /samurai/ws/'''region'''/platforms
| Returns a list of human-readable platform names and their corresponding platform id.
| (none)
|-
| /samurai/ws/'''region'''/title/'''content id'''/aocs
| Returns a list of add-on contents/downloadable content and prices in eShop region currency.
| (none)
|}

=== ninja ===

ninja.ctr.shop.nintendo.net (ninja) contains the seeds for the new 9.6 crypto, pricing information and handles actions that require authentication, such as purchases. Authentication information seems to be obtained from the [[ACT_Services|act:u sysmodule]] and works through OAuth2.

{| class="wikitable" border="1"
|-
! Path
! Description
! Parameters
|-
| /ninja/ws/'''region'''/title/'''content id'''/ec_info
| Contains information about the title. Such as title id, content size, and if available, the 9.6 crypto seed
| (none)
|-
| /ninja/ws/titles/id_pair
| Provides the content id for the given title id, or vice versa.
| title_id[] or ns_uid[] is required.
|-
| /ninja/ws/'''region'''/tax_locations
| Provides the tax location ID
| postal_code is required.
|-
| /ninja/ws/service_hosts
| Provides CCIF and Samurai servers
| country and shop_id is required.
|-
| /ninja/ws/country/'''region'''
| Various eshop related information for a given region
| (none)
|-
| /ninja/ws/country/'''region'''/replenish_amounts
| Provides the amounts of money you can replenish to your account.
| (none)
|}

=== Trusted Root CAs ===
The eShop application itself uses a [[HTTP_Services|RootCertChain]] for all HTTPS requests, all of the trusted root CAs are the following [[SSLC:RootCertChainAddDefaultCert|default]] ones:
* CertID 0x3
* CertID 0x6
* CertID 0x7
* CertID 0x8
* CertID 0x9
* CertID 0xA

=== Server changes following the November 2, 2015, maintenance ===
Pre-v10.0 eShop used an URL like this: "%s/samurai/ws/%s/title/%llu/other_purchased?shop_id=1&lang=%s&_type=json". That URL was removed with v10.0. That URL was requested when trying to load eShop app-pages. Following the maintenance mentioned above, this page was removed from the server, which broke pre-v10.0 eShop app whenever it tried to access that page.

URL changes between [[9.7.0-25]] and [[10.0.0-27]] are (green = add, red = remove):

%s/ninja/ws/%s/titles/online_prices?title%%5B%%5D=%s&lang=%s&include_coupon=true&shop_id=1&_type=json

%s/ninja/ws/%s/coupon/!check?shop_id=1&_type=json

%s/ninja/ws/my/owned_coupons?ns_uid=%llu&shop_id=1&_type=json

%s/ninja/ws/my/owned_coupons?shop_id=1&_type=json

%s/ninja/ws/my/parental_control/!put?shop_id=1&_type=json

%s/ninja/ws/%s/title/%llu/prepurchase_info?%s=%s&shop_id=1&_type=json

%s/samurai/ws/%s/coupon/%llu/titles?lang=%s&limit=%u&offset=%u&shop_id=1&_type=json

%s/ninja/ws/my/auto_billing/plans?limit=%u&offset=%u&shop_id=1&_type=json

%s/ninja/ws/%s/titles/online_prices?title%%5B%%5D=%s&lang=%s&include_coupon=true&coupon_id=%llu&shop_id=1&_type=json

%s/ninja/ws/my/auto_billing/%014llu/!cancel?shop_id=1&_type=json

%s/samurai/ws/%s/title/%llu/other_purchased?shop_id=1&lang=%s&_type=json

%s/samurai/movie/%s/%s/%014llu/moflex

==New3DS==
CheckNew3DS is called in two functions. This is only used for disabling UI button(s) for downloading New3DS titles when running on Old3DS. For example, on a New3DS patching a CheckNew3DS func-call with <retval=0>, results in the download button on the app page being grayed-out for a New3DS-only title.

==TitleID checks==
There's titleID checks in the system eShop application code for "Pokémon Omega Ruby". This appears to be used with UI-related code, unknown why.

News

2016-02-02T14:38:55Z

Vague Rant: Current firmware checked before letting users online.

<noinclude>
==Adding an item==
* Log in to the wiki. Editing is disabled if you don't have an account.
* Add the news event to the top of the list, using this format for the date: <tt><nowiki>'''</nowiki>{{#time: d F y}}<nowiki>''' </nowiki></tt>. Please include the application's creator, version number, and a link to a page on 3DBrew about the application. No external links please.
* '''Move the last entry to the [[:News/Archive|news archive]]. There should be no more than 4 entrees in the list.'''

==Archives==
For older news, see the [[:News/Archive|news archive]].

=== News ===
</noinclude>
*'''2 February 16''' As of this date (time zones notwithstanding) Nintendo now checks that users are on current firmware before allowing access to online functionality in games.
*'''25 January 16''' Nintendo released system update [[10.5.0-30]].
*'''25 January 16''' [[User:Yellows8|Yellows8]] updated [http://yls8.mtheall.com/3dsbrowserhax.php browserhax], [https://github.com/yellows8/3ds_homemenuhax/releases menuhax], and the oot3dhax [https://github.com/yellows8/oot3dhax/releases saveimages] for v10.4.
*'''18 January 16''' Nintendo released system update [[10.4.0-29]].

News/Archive

2016-02-02T14:38:09Z

Vague Rant: Adding to archive.

*'''7 January 16''' (roughly, not automatically detected) Ironfall v1.0 is no longer downloadable due to the main-CXI content files on CDN being removed (TMD wasn't removed).
*'''27 December 15''' A 3DS console hacking [https://events.ccc.de/congress/2015/Fahrplan/events/7240.html talk] was at 32C3. A recording can be found [https://www.youtube.com/watch?v=UutYOidFx3c here]. Around the end of the talk, [[User:Yellows8|Yellows8]] released [[browserhax]] and [[menuhax]] compatible with the latest system-version at the time of release ([[10.3.0-28]]). The homebrew [https://smealum.github.io/3ds/ starter-kit] was updated for latest menuhax, and for an option for downloading the old vulnerable version of Ironfall from eShop.
*'''15 December 15''' Nintendo released Smash Bros update v1.1.3 which fixed [[smashbroshax]], see [https://github.com/yellows8/3ds_smashbroshax here] for details. However, [[smashbroshax]] is still possible on latest firmware: simply remove the update from SD card before attempting the exploit.
*'''13 December 15''' WinterMute released [http://devkitpro.org/viewtopic.php?f=13&t=8542 devkitARM release 45].
*'''25 November 15''' [[User:Yellows8|Yellows8]] released [https://github.com/yellows8/hblauncher_loader/releases hblauncher_loader].
*'''17-20 November 15''' Nintendo released an update for the normal (non-invite-code) Super Smash Bros demos in USA, EUR and JPN, fixing [[smashbroshax]]. Only the demos were updated, the cartridge and eShop version of the full game are still vulnerable.
*'''12 November 15''' [[User:Yellows8|Yellows8]] released [https://github.com/yellows8/oot3dhax/releases oot3dhax] raw savedata images for gamecards with the latest *hax payloads. The official [https://github.com/smealum/sploit_installer installer] is now [https://smealum.github.io/3ds/ included] in the homebrew starter kit.
*'''9 November 15''' Nintendo released system update [[10.3.0-28]].
*'''2 November 15''' Following an eShop servers maintenance, changes to the [[eShop]] system application require an update of the Homebrew starter kit for eShop access on system versions older than [[10.0.0-27]]. See [[EShop|here]] for details.
*'''30 October 15''' [[User:Yellows8|Yellows8]] released [https://github.com/yellows8/3ds_homemenuhax/releases menuhax] v2.0.
*'''29 October 15''' [[User:Yellows8|Yellows8]] released [https://github.com/yellows8/3ds_smashbroshax/releases 3ds_smashbroshax] v1.2.
*'''26 October 15''' A [[Internet_Browser#v9.9_dummy_web-browser|dummy web browser]] is now being included in CUPs (cart updates) on Old3DS/New3DS likely starting with games shipping [[9.9.0-26|9.9.0-X]]. NVer is not updated by this.
*'''26 October 15''' The system web-browser on Old3DS/New3DS now displays a "sysupdate required" message on systems with [[9.9.0-26]] or above installed, if the installed browser(?) is not the latest version. See [[Internet_Browser#Forced_system-update|here]] for details.
*'''25 October 15''' [[User:Smea|smea]] released *hax 2.5 payloads, which fixes a number of bugs and adds new features such as screenshot-taking, romhacking and eshop access.
*'''20 October 15''' Nintendo released system update [[10.2.0-28]]. The publicly available versions of [[menuhax]] and [[browserhax]] at the time of sysupdate release, were blocked.
*'''15 October 15''' The [[YouTube]] application was updated with a fix for [[tubehax]]. This update is forced: the app itself checks whether a newer version of the title is available.
*'''13 October 15''' "Ironfall: Invasion" was made available on the eShop again (originally pulled on August 11th). The updated version blocks [[ironhax]].
*'''25 September 15''' [[User:Yellows8|Yellows8]] released [[browserhax]] and [[menuhax]]. On the 26th menuhax v1.2 was [https://github.com/yellows8/3ds_homemenuhax/releases released].
*'''14 September 15''' Nintendo released system update [[10.1.0-27]].
*'''11 September 15'''(11:30 EDT) [[User:Yellows8|Yellows8]] released [[smashbroshax]]. On the 30th v1.1 was [https://github.com/yellows8/3ds_smashbroshax/releases released] for supporting Super Smash Bros v1.1.1.
*'''8 September 15''' Nintendo released system update [[10.0.0-27]].
*'''18 July 15''' smea released [[ninjhax]] 2 beta [http://smealum.github.io/ninjhax2/], enabling ARM11 homebrew execution on Old/New 3DS up to firmware 9.9.0-26.
*'''13 July 15''' Nintendo released system update [[9.9.0-26]].
*'''1 June 15''' Nintendo released system update [[9.8.0-25]].
*'''03 May 15''' smea released regionFOUR [https://github.com/smealum/regionFOUR/blob/master/README.md], enabling region free gaming on latest firmware. (again)
*'''20 April 15''' Nintendo released system update [[9.7.0-25]].
*'''23 March 15''' Nintendo released system update [[9.6.0-24]].
*'''2 March 15''' Nintendo released system update [[9.5.0-23]].
*'''15 February 15''' WinterMute released [http://devkitpro.org/viewtopic.php?f=13&t=8409 devkitARM release 44].
*'''2 February 15''' Nintendo released system update [[9.5.0-22]], which fixes [[3DS System Flaws|firmlaunch-hax]].
*'''16 January 15''' smea released regionthree [https://github.com/smealum/regionthree/blob/master/README.md], enabling region free gaming on latest firmware.
*'''24 December 14''' smea released [[Ninjhax]] 1.1 ('''NOT''' a fix for firmware [[9.3.0-21]] or [[9.4.0-21]]).
*'''11 December 14''' Nintendo released system update [[9.4.0-21]].
*'''8 December 14''' Nintendo released system update [[9.3.0-21]], which fixes [[3DS System Flaws|rohax]].
*'''20 November 14''' smea released [[Ninjhax]], the first public [[Homebrew Exploits|homebrew exploit]] compatible with system-versions [[4.0.0-7]]-[[9.2.0-20]].
*'''29 October 14''' Nintendo released system update [[9.2.0-20]].
*'''10 October 14''' Nintendo released system update [[9.1.0-20J]].
*'''6 October 14''' Nintendo released system update [[9.0.0-20]].
*'''29 August 14''' Nintendo announced [[New 3DS]].
*'''7 August 14''' Nintendo released system update [[8.1.0-19]].
*'''24 July 14''' Nintendo released system update [[8.1.0-18]].
*'''7 July 14''' Nintendo released system update [[8.0.0-18]].
*'''12 May 14''' Nintendo released system update [[7.2.0-17]].
*'''26 February 14''' Nintendo released system update [[7.1.0-16]].
*'''22 January 14''' Nintendo released system update [[7.1.0-15]].
*'''19 December 13''' Nintendo released system update [[7.1.0-14]].
*'''9 December 13''' Nintendo released system update [[7.0.0-13]].
*'''13 September 13''' Nintendo released system update [[6.3.0-12]].
*'''20 August 13''' [[3DSExplorer|3DSExplorer v1.5.3]] updated by [[User:Elisherer|Elisherer]] (Enable trimming NCSD)
*'''6 August 13''' Nintendo released system update [[6.2.0-12]].
*'''11 July 13''' Nintendo released system update [[6.1.0-12U]] for only USA.
*'''27 June 13''' Nintendo released system update [[6.1.0-11]] (6.1.0-12 for all regions except USA).
*'''17 June 13''' Nintendo released system update [[6.0.0-11]] (6.0.0-12 for all regions except USA).
*'''4 April 13''' Nintendo released system update [[5.1.0-11]].
*'''25 March 13''' Nintendo released system update [[5.0.0-11]].
*'''14 January 13''' [[3DSExplorer|3DSExplorer v1.5.1]] updated by [[User:Elisherer|Elisherer]]
*'''4 December 12''' Nintendo released system update [[4.5.0-10]].
*'''1 December 12''' [[3DSExplorer|3DSExplorer v1.4]] updated by [[User:Elisherer|Elisherer]]
*'''2 November 12''' Added page for [[Fundraiser|Chip decapping fundraiser]]
*'''8 January 13''' [[3DSExplorer|3DSExplorer v1.5]] updated by [[User:Elisherer|Elisherer]]
*'''23 September 12''' [[005tools|005tools v0.1b]] by [[User:McHaggis|McHaggis]]
*'''19 September 12''' Nintendo released system update [[4.4.0-10]].
*'''17 August 12''' Nintendo released New Super Mario Bros. 2, the first 3DS title released simultaneously in stores and as an [[eShop]] download.
*'''28 July 12''' [[3DSExplorer|3DSExplorer v1.3]] (modified by 3DSGuy) updated by [[User:Elisherer|Elisherer]]
*'''24 July 12''' Nintendo released system update [[4.3.0-10]].
*'''26 June 12''' Nintendo released system update [[4.2.0-9]].
*'''19 May 12''' [[3DSExplorer|3DSExplorer v1.2.1]] updated by [[User:Elisherer|Elisherer]]
*'''15 May 12''' Nintendo released its first implementation of 3DS '[[Title list#0004000E - Add-on Content|Add-on Content]]' with the Mario Kart 1.1 update.
*'''14 May 12''' Nintendo released system update [[4.1.0-8]].
*'''24 April 12''' Nintendo released system update [[4.0.0-7]].
*'''08 February 12''' [[CiTRUS|CiTRUS v0.2]] updated by [[User:Xcution|Xcution]]
*'''04 February 12''' [[CiTRUS|CiTRUS v0.1]] released by [[User:Xcution|Xcution]]
*'''02 February 12''' [[3DSExplorer|3DSExplorer v1.2]] updated by [[User:Elisherer|elisherer]]
*'''26 January 12''' [[Crappy Tiny Reader|CTR - Crappy Tiny Reader v0.07]] updated by [[User:PsyKopaT|PsyKo]]
*'''05 January 12''' [[Crappy Tiny Reader|CTR - Crappy Tiny Reader v0.06]] updated by [[User:PsyKopaT|PsyKo]]
*'''21 December 11''' Nintendo released system update [[3.0.0-6]]
*'''21 December 11''' [[3DSExplorer|3DSExplorer v1.1.1]] updated by [[User:Elisherer|elisherer]]
*'''7 December 11''' [[3DSExplorer|3DSExplorer v0.96]] updated by [[User:Elisherer|elisherer]]
*'''4 September 11''' [[3DSViewer|3DSViewer v0.1]] released by [[User:Elisherer|elisherer]]
*'''1 August 11''' [[3DS Save DeEncrypter3DS|Save DeEncrypter v1.0]] released by [[User:Blite|Blite]]
*'''25 July 11''' Nintendo released system update [[2.1.0-4]].
*'''15 June 11''' Nintendo released system update [[2.1.0-3]].
*'''6 June 11''' Nintendo released system update [[2.0.0-2]].
*'''6 April 11''' [[DSaveManager|DSaveManager v0.1]] released by [[User:Crediar|crediar]]
*'''4 April 11''' [[3DSaveTool|3DSaveTool v0.2b]] released by [[User:Crediar|crediar]]
*'''2 April 11''' [[3DSaveTool|3DSaveTool v0.1]] released by [[User:Crediar|crediar]]
*'''28 March 11''' Fixed 3DBrew wiki issues, now fully operational!
*'''18 March 11''' 3DBrew launched.

== 3DBrew International ==
Our community is an international community.

We have freedom, and we will express it in our language (but you have to write it in English before ;)!

Homebrew Exploits

2015-12-24T04:19:08Z

Vague Rant: Web colors black on red/green aren't really conducive to reading.

==Standalone Homebrew Launcher Exploits==
The following homebrew exploits can be executed on a previously un-exploited system.

{| class="wikitable" border="1"
|-
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[ninjhax|Ninjhax 1.1b]]
| From '''4.0.0-7''' up to and including '''9.2.0-20'''.
| A cartridge or eShop version (JPN-only) of "Cubic Ninja".
| smea
| [http://smealum.net/ninjhax/ Install]
|-
| style="background: lightgreen" | Yes
| [[ninjhax|Ninjhax 2.5]]
| From '''9.0.0-7''' up to and including '''10.3.0-28'''.
| A cartridge or eShop version (JPN-only) of "Cubic Ninja".
| smea
| [https://smealum.github.io/ninjhax2/ Install]
|-
| style="background: lightgreen" | Yes
| [[smashbroshax|smashbroshax]] (beaconhax)
| (New 3DS only) From '''9.0.0-X''' up to and including '''10.3.0-28'''.
| Super Smash Bros 3DS (full-game) and a way to broadcast raw wifi beacons. The demo(prior to the updated November 2015 [https://github.com/yellows8/3ds_smashbroshax version]) isn't usable with the release-archives since the demo doesn't have SD access(you must build it yourself with the PAYLOADURL option).
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/3ds_smashbroshax Install]
|-
| style="background: salmon" | No
| [[browserhax]]
| (Old 3DS) From '''9.0.0-16''' to '''9.5.0-22''', '''9.5.0-23''' to '''9.8.0-25''', '''9.9.0-26''' to '''10.1.0-27'''

(New 3DS) From '''9.0.0-20''' to '''9.2.0-20''', '''9.3.0-21''' to '''9.5.0-23''', '''9.6.0-24''' to '''9.8.0-25''', '''9.9.0-26''' to '''10.1.0-27'''

| An USA, EUR, or JPN system.
| [[User:Yellows8|Yellows8]]
| [http://yls8.mtheall.com/3dsbrowserhax.php Install]
|}

Note that ninjhax 1.x is still not obsolete. Even though ninjhax 2.x can be run on 9.3+, this was made possible (amongst other things) by sacrificing the memory remapping exploit used in ninjhax 1.x (rohax). Therefore, things like JIT engines for emulators can only be supported on ninjhax 1.x. Furthermore, ninjhax 2.x does not run on system versions below 9.0.0-X, while ninjhax 1.x does.

==Secondary Exploits==
Installation of these exploits requires a previously exploited system to install. After installation, they can be used on their own.

{| class="wikitable" border="1"
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: lightgreen" | Yes
| [[ironhax]]
| From '''9.5.0-X''' up to and including '''10.3.0-X''', for '''X''' up to and including 28.
| A copy of "Ironfall: Invasion" downloaded from eShop before August 11th, 2015. Note the updated version that was released on October 13th, 2015 is not supported.
| smea
| [http://smealum.github.io/3ds/ Install]
|-
| style="background: lightgreen" | Yes
| [https://github.com/yellows8/oot3dhax oot3dhax]
| From '''9.5.0-X''' up to and including '''10.3.0-X''', for '''X''' up to and including 28.
| A gamecard or eShop-install of Legend of Zelda: Ocarina of Time 3D. Besides using the installer app, writing raw saveimages with a save dongle for example is another option. Due to lack of free space with the size of the *hax payload, the only save-slot that can exist in the *gamecard* savedata is the oot3dhax save-slot.
| Yellows8 / smea et all.
| See [https://smealum.github.io/3ds/ here].
|-
| style="background: salmon" | No
| [[menuhax]]
| From '''9.0.0-X''' up to and including '''10.1.0-X''', for '''X''' up to and including 27.
|
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/3ds_homemenuhax/releases Download]
|}

==Exploits without Homebrew Launcher (Not recommended)==

'''Warning:''' The following exploits can run code, but are missing a 3DSX launcher. They cannot launch any homebrew in the 3DSX format.

{| class="wikitable" border="1"
|-
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[browserhax]] (Without the loader in the 3ds_browserhax_common repo)
| (Old3DS) From '''2.1.0-4''' to '''3.0.0-6''', '''4.0.0-7''' to '''4.5.0-10''', '''5.0.0-11''' to '''7.0.0-13''', '''7.1.0-16''' to '''9.5.0-22''', '''9.5.0-23''' to '''9.8.0-25''', '''9.9.0-26''' to '''10.1.0-27'''

(New3DS) From '''9.0.0-20''' to '''9.2.0-20''', '''9.3.0-21''' to '''9.5.0-23''', '''9.6.0-24''' to '''9.8.0-25''', '''9.9.0-26''' to '''10.1.0-27'''

See above section regarding [[10.2.0-28|10.2.0-X]].
| An USA, EUR, or JPN system.
| [[User:Yellows8|Yellows8]]
| [[browserhax|Install]]
|}

==Previous Exploits==
'''Warning:''' These exploits '''do not work'''. They are exploits which no longer function at all, regardless of software or firmware revision.
{| class="wikitable" border="1"
! Works on latest fw
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| style="background: salmon" | No
| [[tubehax|Tubehax]]
| None. '''Was''': From '''9.0.0-X''' up to and including '''10.1.0-X''', for '''X''' up to and including 27.
| The YouTube application and an Internet connection. As of October 15, 2015, this is no longer usable due to an update being released which fixes the vuln used by tubehax + app update being forced(see [[YouTube|here]]).
| smea
| [http://smealum.github.io/3ds/ Install]
|}

Internet Browser

2015-11-18T12:19:20Z

Vague Rant: /* 0x000200BB savedata */ Typo.

The 3DS Internet Browser was added in the June 2011 Update for JPN/EUR/USA.

From the Internet Browser help section:
In compliance with the LGPL, the source code of the OSS is available via the Nintendo website.
This source code can be downloaded here:
[http://mediacontent.nintendo-europe.com/NOE/images/service/OpenSources.zip] [http://www.nintendo.co.jp/support/oss/index.html]

The 3DS Internet Browser is [http://en.wikipedia.org/wiki/Netfront Netfront] Browser NX v1.0 based on [http://en.wikipedia.org/wiki/WebKit WebKit] engine.

The browser supports up to 64 bookmarks.

The exheader name of this title is "spider".

The only difference between the ExeFS .code for each region of the Old3DS/New3DS browser, is byte values for the title uniqueID/region, otherwise the binaries are identical.

A [[#v9.9_dummy_web-browser|"dummy" browser]] (which replaces the actual browser) is now being included beginning with games shipping the [[9.9.0-26|9.9.0-X]] system update. In addition, versions of the real browser since 9.9.0-26X now attempt to [[#Forced_system-update|check-in with a Nintendo server]] to determine if the existing browser version is out of date.

==[[New 3DS]] Internet Browser==
New3DS has a separate browser title, the exheader name is "SKATER".

Unlike the Old3DS browser, this New3DS browser has videos+HTML5 support. This browser also has a filter enabled by default(ExeFS codebin is same for all regions, this filter only applies for JPN region). Disabling it requires paying money with a credit-card, for [[NIM_Services|purchasing]] web-browser [[Title_list/DLC|DLC]].

During startup the browser does various HTTPS comms. When visting an URL, the browser sends a plaintext HTTP POST to here: [http://ars.ifuser.jp:20080/ars2/rating]. The raw POST data begins with "ARS/2.0\r\n\x00", the rest appears to be encrypted. The server reply content also has this ARS header + encrypted data. This appears to use a fixed xorpad, likely from a fixed encryption CTR/IV. The server content responses for allowed sites, and blocked sites, are fixed. When the server returns that the site is blocked, the browser goes to this page: [http://ars.ifuser.jp/filter/44.html](the Referrer header value is set to the same URL it's actually requesting).

The WebKit source was updated since the Old3DS browser.

Unlike the Old3DS browser, the New3DS browser uses the following services: [[MVD_Services|mvd:STD]] and [[IR_Services|ir:rst]](DLC-related services are used too but those aren't New3DS specific).

Video decoding is done with [[MVD_Services|mvd:STD]]. Audio decoding/playback is done with a browser-specific DSP binary. The Old3DS browser used CSND for audio playback, the New3DS browser doesn't have access to that at all since it uses DSP instead.

The browser manual includes licenses for Android and PacketVideo. The browser uses libstagefright from Android.

===User-Agent and Browser Versions===
Normal user-agent format: <code style="font-size:larger;">Mozilla/5.0 (New Nintendo 3DS like iPhone) AppleWebKit/<WebKit version> (KHTML, like Gecko) NX/<Netfront version> Mobile NintendoBrowser/<Mobile NintendoBrowser version>.<region></code>

<region> can be one of the following: "JP", "US", or "EU".

{| class="wikitable" border="1"
|-
! Mobile NintendoBrowser version(displayed in browser settings)
! Normal UA
! Mobile UA
! CDN Title-version
! Network-only system-update version
! Notes
|-
| 1.0.9934
| Mozilla/5.0 (New Nintendo 3DS like iPhone) AppleWebKit/536.30 (KHTML, like Gecko) NX/3.0.0.5.8 Mobile NintendoBrowser/1.0.9934.<region>
| Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A403 Safari/8536.25
| v10
| [[9.0.0-20]]
| Initial version.
|-
| 1.1.9996
| Mozilla/5.0 (New Nintendo 3DS like iPhone) AppleWebKit/536.30 (KHTML, like Gecko) NX/3.0.0.5.10 Mobile NintendoBrowser/1.1.9996.<region>
| Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A403 Safari/8536.25
| v1027
| [[9.3.0-21]]
| See below regarding OSS changes.
|-
| 1.2.10085
| Mozilla/5.0 (New Nintendo 3DS like iPhone) AppleWebKit/536.30 (KHTML, like Gecko) NX/3.0.0.5.13 Mobile NintendoBrowser/1.2.10085.<region>
| Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A403 Safari/8536.25
| v2051
| [[9.6.0-24]]
| See below.
|-
| None
| None
| None
| v3075
| v9.9 CUP
| v9.9 CUP dummy web-browser, see below.
|-
| 1.3.10126
| Mozilla/5.0 (New Nintendo 3DS like iPhone) AppleWebKit/536.30 (KHTML, like Gecko) NX/3.0.0.5.15 Mobile NintendoBrowser/1.3.10126.US
| Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A403 Safari/8536.25
| v3077
| [[9.9.0-26]]
| See below.
|-
| 1.4.10138
| Mozilla/5.0 (New Nintendo 3DS like iPhone) AppleWebKit/536.30 (KHTML, like Gecko) NX/3.0.0.5.17 Mobile NintendoBrowser/1.4.10138.US
| Mozilla/5.0 (iPhone; CPU iPhone OS 6_0 like Mac OS X) AppleWebKit/536.26 (KHTML, like Gecko) Version/6.0 Mobile/10A403 Safari/8536.25
| v4096
| [[10.2.0-28]]
| See below.
|}

Note that the latest Old3DS browser WebKit version at the time the initial New3DS browser was released, was the following: 532.8.

==== OSS 9.0 and 9.3 diff ====
The following is a diff of the OSS archives from [http://www.nintendo.co.jp/support/oss/index.html here], for v9.0 and v9.3.

Files NewNintendo3DS_OpenSources9.0.0-/WKC/WebCore/platform/network/WKC/ResourceHandleManagerWKC.cpp and NewNintendo3DS_OpenSources9.3.0-/WKC/WebCore/platform/network/WKC/ResourceHandleManagerWKC.cpp differ
Files NewNintendo3DS_OpenSources9.0.0-/WKC/WebKit/WKC/webkit/WKCVersion.h and NewNintendo3DS_OpenSources9.3.0-/WKC/WebKit/WKC/webkit/WKCVersion.h differ

WKC_CUSTOMER_RELEASE_VERSION was changed from "0.5.8" to "0.5.10".

The following code was added to ResourceHandleManager::doRedirect(): curl_easy_setopt(d->m_handle, CURLOPT_SHARE, 0);

==== v9.6 ====
WebKit/OSS code was actually updated.
ExeFS .code was updated. The following files in RomFS were updated:
* "/banner/CN/Skater.icn" and "/banner/KR/Skater.icn".
* "/browser/rootca.pem"
* "/build/buildinfo.dat"
* "/cairo.cro.lex" and "/.crr/static.crr"
* "/lyt/Button/ButtonSelectHSearch.arc"
* "/lyt/Kbd/Swkbd.arc"
* "lyt/Kbd.arc"
* "skater.msbt" under all of the "/message/<region>_<language>/" directories.
* "/oss.cro.lex", "/peer.cro.lex", "/static.crs", and "/webkit.cro.lex".

The following was added to RomFS:
* "/favicon/naver.dat"
* A "KO" directory under "/iwnn".

==== v9.9 ====
ExeFS:/.code was updated.

The only RomFS changes is file-updating, all of the following files were updated:
/browser/rootca.pem
/build/buildinfo.dat
/cairo.cro.lex
/.crr/static.crr
/message/CN_Simp_Chinese/skater.msbt
/message/EU_Dutch/skater.msbt
/message/EU_English/skater.msbt
/message/EU_French/skater.msbt
/message/EU_German/skater.msbt
/message/EU_Italian/skater.msbt
/message/EU_Portuguese/skater.msbt
/message/EU_Russian/skater.msbt
/message/EU_Spanish/skater.msbt
/message/JP_Japanese/skater.msbt
/message/KR_Hangeul/skater.msbt
/message/TW_English/skater.msbt
/message/TW_Trad_Chinese/skater.msbt
/message/US_English/skater.msbt
/message/US_French/skater.msbt
/message/US_Portuguese/skater.msbt
/message/US_Spanish/skater.msbt
/oss.cro.lex
/peer.cro.lex
/static.crs
/webkit.cro.lex

See [https://gist.github.com/yellows8/9fb509fde4112339f342 here] for a diff of the OSS(WebKitLibraries/ is not included due to the massive cairo library diff). An exploitable security vuln(which was already known in the context of 3DS webkit) was fixed. [[User:Yellows8|Yellows8]]' private(at the time of writing) exploit for it is based on the PoC from [http://pastebin.com/ufBCQKda here](see the pastebin for the actual pastebin author).

==== v10.2 ====
The libstagefright build in the main SKATER codebin was updated to a version which fixed libstagefright vuln(s): the vuln used in [[browserhax|browserhax_fright]] at the time of sysupdate release was fixed. The *only* code changed in the main codebin, was code related to libstagefright.

The only RomFS changes is file-updating, all of the following files were updated:
/browser/rootca.pem differ
/build/buildinfo.dat differ
/.crr/static.crr differ
/message/CN_Simp_Chinese/skater.msbt differ
/message/EU_Dutch/skater.msbt differ
/message/EU_English/skater.msbt differ
/message/EU_French/skater.msbt differ
/message/EU_German/skater.msbt differ
/message/EU_Italian/skater.msbt differ
/message/EU_Portuguese/skater.msbt differ
/message/EU_Russian/skater.msbt differ
/message/EU_Spanish/skater.msbt differ
/message/JP_Japanese/skater.msbt differ
/message/KR_Hangeul/skater.msbt differ
/message/TW_English/skater.msbt differ
/message/TW_Trad_Chinese/skater.msbt differ
/message/US_English/skater.msbt differ
/message/US_French/skater.msbt differ
/message/US_Portuguese/skater.msbt differ
/message/US_Spanish/skater.msbt differ
/oss.cro.lex differ
/static.crs differ
/webkit.cro.lex differ

OSS diff:
diff --git a/NewNintendo3DS_OpenSources9.9.0-/WKC/WebKit/WKC/webkit/WKCVersion.h b/NewNintendo3DS_OpenSources10.2.0-/WKC/WebKit/WKC/webkit/WKCVersion.h
index 4543297..0860336 100644
--- a/NewNintendo3DS_OpenSources9.9.0-/WKC/WebKit/WKC/webkit/WKCVersion.h
+++ b/NewNintendo3DS_OpenSources10.2.0-/WKC/WebKit/WKC/webkit/WKCVersion.h
@@ -29,7 +29,7 @@
#define WKC_VERSION_CHECK(major, minor, micro) \
(((major)*10000) + ((minor)*100) + (micro)) >= ((WKC_VERSION_MAJOR*10000) + (WKC_VERSION_MINOR*100) + (WKC_VERSION_MICRO))

-#define WKC_CUSTOMER_RELEASE_VERSION "0.5.15"
+#define WKC_CUSTOMER_RELEASE_VERSION "0.5.17"

#define WKC_WEBKIT_VERSION "536.30"

diff --git a/NewNintendo3DS_OpenSources9.9.0-/webkit/WebCore/ChangeLog b/NewNintendo3DS_OpenSources10.2.0-/webkit/WebCore/ChangeLog
index a5abb35..cf5a9fa 100644
--- a/NewNintendo3DS_OpenSources9.9.0-/webkit/WebCore/ChangeLog
+++ b/NewNintendo3DS_OpenSources10.2.0-/webkit/WebCore/ChangeLog
@@ -1,3 +1,12 @@
+2013-11-05 Ryosuke Niwa <rniwa@webkit.org>
+
+ Use-after-free in SliderThumbElement::dragFrom
+ https://bugs.webkit.org/show_bug.cgi?id=123873
+
+ Reviewed by Andreas Kling.
+
+ Merge https://chromium.googlesource.com/chromium/blink/+/04a23bfca2d04101a1828d36ff36c29f3a24f34b
+
2015-02-06 Maciej Stachowiak <mjs@apple.com>

REGRESSION(r179706): Caused memory corruption on some tests (Requested by _ap_ on #webkit).
@@ -879,7 +888,7 @@
* rendering/RenderLineBoxList.cpp:
(WebCore::RenderLineBoxList::dirtyLinesFromChangedChild):

-2014-01-21 LÃ¡szlÃ³ LangÃ³ <llango.u-szeged@partner.samsung.com>
+2014-01-21 Laszlo Lango <llango.u-szeged@partner.samsung.com>

Assertion failure in Range::nodeWillBeRemoved
https://bugs.webkit.org/show_bug.cgi?id=121694
@@ -1879,7 +1888,7 @@

2012-09-14 Simon Fraser <simon.fraser@apple.com>

- REGRESSION: transition doesnât always override transition-property
+ REGRESSION: transition doesnft always override transition-property
https://bugs.webkit.org/show_bug.cgi?id=96658

Reviewed by Dean Jackson.
@@ -3691,8 +3700,8 @@
glyph with font data for the primary font, presumably to meet the SVG
spec requirement: "If the references to alternate glyphs do not result
in successful identification of alternate glyphs to use, then the
- character(s) that are inside of the çª¶åltGlyphçª¶?element are rendered as
- if the çª¶åltGlyphçª¶?element were a çª¶?spançª¶?element instead."
+ character(s) that are inside of the âaltGlyphâ?element are rendered as
+ if the âaltGlyphâ?element were a â?spanâ?element instead."

If the alt glyph is not then found we are in the case from the spec
and indeed we should use the primary font. However, we end up replacing the GlyphPage
diff --git a/NewNintendo3DS_OpenSources9.9.0-/webkit/WebCore/html/RangeInputType.cpp b/NewNintendo3DS_OpenSources10.2.0-/webkit/WebCore/html/RangeInputType.cpp
index 484adec..d7e9e8d 100644
--- a/NewNintendo3DS_OpenSources9.9.0-/webkit/WebCore/html/RangeInputType.cpp
+++ b/NewNintendo3DS_OpenSources10.2.0-/webkit/WebCore/html/RangeInputType.cpp
@@ -164,7 +164,7 @@ void RangeInputType::handleMouseDownEvent(MouseEvent* event)
ASSERT(element()->hasShadowRoot());
if (targetNode != element() && !targetNode->isDescendantOf(element()->shadowTree()->oldestShadowRoot()))
return;
- SliderThumbElement* thumb = sliderThumbElementOf(element());
+ RefPtr<SliderThumbElement> thumb = sliderThumbElementOf(element());
if (targetNode == thumb)
return;
thumb->dragFrom(event->absoluteLocation());

=== New3DS Browser Specifications ===
[http://www.nintendo.co.jp/3ds/new/features/modal_net.html]

English version(Google translate):
* "Browser engine: NetFront® Browser NX v3.0"
* "User agent: Mozilla/5.0 (New Nintendo 3DS like iPhone) AppleWebKit/536.30 (KHTML, like Gecko) NX/3.0.*.*.* Mobile NintendoBrowser/1.0.****.JP
** The *** is described version information.
** When you use the "mobile version of the request" function, which is different from those described above string."
* "Supported protocols: HTTP1.0/HTTP1.1/SSL3.0/TLS1.0/TLS1.1/TLS1.2"
* "Web standard: HTML4.01 / HTML5 / XHTML1.1 / Fullscreen / Gamepad / SVG / WebSocket / Video Subtitle / WOFF / Web Messaging / Server-Sent / Web Storage of part / XMLHttpRequest / canvas / Video / DOM1-3 / ECMAScript / CSS1 / CSS2.1 / CSS3 part of"
* "Image format: bmp / gif / ico / jpeg / png / svg (There are, however, it is not possible to display some image.)"
* "Image preview: mpo / jpeg (There are, however, it is not possible to display some image.)"
* "Video format: MP4, M3U8 + TS (HTTPLiveStreaming) (However, there are some you can not play the video.)"
* "Video codec: H.264 - MPEG-4 AVC Video (max 854x480 level 3.2, 3D compatible) (However, there are some you can not play the video.)"
* "Audio codec: AAC - ISO / IEC 14496-3 MPEG-4AAC, MP3 (However, there are some you can not play the video.)"
* "Of 3D video at the time of upload format: .mkv (However, in order to play the video, you must format is converted in the upload to the site. In addition, even if it is converted you might not be able to play.)"
* "It does not correspond to the plug-ins such as plug-in Adobe Flash."
* "Use the Active Rating System of filtering function: Digital Arts, Inc. provides. At the time of access to Web content, and implementing the decision of whether access is permitted based on the category information. Feature that can limit access to Web content that may be inappropriate for viewing by the determination result."
* "I will request the display of the mobile version page of the web page you are viewing request function the mobile version. (However, if the web page does not correspond to the mobile version of the page does not change the display.)"

MJPEG + .avi is also supported.

== Old3DS browser ==

=== User-Agent and Browser Versions ===
User-agent format: <code style="font-size:larger;">Mozilla/5.0 (Nintendo 3DS; U; ; <lang>) Version/<version>.<region></code>.

<lang> is "en", "fr", etc. <region> is "US", "EU", etc. See below for <version>.
{| class="wikitable" border="1"
|-
! Browser version
! CDN Title-version
! Network-only system-update version
! Notes
|-
| 1.7412
| v6
| [[2.0.0-2|2.0.0-2]]
| This was the initial version.
|-
| 1.7455
| v1024
| [[2.1.0-4]]
| ExeFS .code was updated, both of the CROs(webkit/OSS) were updated too.
|-
| 1.7498
| v2050
| [[4.0.0-7]]
| ExeFS .code was updated, both of the CROs(webkit/OSS) were updated too. The manual CFA was updated as well.
|-
| 1.7552
| v3075
| [[5.0.0-11]]
| ExeFS .code and icon were updated, both of the CROs(webkit/OSS) were updated too. The manual CFA was updated as well.
|-
| 1.7552
| v3088
| [[7.0.0-13]]
| The main NCCH wasn't updated at all(same TMD contentID/content-hash as the previous version), only the manual CFA for this title was updated.
|-
| 1.7567
| v4096
| [[7.1.0-16]]
| The CXI .code was updated, some data in the RomFS was updated(none of the CROs such as webkit.cro were updated). The manual CFA was updated too.
|-
| 1.7585
| v5121
| [[9.5.0-23]]
| The CXI .code was updated, and the manual CFA was updated. RomFS changes:
* "/browser/rootca.pem" updated
* "/cro/oss.cro" updated
* "/cro/static.crs" updated
* "/cro/webkit.cro" updated
* "/.crr/static.crr" updated
* "/layout/dialogheader/WirelessSwitchOff.arc" was removed
* "/layout/favorite/favicondata/KOR.arc" updated

A vuln used in a public(at the time of this sysupdate) webkit exploit for spider was fixed, which also fixed the removewinframe exploit from [https://github.com/yellows8/3ds_webkithax here].
|-
| None
| v6147
| v9.9 CUP
| v9.9 CUP dummy web-browser, see below.
|-
| 1.7610
| v6149
| [[9.9.0-26]]
| See below.
|-
| 1.7616
| v7168
| [[10.2.0-28]]
| See below.
|}

=== Old3DS v9.9 ===
ExeFS:/.code was updated.

The only changes in RomFS were file-updating, the following files were updated:
/browser/rootca.pem
/cro/oss.cro
/cro/static.crs
/cro/webkit.cro
/.crr/static.crr
/message/CN_Simp_Chinese/spider.msbt
/message/EU_Dutch/spider.msbt
/message/EU_English/spider.msbt
/message/EU_French/spider.msbt
/message/EU_German/spider.msbt
/message/EU_Italian/spider.msbt
/message/EU_Portuguese/spider.msbt
/message/EU_Russian/spider.msbt
/message/EU_Spanish/spider.msbt
/message/JP_Japanese/spider.msbt
/message/KR_Hangeul/spider.msbt
/message/TW_English/spider.msbt
/message/TW_Trad_Chinese/spider.msbt
/message/US_English/spider.msbt
/message/US_French/spider.msbt
/message/US_Portuguese/spider.msbt
/message/US_Spanish/spider.msbt

OSS diff for v9.5 and v9.9, without the .dox changes:

diff --git a/3DS_InternetBrowser_OpenSources_JP_US_EU_KR_TW_HK_CN_9.5.0(23J_23U_23E_19K_18T_3C)/WKC/WebKit/WKC/webkit/WKCVersion.h b/3DS_InternetBrowser_OpenSources_JP_US_EU_KR_TW_HK_CN_9.9.0/WKC/WebKit/WKC/webkit/WKCVersion.h
index be5ff09..55a7274 100644
--- a/3DS_InternetBrowser_OpenSources_JP_US_EU_KR_TW_HK_CN_9.5.0(23J_23U_23E_19K_18T_3C)/WKC/WebKit/WKC/webkit/WKCVersion.h
+++ b/3DS_InternetBrowser_OpenSources_JP_US_EU_KR_TW_HK_CN_9.9.0/WKC/WebKit/WKC/webkit/WKCVersion.h
@@ -29,7 +29,7 @@
#define WKC_VERSION_CHECK(major, minor, micro) \
(((major)*10000) + ((minor)*100) + (micro)) >= ((WKC_VERSION_MAJOR*10000) + (WKC_VERSION_MINOR*100) + (WKC_VERSION_MICRO))

-#define WKC_CUSTOMER_RELEASE_VERSION "1.8.14"
+#define WKC_CUSTOMER_RELEASE_VERSION "1.8.16"

#define WKC_WEBKIT_VERSION "532.7"

diff --git a/3DS_InternetBrowser_OpenSources_JP_US_EU_KR_TW_HK_CN_9.5.0(23J_23U_23E_19K_18T_3C)/webkit/WebCore/rendering/RenderBox.cpp b/3DS_InternetBrowser_OpenSources_JP_US_EU_KR_TW_HK_CN_9.9.0/webkit/WebCore/rendering/RenderBox.cpp
index da4127e..d03403e 100644
--- a/3DS_InternetBrowser_OpenSources_JP_US_EU_KR_TW_HK_CN_9.5.0(23J_23U_23E_19K_18T_3C)/webkit/WebCore/rendering/RenderBox.cpp
+++ b/3DS_InternetBrowser_OpenSources_JP_US_EU_KR_TW_HK_CN_9.9.0/webkit/WebCore/rendering/RenderBox.cpp
@@ -305,23 +305,23 @@ int RenderBox::scrollHeight() const

int RenderBox::scrollLeft() const
{
- return hasOverflowClip() ? layer()->scrollXOffset() : 0;
+ return layer() && hasOverflowClip() ? layer()->scrollXOffset() : 0;
}

int RenderBox::scrollTop() const
{
- return hasOverflowClip() ? layer()->scrollYOffset() : 0;
+ return layer() && hasOverflowClip() ? layer()->scrollYOffset() : 0;
}

void RenderBox::setScrollLeft(int newLeft)
{
- if (hasOverflowClip())
+ if (hasOverflowClip() && layer())
layer()->scrollToXOffset(newLeft);
}

void RenderBox::setScrollTop(int newTop)
{
- if (hasOverflowClip())
+ if (hasOverflowClip() && layer())
layer()->scrollToYOffset(newTop);
}

=== Old3DS v10.2 ===
The slider vuln from [https://github.com/yellows8/3ds_webkithax here] was fixed in the Old3DS browser it seems.

The main codebin .text only increased by 0x10-bytes.

The only changes in RomFS was that the following files were updated:
/cro/oss.cro
/cro/static.crs
/cro/webkit.cro
/.crr/static.crr

OSS diff:
diff --git a/3DS_InternetBrowser_OpenSources_JP_US_EU_KR_TW_HK_CN_9.9.0/WKC/WebKit/WKC/webkit/WKCVersion.h b/3DS_InternetBrowser_OpenSources_JP_US_EU_KR_TW_HK_CN_10.2.0/WKC/WebKit/WKC/webkit/WKCVersion.h
index 55a7274..fc153c4 100644
--- a/3DS_InternetBrowser_OpenSources_JP_US_EU_KR_TW_HK_CN_9.9.0/WKC/WebKit/WKC/webkit/WKCVersion.h
+++ b/3DS_InternetBrowser_OpenSources_JP_US_EU_KR_TW_HK_CN_10.2.0/WKC/WebKit/WKC/webkit/WKCVersion.h
@@ -29,7 +29,7 @@
#define WKC_VERSION_CHECK(major, minor, micro) \
(((major)*10000) + ((minor)*100) + (micro)) >= ((WKC_VERSION_MAJOR*10000) + (WKC_VERSION_MINOR*100) + (WKC_VERSION_MICRO))

-#define WKC_CUSTOMER_RELEASE_VERSION "1.8.16"
+#define WKC_CUSTOMER_RELEASE_VERSION "1.8.17"

#define WKC_WEBKIT_VERSION "532.7"

diff --git a/3DS_InternetBrowser_OpenSources_JP_US_EU_KR_TW_HK_CN_9.9.0/webkit/WebCore/rendering/RenderSlider.cpp b/3DS_InternetBrowser_OpenSources_JP_US_EU_KR_TW_HK_CN_10.2.0/webkit/WebCore/rendering/RenderSlider.cpp
index b2f5cef..1dd3dbd 100644
--- a/3DS_InternetBrowser_OpenSources_JP_US_EU_KR_TW_HK_CN_9.9.0/webkit/WebCore/rendering/RenderSlider.cpp
+++ b/3DS_InternetBrowser_OpenSources_JP_US_EU_KR_TW_HK_CN_10.2.0/webkit/WebCore/rendering/RenderSlider.cpp
@@ -221,6 +221,7 @@ RenderSlider::~RenderSlider()
{
if (m_thumb)
m_thumb->detach();
+ m_thumb = 0;
}

int RenderSlider::baselinePosition(bool, bool) const
@@ -493,7 +494,8 @@ void RenderSlider::forwardEvent(Event* event)
}
}

- m_thumb->defaultEventHandler(event);
+ if (m_thumb)
+ m_thumb->defaultEventHandler(event);
}

bool RenderSlider::inDragMode() const

== Forced system-update ==
The Old3DS/New3DS Internet Browser updated with [[9.9.0-26]] now includes the following message string:
In order to use the Internet
browser, a system update
is required.
To perform a system update,
select System Update from Other
Settings in System Settings.

This wasn't enforced(web-browser displaying the above message when the installed browser isn't the latest version) until October 26, 2015.

This message only triggers when attempting to load a web-page. This is only handled the first time the browser accesses a web-page, during this browser session.

The browser codebins starting with v9.9 now contain the following URL strings:
* Old3DS: <nowiki>"https://cbvc.cdn.nintendo.net/CTR/1/<region>"</nowiki>
* New3DS: <nowiki>"https://cbvc.cdn.nintendo.net/SNAKE/1/<region>"</nowiki>

The <region> string is one of the following:
* "JPN"
* "USA"
* "EUR"
* "KOR"

Starting with the browser from [[10.2.0-28]], the "1" in the above URLs were changed to "2".

As of October 26, 2015, the "1" URLs return the browser-version for v9.9(decimal number as a string without any "."), while the "2" URLs returns 0.

if(internal_browserver > server_browserver)
{
<safe>
}
else
{
<update message>
}

Hence, internal_browserver == server_browserver will trigger the sysupdate message, which appears to be the normal way to indicate that the current browser is outdated(see above).

There is a cache for this in savedata. The request is only done when at least 24-hours have passed since the last time the request was done(see the below savedata section).

It is still possible to guard against this update by blocking the previous URLs using a proxy.
It is not possible to remove the update message by entering the [[Recovery Mode]].

=== Page request ===
The browser(with New3DS at least) does the following with [[HTTP_Services|HTTPC]] for requesting the above page:
* Initializes the HTTP context and uses [[HTTPC:InitializeConnectionSession]] + [[HTTPC:SetProxyDefault]].
* Uses [[HTTP_Services|HTTPC]] command 0x250080 twice with cmd[1]=contexthandle: first time cmd[2]=0x3, second time cmd[2]=0x6.
* Then [[HTTPC:AddTrustedRootCA]] is used 48 times to setup 48 trusted root CAs. This appears to be every cert in the browser "romfs:/browser/rootca.pem" file converted to DER, in the same order from there(in other words, every single root CA the browser trusts by default for normal web-browsing). It's unknown whether any of these actually gets used at all.
* Then [[HTTPC:BeginRequest]] is used.
* Then [[HTTPC:ReceiveDataTimeout]] is used, the recv-size seems to be fixed to 0x20.
* Then [[HTTPC:GetResponseStatusCodeTimeout]] is used.
* Then [[HTTPC:GetDownloadSizeState]] is used.
* Then the HTTP context is closed.

Raw request data(New3DS USA v10.2 browser):
000000: 47 45 54 20 2f 53 4e 41 4b 45 2f 32 2f 55 53 41 GET /SNAKE/2/USA
000010: 20 48 54 54 50 2f 31 2e 31 0d 0a 48 6f 73 74 3a HTTP/1.1..Host:
000020: 20 63 62 76 63 2e 63 64 6e 2e 6e 69 6e 74 65 6e cbvc.cdn.ninten
000030: 64 6f 2e 6e 65 74 0d 0a 0d 0a do.net....

== v9.9 dummy web-browser ==
The gamecard v9.9 sysupdate included with some games contains a dummy Old3DS/New3DS web-browser. The *only* thing this title does is display the same message listed in the above forced-update section. The message files in RomFS *only* contain that message string above. There are no "http" strings in the main codebin, and [[RO_Services|RO]] isn't used either(no CRO data in RomFS at all). Both browsers are internally called "dummySpider".

Hence, if you update your system from pre-v9.9 using a gamecard with v9.9, the system web-browser will be rendered *completely* useless until you install a system-update from CDN(no network requests involved here).

== Savedata ==
=== New3DS ===
On newer SKATER versions, it appears *all* NAND savedata is stored under the [[System_SaveData|0x000200BB]] savedata.

==== 0x000200BB savedata ====
This only contains "t.bin" with filesize 0xadf80, the format is below.

The timestamp format used here is the number of milliseconds since January 1, 2000(local-time).

When using the "Initialize savedata" option in the browser, that deletes this savedata file/image then exits the browser. This file is then re-created when the browser gets started again.

{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x68
| 0x4?
| This counter is incremented each time the savedata is written.
|-
| 0x70
| 0x8
| Timestamp for when the savedata was last written.
|-
| 0x94
| 0x15?
| This is all-zeros on non-JPN systems. On JPN systems where the browser filter is disabled, this is a string in the following format: "4110-%016llX".
|-
| 0xD8
| 0x8
| s64 timestamp, can be either a normal positive timestamp or a relative negative one. Used with the forced-update described above. When an update is detected this timestamp is negative, otherwise this is a normal positive timestamp(it's unknown how exactly this timestamp is checked). When positive, this seems to be the last time the forced-update HTTPS request was done where no update was needed.
|}

==Web Standards==
*HTML 4.01
*HTML 5 (120/400 score on [http://www.html5test.com HTML5Test.com])
*XHTML 1.1
*CSS 1
*CSS 2.1
*CSS 3 (some functionality is unavailable)
*DOM Levels 1-3
*ECMAScript (partial support for ECMA-262 5th Edition)
*XMLHttpRequest Level 2
*Canvas Element (some functionality is unavailable)

==Protocols==
*HTTP 1.0
*HTTP 1.1
*SSLv3
*TLS 1.0

==Image Formats==
*[[File_Formats|MPO]]
*GIF
*JPEG
*PNG
*BMP
*ICO (some files cannot be displayed)

==Plug-Ins==

Plug-ins (such as Adobe Flash) are not supported.

==Other details==

*It scored 90/100 on [http://acid3.acidtests.org/ Acid3] test
*Images from the Internet can be saved to the [[SD Filesystem|SD Card]] and viewed using the [[Nintendo 3DS Camera]] application.
*Images saved to an [[SD Filesystem|SD Card]] or to the Nintendo 3DS system memory can be uploaded to blogs or other sites that allow the uploading of photos using :
<input type="file" />
* HTML5Test.com say that Drag and drop is supported but it's not (code on WebKit is ready, but it's not implemented on interface of browser)

==Tips==

=== Detect User Agent ===

To detect if the user agent is Nintendo 3DS Browser :

<script type="text/javascript">
if (navigator.userAgent.indexOf('Nintendo 3DS') == -1) { //If the UserAgent is not "Nintendo 3DS"
location.replace('http://www.3dbrew.org'); //Redirect to an other page
}
</script>

* You can check navigator.platform=="Nintendo 3DS" as well.

=== Scrolling ===

Scrolling can be altered by modifying document.body.scrollTop and document.body.scrollLeft. However, there are drawbacks related to working with these properties:

* Both properties return 0 when accessed
* Setting one property resets the other property's scroll position

In order to set both at the same time (without either resetting to 0), use window.scrollTo.

=== Events ===
==== Key Events ====
The following buttons trigger the onkeydown, onkeypress and onkeyup events:

{|class="wikitable" width="20%"
! Code !! Button
|-
| 13 || A
|-
| 37 || Left
|-
| 38 || Up
|-
| 39 || Right
|-
| 40 || Down
|}

The events cannot have their default action cancelled. Other buttons do not trigger key events.

==== Touch/Mouse Events ====
onmousedown, onmouseup & onclick are all triggered by the browser. However, the onmousedown event doesn't trigger until you lift the stylus or you've held it on the screen for ~2 seconds—which is when text selection mode is activated—making it pretty much the same as onmouseup. The events cannot have their default action cancelled.

The onmousemove and common touch/gesture events are not supported.

== Screen Resolution ==

The up screen resolution is 400×240. However, the viewable area in the browser is only 400×220.

The touch screen resolution is 320×240. However, the viewable area in the browser is only 320×212.

You can have a page span both screens. However, the browser will behave as if the bottom screen is the only active screen and the top screen is scrolled off. This is important when computing CSS coordinates. Items positioned from "bottom" will be positioned based on 220px and not the full 432px of both screens.

== Using Both Screens ==

Generally the easiest way to accomplish the correct layout is to create HTML elements that "contain" the top and bottom screens. Here's an example:

<!DOCTYPE html>
<html>
<head>
<meta name="viewport" content="width=400">
<style>
body{margin:0px;}
#topscreen{width:400px;height:220px;overflow:hidden;}
#bottomscreen{width:320px;height:212px;overflow:hidden;margin:0 auto;}
</style>
</head>
<body>
<div id="topscreen">Top Screen</div>
<div id="bottomscreen">Bottom Screen</div>
</body>
</html>

This scheme allows the page to be easily manipulated through JavaScript. In order to have the window snap to the correct position, use the following JavaScript code:

window.setInterval(function () {
window.scrollTo(40, 220);
}, 50);

This automatically resets the position if the user accidentally scrolls the page.

==Example Sites==

* [http://geekshadow.com/gaming/dev/weaponscolors/3DS/ Weapons and Colors] (Short URL: http://bit.ly/3DSwc)
* [http://3ds.andysmith.co.uk/jFox.html jFox] (Short URL: http://bit.ly/iB7FqW)
* [http://ditto3d.com/3ds Ditto3D] (Short URL: http://bit.ly/oVreWA)
* [http://www.nintendo.com/3ds/internetbrowser/bookmarks Nintendo 3DS Bookmarks] - This is the first bookmark pre-installed in the browser.

Hackmiibo

2015-10-19T09:29:15Z

Vague Rant: Abandoned project.

Homebrew Exploits

2015-10-19T03:20:27Z

Vague Rant: Move Tubehax to "Previous Exploits".

==Standalone Homebrew Launcher Exploits==
The following homebrew exploits can be executed on a previously un-exploited system.

{| class="wikitable" border="1"
|-
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| [[ninjhax|Ninjhax 1.1b]]
| From '''4.0.0-X''' up to and including '''9.2.0-X''', for '''X''' is between 7 and 20.
| A cartridge or eShop version (JPN-only) of "Cubic Ninja".
| smea
| [http://smealum.net/ninjhax/ Install]
|-
| [[ninjhax|Ninjhax 2.1]]
| From '''9.0.0-X''' up to and including '''10.1.0-X''', for '''X''' up to and including 27.
| A cartridge or eShop version (JPN-only) of "Cubic Ninja".
| smea
| [http://smealum.github.io/ninjhax2/ Install]
|-
| [[smashbroshax|smashbroshax]] (beaconhax)
| (New3DS-only) From '''9.0.0-X''' up to and including '''10.1.0-X''', for '''X''' up to and including 27.
| Super Smash Bros 3DS (full-game or demo) and a way to broadcast raw wifi beacons.
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/3ds_smashbroshax Install]
|-
| [[browserhax]]
| (Old3DS) From '''9.0.0-16''' to '''9.5.0-22''', '''9.5.0-23''' to '''9.8.0-25''', '''9.9.0-26''' to '''10.1.0-27'''

(New3DS) From '''9.0.0-20''' to '''9.2.0-20''', '''9.3.0-21''' to '''9.5.0-23''', '''9.6.0-24''' to '''9.8.0-25''', '''9.9.0-26''' to '''10.1.0-27'''
|
| [[User:Yellows8|Yellows8]]
| [http://yls8.mtheall.com/3dsbrowserhax.php Install]
|}

Note that ninjhax 1.x is still not obsolete. Even though ninjhax 2.x can be run on 9.3+, this was made possible (amongst other things) by sacrificing the memory remapping exploit used in ninjhax 1.x (rohax). Therefore, things like JIT engines for emulators can only be supported on ninjhax 1.x. Furthermore, ninjhax 2.x does not run on system versions below 9.0.0-X, while ninjhax 1.x does.

==Secondary Exploits==
Installation of these exploits requires a previously exploited system to install. After installation, they can be used on their own.

{| class="wikitable" border="1"
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| [[ironhax]]
| From '''9.5.0-X''' up to and including '''10.1.0-X''', for '''X''' up to and including 27.
| A copy of "Ironfall: Invasion" downloaded from eShop before August 11th, 2015. Note the updated version that was released on October 13th, 2015 is not supported.
| smea
| [http://smealum.github.io/3ds/ Install]
|-
| [https://github.com/yellows8/oot3dhax oot3dhax]
| From '''9.5.0-X''' up to and including '''10.1.0-X''', for '''X''' up to and including 27.
| A gamecard or eShop-install of Legend of Zelda: Ocarina of Time 3D.
| Actual hax/payload: Yellows8/smea et all. Installer: Meladroit.
| [https://github.com/meladroit/oot3dhax_installer Installer]
|-
| [[themehax]]
| From '''9.0.0-X''' up to and including '''10.1.0-X''', for '''X''' up to and including 27.
|
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/3ds_homemenuhax/releases Download]
|}

==Exploits without Homebrew Launcher (Not recommended)==

'''Warning:''' The following exploits can run code, but are missing a 3DSX launcher. They cannot launch any homebrew in the 3DSX format.

{| class="wikitable" border="1"
|-
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| [[browserhax]] (Without the loader in the 3ds_browserhax_common repo)
| (Old3DS) From '''2.1.0-4''' to '''3.0.0-6''', '''4.0.0-7''' to '''4.5.0-10''', '''5.0.0-11''' to '''7.0.0-13''', '''7.1.0-16''' to '''9.5.0-22''', '''9.5.0-23''' to '''9.8.0-25''', '''9.9.0-26''' to '''10.1.0-27'''

(New3DS) From '''9.0.0-20''' to '''9.2.0-20''', '''9.3.0-21''' to '''9.5.0-23''', '''9.6.0-24''' to '''9.8.0-25''', '''9.9.0-26''' to '''10.1.0-27'''
|
| [[User:Yellows8|Yellows8]]
| [[browserhax|Install]]
|}

==Previous Exploits==
'''Warning:''' These exploits '''do not work'''. They are exploits which no longer function at all, regardless of software or firmware revision.
{| class="wikitable" border="1"
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| [[tubehax|Tubehax]]
| None. '''Was''': From '''9.0.0-X''' up to and including '''10.1.0-X''', for '''X''' up to and including 27.
| The YouTube application and an Internet connection. As of October 15, 2015, this is no longer usable due to an update being released which fixes the vuln used by tubehax + app update being forced(see [[YouTube|here]]).
| smea
| [http://smealum.github.io/3ds/ Install]
|}

Arm11 Interrupts

2015-10-19T03:09:17Z

Vague Rant: moved Arm11 Interrupts to ARM11 Interrupts: Capitalization.

#REDIRECT [[ARM11 Interrupts]]

ARM11 Interrupts

2015-10-19T03:09:17Z

Vague Rant: moved Arm11 Interrupts to ARM11 Interrupts: Capitalization.

== Interrupts ==

Interrupt priority is 0-0xF

= Private Interrupts =

Each CPU core has 32 software interrupts that are private and belong to that core. These interrupts are numbers 0-0x1F for each core. The hardware interrupts are not core-specific and start at interrupt ID 0x20.

{| class="wikitable" border="1"
! IRQ
! Listener
! Description
|-
| 0-0x5
|
| MPCore software-interrupt.
|-
| 0x6
| Kernel
| MPCore software-interrupt.
|-
| 0x7
|
| MPCore software-interrupt.
|-
| 0x8
| Kernel
| MPCore software-interrupt. Used for scheduling.
|-
| 0x9-0xF
|
| MPCore software-interrupt.
|-
| 0x1D
| Kernel
| MPCore timer.
|-
| 0x1E
| Kernel
| MPCore watchdog.
|}

= Hardware Interrupts =

There are 0x60 hardware interrupts starting at 0x20 and continuing up to 0x7F. These are not private and are accessible from any core.

{| class="wikitable" border="1"
! IRQ
! Listener
! Description
|-
| 0x28
| gsp, TwlBg
| ?
|-
| 0x29
| gsp, TwlBg
| ?
|-
| 0x2A
| gsp, TwlBg
| ?
|-
| 0x2B
| gsp, TwlBg
| ?
|-
| 0x2C
| gsp, TwlBg
| ?
|-
| 0x2D
| gsp, TwlBg
| ?
|-
| 0x30
| Kernel
| ?
|-
| 0x39
| Kernel
| DMA
|-
| 0x3A
| Kernel
| DMA
|-
| 0x3B
| Kernel
| DMA
|-
| 0x40
| nwm
| WIFI SDIO Controller @ 0x10122000
|-
| 0x41
| nwm
| ?
|-
| 0x42
| nwm_dev?
| WIFI SDIO Controller @ 0x10100000
|-
| 0x45
| mvd (New3DS)
| ?
|-
| 0x46
| mvd (New3DS)
| ?
|-
| 0x48
| camera
| ?
|-
| 0x49
| camera
| ?
|-
| 0x4A
| dsp
| ?
|-
| 0x4B
| camera
| Y2R Conversion Finished
|-
| 0x4C
| TwlBg
| ?
|-
| 0x4D
| TwlBg
| ?
|-
| 0x4E
| mvd (New3DS)
| ?
|-
| 0x4F
| mvd (New3DS)
| ?
|-
| 0x50
| pxi, TwlBg
| ?
|-
| 0x51
| pxi, TwlBg
| ?
|-
| 0x52
| pxi, TwlBg
| Send Fifo Empty
|-
| 0x53
| pxi, TwlBg
| Receive Fifo Not Empty
|-
| 0x54
| i2c, TwlBg
| ?
|-
| 0x55
| i2c, TwlBg
| ?
|-
| 0x56
| spi, TwlBg
| ?
|-
| 0x57
| spi, TwlBg
| ?
|-
| 0x58
| Kernel
| ?
|-
| 0x59
| TwlBg
| ?
|-
| 0x5A
| mic
| ?
|-
| 0x5C
| i2c, TwlBg
| ?
|-
| 0x60
| gpio, TwlBg
| ?
|-
| 0x62
| gpio, TwlBg
| ?
|-
| 0x63
| gpio, TwlBg
| ?
|-
| 0x64
| gpio, TwlBg
| ?
|-
| 0x66
| gpio, TwlBg
| ?
|-
| 0x68
| gpio, TwlBg
| ?
|-
| 0x69
| gpio, TwlBg
| ?
|-
| 0x6A
| gpio, TwlBg
| ?
|-
| 0x6B
| gpio, TwlBg
| ?
|-
| 0x6C
| gpio, TwlBg
| ?
|-
| 0x6D
| gpio, TwlBg
| ?
|-
| 0x6E
| gpio, TwlBg
| ?
|-
| 0x6F
| gpio, TwlBg
| ?
|-
| 0x70
| gpio, TwlBg
| ?
|-
| 0x71
| gpio, TwlBg
| ?
|-
| 0x72
| gpio, TwlBg
| ?
|-
| 0x73
| TwlBg
| ?
|}

There are 2 tables in the ARM11 kernel: the first has 32 * 2(or 32 * 4) 8-byte entries. This table is for the private interrupts that belong to each core. The data for each interrupt can be found by doing table_base + (core_num * 0x100) + (intr_num * 8). The second table is for public hardware interrupts and the data for each interrupt can be retrieved by doing table_base + (intr_num * 8).

= Interrupt Table =
(0xFFF308EC in 10.x)

{| class="wikitable" border="1"
! Offset
! Type
! Description
|-
|
|
|
|}

KHeapChunkHeader

2015-09-27T09:16:18Z

Vague Rant: neobrain, you appear to be misunderstanding how MediaWiki redirects work. The other similar pages redirect to this one. There are no other pages with this content on them.

[[Category:Kernel objects]]
{{stub}}
memchunkhdr = a data structure describing chunks of memory allocated by the ARM11 kernel.

Here is some code describing the layout of a memory chunk header.

struct MemoryChunkHeader {
int num_pages; // size of this chunk in terms of small pages
void* next;
void* prev;
int unk1;
int unk2;
};

The "next" and "prev" members are used to implement a linked-list. In fact, chances are this is actually a kernel object inherited from [[KLinkedList]].

Homebrew Exploits

2015-09-23T10:45:25Z

Vague Rant: Stop that.

==Self-Exploitable==
The following homebrew exploits can be executed on a previously un-exploited system.
{| class="wikitable" border="1"
|-
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| [[ninjhax|Ninjhax 1.1b]]
| From '''4.0.0-X''' up to and including '''9.2.0-X''', for '''X''' is between 7 and 20.
| A cartridge or eShop version (JPN-only) of "Cubic Ninja".
| smea
| [http://smealum.net/ninjhax/ Install]
|-
| [[ninjhax|Ninjhax 2.1]]
| From '''9.0.0-X''' up to and including '''10.1.0-X''', for '''X''' up to and including 27.
| A cartridge or eShop version (JPN-only) of "Cubic Ninja".
| smea
| [http://smealum.github.io/ninjhax2/ Install]
|-
| [[tubehax|Tubehax]]
| From '''9.0.0-X''' up to and including '''10.1.0-X''', for '''X''' up to and including 27.
| The YouTube application and an internet connection.
| smea
| [http://smealum.github.io/3ds/ Install]
|-
| [[smashbroshax|smashbroshax]] (beaconhax)
| From '''9.0.0-X''' up to and including '''10.1.0-X''', for '''X''' up to and including 27.
| Super Smash Bros 3DS (full-game or demo) and a way to broadcast raw wifi beacons. Currently the hb-launcher payload can only be properly booted on New3DS with this, see the repo for details on that.
| [[User:Yellows8|Yellows8]]
| [https://github.com/yellows8/3ds_smashbroshax]
|}

Note that ninjhax 1.x is still not obsolete. Even though ninjhax 2.x can be run on 9.3+, this was made possible (amongst other things) by sacrificing the memory remapping exploit used in ninjhax 1.x (rohax). Therefore, things like JIT engines for emulators can only be supported on ninjhax 1.x. Furthermore, ninjhax 2.x does not run on system versions below 9.0.0-X, while ninjhax 1.x does.

==Secondary Exploits==
Installation of these exploits requires a previously exploited system.
{| class="wikitable" border="1"
! Name
! Supported firmwares
! Requirements
! Author
! Install
|-
| [[ironhax]]
| From '''9.5.0-X''' up to and including '''10.1.0-X''', for '''X''' up to and including 27.
| A copy of "Ironfall: Invasion" (not available on eShop as of August 11th, 2015) and a self-exploitable title.
| smea
| [http://smealum.github.io/3ds/ Install]
|-
| [https://github.com/yellows8/oot3dhax oot3dhax]
| From '''9.5.0-X''' up to and including '''10.1.0-X''', for '''X''' up to and including 27.
| A gamecard or eShop-install of Legend of Zelda: Ocarina of Time 3D.
| Actual hax/payload: Yellows8/smea et all. Installer linked here(modified version of the ironhax installer): Meladroit.
| OoT3DHax can be used to boot the otherapp homebrew-launcher payload. An installer for installing the hax-save + payload into the OoT3D savedata can be found [https://github.com/meladroit/oot3dhax_installer here].
|}

Homebrew Exploits

2015-08-24T09:41:07Z

Vague Rant: How about if we split them into self-exploitable and secondary exploits? Feel free to revert if found objectionable.

==Self-Exploitable==
The following homebrew exploits can be executed on a previously un-exploited system.
{| class="wikitable" border="1"
|-
! Name
! Supported firms
! Requirements
! Author
! Install
|-
| [[ninjhax]]
| From '''4.0.0-X''' up to and including '''9.2.0-X''', for '''X''' is between 7 and 20.
| A cartridge or eShop version (JPN-only) of "Cubic Ninja". (Obsolete?)
| smea
| [http://smealum.net/ninjhax/ Install]
|-
| [[ninjhax2.1]]
| From '''9.0.0-X''' up to and including '''9.9.0-X''', for '''X''' up to and including 26.
| A copy of "Cubic Ninja" (cartridge or eShop version).
| smea
| [http://smealum.github.io/ninjhax2/ Install]
|-
| [[tubehax]]
| From '''9.0.0-X''' up to and including '''9.9.0-X''', for '''X''' up to and including 26.
| The YouTube application and an internet connection.
| smea
| [http://smealum.github.io/3ds/ Install]
|}

==Secondary Exploits==
Installation of these exploits requires a previously exploited system.
{| class="wikitable" border="1"
! Name
! Supported firms
! Requirements
! Author
! Install
|-
| [[ironhax]]
| From '''9.5.0-X''' up to and including '''9.9.0-X''', for '''X''' up to and including 26.
| A copy of "Ironfall: Invasion" (not available on eShop as of August 11th, 2015) and a self-exploitable title.
| smea
| [http://smealum.github.io/3ds/ Install]
|}

Homebrew Applications

2015-08-20T03:10:58Z

Vague Rant: /* Applications */ Remove vid3o; can be readded at some point if it ever exists.

==Installing==
Applications are installed by copying the necessary files to the 3ds/ folder in the root of the SD-card. Most applications come with two files:
* boot.3dsx: The executable.
* icon.bin: The icon/metadata.

The [[Homebrew Launcher]] will scan the sdcard for all .3dsx files, but will only display an icon for those who have one according to the format described above.

==List==

===Launcher===
{| class="wikitable" border="1" width="100%"
! width="20%" | Name
! width="50%" | Description
! width="10%" | Author
! width="10%" | Download
! width="10%" | Open-Source
|-
| [https://github.com/smealum/3ds_hb_menu Ninjhax homebrew launcher]
| Ninjhax homebrew launcher can be started by exploiting a bug in the '''Cubic Ninja''' 3DS game. Works on 3DS devices between version 4.4.0 and 9.2.0.
| [https://twitter.com/smealum smea] et al.
| [http://smealum.net/ninjhax/dl/hbmenu/boot.3dsx Here]
| Yes
|-
| [http://smealum.github.io/ninjhax2/ Ninjhax homebrew launcher (v2.1)]
| Ninjhax homebrew launcher can be started by exploiting a bug in the '''Cubic Ninja''' 3DS game. Works on all 3DS devices between version 9.0.0 and 9.9.0
| [https://twitter.com/smealum smea] et al.
| [http://smealum.github.io/ninjhax2/boot.3dsx Here]
| No
|-
| [http://smealum.github.io/3ds/ Tubehax homebrew launcher]
| Tubehax homebrew launcher can be started by exploiting a bug in the '''Youtube''' 3DS app. Works on all 3DS devices between version 9.0.0 and 9.9.0.
| [https://twitter.com/smealum smea] et al.
| [https://smealum.github.io/ninjhax2/boot.3dsx Here]
| No
|-
| [http://smealum.github.io/3ds/ IRONhax homebrew launcher]
| IRONhax homebrew launcher can be started by exploiting a bug in the '''IronFall''' 3DS game. Works on all 3DS devices between version 9.0.0 and 9.9.0. '''IMPORTANT: Another exploit is required to run this installer. You need to be able to run the homebrew to install the exploit on your device.'''
| [https://twitter.com/smealum smea] et al.
| [http://smealum.github.io/ninjhax2/installer.zip Here]
| No
|}

===Applications===
{| class="wikitable" border="1"
! width="20%" | Name
! width="50%" | Description
! width="10%" | Author
! width="10%" | Download
! width="10%" | Open-Source
|-
| [https://github.com/yellows8/3ds_homemenu_extdatatool 3DS HomeMenu extdata Tool]
| Tool for accessing the SD extdata which Home Menu uses. This essentially allows writing custom themes to extdata which get loaded at Home Menu startup.
| [[User:yellows8|yellows8]]
| [https://github.com/yellows8/3ds_homemenu_extdatatool/releases]
| Yes
|-
| [https://github.com/markwinap/3DS_Nyan_Cat 3DS Nyan Cat]
| 3DS Nyan Cat using LIBSF2D.
| [[User:markwinap|markwinap]]
| [https://www.dropbox.com/s/e400my3xm0zw74r/nyan_cat.zip?dl=0 Here]
| Yes
|-
| [https://github.com/plutooo/ctrrpc ctrrpc]
| A small and easily extensible RPC server/client written in C/Python. Allows you to quickly poke service-commands and syscalls over wifi from a Python shell on your PC. Useful during reverse-engineering.
| [[User:plutooo|plutoo]]
| N/A
| Yes
|-
| [https://github.com/yellows8/ctr-streaming-server ctr-streaming-server]
| This is a server which runs on a 3DS, which receives audio/video for playback. This can also send [[HID_Shared_Memory|HID]] state to the client (see the README) when enabled. The included parse_hidstream tool can be used to parse that HID data to simulate keyboard/mouse input events, via Linux uinput.
| [[User:yellows8|yellows8]]
| N/A
| Yes
|-
| [https://github.com/DownloadMii/DownloadMii DownloadMii]
| This is a WIP homebrew online store.
| [[User:filfat|filfat]]
| [https://www.downloadmii.com/download/#release Latest]
| Yes
|-
| [https://github.com/linoma/fb43ds fb43ds]
| This is a simple Facebook's chat client
| [[User:linoma|linoma]]
| [https://github.com/linoma/fb43ds Here]
| Yes
|-
| [https://github.com/Steveice10/FBI FBI]
| Open source CIA (un)installer.
| [[User:Steveice10|Steveice10]]
| [https://www.dropbox.com/s/866yhujdg859mor/FBI.zip?dl=0 Here]
| Yes
|-
| [https://github.com/iamevn/for-anyone-who-walks-a-lot for-anyone-who-walks-a-lot]
| Tool to get past the 10 coin per day limit on earning Play Coins by walking.
| [[User:iamevn|iamevn]]
| [https://github.com/iamevn/for-anyone-who-walks-a-lot/releases Here]
| Yes
|-
| [https://github.com/mtheall/ftbrony ftBRONY]
| An FTP server.
| [[User:mtheall|mtheall]]
| N/A
| Yes
|-
| [https://github.com/iamevn/FTP-3DS FTP-3DS]
| Fork of ftBRONY with a Nintendo theme.
| [[User:iamevn|iamevn]]
| [https://github.com/iamevn/FTP-3DS/releases Here]
| Yes
|-
| [https://github.com/smealum/ftPONY ftPONY]
| A basic FTP server, useful for testing new homebrew versions without swapping the SD card.
| [[User:smea|smea]]
| [https://mega.co.nz/#!nchBkL7B!T3vXnX4q8Uwp6APYYTDSZi2bkm25la-Qyz6j4CjsllI Here]
| Yes
|-
| [https://github.com/zeta0134/3ds-homebrew-browser Homebrew Browser]
| Download homebrew from the internet!
| [[User:cromo|cromo]] [[User:zeta0134|zeta0134]]
| [https://github.com/zeta0134/3ds-homebrew-browser/releases/tag/v0.1 Here]
| Yes
|}

===Games===
{| class="wikitable" border="1"
! width="20%" | Name
! width="50%" | Description
! width="10%" | Author
! width="10%" | Download
! width="10%" | Open-Source
|-
| [http://gbatemp.net/threads/release-100-boxes-2ds.384714/ 100 Boxes 2DS]
| Simple puzzle game.
| [[User:Cid2mizard|Cid2mizard]]
| [http://3ds.nintendomax.com/Homebrews/Jeux/100Boxes2DS/100_Boxes_2DS.rar Here]
| Yes
|-
| [https://github.com/MrJPGames/2048-3D 2048-3D]
| "2048 was a big hit not so long ago, and I still see many people at my school playing it. So I thought it would be pretty cool to be able to play 2048 on the go on the 3DS."
| [[User:MrJPGames|Jasper Peters]]
| [https://github.com/MrJPGames/2048-3D/blob/master/2048-3D.3dsx?raw=true Here]
| Yes
|-
| [https://github.com/smealum/3dscraft 3DSCraft]
| Minecraft clone.
| [https://twitter.com/smealum smea]
| [http://smealum.github.io/3dscraft/downloads/3dscraft_141120.zip Here]
| Yes
|-
| [https://github.com/UnsureSherlock/checkers3ds/tree/master checkers3ds]
| A buggy ASCII checkers game
| [[User:UnsureSherlock|UnsureSherlock]]
| [http://www.filedropper.com/checkers3ds Here]
| Yes
|-
| [http://gbatemp.net/threads/release-hamsters-2ds.383457/ Hamsters 2DS]
| A hamster breeding game in text mode.
| [[User:Cid2mizard|Cid2mizard]]
| [http://3ds.nintendomax.com/Homebrews/Jeux/Hamsters2DS/Hamsters_2DS.rar Here]
| No
|-
| [https://gbatemp.net/threads/release-mastermind-3ds.394710/#post-5611660 Mastermind 3DS]
| Mastermind on 3DS
| [[User:MrJPGames|Jasper Peters]]
| [https://github.com/MrJPGames/Mastermind-3DS/blob/master/Mastermind.zip?raw=true Here]
| Yes
|-
| [http://gbatemp.net/threads/release-minesweeper-2ds.384185/ Minesweeper 2DS]
| Minesweeper clone.
| [[User:Cid2mizard|Cid2mizard]]
| [http://3ds.nintendomax.com/Homebrews/Jeux/Minesweeper2DS/Minesweeper_2DS.rar Here]
| Yes
|-
| [http://gbatemp.net/threads/release-paddle-puffle-3ds.392215/ Paddle Puffle 3DS]
| A port of [http://puffles.gatuno.mx Paddle Puffle] for the 3DS.
| Peanut42
| [http://puffles.gatuno.mx/releases/paddlepuffle3ds.zip Here]
| [https://github.com/gatuno/PaddlePuffle3DS Yes]
|-
| [https://github.com/smealum/portal3DS Portal3DS]
| An adaptation of [https://en.wikipedia.org/wiki/Portal_(video_game) Portal] for the 3DS.
| [https://twitter.com/smealum smea]
| N/A
| [https://github.com/smealum/portal3DS Yes]
|-
| [http://gbatemp.net/threads/release-tilemap-2ds.386733/ TileMap 2DS]
| Puzzle game.
| [[User:Cid2mizard|Cid2mizard]]
| [http://3ds.nintendomax.com/Homebrews/Jeux/TileMap2DS/TileMap_2DS.rar Here]
| Yes
|-
| [http://gbatemp.net/threads/release-tiles-2ds.385796/ Tiles 2DS]
| Puzzle game, Lights Out Like.
| [[User:Cid2mizard|Cid2mizard]]
| [http://3ds.nintendomax.com/Homebrews/Jeux/Tiles2DS/Tiles_2DS.rar Here]
| Yes
|-
| [https://github.com/Steveice10/WorldOf3DSand World of 3DSand]
| World of Sand clone.
| [[User:Steveice10|Steveice10]]
| [https://www.dropbox.com/s/91tqtydxpny9p1g/WorldOf3DSand.zip?dl=0 Here]
| Yes
|-
| [https://github.com/smealum/yeti3DS Yeti3DS]
| A quick and dirty port of Derek Evans' Yeti3D software rendering engine.
| [https://twitter.com/smealum smea]
| N/A
| Yes
|}

===Emulators===
{| class="wikitable" border="1"
! width="20%" | Name
! width="50%" | Description
! width="10%" | Author
! width="10%" | Download
! width="10%" | Open-Source
|-
| [https://github.com/st4rk/3DNES 3DNES]
| An NES emulator.
| St4rk
| [http://filetrip.net/3ds-downloads/homebrew/dl-3dnes-1-2-f32931.html Here]
| Yes
|-
| [https://github.com/Steveice10/3DSGBA 3DSGBA]
| A GBA emulator.
| Steveice10
| [https://www.dropbox.com/s/fraixj1fn9ql3w4/3DSGBA.zip?dl=0 Here]
| Yes
|-
| [https://github.com/StapleButter/blargSnes blargSnes]
| A Super Nintendo emulator.
| StapleButter
| [http://kuribo64.net/get.php?id=fYRTHLeS0pR3DXFw Here]
| Yes
|-
| [https://github.com/xerpi/CHIP-3DS CHIP-3DS]
| A simple and slow CHIP-8 emulator.
| xerpi
| [https://www.mediafire.com/?y94yjhzf70fsfsi Here]
| Yes
|-
| [https://github.com/shinyquagsire23/gpsp CitrAGB]
| Yet another GBA emulator.
| shinyquagsire23
| [https://www.dropbox.com/s/sxb7x34u58g4zo2/3ds.3dsx?dl=0 Here]
| Yes
|-
| [https://github.com/Drenn1/GameYob/tree/master/platform/3ds GameYob]
| A Game Boy (Color) emulator.
| Drenn
| [https://gbatemp.net/threads/gameyob-3ds-gb-c-emu.372523/ Here]
| Yes
|}

===Demos===
{| class="wikitable" border="1"
! width="20%" | Name
! width="50%" | Description
! width="10%" | Author
! width="10%" | Download
! width="10%" | Open-Source
|-
| cubedemo
| A short demo of Homebrew on 3ds with working sound.
| [[User:plutoo|plutoo]]
| [https://mega.co.nz/#!KUQFiQYA!pv8HDEyrmuX6Eyw2hW0opL7gf9Ztmjd9J5pPsvs_rD4 Here]
| No
|}

News

2015-07-26T06:25:58Z

Vague Rant: Restore from Google cache.

<noinclude>
==Adding an item==
* Log in to the wiki. Editing is disabled if you don't have an account.
* Add the news event to the top of the list, using this format for the date: <tt><nowiki>'''</nowiki>{{#time: d F y}}<nowiki>''' </nowiki></tt>. Please include the application's creator, version number, and a link to a page on 3DBrew about the application. No external links please.
* '''Move the last entry to the [[:News/Archive|news archive]]. There should be no more than 4 entrees in the list.'''

==Archives==
For older news, see the [[:News/Archive|news archive]].

=== News ===
</noinclude>
*'''18 July 15''' smea released [[ninjhax]] 2 beta [http://smealum.github.io/ninjhax2/], enabling ARM11 homebrew execution on Old/New 3DS up to firmware 9.9.0-26.
*'''13 July 15''' Nintendo released system update [[9.9.0-26]].
*'''1 June 15''' Nintendo released system update [[9.8.0-25]].
*'''03 May 15''' smea released regionFOUR [https://github.com/smealum/regionFOUR/blob/master/README.md], enabling region free gaming on latest firmware. (again)

News/Archive

2015-07-26T06:25:44Z

Vague Rant: Restore from Google cache.

*'''20 April 15''' Nintendo released system update [[9.7.0-25]].
*'''23 March 15''' Nintendo released system update [[9.6.0-24]].
*'''2 March 15''' Nintendo released system update [[9.5.0-23]].
*'''15 February 15''' WinterMute released [http://devkitpro.org/viewtopic.php?f=13&t=8409 devkitARM release 44].
*'''2 February 15''' Nintendo released system update [[9.5.0-22]], which fixes [[3DS System Flaws|firmlaunch-hax]].
*'''16 January 15''' smea released regionthree [https://github.com/smealum/regionthree/blob/master/README.md], enabling region free gaming on latest firmware.
*'''24 December 14''' smea released [[Ninjhax]] 1.1 ('''NOT''' a fix for firmware [[9.3.0-21]] or [[9.4.0-21]]).
*'''11 December 14''' Nintendo released system update [[9.4.0-21]].
*'''8 December 14''' Nintendo released system update [[9.3.0-21]], which fixes [[3DS System Flaws|rohax]].
*'''20 November 14''' smea released [[Ninjhax]], the first public [[Homebrew Exploits|homebrew exploit]] compatible with system-versions [[4.0.0-7]]-[[9.2.0-20]].
*'''29 October 14''' Nintendo released system update [[9.2.0-20]].
*'''10 October 14''' Nintendo released system update [[9.1.0-20J]].
*'''6 October 14''' Nintendo released system update [[9.0.0-20]].
*'''29 August 14''' Nintendo announced [[New 3DS]].
*'''7 August 14''' Nintendo released system update [[8.1.0-19]].
*'''24 July 14''' Nintendo released system update [[8.1.0-18]].
*'''7 July 14''' Nintendo released system update [[8.0.0-18]].
*'''12 May 14''' Nintendo released system update [[7.2.0-17]].
*'''26 February 14''' Nintendo released system update [[7.1.0-16]].
*'''22 January 14''' Nintendo released system update [[7.1.0-15]].
*'''19 December 13''' Nintendo released system update [[7.1.0-14]].
*'''9 December 13''' Nintendo released system update [[7.0.0-13]].
*'''13 September 13''' Nintendo released system update [[6.3.0-12]].
*'''20 August 13''' [[3DSExplorer|3DSExplorer v1.5.3]] updated by [[User:Elisherer|Elisherer]] (Enable trimming NCSD)
*'''6 August 13''' Nintendo released system update [[6.2.0-12]].
*'''11 July 13''' Nintendo released system update [[6.1.0-12U]] for only USA.
*'''27 June 13''' Nintendo released system update [[6.1.0-11]] (6.1.0-12 for all regions except USA).
*'''17 June 13''' Nintendo released system update [[6.0.0-11]] (6.0.0-12 for all regions except USA).
*'''4 April 13''' Nintendo released system update [[5.1.0-11]].
*'''25 March 13''' Nintendo released system update [[5.0.0-11]].
*'''14 January 13''' [[3DSExplorer|3DSExplorer v1.5.1]] updated by [[User:Elisherer|Elisherer]]
*'''4 December 12''' Nintendo released system update [[4.5.0-10]].
*'''1 December 12''' [[3DSExplorer|3DSExplorer v1.4]] updated by [[User:Elisherer|Elisherer]]
*'''2 November 12''' Added page for [[Fundraiser|Chip decapping fundraiser]]
*'''8 January 13''' [[3DSExplorer|3DSExplorer v1.5]] updated by [[User:Elisherer|Elisherer]]
*'''23 September 12''' [[005tools|005tools v0.1b]] by [[User:McHaggis|McHaggis]]
*'''19 September 12''' Nintendo released system update [[4.4.0-10]].
*'''17 August 12''' Nintendo released New Super Mario Bros. 2, the first 3DS title released simultaneously in stores and as an [[eShop]] download.
*'''28 July 12''' [[3DSExplorer|3DSExplorer v1.3]] (modified by 3DSGuy) updated by [[User:Elisherer|Elisherer]]
*'''24 July 12''' Nintendo released system update [[4.3.0-10]].
*'''26 June 12''' Nintendo released system update [[4.2.0-9]].
*'''19 May 12''' [[3DSExplorer|3DSExplorer v1.2.1]] updated by [[User:Elisherer|Elisherer]]
*'''15 May 12''' Nintendo released its first implementation of 3DS '[[Title list#0004000E - Add-on Content|Add-on Content]]' with the Mario Kart 1.1 update.
*'''14 May 12''' Nintendo released system update [[4.1.0-8]].
*'''24 April 12''' Nintendo released system update [[4.0.0-7]].
*'''08 February 12''' [[CiTRUS|CiTRUS v0.2]] updated by [[User:Xcution|Xcution]]
*'''04 February 12''' [[CiTRUS|CiTRUS v0.1]] released by [[User:Xcution|Xcution]]
*'''02 February 12''' [[3DSExplorer|3DSExplorer v1.2]] updated by [[User:Elisherer|elisherer]]
*'''26 January 12''' [[Crappy Tiny Reader|CTR - Crappy Tiny Reader v0.07]] updated by [[User:PsyKopaT|PsyKo]]
*'''05 January 12''' [[Crappy Tiny Reader|CTR - Crappy Tiny Reader v0.06]] updated by [[User:PsyKopaT|PsyKo]]
*'''21 December 11''' Nintendo released system update [[3.0.0-6]]
*'''21 December 11''' [[3DSExplorer|3DSExplorer v1.1.1]] updated by [[User:Elisherer|elisherer]]
*'''7 December 11''' [[3DSExplorer|3DSExplorer v0.96]] updated by [[User:Elisherer|elisherer]]
*'''4 September 11''' [[3DSViewer|3DSViewer v0.1]] released by [[User:Elisherer|elisherer]]
*'''1 August 11''' [[3DS Save DeEncrypter3DS|Save DeEncrypter v1.0]] released by [[User:Blite|Blite]]
*'''25 July 11''' Nintendo released system update [[2.1.0-4]].
*'''15 June 11''' Nintendo released system update [[2.1.0-3]].
*'''6 June 11''' Nintendo released system update [[2.0.0-2]].
*'''6 April 11''' [[DSaveManager|DSaveManager v0.1]] released by [[User:Crediar|crediar]]
*'''4 April 11''' [[3DSaveTool|3DSaveTool v0.2b]] released by [[User:Crediar|crediar]]
*'''2 April 11''' [[3DSaveTool|3DSaveTool v0.1]] released by [[User:Crediar|crediar]]
*'''28 March 11''' Fixed 3DBrew wiki issues, now fully operational!
*'''18 March 11''' 3DBrew launched.

== 3DBrew International ==
Our community is an international community.

We have freedom, and we will express it in our language (but you have to write it in English before ;)!

Memory layout

2015-07-26T06:21:04Z

Vague Rant: Restore from Google cache.

=ARM11 Physical memory regions =
{| class="wikitable" border="1"
|-
! Old 3DS
! Address
! Size
! Description
|-
| style="background: green" | Yes
| 0x00000000
| 0x00010000
| Bootrom (super secret code/data @ 0x8000)
|-
| style="background: green" | Yes
| 0x00010000
| 0x00010000
| Bootrom mirror
|-
| style="background: green" | Yes
| 0x10000000
|?
| [[IO]] memory
|-
| style="background: green" | Yes
| 0x17E00000
| 0x00002000
| MPCore private memory region

|-
| style="background: red" | No
| 0x17E10000
| 0x00001000
| ?
|-
| style="background: green" | Yes
| 0x18000000
| 0x00600000
| VRAM (divided in two banks, VRAM and VRAMB)
|-
| style="background: red" | No
| 0x1F000000
| 0x00400000
| [[New_3DS]] additional memory
|-
| style="background: green" | Yes
| 0x1FF00000
| 0x00080000
| DSP memory
|-
| style="background: green" | Yes
| 0x1FF80000
| 0x00080000
| AXI WRAM
|-
| style="background: green" | Yes
| 0x20000000
| 0x08000000
| FCRAM
|-
| style="background: red" | No
| 0x28000000
| 0x08000000
| [[New_3DS]] FCRAM extension
|-
| style="background: green" | Yes
| 0xFFFF0000
| 0x00010000
| Bootrom mirror
|}

=ARM9 Physical memory regions =
{| class="wikitable" border="1"
|-
! Old 3DS
! Address
! Size
! Description
|-
| style="background: green" | Yes
| 0x00000000
| 0x08000000
| Instruction TCM, repeating each 0x8000 bytes.
|-
| style="background: green" | Yes
| 0x01FF8000
| 0x00008000
| Instruction TCM (Accessed by the kernel and process by this address)
|-
| style="background: green" | Yes
| 0x07FF8000
| 0x00008000
| Instruction TCM (Accessed by bootrom by this address)
|-
| style="background: green" | Yes
| 0x08000000
| 0x00100000
| ARM9-only internal memory (ARM7's internal regions are mapped here as well)
|-
| style="background: red" | No
| 0x08100000
| 0x00080000
| [[New_3DS]] ARM9-only extension, only enabled when a certain [[CONFIG_Registers|CONFIG]] register is set.
|-
| style="background: green" | Yes
| 0x10000000
| 0x08000000
| [[IO]] memory
|-
| style="background: green" | Yes
| 0x18000000
| 0x00600000
| VRAM (divided in two banks, VRAM and VRAMB)
|-
| style="background: green" | Yes
| 0x1FF00000
| 0x00080000
| DSP memory
|-
| style="background: green" | Yes
| 0x1FF80000
| 0x00080000
| AXI WRAM
|-
| style="background: green" | Yes
| 0x20000000
| 0x08000000
| FCRAM
|-
| style="background: red" | No
| 0x28000000
| 0x08000000
| [[New_3DS]] FCRAM extension
|-
| style="background: green" | Yes
| 0xFFF00000
| 0x00004000
| Data TCM (Mapped during bootrom)
|-
| style="background: green" | Yes
| 0xFFFF0000
| 0x00010000
| Bootrom, the main region is at +0x8000, which is disabled during system boot.
|}

==ARM9 MPU regions==
For the below instruction permissions: RO = memory is executable, while None = not-executable.

===NATIVE_FIRM/SAFE_MODE_FIRM ARM9 kernel===
{| class="wikitable" border="1"
|-
! Region
! Address
! Size
! Privileged-mode data permissions
! User-mode data permissions
! Privileged-mode instruction permissions
! User-mode instruction permissions
|-
| 0
| 0xFFFF0000
| 32KB/0x8000
| RO
| None
| RO
| None
|-
| 1
| 0x01FF8000
| 32KB/0x8000
| RW
| RW
| RO
| RO
|-
| 2
| 0x08000000
| 1MB/0x100000. >=[[8.0.0-18|8.0.0-X]]: 2MB/0x200000.
| RW
| RW
| RO
| RO
|-
| 3
| 0x10000000
| 128KB/0x20000
| RW
| RW
| None
| None
|-
| 4
| 0x10100000
| 512KB/0x80000
| RW
| RW
| None
| None
|-
| 5
| 0x20000000
| 128MB/0x8000000. >=[[8.0.0-18|8.0.0-X]]: 256MB/0x10000000.
| RW
| RW
| None
| None
|-
| 6
| 0x08000000
| 128KB/0x20000
| RW
| None
| RO
| None
|-
| 7
| 0x08020000
| <[[3.0.0-5]]: 64KB/0x10000. >=[[3.0.0-5]]: 32KB/0x8000.
| RW
| None
| RO
| None
|}

The above is the MPU region settings setup by the ARM9-kernel in the crt0.

The New3DS ARM9-kernel MPU region settings are the same as the Old3DS MPU region settings for >=[[8.0.0-18|8.0.0-X]].

At the start of the Process9 function executed in kernel-mode via svc7b during firm-launching, it changes some MPU region settings. At the end of that function, before it uses the ARM9/ARM11 entrypoint fields, it disables MPU.

===New3DS [[FIRM|ARM9-loader]]===
{| class="wikitable" border="1"
|-
! Region
! Address
! Size
! Privileged-mode data permissions
! User-mode data permissions
! Privileged-mode instruction permissions
! User-mode instruction permissions
|-
| 0
| 0xFFFF0000
| 32KB/0x8000
| RO
| None
| RO
| None
|-
| 1
| 0x01FF8000
| 32KB/0x8000
| RW
| None
| RO
| None
|-
| 2
| 0x08000000
| 2MB/0x200000
| RW
| None
| RO
| None
|-
| 3
| 0x10000000
| 128KB/0x20000
| RW
| None
| None
| None
|}

MPU regions 4-7 are disabled. Note that the entire ARM9-loader runs in SVC-mode.

===TWL_FIRM/AGB_FIRM ARM9 kernel===
{| class="wikitable" border="1"
|-
! Region
! Address
! Size
! Privileged-mode data permissions
! User-mode data permissions
! Privileged-mode instruction permissions
! User-mode instruction permissions
|-
| 0
| 0xFFFF0000
| 32KB/0x8000
| RO
| None
| RO
| None
|-
| 1
| 0x01FF8000
| 32KB/0x8000
| RW
| RW
| RO
| RO
|-
| 2
| 0x08000000
| 1MB/0x100000. New3DS: 2MB/0x200000.
| RW
| RW
| RO
| RO
|-
| 3
| 0x10000000
| 2MB/0x200000.
| RW
| RW
| None
| None
|-
| 4
| 0x1FF00000
| 512KB/0x80000
| RW
| RW
| None
| None
|-
| 5
| 0x20000000
| 128MB/0x8000000. New3DS: 256MB/0x10000000.
| RW
| RW
| None
| None
|-
| 6
| 0x08000000
| <[[3.0.0-5|3.0.0-X]]: 256KB/0x40000. >=[[3.0.0-5|3.0.0-X]]: 128KB/0x20000
| RW
| None
| RO
| None
|-
| 7
| 0x08080000
| 128KB/0x20000
| RW
| RW
| RO
| RO
|}

==ARM9 ITCM==
{| class="wikitable" border="1"
|-
! ITCM mirror address
! ITCM bootrom mirror address
! Offset
! Size
! Description
|-
| 0x01FF8000
|
| 0x0
| 0x3700
| Uninitialized memory.
|-
| 0x01FFB700
| 0x07FFB700
| 0x3700
| 0x100
| The unprotected ARM9-bootrom code copies code from unprotected bootrom to 0x07FFB700(ITCM mirror) size 0x100, then calls the code at 0x07FFB700. The code located here is the code used for disabling access to the bootroms.
|-
| 0x01FFB800
|
| 0x3800
| 0x4
| This is always 0xDEADB00F.
|-
| 0x01FFB804
|
| 0x3804
| 0x4
| This is the u32 DeviceId.
|-
| 0x01FFB808
|
| 0x3808
| 0x10
| This is the fall-back keyY used for movable.sed keyY when movable.sed doesn't exist in NAND(the last two words here are used on retail for generating console-unique TWL keydata/etc). This is also used for "LocalFriendCodeSeed", etc.
|-
| 0x01FFB818
|
| 0x3818
| 0x1
| ?
|-
| 0x01FFB819
|
| 0x3819
| 0x1
| This is the [[CTCert]] issuer type: 0 = retail "Nintendo CA - G3_NintendoCTR2prod", non-zero = dev "Nintendo CA - G3_NintendoCTR2dev".
|-
| 0x01FFB81A
|
| 0x381A
| 0x6
| ?
|-
| 0x01FFB820
|
| 0x3820
| 0x4
| This is the CTCert ECDSA exponent, this is byte-swapped when *((u8*)(0x01FFB800+0x18)) is >=5.
|-
| 0x01FFB824
|
| 0x3824
| 0x2
| ?
|-
| 0x01FFB826
|
| 0x3826
| 0x1E
| This is the CTCert ECDSA privk.
|-
| 0x01FFB844
|
| 0x3844
| 0x3C
| This is the CTCert ECDSA signature.
|-
| 0x01FFB880
|
| 0x3880
| 0x80
| This is all-zero.
|-
| 0x01FFB900
|
| 0x3900
| 0x200
| This is the 0x200-bytes from NAND sector0.
|-
| 0x01FFBB00
|
| 0x3B00
| 0x200
| This is the 0x200-bytes from the plaintext NAND firm partition FIRM header, read by bootrom.
|-
| 0x01FFBD00
|
| 0x3D00
| 0x200
| Unknown, not used by [[FIRM]]. Probably RSA related going by the data right after this? These are not console-unique.
|-
| 0x01FFBF00
|
| 0x3F00
| 0x100
| This is the RSA-2048 modulo for [[RSA_Registers|RSA]]-engine slot2.
|-
| 0x01FFC000
|
| 0x4000
| 0x100
| This is the RSA-2048 modulo for RSA-engine slot3.
|-
| 0x01FFC100
|
| 0x4100
| 0x800
| These are RSA-2048 keys: 4 slots, each slot is 0x200-bytes. Slot+0 is the modulo, 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 modulus are separate from all other modulus used elsewhere.
|-
| 0x01FFC900
| 0x07FFC900
| 0x4900
| 0x400
| 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 [[CONFIG_Registers|REG_UNITINFO]]). These are RSA modulus: retailsrcptr = 0x1FFFD000, devsrvptr = 0x1FFFD400.
* The first 0x100-bytes here is the RSA-2048 modulo for the CFA NCCH header, and for the gamecard NCSD header.
* 0x01FFCA00 is the RSA-2048 modulo 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 console-unique).
|-
| 0x01FFCD00
|
| 0x4D00
| 0x80
| 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 was already all-zero, it immediately returns.
|-
| 0x01FFCD80
|
| 0x4D80
| 0x64
| 0x01FFCD84 size 0x10-bytes is the NAND CID(the 0x64-byte region at 0x01FFCD80 is initialized by Process9 + ARM9-bootrom). The u32 at 0x01FFCDC4 is the total number of NAND sectors, read from a MMC command.
|-
| 0x01FFCDE4
|
| 0x4DE4
| 0x21C
| Uninitialized memory.
|-
| 0x01FFD000
| 0x07FFD000
| 0x5000
| 0x2470
| The unprotected ARM9-bootrom copies 0x1FFFA000(AXIWRAM mem initialized by ARM11-bootrom) size 0x2470 to 0x07FFD000(mirror of 0x01FFD000). This block contains DSi keys.
* 0x01FFD000 is the RSA-1024 modulus for the retail System Menu
* 0x01FFD080 is the RSA-1024 modulus for DSi Wifi firmware and DSi Sound
* 0x01FFD100 is the RSA-1024 modulus for base DSi apps (Settings, Shop, etc.)
* 0x01FFD180 is the RSA-1024 modulus for DSiWare and RSA-signed cartridge headers
* 0x01FFD210 is the keyY for per-console-encrypted ES blocks
* 0x01FFD220 is the keyY for fixed-keyX ES blocks
* 0x01FFD300 is the DSi common (normal)key
* 0x01FFD350 is a normalkey set on keyslot 0x02, and is likely only used during boot
* 0x01FFD380 is the keyslot 0x00 keyX and the first half of the retail keyX for modcrypt crypto "Nintendo"
* 0x01FFD398 is the keyX used for 'Tad' crypto, usually in keyslot 0x02 "Nintendo DS", ..
* 0x01FFD3A8 is set as the middle two words of keyslot 0x03's keyX, before being overwritten "NINTENDO"
* 0x01FFD3BC is the keyY for keyslot 0x01, see below
* 0x01FFD3C8 is the fixed keyY used for eMMC partition crypto on retail DSi, see below (keyslot 0x03)
* 0x01FFD3E0 is the 0x1048-byte Blowfish data for DSi cart crypto
* 0x01FFE428 is the 0x1048-byte Blowfish data for DS cart crypto
On the 3DS, keyslots 0x01 and 0x03 have the last word set as 0xE1A00005 instead of the next word in ITCM. This is consistent with retail DSis.
|-
| 0x01FFF470
|
| 0x7470
| 0xB90
| Uninitialized memory.
0x01FFFC00 size 0x100-bytes starting with [[9.5.0-22|9.5.0-X]] is the FIRM header used during FIRM-launching.
|}

=[[New_3DS]] physical 0x1F000000 memory=
This area is used by [[QTM Services]](starting at offset 0x200000, size 0x180000). This area is not accessible to the GPU on the old 3DS. The old 3DS and New 3DS GSP module has vaddr->physaddr conversion code for this entire region. On the New 3DS, only the first 0x200000-bytes (half of this memory) are accessible to the GPU.

=Memory map by firmware=
* [[Virtual address mapping FW0B]]
* [[Virtual address mapping FW1F]]
* [[Virtual address mapping FW25]]
* [[Virtual address mapping FW2E]]
* [[Virtual address mapping FW37]]
* [[Virtual address mapping FW38‎]]
* [[Virtual address mapping FW3F]]
* FW49([[9.6.0-24|9.6.0-X]]) ARM11-kernel vmem mapping is identical to FW40([[9.5.0-22|9.5.0-X]]).

* [[Virtual address mapping TWLFIRM04]]

* [[Virtual address mapping New3DS v8.1]]
* [[Virtual address mapping New3DS v9.0]]
* [[Virtual address mapping New3DS v9.2]]

=ARM11 Detailed physical memory map=
18000000 - 18600000: VRAM

1FF80000 - 1FFAB000: Kernel code
1FFAB000 - 1FFF0000: SlabHeap [temporarily contains boot processes]
1FFF0000 - 1FFF1000: ?
1FFF1000 - 1FFF2000: ?
1FFF2000 - 1FFF3000: ?
1FFF3000 - 1FFF4000: ?
1FFF4000 - 1FFF5000: Exception vectors
1FFF5000 - 1FFF5800: Unused?
1FFF5800 - 1FFF5C00: 256-entry L2 MMU table for VA FF4xx000
1FFF5C00 - 1FFF6000: 256-entry L2 MMU table for VA FF5xx000
1FFF6000 - 1FFF6400: 256-entry L2 MMU table for VA FF6xx000
1FFF6400 - 1FFF6800: 256-entry L2 MMU table for VA FF7xx000
1FFF6800 - 1FFF6C00: 256-entry L2 MMU table for VA FF8xx000
1FFF6C00 - 1FFF7000: 256-entry L2 MMU table for VA FF9xx000
1FFF7000 - 1FFF7400: 256-entry L2 MMU table for VA FFAxx000
1FFF7400 - 1FFF7800: 256-entry L2 MMU table for VA FFBxx000
1FFF7800 - 1FFF7C00: MMU table but unused?
1FFF7C00 - 1FFF8000: 256-entry L2 MMU table for VA FFFxx000
1FFF8000 - 1FFFC000: 4096-entry L1 MMU table for VA xxx00000 (CPU 0)
1FFFC000 - 20000000: 4096-entry L1 MMU table for VA xxx00000 (CPU 1)
20000000 - 28000000: Main memory

The entire FCRAM is cleared during NATIVE_FIRM boot. This is probably done by the ARM11 kernel(after loading [[FIRM]] launch parameters from FCRAM)?

== FCRAM memory-regions layout ==
{| class="wikitable" border="1"
! [[Configuration_Memory#APPMEMTYPE|Configmem-APPMEMTYPE]] Value
! Base address relative to FCRAM+0, for APPLICATION mem-region
! Region size, for APPLICATION mem-region
! Base address relative to FCRAM+0, for SYSTEM mem-region
! Region size, for SYSTEM mem-region
! Base address relative to FCRAM+0, for BASE mem-region
! Region size, for BASE mem-region
|-
| 0 (default with regular 3DS kernel, used when the type is not 2-5)
| 0x0
| 0x04000000(64MB)
| 0x04000000
| 0x02C00000
| 0x06C00000
| 0x01400000
|-
| 2
| 0x0
| 0x06000000(96MB)
| 0x06000000
| 0x00C00000
| 0x06C00000
| 0x01400000
|-
| 3
| 0x0
| 0x05000000(80MB)
| 0x05000000
| 0x01C00000
| 0x06C00000
| 0x01400000
|-
| 4
| 0x0
| 0x04800000(72MB)
| 0x04800000
| 0x02400000
| 0x06C00000
| 0x01400000
|-
| 5
| 0x0
| 0x02000000(32MB)
| 0x02000000
| 0x04C00000
| 0x06C00000
| 0x01400000
|-
| 6 (This is the default on New3DS. With [[New_3DS]] kernel this is the type used when the value is not 7)
| 0x0
| 0x07C00000(124MB)
| 0x07C00000
| 0x06400000
| 0x0E000000
| 0x02000000
|-
| 7
| 0x0
| 0x0B200000(178MB)
| 0x0B200000
| 0x02E00000
| 0x0E000000
| 0x02000000
|}

The SYSTEM mem-region size is calculated with: size = FCRAMTOTALSIZE - (APPLICATION_MEMREGIONSIZE + BASE_MEMREGIONSIZE).

Support for type6/7 was [[NCCH/Extended Header|implemented]] in [[NS]] with [[8.0.0-18]], these are only supported in the [[New_3DS]] ARM11-kernel not the regular 3DS kernel. These two types are the only ones supported by the New3DS kernel.

All memory allocated by the kernel itself for kernel use is located under BASE. Most system-modules run under the BASE memregion too.

Free/used memory on [[4.5.0-10]] with Home Menu / Internet Browser, with the default APPMEMTYPE on retail:
{| class="wikitable" border="1"
! Region
! Base address relative to FCRAM+0
! Region size
! Used memory once [[Home Menu]] finishes loading for system boot, on [[4.5.0-10]]
! Used memory with [[Internet Browser]] running instead of [[Home Menu]], on [[4.5.0-10]]
! Free memory once [[Home Menu]] finishes loading for system boot, on [[4.5.0-10]]
! Free memory with [[Internet Browser]] running instead of [[Home Menu]], on [[4.5.0-10]]
|-
| APPLICATION
| 0x0
| 0x04000000
| 0x0
|
| 0x04000000
|
|-
| SYSTEM
| 0x04000000
| 0x02C00000
| 0x01488000
| 0x02A50000
| 0x01778000
| 0x001B0000
|-
| BASE
| 0x06C00000
| 0x01400000
| 0x01202000
| 0x01236000
| 0x001FE000
| 0x001CA000
|}

=ARM11 Detailed virtual memory map=
(valid only for FW0B, see [[#Memory map by firmware|Memory map by firmware]] for subsequent versions)

E8000000 - E8600000: mapped VRAM (18000000 - 18600000)

EFF00000 - F0000000: mapped Internal memory (1FF00000 - 20000000)
F0000000 - F8000000: mapped Main memory

FF401000 - FF402000: mapped ? (27FC7000 - 27FC8000)

FF403000 - FF404000: mapped ? (27FC2000 - 27FC3000)

FF405000 - FF406000: mapped ? (27FBB000 - 27FBC000)

FF407000 - FF408000: mapped ? (27FB3000 - 27FB4000)

FF409000 - FF40A000: mapped ? (27F8E000 - 27F8F000)

FFF00000 - FFF45000: mapped SlabHeap

FFF60000 - FFF8B000: mapped Kernel code

FFFCC000 - FFFCD000: mapped IO [[I2C|I2C]] second bus (10144000 - 10145000)

FFFCE000 - FFFCF000: mapped IO PDC([[LCD]]) (10400000 - 10401000)

FFFD0000 - FFFD1000: mapped IO PDN (10141000 - 10142000)

FFFD2000 - FFFD3000: mapped IO PXI (10163000 - 10164000)

FFFD4000 - FFFD5000: mapped IO PAD (10146000 - 10147000)

FFFD6000 - FFFD7000: mapped IO LCD (10202000 - 10203000)

FFFD8000 - FFFD9000: mapped IO DSP (10140000 - 10141000)

FFFDA000 - FFFDB000: mapped IO XDMA (10200000 - 10201000)

FFFDC000 - FFFE0000: mapped ? (1FFF8000 - 1FFFC000)

FFFE1000 - FFFE2000: mapped ? (1FFF0000 - 1FFF1000)

FFFE3000 - FFFE4000: mapped ? (1FFF2000 - 1FFF3000)

FFFE5000 - FFFE9000: mapped L1 MMU table for VA xxx00000

FFFEA000 - FFFEB000: mapped ? (1FFF1000 - 1FFF2000)

FFFEC000 - FFFED000: mapped ? (1FFF3000 - 1FFF4000)

FFFEE000 - FFFF0000: mapped IO IRQ (17E00000 - 17E02000)

FFFF0000 - FFFF1000: mapped Exception vectors

FFFF2000 - FFFF6000: mapped L1 MMU table for VA xxx00000

FFFF7000 - FFFF8000: mapped ? (1FFF1000 - 1FFF2000)

FFFF9000 - FFFFA000: mapped ? (1FFF3000 - 1FFF4000)

FFFFB000 - FFFFE000: mapped L2 MMU tables (1FFF5000 - 1FFF8000)

==0xFF4XX000==
Each [[KThread|thread]] is allocated a 0x1000-byte page in this region: the first page at 0xFF401000 is for the first created thread, 0xFF403000 for the second thread. This region is used to store the SVC-mode stack for the thread, and thread context data used for context switching. When the IRQ handler, prefetch/data abort handlers, and undefined instruction handler are entered where the SPSR-mode=user, these handlers then store LR+SPSR for the current mode on the SVC-mode stack, then these handlers switch to SVC-mode.

This page does not contain a dedicated block for storing R0-PC(etc). For user-mode, the user-mode regs are instead saved on the SVC-mode stack when IRQs such as timers for context switching are triggered.

Structure of this page, relative to page_endaddr-0xC8:
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
|
| SVC-mode stack-top. The 0x10-byte SVC-access-control for this thread is also located here, which is checked by the SVC-handler.
|-
| 0x18
| 0x28
| SVC-mode saved registers, stored/loaded during context switches: R4-R9, SL, FP, SP, LR. After loading these registers, the context switch code will jump to the loaded LR.
|-
| 0xC0
| 4
| fpexc from vmrs, used during context switches with the above saved registers.
|}

For NATIVE_FIRM the memory pages for this region are located in FCRAM, however for TWL_FIRM these are located in AXI WRAM. For TWL_FIRM v6704 the first thread's page for this region is located at physical address 0x1FF93000, the next one at 0x1FF92000, etc.

=ARM11 User-land memory regions=
==NATIVE_FIRM/SAFE_MODE_FIRM Userland Memory==
{| class="wikitable" border="1"
|-
! Virtual Address Base
! Physical Address Base
! Region Max Size
! Address-range available for svcMapMemoryBlock
! Description
|-
| 0x00100000 / 0x14000000
|
| 0x03F00000
| No
| The [[ExeFS]]:/.code is loaded here, executables must be loaded to the 0x00100000 region when the exheader "special memory" flag is clear. The 0x03F00000-byte size restriction only applies when this flag is clear. Executables are usually loaded to 0x14000000 when the exheader "special memory" flag is set, however this address can be arbitrary.
|-
| 0x04000000
| ?
| ?
| No
| Used for mapping buffers during IPC, see [[IPC Command Structure]].
|-
| 0x08000000
| Main stack physaddr - <heap size for the allocated vaddr 0x08000000 memory>
| 0x08000000
| Yes
| Heap mapped by [[SVC|ControlMemory]]
|-
| 0x10000000-StackSize
| .bss physical address - total stack pages
| StackSize from process exheader
|
| Stack for the main-thread, initialized by the ARM11 kernel. The StackSize from the exheader is usually 0x4000, therefore the stack-bottom is usually 0x0FFFC000. The stack for the other threads is normally located in the process .data section however this can be arbitrary.
|-
| 0x10000000
|
| 0x04000000
| Yes
| [[SVC|Shared]] memory
|-
| 0x14000000
| FCRAM+0
| 0x08000000
| No
| Can be mapped by [[SVC|ControlMemory]], this is used for processes' [[SVC|LINEAR]]/GSP heap.
|-
| 0x1E800000
| 0x1F000000
| 0x00400000
| No
| [[New_3DS]] additional memory, access to this is specified by the exheader. Added with [[8.0.0-18]], see above section regarding this memory.
|-
| 0x1EC00000
| 0x10100000
| 0x01000000
| No
| [[IO]] registers, the mapped IO pages which each process can access is specified in the [[NCCH#CXI|CXI]] exheader.(Applications normally don't have access to registers in this range)
|-
| 0x1F000000
| 0x18000000
| 0x00600000
| No
| VRAM, access to this is specified by the exheader.
|-
| 0x1FF00000
| 0x1FF00000
| 0x00080000
| No
| DSP memory, access to this is specified by the exheader.
|-
| 0x1FF80000
| FCRAM memory page allocated by the ARM11 kernel.
| 0x1000
| No
| [[Configuration Memory]], all processes have read-only access to this.
|-
| 0x1FF81000
| FCRAM memory page allocated by the ARM11 kernel.
| 0x1000
| No
| [[Configuration Memory|Shared]] page, all processes have read-access to this. Write access to this is specified by the exheader "Shared page writing" kernel flag.
|-
| 0x1FF82000
| ?
| ?
| No
| [[Thread Local Storage]]
|-
| 0x30000000
| FCRAM+0
| 0x08000000(Old3DS) / 0x10000000([[New_3DS]])
| No
| This LINEAR memory mapping was added with [[8.0.0-18]], see [[SVC#enum_MemoryOperation|here]]. This replaces the original 0x14000000 mapping, for system(memory-region=BASE)/newer titles. The Old3DS kernel uses size 0x08000000 for LINEAR-memory address range checks, while the New3DS kernel uses size 0x10000000 for those range checks. Old3DS/New3DS system-module code doing vaddr->phys-addr conversion uses size 0x10000000.
|-
| 0x20000000 / 0x40000000
|
|
|
| This is the end-address of userland memory, memory under this address is process-unique. Memory starting at this address is only accessible in privileged-mode. This address was changed from 0x20000000 to 0x40000000 with [[8.0.0-18]].
|}

All executable pages are read-only, and data pages have the execute-never permission set. Normally .text from the loaded ExeFS:/.code is the only mapped executable memory. Executable [[RO Services|CROs]] can be loaded into memory, once loaded the CRO .text section memory page permissions are changed via [[SVC|ControlProcessMemory]] from RW- to R-X. The address and size of each ExeFS:/.code section is stored in the exheader, the permissions for each section is: .text R-X, .rodata R--, .data RW-, and .bss RW-. The loaded .code is mapped to the addresses specified in the exheader by the ARM11 kernel. The stack permissions is initialized by the ARM11 kernel: RW-. The heap permissions is normally RW-.

All userland memory is mapped with RW permissions for privileged-mode. However, normally the ARM11 kernel only uses userland read/write instructions(or checks that the memory can be written from userland first) for accessing memory specified by [[SVC|SVCs]].

Processes can't directly access memory for other processes. When service [[Services API|commands]] are used, the kernel maps memory in the destination process for input/output buffers, where the addresses in the command received by the process is replaced by this mapped memory. When this is an input buffer, the buffer data is copied to the mapped memory. When this is an output buffer, the data stored in the mapped memory is copied to the destination buffer specified in the command.

The physical address which memory for the application memory-type is mapped to begins at FCRAM+0, the total memory allocated for this memory-type is stored in [[Configuration_Memory]]. Applications' .text + .rodata + .data under the application memory-type is mapped at FCRAM + APPMEMALLOC - (aligned page-size for .text + .rodata + .data). The application .bss is mapped at CODEADDR - .bss size aligned down to the page size.

==TWL_FIRM Userland Memory==
{| class="wikitable" border="1"
|-
! Virtual Address Base
! Physical Address Base
! Size
! Description
|-
| 0x00100000
| 0x1FFAB000 (with newer TWL_FIRM such as v6704 this is located at 0x1FFAC000)
| 0x00055000
| Code + .(ro)data copied from the process 0x00300000 region is located here(.bss is located here as well).
|-
| 0x00155000
| 0x18555000
| 0x000AB000
|
|-
| 0x00200000
| 0x18500000
| 0x00100000
|
|-
| 0x00300000
| 0x24000000
| 0x04000000
| The beginning of the ARM11 process .text is located here.
|-
| 0x08000000
| 0x20000000
| 0x07E00000
|
|-
| 0x1EC00000
| 0x10100000
| 0x00400000
| [[IO]]
|-
| 0x1F000000
| 0x18000000
| 0x00600000
| VRAM
|-
| 0x1FF00000
| 0x1FF00000
| 0x00080000
| This is mapped to the DSP memory.
|}

The above regions are mapped by the ARM11 kernel. Later when the ARM11 process uses [[SVC|svcKernelSetState]] with type4, the kernel unmaps(?) the following regions: 0x00300000..0x04300000, 0x08000000..0x0FE00000, and 0x10000000..0xF8000000.

=== Detailed TWL_FIRM ARM11 Memory ===
{| class="wikitable" border="1"
|-
! Process Virtual Address
! Physical Address
! Size
! Description
|-
| 0x08000000
| 0x20000000
| 0x01000000*4
| DS(i) 0x02000000 RAM. Vaddr = (DSRAMOffset*4) + 0x08000000, where DSRAMOffset is DSRAMAddr-0x02000000.
|-
| 0x0FC00000
| 0x27C00000
|
| Loaded SRL binary, initially the dev DSi launcher SRL is located here(copied here by the ARM11 process).
|-
| 0x0FD00000
| 0x27D00000
|
| The data located here is copied to here by the ARM11 process. The data located here is a TWL NAND [http://dsibrew.org/wiki/Bootloader bootloader] image, using the same format+encryption/verification methods as the DSi NAND bootloader(stage2). The keyX for this bootloader keyslot is initially set to the retail DSi key-data, however when TWL_FIRM is launched this keyX key-data is replaced with a separate keyX. TWL_FIRM can use either the retail DSi bootloader RSA-1024 modulo, or a seperate modulo: normally only the latter is used(the former is only used when loading the image from FS instead of FCRAM). When using the image from FCRAM(default code-path), TWL_FIRM will not calculate+check the hashes for the bootloader code binaries(this is done when loading from FS however).
|-
| 0x0FDF7000
| 0x27DF7000
| 0x1000
| SRL header
|}

= System memory details =
0xFFFF9000 Pointer to the current KThread instance
0xFFFF9004 Pointer to the current KProcess instance
0xFFFF9008 Pointer to the current KScheduler instance
0xFFFF9010 Pointer to the last KThread to encounter an exception

0x8000040 Pointer to the current KThread instance on the ARM9
0x8000044 Pointer to the current KProcess instance on the ARM9
0x8000048 Pointer to the current KScheduler instance on the ARM9

= Handles =
The handle 0xFFFF8001 is a reference to the current KProcess.
The handle 0xFFFF8000 is a reference to the current KThread.

= IO Process/Kernel virtual addressing equivalence =
It seems an IO register's process virtual address can be calculated by adding 0xEB00000 to its physical address.

= VRAM Map While Running System Applets =
*0x1E6000-0x22C500 -- top screen 3D left framebuffer 0(240x400x3) (The "3D right first-framebuf" addr stored in the LCD register is set to this, when the 3D is set to "off")
*0x22C800-0x272D00 -- top screen 3D left framebuffer 1(240x400x3)
*0x273000-0x2B9500 -- top screen 3D right framebuffer 0(240x400x3)
*0x2B9800-0x2FFD00 -- top screen 3D right framebuffer 1(240x400x3)
*0x48F000-0x4C7400 -- bottom screen framebuffer 0(240x320x3)
*0x4C7800-0x4FF800 -- bottom screen framebuffer 1(240x320x3)

These LCD framebuffer addresses are not changed by the system when launching regular applications, the application itself handles that if needed. These VRAM framebuffers are cleared when launching regular applications.

3DS System Flaws

2015-07-26T05:51:01Z

Vague Rant: /* Process9 */ Missed a wikilink.

Exploits are used to execute unofficial code (homebrew) on the Nintendo 3DS. This page is a list of publicly known system flaws, for userland applications/applets flaws see [[3DS_Userland_Flaws|here]].

=Stale / Rejected Efforts=
* Neimod has been working on a RAM dumping setup for a little while now. He's de-soldered the 3DS's RAM chip and hooked it and the RAM pinouts on the 3DS' PCB up to a custom RAM dumping setup. A while ago he published photos showing his setup to be working quite well, with the 3DS successfully booting up. However, his flickr stream is now private along with most of his work.

* Someone (who will remain unnamed) has released CFW and CIA installers, all of which is copied from the work of others, or copyrighted material.

==Tips and info==
The 3DS uses the XN feature of the ARM11 processor. There's no official way from applications to enable executable permission for memory containing arbitrary unsigned code(there's a [[SVC]] for this, but only [[RO_Services|RO-module]] has access to it). An usable userland exploit would still be useful: you could only do return-oriented-programming with it initially. From ROP one could then exploit system flaw(s), see below.

SD card [[extdata]] and SD savegames can be attacked, for consoles where the console-unique [[Nand/private/movable.sed|movable.sed]] was dumped(accessing SD data is far easier by running code on the target 3DS however).

=System flaws=
== Hardware ==
{| class="wikitable" border="1"
! Summary
! Description
! Fixed with hardware model/revision
! Newest hardware model/revision this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| ARM9/ARM11 bootrom vectors point at unitialized RAM
| ARM9's and ARM11's exception vectors are hardcoded to point at the CPU's internal memory (0x08000000 region for ARM9, AXIWRAM for ARM11). While the bootrom does set them up to point to an endless loop at some point during boot, it does not do so immediately. As such, a carefully-timed fault injection (via hardware) to trigger an exception (such as an invalid instruction) will cause execution to fall into ARM9 RAM.
Since RAM isn't cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc.
The ARM9 bootrom does the following at reset: reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there's no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.

This requires *very* *precise* timing for triggering the hardware fault: it's unknown if anyone actually exploited this successfully at the time of writing(the one who attempted+discovered it *originally* as listed in this wiki section hasn't).
| None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.
| New3DS
| End of February 2014
| [[User:Derrek|derrek]], WulfyStylez (May 2015) independently
|-
| Missing AES key clearing
| The hardware AES engine does not clear keys when doing a hard reset/reboot.
| None
| New3DS
| August 2014
| Mathieulh/Others
|-
| No RAM clearing on reboots
| On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM keeps its contents.
| None
| New3DS
| March 2014
| [[User:Derrek|derrek]]
|-
| 32bits of actual console-unique TWLNAND keydata
| On retail the 8-bytes at ARM9 address [[Memory_layout|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 of this, the lower u32's highest bit is always ORed. only 31 bits of the TWL console-unique keydata / TWL consoleID are actually console-unique.
This allows one to easily bruteforce the TWL console-unique keydata with *just* data from TWLNAND. On DSi the actual console-unique data for key generation is 8-bytes(all bytes actually set).
| None
| New3DS
| 2012?
| [[User:Yellows8|Yellows8]]
|-
| DSi / 3DS-TWL key-generator
| After using the key generator to generate the normal-key, you could overwrite parts of the normal-key with your own data and then recover the key-generator output by comparing the new crypto output with the original crypto output. From the normal-key outputs, you could deduce the TWL key-generator function.
This applies to the keyX/keyY too.

This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys.
|
|
| 2011
| [[User:Yellows8|Yellows8]]
|}

== ARM9 software ==
=== arm9loader ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| Missing verification-block for the 9.6 keys
| Starting with [[9.6.0-24|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-22|9.5.0-X]] with the original sector+0 keydata, however the below is only possible with [[9.6.0-24|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 ARM9 kernel as garbage and then jump to it.

This allows an hardware-based attack where you can boot into an older exploited firmware, fill all memory with NOP sleds/jump-instructions, and then reboot into executing garbage. By automating this process with various input keydata, eventually you'll find some garbage that jumps to your code.

This should give very early ARM9 code execution (pre-ARM9 kernel). As such, it is possible to dump RSA keyslots with this and calculate the 6.x [[Savegames#6.0.0-11_Savegame_keyY|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.

Due to FIRMs on both Old and New 3DS using the same RSA data, this 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.
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key
| None
| [[9.6.0-24|9.6.0-X]]
| March, 2015
| plutoo
|-
| Uncleared New3DS keyslot 0x11
| Originally the New3DS [[FIRM]] arm9bin loader only cleared keyslot 0x11 when it gets executed at firmlaunch. This was fixed with [[9.5.0-22|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 at firmlaunch(including firmlaunch-hax) can get access to the uncleared 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-24|9.6.0-X]].
| New3DS keyXs generation
| Mostly fixed with [[9.5.0-22|9.5.0-X]], completely fixed with new keys with [[9.6.0-24|9.6.0-X]].
|
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)
| [[User:Yellows8|Yellows8]]
|}

=== Process9 ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| FAT FS code null-deref
| When FSFile:Read is used with a file which is corrupted on a FAT filesystem(in particular SD), Process9 can crash. This particular crash is caused by a function returning NULL instead of an actual ptr due to an error. The caller of that function doesn't check for NULL which then triggers a read based at NULL.

Sample "fsck.vfat -n -v -V <fat image backup>" output for the above crash:

<pre>...
Starting check/repair pass.
<FilePath0> and
<FilePath1>
share clusters.
Truncating second to 3375104 bytes.
<FilePath1>
File size is 2787392 bytes, cluster chain length is 16384 bytes.
Truncating file to 16384 bytes.
Checking for unused clusters.
Reclaimed 1 unused cluster (16384 bytes).
Checking free cluster summary.
Free cluster summary wrong (1404490 vs. really 1404491)
Auto-correcting.
Starting verification pass.
Checking for unused clusters.
Leaving filesystem unchanged.</pre>
| Useless null-based-read
| None
| [[9.6.0-24|9.6.0-X]]
| July 8-9, 2015
| [[User:Yellows8|Yellows8]]
|-
| RSA signature padding checks
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|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 here because there's proper padding check code which is executed prior to this.
|
| None
| [[9.5.0-22|9.5.0-X]]
| March 2015
| [[User:Yellows8|Yellows8]]
|-
| firmlaunch-hax: FIRM header ToCToU
| This can't be exploited from ARM11 userland.
During [[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 header was changed from a FCRAM address, to ARM9-only address 0x01fffc00.
| ARM9 code execution
| [[9.5.0-22]]
|
| 2012, 3 days after [[User:Yellows8|Yellows8]] started Process9 code RE.
| [[User:Yellows8|Yellows8]]
|-
| Uninitialized data output for (PXI) command replies
| PXI commands for various services(including some [[Filesystem_services_PXI|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.
|
| None
| [[9.3.0-21|9.3.0-X]]
| ?
| [[User:Yellows8|Yellows8]]
|-
| [[Filesystem_services_PXI|FSPXI]] OpenArchive SD permissions
| Process9 does not use the exheader ARM9 access-mount permission flag for SD at all.
This would mean ARM11-kernelmode code / fs-module itself could directly use FSPXI to access SD card without ARM9 checking for SD access, but this is rather useless since a process is usually running with SD access(Home Menu for example) anyway.
|
| None
| [[9.3.0-21|9.3.0-X]]
| 2012
| [[User:Yellows8|Yellows8]]
|-
| [[AMPXI:ExportDSiWare]] export path
| Process9 allocates memory on Process9 heap for the export path then verifies that the actual allocated size matches the input size. Then Process9 copies the input path from FCRAM to this buffer, and uses it with the Process9 FS openfile code, which use paths in the form of "<mountpoint>:/<path>".
Process9 does not check the contents of this path at all before passing it to the FS code, besides writing a NUL-terminator to the end of the buffer.
| Exporting of DSiWare to arbitrary Process9 file-paths, such as "nand:/<path>" etc. This isn't really useful since the data which gets written can't be controlled.
| None
| [[9.5.0-22]]
| April 2013
| [[User:Yellows8|Yellows8]]
|-
| [[DSiWare_Exports]] [[CTCert]] verification
| 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 console-unique cert instead(stored in NAND), while on 3DS it's still not(?) fixed.
On 3DS however this is rather useless, due to the entire DSiWare .bin being encrypted with the console-unique movable.sed keyY.
| When the movable.sed keyY for the target 3DS is known and the target 3DS CTCert private-key is unknown, importing of modified DSiWare SD .bin files.
| Unknown, probably none.
| ?
| April 2013
| [[User:Yellows8|Yellows8]]
|-
| [[Gamecard_Services_PXI]] unchecked REG_CTRCARDCNT transfer-size
| The u8 REG_CTRCARDCNT transfer-size parameter for the [[Gamecard_Services_PXI]] read/write CTRCARD commands is used as an index for an array of u16 values. Before [[5.0.0-11|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.
| [[5.0.0-11|5.0.0-X]]
|
| 2013?
| [[User:Yellows8|Yellows8]]
|-
| [[PXI_Registers|PXI]] cmdbuf buffer overrun
| The Process9 code responsible [[PXI_Registers|PXI]] communications didn't verify the size of the incoming command before writing it to a C++ member variable.
| Probably ARM9 code execution
| [[5.0.0-11|5.0.0-11]]
|
| March 2015, original timeframe if any unknown
| plutoo/[[User:Yellows8|Yellows8]]/maybe others(?)
|-
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|this]])
| 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-11|5.0.0-X]], the total combined size of the input data must be <=0x2800.
| ARM9 code execution
| [[5.0.0-11|5.0.0-X]]
|
| May 2013
| [[User:Yellows8|Yellows8]]
|-
| [[Process_Services_PXI|PS RSA]] commands buffer overflows
| pxips9 cmd1(not accessible via ps:ps) and VerifyRsaSha256: unchecked copy to a buffer in Process9's .bss, from the input FCRAM buffer. The buffer is located before the pxi cmdhandler threads' stacks. 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 [[SVC|svcBreak]].
| ARM9 code execution
| [[5.0.0-11|5.0.0-X]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| [[PXI_Registers|PXI]] pxi_id bad check
| The Process9 code responsible for [[PXI_Registers|PXI]] communications read pxi_id as a signed char. There were two flaws:
* They used it as index to a lookup-table without checking the value at all.
* Another function verified that pxi_id < 7, allowing negative values to pass the check. This would also cause an out-of-range table-lookup.
| Maybe ARM9 code execution
| [[3.0.0-5|3.0.0-5]]
|
| March 2015, originally 2012 for the first issue at least
| plutoo, [[User:Yellows8|Yellows8]], maybe others(?)
|}

=== Kernel9 ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit1 not set by Kernel9
| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]]. This leaves the [[OTP Registers|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. See [[OTP Registers|here]] regarding the data stored there.

From [[3.0.0-5|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.
| Dumping of the [[OTP Registers|OTP]] area
| [[3.0.0-5|3.0.0-X]]
|
| February 2015
| plutoo, Normmatt independently
|}

== ARM11 software ==
=== Kernel11 ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[SVC]] table too small
| 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 buffer, and interpret some ARM instructions as function pointers.

However, this would require patching the kernel .text or modifying SVC-access-control. Even if you could get these to execute, they would still jump to memory that isn't mapped as executable.
|
| None
| [[9.6.0-24|9.6.0-X]]
| 2012
| Everyone
|-
| [[SVC|svcBackdoor (0x7B)]]
| 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) requires patching the kernel .text or modifying SVC-access-control.
| See description
| None
| [[9.6.0-24|9.6.0-X]]
|
| Everyone
|-
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|0xEFF00000]] / 0xDFF00000 ARM11 kernel virtual-memory
| The ARM11 kernel-mode 0xEFF00000/0xDFF00000 virtual-memory(size 0x100000) is mapped to phys-mem 0x1FF00000(entire DSP-mem + entire AXIWRAM), with permissions RW-. This is used during ARM11 kernel startup, this never seems to be used after that, however.
|
| None
| [[9.6.0-24|9.6.0-X]]
|
|
|-
| 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-21|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 basically. When any of these checks fail, kernelpanic() is called.
| When combined with other flaws: ARM11-kernelmode code execution
| [[9.3.0-21|9.3.0-21]]
|
| February 2014
| [[User:Yellows8|Yellows8]]
|-
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs
| The ARM11-kernel did access the 'key' field of [[KLinkedListNode|KLinkedListNode]] objects, which are located on the SlabHeap, after freeing them. Thus, triggering an allocation of a new [[KLinkedListNode|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.
| ARM11-kernelmode code exec maybe
| [[8.0.0-18|8.0.0-18]]
|
| April 2015
| [[User:Derrek|derrek]]
|-
| PXI [[RPC_Command_Structure|Command]] input/output buffer permissions
| Originally the ARM11-kernel didn't check permissions for PXI input/output buffers for commands. Starting with [[6.0.0-11|6.0.0]] PXI input/output buffers must have RW permissions, otherwise kernelpanic is triggered.
|
| [[6.0.0-11|6.0.0-11]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|svcStartInterProcessDma]]
| For svcStartInterProcessDma, the kernel code had the following flaws:

* Originally the ARM11-kernel read the input DmaConfig structure directly in kernel-mode(ldr(b/h) instructions), without checking whether the DmaConfig address is readable under userland. This was fixed by copying that structure to the SVC-mode stack, using the ldrbt instruction.

* Integer overflows for srcaddr+size and dstaddr+size are now 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 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).
|
| [[6.0.0-11]]
|
| DmaConfig issue: unknown. The rest: 2014
| plutoo, [[User:Yellows8|Yellows8]] independently
|-
| [[SVC|svcControlMemory]] Parameter checks
| For svcControlMemory the parameter check had these two flaws:

* The allowed range for addr0, addr1, size parameters depends on which MemoryOperation is being specified. The limitation for GSP heap was only checked if op=(u32)0x10003. By setting a random bit in op that has no meaning (like bit17?), op would instead be (u32)0x30003, and the range-check would be less strict and not accurate. However, the kernel doesn't actually use the input address for LINEAR memory-mapping at all besides the range-checks, so this isn't actually useful. This was fixed in the kernel by just checking for the LINEAR bit, instead of comparing the entire MemoryOperation value with 0x10003.

* Integer overflows on (addr0+size) are now checked that previously weren't (this also applies to most other address checks elsewhere in the kernel).

|
| [[5.0.0-11]]
|
|
| plutoo
|-
| [[RPC_Command_Structure|Command]] request/response buffer overflow
| 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 threadlocalstorage+0x180 in the destination thread. However, since the data written there would be translate parameters (such as header-words + buffer addresses), exploiting this would likely be very difficult, if possible at all.

If the two words at threadlocalstorage+0x180 could be overwritten with controlled data this way, one could then use a command with a buffer-header of <nowiki>((size<<14) | 2)</nowiki> to write arbitrary memory to any RW userland memory in the destination process.
|
| [[5.0.0-11]]
|
| v4.1 FIRM -> v5.0 code diff
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|SVC stack allocation overflows]]
|
* Syscalls that allocate a variable-length array on stack, only checked bit31 before multiplying by 4/16 (when calculating how much memory to allocate). If a large integer was passed as input to one of these syscalls, an integer overflow would occur, and too little memory would have been allocated on stack resulting in a buffer overrun.
* The alignment (size+7)&~7 calculation before allocation was not checked for integer overflow.

This might allow for ARM11 kernel code-execution.

(Applies to svcSetResourceLimitValues, svcGetThreadList, svcGetProcessList, svcReplyAndReceive, svcWaitSynchronizationN.)
|
| [[5.0.0-11]]
|
| v4.1 FIRM -> v5.0 code diff
| plutoo, [[User:Yellows8|Yellows8]] complementary
|-
| [[SVC|svcControlMemory]] MemoryOperation MAP memory-permissions
| svcControlMemory with MemoryOperation=MAP allows mapping the already-mapped process virtual-mem at addr1, to addr0. The lowest address permitted for addr1 is 0x00100000. Originally the ARM11 kernel didn't check memory permissions for addr1. Therefore .text as addr1 could be mapped elsewhere as RW- memory, which allowed ARM11 userland code-execution.
|
| [[4.1.0-8]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| [[RPC_Command_Structure|Command]] input/output buffer permissions
| 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.
|
| [[4.0.0-7]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|svcReadProcessMemory/svcWriteProcessMemory memory]] permissions
| Originally the kernel only checked the first page(0x1000-bytes) of the src/dst buffers, for svcReadProcessMemory and svcWriteProcessMemory. There is no known retail processes which have access to these SVCs.
|
| [[4.0.0-7]]
|
| 2012?
| [[User:Yellows8|Yellows8]]
|}

=== [[FIRM]] Sysmodules ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[Services|"srv:pm"]] process registration
| 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]] 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.

This flaw was needed for exploiting the <=v4.x Process9 PXI vulnerabilities from ARM11 userland ROP, since most applications don't have access to those service(s).
| Access to arbitrary services
| [[7.0.0-13]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| FSDIR null-deref
| [[Filesystem_services|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.
|
| None
| [[9.6.0-24|9.6.0-X]]
| May 19(?)-20, 2015
| [[User:Yellows8|Yellows8]]
|}

=== Standalone Sysmodules ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system-module system-version
! Last system-module system-version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[SPI_Services|SPI]] service out-of-bounds write
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.
|
| None
| [[9.5.0-22]]
| March 2015
| plutoo
|-
| [[NFC_Services|NFC]] module service command buf-overflows
| NFC module copies data with certain commands, from command input buffers to stack without checking the size. These commands include the following, it's unknown if there's more commands with similar issues: "nfc:dev" <0x000C....> and "nfc:s" <0x0037....>.
Since both of these commands are stubbed in the Old3DS NFC module from the very first version(those just return an error), these issues only affect the New3DS NFC module.

There's no known retail titles which have access to either of these services.
| ROP under NFC module.
| New3DS: None
| New3DS: [[9.5.0-22]]
| December 2014?
| [[User:Yellows8|Yellows8]]
|-
| [[News_Services|NEWSS]] service command notificationID validation failure
| This module does not validate the input notificationID for <nowiki>"news:s"</nowiki> 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).
| ROP under news module.
| None
| [[9.7.0-25|9.7.0-X]]
| December 2014
| [[User:Yellows8|Yellows8]]
|-
| [[HID_Services|HID]] module shared-mem
| HID module does not validate the index values in [[HID_Shared_Memory|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.
| None
| [[9.3.0-21]]
| 2014?
| [[User:Yellows8|Yellows8]]
|-
| gspwn
| GSP module does not validate addresses given to the GPU. This 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 located beyond the area accessible by the GPU, except for [[RO_Services|CROs]] used by applets([[Internet Browser]] for example).

FCRAM is gpu-accessible up to physaddr 0x26400000 on Old3DS, and 0x2DC00000 on New3DS.
| User-mode code execution.
| None
| [[9.6.0-24|9.6.0-X]]
| Early 2014
| smea, [[User:Yellows8|Yellows8]]/others before then
|-
| rohax
| 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 [[SVC|syscalls]] 0x70-0x72, 0x7D.

This was fixed after [[ninjhax]] release by adding checks on [[CRO0]]-based pointers before writing to them.
| Memory-mapping syscalls.
| [[9.3.0-21]]
| [[9.4.0-21]]
|
| smea, plutoo joint effort
|-
| Region free
| Only [[Home Menu]] itself checks gamecards' region when launching them. Therefore, any application 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_and_APT_Services|"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 [[NSS:RebootSystem|reboot]].
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation
| None
| [[9.8.0-25|9.8.0-X]]
| June(?) 2014
| [[User:Yellows8|Yellows8]]
|-
| [[NWM_Services|NWM]] service-cmd state null-ptr deref
| 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 command-handler function. The value of the ptr loaded from .data is not checked, therefore this will cause crashes due to that being 0x0 when NWMUDS was not properly initialized.
It's unknown whether any NWM services besides NWMUDS have this issue.
| This is rather useless since it's only a crash caused by a state ptr based at 0x0.
| None
| [[9.0.0-20]]
| 2013?
| [[User:Yellows8|Yellows8]]
|}

=== General/CTRSDK ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in version
! Last version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[NWM_Services|UDS]] beacon additional-data buffer overflow
| Originally CTRSDK did not validate the UDS additional-data size before using that size to copy the additional-data to a [[NWM_Services|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 version.

It's unknown if there's any titles using a vulnerable CTRSDK version which are also exploitable with this(dlp module can't be exploited with this).

The maximum number of bytes that can be written beyond the end of the outbuf is 0x37-bytes, with additionaldata_size=0xFF.
| Perhaps ROP, very difficult if possible with anything at all
| ?
|
| September(?) 2014
| [[User:Yellows8|Yellows8]]
|}

3DS System Flaws

2015-07-26T05:49:38Z

Vague Rant: Restore from Google cache.

Exploits are used to execute unofficial code (homebrew) on the Nintendo 3DS. This page is a list of publicly known system flaws, for userland applications/applets flaws see [[3DS_Userland_Flaws|here]].

=Stale / Rejected Efforts=
* Neimod has been working on a RAM dumping setup for a little while now. He's de-soldered the 3DS's RAM chip and hooked it and the RAM pinouts on the 3DS' PCB up to a custom RAM dumping setup. A while ago he published photos showing his setup to be working quite well, with the 3DS successfully booting up. However, his flickr stream is now private along with most of his work.

* Someone (who will remain unnamed) has released CFW and CIA installers, all of which is copied from the work of others, or copyrighted material.

==Tips and info==
The 3DS uses the XN feature of the ARM11 processor. There's no official way from applications to enable executable permission for memory containing arbitrary unsigned code(there's a [[SVC]] for this, but only [[RO_Services|RO-module]] has access to it). An usable userland exploit would still be useful: you could only do return-oriented-programming with it initially. From ROP one could then exploit system flaw(s), see below.

SD card [[extdata]] and SD savegames can be attacked, for consoles where the console-unique [[Nand/private/movable.sed|movable.sed]] was dumped(accessing SD data is far easier by running code on the target 3DS however).

=System flaws=
== Hardware ==
{| class="wikitable" border="1"
! Summary
! Description
! Fixed with hardware model/revision
! Newest hardware model/revision this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| ARM9/ARM11 bootrom vectors point at unitialized RAM
| ARM9's and ARM11's exception vectors are hardcoded to point at the CPU's internal memory (0x08000000 region for ARM9, AXIWRAM for ARM11). While the bootrom does set them up to point to an endless loop at some point during boot, it does not do so immediately. As such, a carefully-timed fault injection (via hardware) to trigger an exception (such as an invalid instruction) will cause execution to fall into ARM9 RAM.
Since RAM isn't cleared on boot (see below), one can immediately start execution of their own code here to dump bootrom, OTP, etc.
The ARM9 bootrom does the following at reset: reset vector branches to another instruction, then branches to bootrom+0x8000. Hence, there's no way to know for certain when exactly the ARM9 exception-vector data stored in memory gets initialized.

This requires *very* *precise* timing for triggering the hardware fault: it's unknown if anyone actually exploited this successfully at the time of writing(the one who attempted+discovered it *originally* as listed in this wiki section hasn't).
| None: all available 3DS models at the time of writing have the exact same ARM9/ARM11 bootrom for the unprotected areas.
| New3DS
| End of February 2014
| [[User:Derrek|derrek]], WulfyStylez (May 2015) independently
|-
| Missing AES key clearing
| The hardware AES engine does not clear keys when doing a hard reset/reboot.
| None
| New3DS
| August 2014
| Mathieulh/Others
|-
| No RAM clearing on reboots
| On an MCU-triggered reboot all RAM including FCRAM/ARM9 memory/AXIWRAM keeps its contents.
| None
| New3DS
| March 2014
| [[User:Derrek|derrek]]
|-
| 32bits of actual console-unique TWLNAND keydata
| On retail the 8-bytes at ARM9 address [[Memory_layout|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 of this, the lower u32's highest bit is always ORed. only 31 bits of the TWL console-unique keydata / TWL consoleID are actually console-unique.
This allows one to easily bruteforce the TWL console-unique keydata with *just* data from TWLNAND. On DSi the actual console-unique data for key generation is 8-bytes(all bytes actually set).
| None
| New3DS
| 2012?
| [[User:Yellows8|Yellows8]]
|-
| DSi / 3DS-TWL key-generator
| After using the key generator to generate the normal-key, you could overwrite parts of the normal-key with your own data and then recover the key-generator output by comparing the new crypto output with the original crypto output. From the normal-key outputs, you could deduce the TWL key-generator function.
This applies to the keyX/keyY too.

This attack does not work for the 3DS key-generator because keyslots 0-3 are only for TWL keys.
|
|
| 2011
| [[User:Yellows8|Yellows8]]
|}

== ARM9 software ==
=== arm9loader ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| Missing verification-block for the 9.6 keys
| Starting with [[9.6.0-24|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-22|9.5.0-X]] with the original sector+0 keydata, however the below is only possible with [[9.6.0-24|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 ARM9 kernel as garbage and then jump to it.

This allows an hardware-based attack where you can boot into an older exploited firmware, fill all memory with NOP sleds/jump-instructions, and then reboot into executing garbage. By automating this process with various input keydata, eventually you'll find some garbage that jumps to your code.

This should give very early ARM9 code execution (pre-ARM9 kernel). As such, it is possible to dump RSA keyslots with this and calculate the 6.x [[Savegames#6.0.0-11_Savegame_keyY|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.

Due to FIRMs on both Old and New 3DS using the same RSA data, this 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.
| Recovery of 6.x [[Savegames#6.0.0-11_Savegame_keyY|save key]]/7.x [[NCCH]] key
| None
| [[9.6.0-24|9.6.0-X]]
| March, 2015
| plutoo
|-
| Uncleared New3DS keyslot 0x11
| Originally the New3DS [[FIRM]] arm9bin loader only cleared keyslot 0x11 when it gets executed at firmlaunch. This was fixed with [[9.5.0-22|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 at firmlaunch(including firmlaunch-hax) can get access to the uncleared 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-24|9.6.0-X]].
| New3DS keyXs generation
| Mostly fixed with [[9.5.0-22|9.5.0-X]], completely fixed with new keys with [[9.6.0-24|9.6.0-X]].
|
| February 3, 2015 (one day after [[9.5.0-22|9.5.0-X]] release)
| [[User:Yellows8|Yellows8]]
|}

=== Process9 ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| FAT FS code null-deref
| When FSFile:Read is used with a file which is corrupted on a FAT filesystem(in particular SD), Process9 can crash. This particular crash is caused by a function returning NULL instead of an actual ptr due to an error. The caller of that function doesn't check for NULL which then triggers a read based at NULL.

Sample "fsck.vfat -n -v -V <fat image backup>" output for the above crash:

<pre>...
Starting check/repair pass.
<FilePath0> and
<FilePath1>
share clusters.
Truncating second to 3375104 bytes.
<FilePath1>
File size is 2787392 bytes, cluster chain length is 16384 bytes.
Truncating file to 16384 bytes.
Checking for unused clusters.
Reclaimed 1 unused cluster (16384 bytes).
Checking free cluster summary.
Free cluster summary wrong (1404490 vs. really 1404491)
Auto-correcting.
Starting verification pass.
Checking for unused clusters.
Leaving filesystem unchanged.</pre>
| Useless null-based-read
| None
| 9.6.0-X
| July 8-9, 2015
| [[User:Yellows8|Yellows8]]
|-
| RSA signature padding checks
| The TWL_FIRM RSA sig padding check code used for all TWL RSA sig-checks has issues, see [[FIRM|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 here because there's proper padding check code which is executed prior to this.
|
| None
| [[9.5.0-22|9.5.0-X]]
| March 2015
| [[User:Yellows8|Yellows8]]
|-
| firmlaunch-hax: FIRM header ToCToU
| This can't be exploited from ARM11 userland.
During [[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 header was changed from a FCRAM address, to ARM9-only address 0x01fffc00.
| ARM9 code execution
| [[9.5.0-22]]
|
| 2012, 3 days after [[User:Yellows8|Yellows8]] started Process9 code RE.
| [[User:Yellows8|Yellows8]]
|-
| Uninitialized data output for (PXI) command replies
| PXI commands for various services(including some [[Filesystem_services_PXI|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.
|
| None
| [[9.3.0-21|9.3.0-X]]
| ?
| [[User:Yellows8|Yellows8]]
|-
| [[Filesystem_services_PXI|FSPXI]] OpenArchive SD permissions
| Process9 does not use the exheader ARM9 access-mount permission flag for SD at all.
This would mean ARM11-kernelmode code / fs-module itself could directly use FSPXI to access SD card without ARM9 checking for SD access, but this is rather useless since a process is usually running with SD access(Home Menu for example) anyway.
|
| None
| [[9.3.0-21|9.3.0-X]]
| 2012
| [[User:Yellows8|Yellows8]]
|-
| [[AMPXI:ExportDSiWare]] export path
| Process9 allocates memory on Process9 heap for the export path then verifies that the actual allocated size matches the input size. Then Process9 copies the input path from FCRAM to this buffer, and uses it with the Process9 FS openfile code, which use paths in the form of "<mountpoint>:/<path>".
Process9 does not check the contents of this path at all before passing it to the FS code, besides writing a NUL-terminator to the end of the buffer.
| Exporting of DSiWare to arbitrary Process9 file-paths, such as "nand:/<path>" etc. This isn't really useful since the data which gets written can't be controlled.
| None
| [[9.5.0-22]]
| April 2013
| [[User:Yellows8|Yellows8]]
|-
| [[DSiWare_Exports]] [[CTCert]] verification
| 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 console-unique cert instead(stored in NAND), while on 3DS it's still not(?) fixed.
On 3DS however this is rather useless, due to the entire DSiWare .bin being encrypted with the console-unique movable.sed keyY.
| When the movable.sed keyY for the target 3DS is known and the target 3DS CTCert private-key is unknown, importing of modified DSiWare SD .bin files.
| Unknown, probably none.
| ?
| April 2013
| [[User:Yellows8|Yellows8]]
|-
| [[Gamecard_Services_PXI]] unchecked REG_CTRCARDCNT transfer-size
| The u8 REG_CTRCARDCNT transfer-size parameter for the [[Gamecard_Services_PXI]] read/write CTRCARD commands is used as an index for an array of u16 values. Before [[5.0.0-11|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.
| [[5.0.0-11|5.0.0-X]]
|
| 2013?
| [[User:Yellows8|Yellows8]]
|-
| [[PXI_Registers|PXI]] cmdbuf buffer overrun
| The Process9 code responsible [[PXI_Registers|PXI]] communications didn't verify the size of the incoming command before writing it to a C++ member variable.
| Probably ARM9 code execution
| [[5.0.0-11|5.0.0-11]]
|
| March 2015, original timeframe if any unknown
| plutoo/[[User:Yellows8|Yellows8]]/maybe others(?)
|-
| [[Application_Manager_Services_PXI|PXIAM]] command 0x003D0108(See also [[Application_Manager_Services|this]])
| 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-11|5.0.0-X]], the total combined size of the input data must be <=0x2800.
| ARM9 code execution
| [[5.0.0-11|5.0.0-X]]
|
| May 2013
| [[User:Yellows8|Yellows8]]
|-
| [[Process_Services_PXI|PS RSA]] commands buffer overflows
| pxips9 cmd1(not accessible via ps:ps) and VerifyRsaSha256: unchecked copy to a buffer in Process9's .bss, from the input FCRAM buffer. The buffer is located before the pxi cmdhandler threads' stacks. 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 [[SVC|svcBreak]].
| ARM9 code execution
| [[5.0.0-11|5.0.0-X]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| [[PXI_Registers|PXI]] pxi_id bad check
| The Process9 code responsible for [[PXI_Registers|PXI]] communications read pxi_id as a signed char. There were two flaws:
* They used it as index to a lookup-table without checking the value at all.
* Another function verified that pxi_id < 7, allowing negative values to pass the check. This would also cause an out-of-range table-lookup.
| Maybe ARM9 code execution
| [[3.0.0-5|3.0.0-5]]
|
| March 2015, originally 2012 for the first issue at least
| plutoo, [[User:Yellows8|Yellows8]], maybe others(?)
|}

=== Kernel9 ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]] bit1 not set by Kernel9
| Old versions of Kernel9 never set bit1 of [[CONFIG Registers#CFG_SYSPROT9|CFG_SYSPROT9]]. This leaves the [[OTP Registers|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. See [[OTP Registers|here]] regarding the data stored there.

From [[3.0.0-5|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.
| Dumping of the [[OTP Registers|OTP]] area
| [[3.0.0-5|3.0.0-X]]
|
| February 2015
| plutoo, Normmatt independently
|}

== ARM11 software ==
=== Kernel11 ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[SVC]] table too small
| 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 buffer, and interpret some ARM instructions as function pointers.

However, this would require patching the kernel .text or modifying SVC-access-control. Even if you could get these to execute, they would still jump to memory that isn't mapped as executable.
|
| None
| [[9.6.0-24|9.6.0-X]]
| 2012
| Everyone
|-
| [[SVC|svcBackdoor (0x7B)]]
| 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) requires patching the kernel .text or modifying SVC-access-control.
| See description
| None
| [[9.6.0-24|9.6.0-X]]
|
| Everyone
|-
| [[Memory_layout#ARM11_Detailed_virtual_memory_map|0xEFF00000]] / 0xDFF00000 ARM11 kernel virtual-memory
| The ARM11 kernel-mode 0xEFF00000/0xDFF00000 virtual-memory(size 0x100000) is mapped to phys-mem 0x1FF00000(entire DSP-mem + entire AXIWRAM), with permissions RW-. This is used during ARM11 kernel startup, this never seems to be used after that, however.
|
| None
| [[9.6.0-24|9.6.0-X]]
|
|
|-
| 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-21|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 basically. When any of these checks fail, kernelpanic() is called.
| When combined with other flaws: ARM11-kernelmode code execution
| [[9.3.0-21|9.3.0-21]]
|
| February 2014
| [[User:Yellows8|Yellows8]]
|-
| Multiple [[KLinkedListNode|KLinkedListNode]] SlabHeap use after free bugs
| The ARM11-kernel did access the 'key' field of [[KLinkedListNode|KLinkedListNode]] objects, which are located on the SlabHeap, after freeing them. Thus, triggering an allocation of a new [[KLinkedListNode|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.
| ARM11-kernelmode code exec maybe
| [[8.0.0-18|8.0.0-18]]
|
| April 2015
| [[User:Derrek|derrek]]
|-
| PXI [[RPC_Command_Structure|Command]] input/output buffer permissions
| Originally the ARM11-kernel didn't check permissions for PXI input/output buffers for commands. Starting with [[6.0.0-11|6.0.0]] PXI input/output buffers must have RW permissions, otherwise kernelpanic is triggered.
|
| [[6.0.0-11|6.0.0-11]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|svcStartInterProcessDma]]
| For svcStartInterProcessDma, the kernel code had the following flaws:

* Originally the ARM11-kernel read the input DmaConfig structure directly in kernel-mode(ldr(b/h) instructions), without checking whether the DmaConfig address is readable under userland. This was fixed by copying that structure to the SVC-mode stack, using the ldrbt instruction.

* Integer overflows for srcaddr+size and dstaddr+size are now 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 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).
|
| [[6.0.0-11]]
|
| DmaConfig issue: unknown. The rest: 2014
| plutoo, [[User:Yellows8|Yellows8]] independently
|-
| [[SVC|svcControlMemory]] Parameter checks
| For svcControlMemory the parameter check had these two flaws:

* The allowed range for addr0, addr1, size parameters depends on which MemoryOperation is being specified. The limitation for GSP heap was only checked if op=(u32)0x10003. By setting a random bit in op that has no meaning (like bit17?), op would instead be (u32)0x30003, and the range-check would be less strict and not accurate. However, the kernel doesn't actually use the input address for LINEAR memory-mapping at all besides the range-checks, so this isn't actually useful. This was fixed in the kernel by just checking for the LINEAR bit, instead of comparing the entire MemoryOperation value with 0x10003.

* Integer overflows on (addr0+size) are now checked that previously weren't (this also applies to most other address checks elsewhere in the kernel).

|
| [[5.0.0-11]]
|
|
| plutoo
|-
| [[RPC_Command_Structure|Command]] request/response buffer overflow
| 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 threadlocalstorage+0x180 in the destination thread. However, since the data written there would be translate parameters (such as header-words + buffer addresses), exploiting this would likely be very difficult, if possible at all.

If the two words at threadlocalstorage+0x180 could be overwritten with controlled data this way, one could then use a command with a buffer-header of <nowiki>((size<<14) | 2)</nowiki> to write arbitrary memory to any RW userland memory in the destination process.
|
| [[5.0.0-11]]
|
| v4.1 FIRM -> v5.0 code diff
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|SVC stack allocation overflows]]
|
* Syscalls that allocate a variable-length array on stack, only checked bit31 before multiplying by 4/16 (when calculating how much memory to allocate). If a large integer was passed as input to one of these syscalls, an integer overflow would occur, and too little memory would have been allocated on stack resulting in a buffer overrun.
* The alignment (size+7)&~7 calculation before allocation was not checked for integer overflow.

This might allow for ARM11 kernel code-execution.

(Applies to svcSetResourceLimitValues, svcGetThreadList, svcGetProcessList, svcReplyAndReceive, svcWaitSynchronizationN.)
|
| [[5.0.0-11]]
|
| v4.1 FIRM -> v5.0 code diff
| plutoo, [[User:Yellows8|Yellows8]] complementary
|-
| [[SVC|svcControlMemory]] MemoryOperation MAP memory-permissions
| svcControlMemory with MemoryOperation=MAP allows mapping the already-mapped process virtual-mem at addr1, to addr0. The lowest address permitted for addr1 is 0x00100000. Originally the ARM11 kernel didn't check memory permissions for addr1. Therefore .text as addr1 could be mapped elsewhere as RW- memory, which allowed ARM11 userland code-execution.
|
| [[4.1.0-8]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| [[RPC_Command_Structure|Command]] input/output buffer permissions
| 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.
|
| [[4.0.0-7]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| [[SVC|svcReadProcessMemory/svcWriteProcessMemory memory]] permissions
| Originally the kernel only checked the first page(0x1000-bytes) of the src/dst buffers, for svcReadProcessMemory and svcWriteProcessMemory. There is no known retail processes which have access to these SVCs.
|
| [[4.0.0-7]]
|
| 2012?
| [[User:Yellows8|Yellows8]]
|}

=== [[FIRM]] Sysmodules ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in [[FIRM]] system version
! Last [[FIRM]] system version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[Services|"srv:pm"]] process registration
| 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]] 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.

This flaw was needed for exploiting the <=v4.x Process9 PXI vulnerabilities from ARM11 userland ROP, since most applications don't have access to those service(s).
| Access to arbitrary services
| [[7.0.0-13]]
|
| 2012
| [[User:Yellows8|Yellows8]]
|-
| FSDIR null-deref
| [[Filesystem_services|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.
|
| None
| [[9.6.0-24|9.6.0-X]]
| May 19(?)-20, 2015
| [[User:Yellows8|Yellows8]]
|}

=== Standalone Sysmodules ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in system-module system-version
! Last system-module system-version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[SPI_Services|SPI]] service out-of-bounds write
| cmd1 has out-of-bounds write allowing overwrite of some static variables in .data.
|
| None
| [[9.5.0-22]]
| March 2015
| plutoo
|-
| [[NFC_Services|NFC]] module service command buf-overflows
| NFC module copies data with certain commands, from command input buffers to stack without checking the size. These commands include the following, it's unknown if there's more commands with similar issues: "nfc:dev" <0x000C....> and "nfc:s" <0x0037....>.
Since both of these commands are stubbed in the Old3DS NFC module from the very first version(those just return an error), these issues only affect the New3DS NFC module.

There's no known retail titles which have access to either of these services.
| ROP under NFC module.
| New3DS: None
| New3DS: [[9.5.0-22]]
| December 2014?
| [[User:Yellows8|Yellows8]]
|-
| [[News_Services|NEWSS]] service command notificationID validation failure
| This module does not validate the input notificationID for <nowiki>"news:s"</nowiki> 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).
| ROP under news module.
| None
| [[9.7.0-25|9.7.0-X]]
| December 2014
| [[User:Yellows8|Yellows8]]
|-
| [[HID_Services|HID]] module shared-mem
| HID module does not validate the index values in [[HID_Shared_Memory|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.
| None
| [[9.3.0-21]]
| 2014?
| [[User:Yellows8|Yellows8]]
|-
| gspwn
| GSP module does not validate addresses given to the GPU. This 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 located beyond the area accessible by the GPU, except for [[RO_Services|CROs]] used by applets([[Internet Browser]] for example).

FCRAM is gpu-accessible up to physaddr 0x26400000 on Old3DS, and 0x2DC00000 on New3DS.
| User-mode code execution.
| None
| [[9.6.0-24|9.6.0-X]]
| Early 2014
| smea, [[User:Yellows8|Yellows8]]/others before then
|-
| rohax
| 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 [[SVC|syscalls]] 0x70-0x72, 0x7D.

This was fixed after [[ninjhax]] release by adding checks on [[CRO0]]-based pointers before writing to them.
| Memory-mapping syscalls.
| [[9.3.0-21]]
| [[9.4.0-21]]
|
| smea, plutoo joint effort
|-
| Region free
| Only [[Home Menu]] itself checks gamecards' region when launching them. Therefore, any application 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_and_APT_Services|"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 [[NSS:RebootSystem|reboot]].
| Launching gamecards from any region + bypassing Home Menu gamecard-sysupdate installation
| None
| [[9.8.0-25|9.8.0-X]]
| June(?) 2014
| [[User:Yellows8|Yellows8]]
|-
| [[NWM_Services|NWM]] service-cmd state null-ptr deref
| 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 command-handler function. The value of the ptr loaded from .data is not checked, therefore this will cause crashes due to that being 0x0 when NWMUDS was not properly initialized.
It's unknown whether any NWM services besides NWMUDS have this issue.
| This is rather useless since it's only a crash caused by a state ptr based at 0x0.
| None
| [[9.0.0-20]]
| 2013?
| [[User:Yellows8|Yellows8]]
|}

=== General/CTRSDK ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Successful exploitation result
! Fixed in version
! Last version this flaw was checked for
! Timeframe this was discovered
! Discovered by
|-
| [[NWM_Services|UDS]] beacon additional-data buffer overflow
| Originally CTRSDK did not validate the UDS additional-data size before using that size to copy the additional-data to a [[NWM_Services|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 version.

It's unknown if there's any titles using a vulnerable CTRSDK version which are also exploitable with this(dlp module can't be exploited with this).

The maximum number of bytes that can be written beyond the end of the outbuf is 0x37-bytes, with additionaldata_size=0xFF.
| Perhaps ROP, very difficult if possible with anything at all
| ?
|
| September(?) 2014
| [[User:Yellows8|Yellows8]]
|}

FirmwareNews

2015-07-26T05:12:30Z

Vague Rant: Restore from Google cache.

From '''4.0.0-X''' up to and including '''9.2.0-X''' are safe for [[ninjhax]], if '''X''' is between 7 and 20.
ARM11 userland homebrew is possible with [[ninjhax]] 2 from system versions '''9.0.0-X''' up to and including '''9.9.0-X''', for '''X''' up to and including '''26'''.

Full system control exploits are only known for system versions up to and including '''9.2.0'''.

Ninjhax

2015-07-26T05:08:13Z

Vague Rant: /* Installation */ success

ninjhax is an exploit by smea for the game Cubic Ninja. It was released on November 20th, 2014. It can be used on all 3DS firmware versions from 4.0 up to and including 9.2.0-20. It was partially patched in [[9.3.0-21|9.3.0-X]] (only system flaws used by ninjhax were fixed, the game haxx itself was not affected).

ninjhax 2 was released on 18 July 2015, and works on any system version from 9.0.0-X up to 9.9.0-26.

When triggered, it will boot a [[3DSX_Format | 3dsx-file]] from the sdcard root called "boot.3dsx". This file is usually the [[Homebrew Launcher]], which in turn can be used to launch other games/apps from the (micro)SD card. The launched application will run with user privileges on the ARM11 CPU. On system versions up to 9.2.0-20, one of the publicly known [[3DS System Flaws]] can be chained to gain ARM11 kernel privileges or to take control over the ARM9 CPU. More recent system versions are limited to ARM11 userland homebrew until new exploits are disclosed.

==Installation==

Visit [http://smealum.net/ninjhax/ here] for instructions on how to install Ninjhax, and [http://smealum.github.io/ninjhax2/ here] for instructions on how to install Ninjhax 2!

==Service access==

ninjhax gives developers access to a number of services. These include :

* ac:u
* APT:U
* boss:U
* cam:u
* cecd:u
* cfg:u
* dlp:FKCL
* dlp:SRVR
* dsp::DSP
* frd:u
* fs:USER
* gsp::Gpu
* hid:USER
* http:C
* ir:u
* mic:u
* ndm:u
* <nowiki>news:u</nowiki>
* nwm::UDS
* ptm:u
* pxi:dev
* soc:U
* ssl:C
* y2r:u

Additionally, Old 3DS models (3DS, 3DS XL and 2DS) are given access to the following :

* csnd:SND

In contrast, New 3DS models (New 3DS, New 3DS XL) get access to :

* am:app
* ir:rst
* l2b2:u
* l2b:u
* mvd:STD
* nim:aoc
* y2r2:u

The normal service used for accessing [[Circle Pad Pro]] is not accessible: [[IR_Services|ir:USER]].

==System Call Access==

The following [[SVC|system calls]] are usable by homebrew running using ninjhax:

Allowed systemcalls: 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08
0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x10
0x11, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19
0x1A, 0x1B, 0x1C, 0x1D, 0x1E, 0x1F, 0x20, 0x21
0x22, 0x23, 0x24, 0x25, 0x27, 0x28, 0x29, 0x2A
0x2B, 0x2C, 0x2D, 0x2E, 0x2F, 0x30, 0x31, 0x32
0x35, 0x36, 0x37, 0x38, 0x39, 0x3A, 0x3B, 0x3C
0x3D

==Limitations==

At the moment, ninjhax only allows users to access 64MB of RAM, including on the New 3DS. This may change in the future.

While sound works on the New 3DS for homebrew running via ninjhax 2.0, at the time of the exploit's original release, there was no good way to use the DSP from homebrew, so sound output is not possible on the New 3DS using the old version. At the moment, there is also no known way of running code on the New 3DS's extra CPU cores under ninjhax, though it is possible to use 80% of the system core's time using [[APT:SetApplicationCpuTimeLimit]] rather than 30% as was the case on the Old 3DS.

==Capabilities==
* All SD and NAND [[extdata]] is accessible via the main extdata [[FS:OpenArchive|archive]](R/W). Note that the [[FS:OpenArchive|ExtSaveData-for-BOSS]] archive is not accessible.

Ninjhax

2015-07-26T05:07:32Z

Vague Rant: Restore from Google cache.

ninjhax is an exploit by smea for the game Cubic Ninja. It was released on November 20th, 2014. It can be used on all 3DS firmware versions from 4.0 up to and including 9.2.0-20. It was partially patched in [[9.3.0-21|9.3.0-X]] (only system flaws used by ninjhax were fixed, the game haxx itself was not affected).

ninjhax 2 was released on 18 July 2015, and works on any system version from 9.0.0-X up to 9.9.0-26.

When triggered, it will boot a [[3DSX_Format | 3dsx-file]] from the sdcard root called "boot.3dsx". This file is usually the [[Homebrew Launcher]], which in turn can be used to launch other games/apps from the (micro)SD card. The launched application will run with user privileges on the ARM11 CPU. On system versions up to 9.2.0-20, one of the publicly known [[3DS System Flaws]] can be chained to gain ARM11 kernel privileges or to take control over the ARM9 CPU. More recent system versions are limited to ARM11 userland homebrew until new exploits are disclosed.

==Installation==

Visit [http://smealum.net/ninjhax/ here] for instructions on how to install Ninjhax, and [http://smealum.github.io/ninjhax2/ here]  for instructions on how to install Ninjhax 2!

==Service access==

ninjhax gives developers access to a number of services. These include :

* ac:u
* APT:U
* boss:U
* cam:u
* cecd:u
* cfg:u
* dlp:FKCL
* dlp:SRVR
* dsp::DSP
* frd:u
* fs:USER
* gsp::Gpu
* hid:USER
* http:C
* ir:u
* mic:u
* ndm:u
* <nowiki>news:u</nowiki>
* nwm::UDS
* ptm:u
* pxi:dev
* soc:U
* ssl:C
* y2r:u

Additionally, Old 3DS models (3DS, 3DS XL and 2DS) are given access to the following :

* csnd:SND

In contrast, New 3DS models (New 3DS, New 3DS XL) get access to :

* am:app
* ir:rst
* l2b2:u
* l2b:u
* mvd:STD
* nim:aoc
* y2r2:u

The normal service used for accessing [[Circle Pad Pro]] is not accessible: [[IR_Services|ir:USER]].

==System Call Access==

The following [[SVC|system calls]] are usable by homebrew running using ninjhax:

Allowed systemcalls: 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08
0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F, 0x10
0x11, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19
0x1A, 0x1B, 0x1C, 0x1D, 0x1E, 0x1F, 0x20, 0x21
0x22, 0x23, 0x24, 0x25, 0x27, 0x28, 0x29, 0x2A
0x2B, 0x2C, 0x2D, 0x2E, 0x2F, 0x30, 0x31, 0x32
0x35, 0x36, 0x37, 0x38, 0x39, 0x3A, 0x3B, 0x3C
0x3D

==Limitations==

At the moment, ninjhax only allows users to access 64MB of RAM, including on the New 3DS. This may change in the future.

While sound works on the New 3DS for homebrew running via ninjhax 2.0, at the time of the exploit's original release, there was no good way to use the DSP from homebrew, so sound output is not possible on the New 3DS using the old version. At the moment, there is also no known way of running code on the New 3DS's extra CPU cores under ninjhax, though it is possible to use 80% of the system core's time using [[APT:SetApplicationCpuTimeLimit]] rather than 30% as was the case on the Old 3DS.

==Capabilities==
* All SD and NAND [[extdata]] is accessible via the main extdata [[FS:OpenArchive|archive]](R/W). Note that the [[FS:OpenArchive|ExtSaveData-for-BOSS]] archive is not accessible.