3dbrew - Recent changes [en]

Pinouts

TimmSkiller — Tue, 14 Jul 2026 15:10:21 GMT

Add red power LED to MCU pinout

← Older revision		Revision as of 19:10, 14 July 2026
Line 243:		Line 243:
	\| P2.0		\| P2.0
	\| HOME button		\| HOME button
			\|-
			\|
			\|
			\| P4.2
			\| Red power LED
	\|-		\|-
	\|		\|

StreetPass

Katanya04 — Sun, 12 Jul 2026 23:10:01 GMT

Fix typo

← Older revision		Revision as of 03:10, 13 July 2026
Line 435:		Line 435:
	=== Encrypted conversation ===		=== Encrypted conversation ===

	After the handshake is done, ~~the~~ 3DS start an encrypted conversation. ~~It's~~ format and protocols can be seen at [[SPTCP]] and [[SPMTP]].		After the handshake is done, both 3DS start having an encrypted conversation. Its format and protocols can be seen at [[SPTCP]] and [[SPMTP]].

	== StreetPass Spoofing ==		== StreetPass Spoofing ==

Mysteries

Kynex7510 — Thu, 02 Jul 2026 10:02:40 GMT

sed

← Older revision		Revision as of 14:02, 2 July 2026
Line 52:		Line 52:
	'''Theory:''' NtrBoot another time		'''Theory:''' NtrBoot another time
	=== Why are there 4 stubbed syscalls named SendSyncRequest1-4? ===		=== Why are there 4 stubbed syscalls named SendSyncRequest1-4? ===

	=== Is there a deterministic formula for calculating the Movable.sed KeyY high u64? ===		=== Is there a deterministic formula for calculating the Movable.sed KeyY high u64? ===
	'''Background:''' We know now that the high 4 bytes of KeyY can be reliably estimated to be 1/5th of the LocalFriendCodeSeed (low 8 bytes of KeyY), which is close enough to brute force. However, the actual value is usually about 0-4000 units off the actual high u32 of the KeyY (called msed3 in the seedminer implementation). Could there possibly be a deterministic formula given this 1/5 ratio is so close to the correct value? It's difficult to imagine this is just a coincidence.		'''Background:''' We know now that the high 4 bytes of KeyY can be reliably estimated to be 1/5th of the LocalFriendCodeSeed (low 8 bytes of KeyY), which is close enough to brute force. However, the actual value is usually about 0-4000 units off the actual high u32 of the KeyY (called msed3 in the seedminer implementation). Could there possibly be a deterministic formula given this 1/5 ratio is so close to the correct value? It's difficult to imagine this is just a coincidence.

			'''Answer:''' No. Both LFCS and the second half of key Y are monotonically increasing:
			* The former increases by a random value between [1, 4], thus the average increase is 2.5.
			* The latter increases by a random value between [1, 2^32], thus the average increase is 2^31.
			After X increases, the LFCS assumes a value of roughly X * 2.5, the second half of key Y assumes a value roughly of X * 2^31, which means msed3 becomes roughly (X >> 1) -> X / 2. Thus the correlation: LFCS/msed3 = (X * 2.5) / (X / 2) -> (X * 2.5) * (2 / X) = 2.5 * 2 = 5.

User:Katanya04

Katanya04 — Thu, 02 Jul 2026 02:41:38 GMT

Create my user page

New page

Quack quack :duck:

StreetPass

Katanya04 — Thu, 02 Jul 2026 02:33:32 GMT

Added links to SPTCP and SPMTP protocols

← Older revision		Revision as of 06:33, 2 July 2026
Line 432:		Line 432:

	The 3DS (#1) that the Initial Probe Response is directed to will send an 802.11 Action frame back to the device. The sequence numbers at this point stop stepping up by 3, and instead increase by one based from each originating device's SN. It will then send another Probe Request, this time sent directly to the responding 3DS (#2) by specifying its MAC address in the destination field, and setting its own MAC address in the source address field. It also does not have a SSID specified in the frame, except the frame will contain a BSSID with the value of the 3DS (#2) that responded to the initial Probe, and thus acts as the master in the 802.11 exchange.		The 3DS (#1) that the Initial Probe Response is directed to will send an 802.11 Action frame back to the device. The sequence numbers at this point stop stepping up by 3, and instead increase by one based from each originating device's SN. It will then send another Probe Request, this time sent directly to the responding 3DS (#2) by specifying its MAC address in the destination field, and setting its own MAC address in the source address field. It also does not have a SSID specified in the frame, except the frame will contain a BSSID with the value of the 3DS (#2) that responded to the initial Probe, and thus acts as the master in the 802.11 exchange.

			=== Encrypted conversation ===

			After the handshake is done, the 3DS start an encrypted conversation. It's format and protocols can be seen at [[SPTCP]] and [[SPMTP]].

	== StreetPass Spoofing ==		== StreetPass Spoofing ==

SPTCP

Katanya04 — Thu, 02 Jul 2026 02:30:34 GMT

Created the SPTCP page, based upon MrNbaYoh presentation and my own findings

New page

Similar to TCP, but on layer 2 (no IP, only MAC), with control flags and handles data segmentation. Used to send data packets ([[SPMTP]]) in a StreetPass exchange.

= Header Structure =
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x2
| Magic value (0x5959)
|-
| 0x2
| 0x2
| Header size (0x18) + payload (SPMTP) size + 0x18
|-
| 0x4
| 0x4
| Constant (0xaddeafbe)
|-
| 0x8
| 0x4
| Number of payload bytes sent (used when payload has to be segmented in multiple packets)
|-
| 0xC
| 0x4
| Number of payload bytes received from peer
|-
| 0x10
| 0x1
| (Header size (0x18) + 0x18) right shifted 2 places (this is always 0x0c)
|-
| 0x11
| 0x1
| Flags
|-
| 0x12
| 0x2
| Payload buffer size (by default 0xb838)
|-
| 0x14
| 0x4
| Padding (0x00000000)
|}

== Flags ==
The flag field encodes the following flags, from bit nº0 to bit nº5 respectively: FIN, SYN, RST, PSH, ACK, END.

== Buffer ==
By default, the 3DS uses a buffer of size 0x38b8 (appears as 0xb838 in the SPTCP header since it is sent in little endian). No other buffer size has been observed being used. Similar to the sliding window protocol of TCP, it indicates the amount of payload bytes the 3DS can send before having to wait for the other 3DS to send an ACK.

The SPMTP data is always encapsulated in one (or multiple if segmented) SPTCP header with at least the ACK flag set. If the PSH flag is set too, it means the buffer size limit has been reached, and if the END flag is also set, it means the 3DS has finished sending the current SPMTP payload. In both cases, the receiver 3DS has to send an ACK that contains the number of payload bytes received from the current SPMTP until that point.

Aside from this buffer, it has been observed that the maximum payload chunk size is hardcoded to be 0x38b8. Since this is also the default buffer size, when it reaches the buffer limit it has also reached the current chunk length so the 3DS sends the packet with ACK + PSH + END flags, even though it may not be the actual end of the message. Both Info SPMTP and Message Box SPMTP headers have a field containing the total payload length, this value should be used to check if the ACK + PSH + END actually indicates the end of the current message or not.

= Conversation Flow =
== Handshake ==
Before sending any new SPMTP payload, the 3DS (A) has to do the three-way handshake with its peer (B): (A) sends a SYN, (B) sends a SYN + ACK, (A) sends a ACK. Then (A) sends the SPMTP.
<pre>
A sends:
0000 59 59 30 00 ad de af be 00 00 00 00 00 00 00 00 YY0.............
0010 0c 02 b8 38 00 00 00 00 ...8....

B sends:
0000 59 59 30 00 ad de af be 00 00 00 00 00 00 00 00 YY0.............
0010 0c 12 b8 38 00 00 00 00 ...8....

A sends:
0000 59 59 30 00 ad de af be 00 00 00 00 00 00 00 00 YY0.............
0010 0c 10 b8 38 00 00 00 00 ...8....

</pre>

== Info SPMTP state ==
The first messages of the conversation consist of info SPMTP messages. These messages' format can be seen at [[SPMTP#Handshake_Packets]]. They are small enough to fit in 1 Ethernet MTU, so they don't get segmented, and therefore are all sent with the ACK + PSH + END flags.

The number of info messages, their type and the order in which they get sent are always the same. Alternating between client and master, the order is as follows: 0x41, 0x42, 0x43, 0x43, 0x11, 0x12, 0x21, 0x22, 0x23, 0x24, 0x31, 0x32, 0x33, 0x34, 0x81, 0x81. Each 3DS has to initiate the handshake before sending one of these messages, and the other 3DS replies with an ACK to each of these messages.

== Message Box SPMTP ==
After sending all the Info SPMTP messages, both 3DS start exchanging StreetPass messages ([[SPMTP#TMP_Box_Packets]]).

- If the 3DS (A) is sending a message, but it has reached the buffer limit, the receiver 3DS (B) will reply with an ACK and (A) will immediately continue sending data without needing to perform the handshake again.

- If the 3DS (A) has finished sending a message, and it has more messages to send of that same game, the receiver 3DS (B) will reply with an ACK and (A) will immediately continue sending the next message without needing to perform the handshake again.

- If the 3DS (A) has finished sending a message, it doesn't have more messages to send of the current game, and the receiver 3DS (B) does have more messages to send, then (B) will reply with an ACK and initiate the handshake, then it will be (B)'s turn to send messages.

- If the 3DS (A) has finished sending a message, it doesn't have more messages to send of the current game but does have more messages to send from other games, and the receiver 3DS (B) does not have any more messages from any game to send, then (B) will reply with an ACK and (A) will initiate the handshake and send its next message.

- If the 3DS (A) has finished sending a message, it doesn't have more messages to send from any game, and neither does the receiver 3DS (B), then (B) will reply with an ACK and a FIN. (A) will reply an ACK + FIN and lastly (B) will reply with an ACK. The conversation ends.

The order in which they exchange the games messages is determined by the order they specified in the Info SPMTP 0x81 message.

StreetPass

Katanya04 — Wed, 01 Jul 2026 22:25:41 GMT

Added that bits 5 and 6 encode the send method of the service. Moved the send method table to where bits 5 and 6 are talked about

@@ Line 134: / Line 134: @@
 Only the bits 2,5,6 were used.
-Some services have a 6-byte field succeeding the StreetPass service that is just FF bytes (e.g. FF FF FF FF FF FF). The purpose of these is unknown, although may be used as data for a service, or as separator of some sort for different types of StreetPass services.
+Bits n°5 and n°6 encode the send method of the service:
 Observed services (leading titleID 0x00 removed, 6*0xff ignored) on 68K probe requests between 2013-08-24 and 2014-06-29 in various european locations.
@@ Line 419: / Line 432: @@
 The 3DS (#1) that the Initial Probe Response is directed to will send an 802.11 Action frame back to the device. The sequence numbers at this point stop stepping up by 3, and instead increase by one based from each originating device's SN. It will then send another Probe Request, this time sent directly to the responding 3DS (#2) by specifying its MAC address in the destination field, and setting its own MAC address in the source address field. It also does not have a SSID specified in the frame, except the frame will contain a BSSID with the value of the 3DS (#2) that responded to the initial Probe, and thus acts as the master in the 802.11 exchange.
 == StreetPass Spoofing ==

User:Colsignifi

Colsignifi — Thu, 25 Jun 2026 13:34:10 GMT

User account Colsignifi was created

Config Savegame

TimmSkiller — Tue, 23 Jun 2026 20:39:05 GMT

Configuration blocks

← Older revision		Revision as of 00:39, 24 June 2026
(4 intermediate revisions by the same user not shown)
Line 220:		Line 220:
	\| 0x8		\| 0x8
	\| 0xE		\| 0xE
	\| ~~This contains a~~ u64 ID, ~~used~~ by ~~processes using [[NWMUDS:InitializeWithVersion]]. The first word~~ is ~~the same as~~ [[~~CfgS~~:~~GetLocalFriendCodeSeed\|LocalFriendCodeSeed~~]]~~, while the latter is a separate word~~.		\| u64, Current local friend code. Updated by the friends sysmodule when a local friends account is loaded with [[FRDA:LoadLocalAccount]] accordingly.
	\|-		\|-
	\| 0x00090001		\| 0x00090001
	\| 0x8		\| 0x8
	\| 0xE		\| 0xE
	\| ~~Same content as 0x0009000?~~ This ~~console-unique u64~~ is ~~used~~ by [[~~Cfg~~:~~GenHashConsoleUnique~~\|~~GenHashConsoleUnique~~]]. It is ~~generated~~ by ~~<code>((0x3FFFFFFFF) &~~ LocalFriendCodeSeed~~) \| (random16 << 48))</code>, where random16~~ is ~~generated~~ by [[~~PSPXI~~:~~GenerateRandomBytes~~\|~~GenerateRandomBytes~~]]		\| u64, Local friend code base value. This value is sent by the friends sysmodule to the friends gameserver during NEX account creation and serves as a means to find PIDs (and thus "online" friend codes) for other consoles' that were registered using [[FRDA:AddFriendOffline]] when those console(s) hadn't yet registered with the friends services at the time. The lower 34 bits are from [[Nandrw/sys/LocalFriendCodeSeed_B\|LocalFriendCodeSeed]], and the upper 16 bits are from the LocalFriendCodeSeed counter (see below block, 0x90002). The remaining bits are left zero. This value is initialized as described by the CFG module when the LocalFriendCodeSeed part is zero. Used by [[Cfg:GenHashConsoleUnique\|GenHashConsoleUnique]].
	\|-		\|-
	\| 0x00090002		\| 0x00090002
	\| 0x4		\| 0x4
	\| 0xE		\| 0xE
	\| ~~The first~~ two bytes ~~are~~ the ~~same random16 used~~ in ~~0x00090001~~. ~~The second two bytes are zeros~~.		\| u16, Local friend code counter. This value is initialized by the CFG module alongside block 0x90001 to two random bytes generated by [[PS:GenerateRandomBytes]] and also serves as a component of that block. It is incremented by PTM and stored in MCU storage when PTM save data is formatted. Once incremented, upon reboot, PTM will use the counter stored in MCU storage to update the local friend code base value (block 0x90001). After updating the relevant configuration blocks, PTM sets the storage area reserved for the counter to 0.
	\|-		\|-
	\| 0x000A0000		\| 0x000A0000

Title Database

TimmSkiller — Tue, 16 Jun 2026 11:24:26 GMT

Move table of contents to the correct location

← Older revision		Revision as of 15:24, 16 June 2026
Line 1:		Line 1:
			__TOC__

	These files contain data relating to install/usage/management of installed 3DS titles. The database files are located at:		These files contain data relating to install/usage/management of installed 3DS titles. The database files are located at: