3dbrew - User contributions [en]

3DS System Flaws

2014-11-03T04:05:34Z

Irocktolive7:

Exploits are used to execute unofficial code (homebrew) on the Nintendo 3DS. This page is a list of known 3DS-mode exploits.

==List of 3DS exploits==

==Current Efforts==
There are people working on finding exploits and documenting the 3DS. Here's a list of some current efforts being made to make homebrew on the 3DS possible:

* Smealum has a working exploit up to newest system version and has shown what seems to be viable proof that this is real. He says that he will be releasing the exploit when he believes all of the bundled software (HBC and others) are relatively bug free. In other words NO ETA.

==Stale / Rejected Efforts==
* Neimod has been working on a RAM dumping setup for a little while now. He's desoldered the 3DS's RAM chip and hooked it and the RAM pinouts on the 3DS's PCB up to a custom RAM dumping setup. Recent photos show that the setup is working quite well, with the 3DS successfully booting up. Pictures of neimod's work can be found on [http://www.flickr.com/photos/neimod/ his Flickr stream].

Neimod's flickr stream is now private and his work is considered stale

* Govanify has released CFW and CIA installers along with some other interesting stuff (and illegal stuff) most of which were created by others and stolen

== Fixed vulnerabilities ==
* The following was fixed with [[7.0.0-13]], see here for [[7.0.0-13|details]]. Too long or corrupted strings (01Ah 2 Nickname length in characters 050h 2 Message length in characters) in the NVRAM DS user settings cause (System Settings->Other Settings->Profile->Nintendo DS Profile) to crash in 3DS-mode due to a stack-smash. The DSi is not vulnerable to this, DSi launcher(menu) and DSi System Settings will reset the NVRAM user-settings if the length field values are too long(same result as when the CRCs are invalid).

==Failed attempts==
Here are listed all attempts at exploiting 3DS software that have failed so far.

* Pushmo (3DSWare), QR codes: level name is properly limited to 16 characters, game doesn't crash with a longer name. The only possible crashes are triggered by out-of-bounds values, these crashes are caused by the application attempting to load a ptr from a buffer located at NULL.
* Pyramids (3DSWare), QR codes: no strings. Only crashes are from out-of-bounds values (like background ID) and are not exploitable.
* 3DS browser, 2^32 characters long string: this is similar to the vuln fixed [http://git.chromium.org/gitweb/?p=external/Webkit.git;a=commitdiff;h=ec471f16fbd1f879cb631f9b022fd16acd75f4d4 here], concat-large-strings-crash2.html triggers a crash which is about the same as the one triggered by a 2^32 string. Most of the time this vuln will cause a memory page permissions fault, since the webkit code attempts to copy the string text data to the output buffer located in read-only [[CRO0|CRO]] heap memory. The only difference between a crash triggered by a 2^32 string and the concat-large-strings-crash2.html crash is that the former copies the string data using the original string length(like 1 text character for "x", 4 for "xxxx") while the latter attempts to copy >12MB. In some ''very'' rare cases a thread separate from the string data-copy thread will crash, this might be exploitable however this is useless since it rarely crashes this way.

==Tips and info==
The 3DS uses the XN feature of the ARM processor, and only apps that have the necessary permissions in their headers can set memory to be executable. This means that although a usable buffer overflow exploit would still be useful, it would not go the entire way towards allowing code to be run in an easy/practical fashion (ie an actual homebrew launcher) - for that, an exploit in the system is required. A buffer overflow exploit does, however, provide enough wriggle room through the use of return-oriented programming to potentially trigger a system exploit.

SD card [[extdata]] and SD savegames can be attacked, for consoles where the console-unique [[Nand/private/movable.sed|movable.sed]] was dumped.

Note that the publicly-available <v5.0 total-control exploits are [[FIRM|Process9]] exploits, not "kernel exploits".

==System flaws==
=== ARM11 kernel ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in system version
|-
| [[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
|-
| [[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.
| None
|-
| [[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
|-
| [[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]]
|-
| [[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]]
|-
| [[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]]
|-
| [[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 calucation 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]]
|-
| [[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]]
|-
| [[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]]
|-
| [[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]]
|}

=== FIRM ARM11 modules ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in system version
|-
| [[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).
| [[7.0.0-13]]
|}

3DS System Flaws

2014-11-03T04:05:18Z

Irocktolive7:

Exploits are used to execute unofficial code (homebrew) on the Nintendo 3DS. This page is a list of known 3DS-mode exploits.

==List of 3DS exploits==

==Current Efforts==
There are people working on finding exploits and documenting the 3DS. Here's a list of some current efforts being made to make homebrew on the 3DS possible:

* Smealum has a working exploit up to newest system version and has shown what seems to be viable proof that this is real. He says that he will be releasing the exploit when he believes all of the bundled software (HBC and others) are relatively bug free. In other words NO ETA.

==Stale / Rejected Efforts==
* Neimod has been working on a RAM dumping setup for a little while now. He's desoldered the 3DS's RAM chip and hooked it and the RAM pinouts on the 3DS's PCB up to a custom RAM dumping setup. Recent photos show that the setup is working quite well, with the 3DS successfully booting up. Pictures of neimod's work can be found on [http://www.flickr.com/photos/neimod/ his Flickr stream].

* Neimod's flickr stream is now private and his work is considered stale

* Govanify has released CFW and CIA installers along with some other interesting stuff (and illegal stuff) most of which were created by others and stolen

== Fixed vulnerabilities ==
* The following was fixed with [[7.0.0-13]], see here for [[7.0.0-13|details]]. Too long or corrupted strings (01Ah 2 Nickname length in characters 050h 2 Message length in characters) in the NVRAM DS user settings cause (System Settings->Other Settings->Profile->Nintendo DS Profile) to crash in 3DS-mode due to a stack-smash. The DSi is not vulnerable to this, DSi launcher(menu) and DSi System Settings will reset the NVRAM user-settings if the length field values are too long(same result as when the CRCs are invalid).

==Failed attempts==
Here are listed all attempts at exploiting 3DS software that have failed so far.

* Pushmo (3DSWare), QR codes: level name is properly limited to 16 characters, game doesn't crash with a longer name. The only possible crashes are triggered by out-of-bounds values, these crashes are caused by the application attempting to load a ptr from a buffer located at NULL.
* Pyramids (3DSWare), QR codes: no strings. Only crashes are from out-of-bounds values (like background ID) and are not exploitable.
* 3DS browser, 2^32 characters long string: this is similar to the vuln fixed [http://git.chromium.org/gitweb/?p=external/Webkit.git;a=commitdiff;h=ec471f16fbd1f879cb631f9b022fd16acd75f4d4 here], concat-large-strings-crash2.html triggers a crash which is about the same as the one triggered by a 2^32 string. Most of the time this vuln will cause a memory page permissions fault, since the webkit code attempts to copy the string text data to the output buffer located in read-only [[CRO0|CRO]] heap memory. The only difference between a crash triggered by a 2^32 string and the concat-large-strings-crash2.html crash is that the former copies the string data using the original string length(like 1 text character for "x", 4 for "xxxx") while the latter attempts to copy >12MB. In some ''very'' rare cases a thread separate from the string data-copy thread will crash, this might be exploitable however this is useless since it rarely crashes this way.

==Tips and info==
The 3DS uses the XN feature of the ARM processor, and only apps that have the necessary permissions in their headers can set memory to be executable. This means that although a usable buffer overflow exploit would still be useful, it would not go the entire way towards allowing code to be run in an easy/practical fashion (ie an actual homebrew launcher) - for that, an exploit in the system is required. A buffer overflow exploit does, however, provide enough wriggle room through the use of return-oriented programming to potentially trigger a system exploit.

SD card [[extdata]] and SD savegames can be attacked, for consoles where the console-unique [[Nand/private/movable.sed|movable.sed]] was dumped.

Note that the publicly-available <v5.0 total-control exploits are [[FIRM|Process9]] exploits, not "kernel exploits".

==System flaws==
=== ARM11 kernel ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in system version
|-
| [[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
|-
| [[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.
| None
|-
| [[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
|-
| [[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]]
|-
| [[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]]
|-
| [[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]]
|-
| [[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 calucation 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]]
|-
| [[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]]
|-
| [[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]]
|-
| [[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]]
|}

=== FIRM ARM11 modules ===
{| class="wikitable" border="1"
|-
! Summary
! Description
! Fixed in system version
|-
| [[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).
| [[7.0.0-13]]
|}

Main Page/Navigation

2014-11-03T03:56:19Z

Irocktolive7:

{{Main page box|Navigation|Main Page/Navigation}}
<div style="margin: -.3em -1em -1em -1em;">
{| width="100%" bgcolor="#fff" border="0" cellpadding="2px" cellspacing="2px" style="margin:auto;"
|- align="center" bgcolor="#e7eef6"
! width="25%" | '''General'''
! width="25%" | '''3DS hardware'''
! width="50%" colspan="2" | '''3DS software'''
|- valign="top" style="background: #F5FAFF;"
|
*[[Glossary]]
*[[FAQ]]
*[[Friend code]]
*[[Games]]
*[[Serials]]
*[[:Category:PC utilities|PC Utilities]]
*[[Homebrew Applications]]
*[[3DS System Flaws]]
|
*[[Hardware]]
*[[Peripherals]]
*[[Gamecards]]
*[[Video Capture]]
|
*[[Nintendo Software]]
*[[3DS Development Unit Software]]
*[[Memory layout]]
*[[Services API]]
*[[SVC|List of systemcalls]]
*[[IO|List of IO registers]]
*[[:Category:Kernel_objects|Kernel objects]]
*[[3DS System Flaws]]
|
*[[:Category:File_formats|File Formats]] ([[NCSD|CCI]]/[[NCCH#CXI|CXI]]/[[CIA]])
*[[Title list]]
*[[Title metadata]]
*[[Update Data]]
*[[SD Filesystem]]
*[[Flash Filesystem]]
*[[Bootloader]]
*[[Savegames]]
|}
</div>
{{box-footer-empty}}

Main Page/OtherSites

2013-12-30T02:05:51Z

Irocktolive7:

{{Main page box|Other Nintendo Homebrew Sites|:OtherSites}}
<div style="margin: -.3em -1em -1em -1em;">
{| width="100%" bgcolor="#fff" border="0" cellpadding="2px" cellspacing="2px" style="margin:auto;"
|- valign="top" align="left" style="background: #F5FAFF;"
| DSiBrew [http://dsibrew.org] WiiBrew [http://wiibrew.org] WiiUBrew [http://wiiubrew.org] GBAtemp [http://gbatemp.net] FileTrip [http://filetrip.net]
|}
</div>
{{box-footer-empty}}

Main Page/OtherSites

2013-12-30T00:46:16Z

Irocktolive7:

Main Page/OtherSites

2013-12-30T00:41:40Z

Irocktolive7: Created page with "[[http://google.com] test]"

[[http://google.com] test]

Main Page

2013-12-30T00:40:24Z

Irocktolive7:

{{:Main Page/Header}}
{{:Main Page/Welcome}}
{{:Main Page/OtherSites}}
{{:Main Page/Current events}}
{{:Main Page/Navigation}}
__NOTOC____NOEDITSECTION__

{{:Language_selection}}

Main Page/Other Sites

2013-12-30T00:40:04Z

Irocktolive7: Created page with "! width="25%"| '''DS Brew?'''"

! width="25%"| '''DS Brew?'''

Main Page

2013-12-30T00:38:08Z

Irocktolive7:

{{:Main Page/Header}}
{{:Main Page/Welcome}}
{{:Main Page/Other Sites}}
{{:Main Page/Current events}}
{{:Main Page/Navigation}}
__NOTOC____NOEDITSECTION__

{{:Language_selection}}

3dbrew:Community portal

2013-12-30T00:29:45Z

Irocktolive7:

== Theme ==

How about we change the default theme to 'Vector' to match the Wii and WiiU brew sites? --[[User:Elisherer|Elisherer]] 08:51, 11 December 2012 (CET)

==Translations==
To whoever translates this days..
* I recommend you wouldn't waste your time on translating pages which aren't finished (i.e. [[Savegames]])
* Do not translate database pages like [[Title list]] or [[Friend code]] these pages are updated regulary.
* This Wiki doesn't have a localization plug-in I would recommend waiting until it does..
--[[User:Elisherer|Elisherer]] 11:06, 15 March 2012 (CET)
: Okay, I see...--[[User:Wangxuan8331800|Wangxuan8331800]] 12:46, 16 March 2012 (CET)

Humm...

I think we create the other domains for those languages.--Matyapiro3118:24, 19 March 2012 (CET)

==Forum?==
A forum will be created when it becomes necessary, for e.g. actual discussion about homebrew development. Currently homebrew is not possible, so a forum is not needed yet. --[[User:Neimod|Neimod]] 01:05, 29 February 2012 (CET)

==weird communication==
Hello all, I found some weird UDP communication coming from the 3ds to the internet (japan). Connection is made towards IP 203.180.85.77, 202.232.239.25, and contains a string.
String starts with afa1, then the number 1,4 or 6, then comes either a short or long string (can contain 00) and it ends with a 2-byte counter (b3 in my case). It seems to be repeated, but I cant reproduce it as of now. It happened after I tried to update the 3ds, but it could be related to video/spotpass (suggestions?)

Example:
af a1 44 00 00 00 00 00 00 00 00 b3

Any suggestions/ideas what it could be? --[[User:Mr seeker|Mr seeker]] 20:26, 8 December 2011 (CET)

==3ds dev unit==
Hey,Xcution,don't you release helloworld.cia?--Matyapiro31 15:40, 1 December 2011 (CET)

==Homebrew install idea?==
Could it be installed in a way similar to Smash Bros. Brawl? Where you go to a webpage with a 3D image to download (like on 3ds.to) but when you load it in Camera/Swapnote it triggers? Or with the new Save Backup feature they just added? Sorry if this is the wrong place to suggest ideas... [[User:Jariesuicune|Jarieスイクン]] 18:22, 28 June 2013 (CEST)
:It is good place to post idea, that's all good as well. however since there is few that can reverse those ARM executables, we don't have ones alike yellow that can do such a job. even grabbed the power of 4.5.x we don't have people that can work on analysis on those app - we don't have enough ones to see into the implementation of system modules yet. So that is a pity we can only think and suggest, or go to learn reverse engineering and ARM disassembly first. BTW that site seems down (to me), also i don't think they would enable such a method. you can contact them on irc when you got something you think that is very interesting or would easily happen.--[[User:Syphurith|Syphurith]] 05:31, 29 June 2013 (CEST)

==DSiBrew==
Can one of the devs on DSIBREW lock the crucial pages. I (Dsihaxx) have been going around correcting them with the latest backups on the wayback machine however random people keep changing it to either advertisements or gibberish. Thx.