3dbrew - User contributions [en]

Amiibo

2022-09-21T10:47:23Z

GaryOderNichts: Create table for nfc page 0x4

'''Amiibo''' are [[NFC_Services|NFC]] figures made by Nintendo, used in games in different forms (different in each game). It can be used with the New3DS and the Old3DS with an [[IR_Services|IR]] [[NFC_adapter|peripheral]].

= Tag information =
* Model: [http://www.nxp.com/products/identification_and_security/smart_label_and_tag_ics/ntag/series/NTAG213_215_216.html NTAG215]
* Manufacturer: NXP Semiconductor
* Page size: 4 bytes
* Page count: 135 pages (540 bytes)
* Data pages: 126 pages (504 bytes)

= Page layout =
Excluding the auth-related configuration pages at the end, the structure of the NFC pages is the following:
{| class="wikitable" border="1"
|-
! NFC page
! Total pages
! Raw byte offset in EEPROM
! Total byte size
! Writable
! Description
|-
| 0x0
| 0x3
| 0x0
| 0xC
| style="background: red" | No
| Standard NTAG215: 9-byte serial-number, "internal" u8 value, then the two lock bytes which must match raw binary "0F E0".
|-
| 0x3
| 0x1
| 0xC
| 0x4
| style="background: red" | No
| Standard NTAG215: "Capability Container (CC)". Must match raw binary "F1 10 FF EE".
|-
| 0x4
| 0x1
| 0x10
| 0x4
| style="background: green" | Yes
| Last 3-bytes here are used with the following HMAC where the size is 0x1DF-bytes. The u16 starting at byte1 is used for the first two bytes in the 0x40-byte input buffer for Amiibo [[Process_Services_PXI|crypto]] init.
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Magic (Always 0xA5)
|-
| 0x1
| 0x2
| Incremented each time the Amiibo is written to.
|-
| 0x3
| 0x1
| Figure version (always 0x00)
|}
|-
| 0x5
| 0x8
| 0x14
| 0x20
| style="background: green" | Yes
| The system crypts 0x1A0-bytes with some data from here, see below.
|-
| 0xD
| 0x8
| 0x34
| 0x20
| style="background: red" | No
| SHA256-(HMAC?) hash. The first 0x18-bytes of this hash is section3 in the encrypted buffer.
|-
| 0x15
| 0xB
| 0x54
| 0x2C
| style="background: red" | No
| This is plaintext data, see below.
|-
| 0x20
| 0x8
| 0x80
| 0x20
| style="background: green" | Yes
| SHA256-HMAC hash over 0x1DF-bytes: first 3-bytes are from the last 3-bytes of page[4], the rest is over the first 0x1DC-bytes of the plaintext data.
|-
| 0x28
| 0x45
| 0xA0
| 0x114
| style="background: green" | Yes
| This is section1 in the encrypted buffer.
|-
| 0x6D
| 0x15
| 0x1B4
| 0x54
| style="background: green" | Yes
| This is section2 in the encrypted buffer.
|-
| 0x82
| 0x1
| 0x208
| 0x4
| style="background: red" | No
| Standard NTAG215: first 3-bytes are dynamic lock bytes. Must match raw binary "01 00 0F".
|-
| 0x83
| 0x1
| 0x20C
| 0x4
| style="background: red" | No
| Standard NTAG215: CFG0. Must match raw binary "00 00 00 04".
|-
| 0x84
| 0x1
| 0x210
| 0x4
| style="background: red" | No
| Standard NTAG215: CFG1. Must match raw binary "5F 00 00 00".
|}

Specifications can be found on this image, which is a compilation of screenshots made by scanning a Samus amiibo with the Android App "NFC TagInfo":
[[File:Amiibonfctaginfo.png|500px]]

See here regarding the Amiibo [[Process_Services_PXI|encryption]].

= Data structures =

== Structure of the data starting at page 0x15 ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x8
| Amiibo Identification Block
|-
| 0x8
| 0x4
| ?
|-
| 0xC
| 0x20
| Probably a SHA256-(HMAC?) hash.
|}

===Structure of Amiibo Identification Block===
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
! Notes
|-
| 0x0
| 0x2
| Game & Character ID
| First 10 bits are the Game ID and last 6 bits are Character ID.
|-
| 0x2
| 0x1
| Character variant
|
|-
| 0x3
| 0x1
| Amiibo Figure Type
|
|-
| 0x4
| 0x2
| Amiibo Model Number
|
|-
| 0x6
| 0x1
| Amiibo Series
|
|-
| 0x7
| 0x1
| Format Version
| Always 0x02
|}

== Encrypted data buffer structure ==
{| class="wikitable" border="1"
|-
! Encrypted buffer offset
! Raw byte offset in NFC EEPROM
! NFC page
! Byte size
! Notes
|-
| 0x0
| 0x14
| 0x5
| 0x20
|
|-
| 0x20
| 0xA0
| 0x28
| 0x114
|
|-
| 0x134
| 0x1B4
| 0x6D
| 0x54
|
|-
| 0x188
| 0x34
| 0xD
| 0x18
| This data is included in the crypto buffer, even though this data isn't actually encrypted(this is part of a hash).
|}

== Structure of the plaintext data ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0xB0
| Amiibo settings are stored within here.
|-
| 0xB0
| 0xD8
| AppData, for the user-application specified in the above Amiibo settings. The data stored here is application-specific. The data stored here is normally all big-endian, even when the user-application is only for 3DS systems. Note that this data is initially uninitialized, and at least some of it will stay that way unless an application clears/initializes *all* of it.
|-
| 0x188
| 0x18
| Not used in "decrypted" form, since this isn't encrypted to begin with.
|}

== Structure of Amiibo settings ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Flags. The low 4-bits here are copied to the struct used with [[NFC:GetAmiiboSettings]]. The below setup date is only loaded when bit4 and/or bit5 here are set, otherwise value 0 is used instead for the date. Bit4=1 indicates that the Amiibo was setup with [[amiibo Settings]]: [[NFC:GetAmiiboSettings]] will return an all-zero struct when this is not set.
Bit5=1 indicates that the AppData was [[NFC:InitializeWriteAppData|initialized]]. [[NFC:InitializeWriteAppData]] will return an error if this is value 1, when successful that command will then set this bit to value 1.
|-
| 0x1
| 0x1
| Country Code ID, [[Config_Savegame|from]] the system which setup this amiibo. This is copied to the struct used with [[NFC:GetAmiiboSettings]].
|-
| 0x2
| 0x2
| This big-endian u16 counter is incremented each time that the CRC32 at offset 0x8 gets updated by [[NFC:InitializeWriteAppData]], due to that value not matching the calculated one. When this value is already 0xFFFF, this counter won't be updated anymore.
|-
| 0x4
| 0x2
| u16 big-endian date value, see below. This is the date for when the Amiibo was initially setup in [[amiibo Settings]]. This is also written by [[NFC:InitializeWriteAppData]].
|-
| 0x6
| 0x2
| u16 big-endian date value, see below. This is the date for when the Amiibo was last written to.
|-
| 0x8
| 0x4
| Big-endian CRC32 value with initialval=~0, with the 8-byte output from [[Cfg:GenHashConsoleUnique]]. This is written by [[NFC:InitializeWriteAppData]], when the current value doesn't match the calculated one.
|-
| 0xC
| 0x14(10*2)
| UTF-16BE Amiibo nickname.
|-
| 0x20
| 0x60
| Owner [[Mii_Maker|Mii]].
|-
| 0x80
| 0x8
| Big-endian application programID/titleID from the application which [[NFC:InitializeWriteAppData|initialized]] the AppData, zero otherwise. This is only written, not compared with the user application titleID: doing the latter would break games' cross-platform compatibility with 3DS<>Wii U(Super Smash Bros 3DS/Wii U for example).
|-
| 0x88
| 0x2
| u16 big-endian. This value is incremented each time the Amiibo is written to. When this value is already 0xFFFF, this counter won't be updated anymore.
|-
| 0x8A
| 0x4
| Big-endian u32 Amiibo AppID.
|-
| 0x8E
| 0x2
| ?
|-
| 0x90
| 0x20
| Probably a SHA256-HMAC hash.
|}

Format of the big-endian date values:
{| class="wikitable" border="1"
|-
! Bit
! Description
|-
| 0-4
| Day
|-
| 5-8
| Month
|-
| 9-15
| Year, relative to 2000.
|}

= 3DS read/write procedure =
Note this is the procedure used by the console, but isn't the only way of reading them.

== Read procedure ==
* GET_VERSION
* READ, startpage=0x03.
* PWD_AUTH. Key is based on UID.
* FAST_READ: startpage=0x00, endpage=0x3B
* FAST_READ: startpage=0x3C, endpage=0x77
* FAST_READ: startpage=0x78, endpage=0x86

Therefore, *all* pages from the Amiibo NFC tag are read, including the configuration pages at the end.

== Write procedure ==
* GET_VERSION
* READ, startpage=0x03.
* PWD_AUTH. Key is based on UID.
* Multiple WRITE commands for writing to pages 0x04..0x0C. The first byte for page[4] is zero here.
* Multiple WRITE commands for writing to pages 0x20..0x81.
* Use the last 3 commands from the above reading section.
* WRITE: page=0x04, same data as before except first byte is 0xA5 this time.
* FAST_READ: startpage=0x04, endpage=0x04

=Games using Amiibo AppData=
The following is a list of games which actually store game-specific data on Amiibo, not *just* using Amiibo for checking character IDs:
{| class="wikitable" border="1"
|-
! Name
! Available for (New)3DS
! Available for Wii U
! Amiibo AppID
! AppData structure / link to info
! AppData modification for exploitation notes.
|-
| Super Smash Bros
| Yes
| Yes
| 0x10110E00
| [https://github.com/yellows8/smash3ds-tools/wiki/SmashAmiiboAppData]
| No crash ever triggered via AppData fuzzing.
|-
| Mario Party 10
| No
| Yes
| ?
| N/A
| N/A
|-
| Animal Crossing: Happy Home Designer
| Yes
| No
| 0x0014F000
| N/A
| The initial AppData handling doesn't appear to have any vuln(s), going by manual code-RE for update v2.0. Fuzzing wasn't attempted.
|-
| Chibi-Robo!: Zip Lash
| Yes
| No
| 0x00152600
| The entire AppData is read by the game, but only the first 0x10-bytes are actually used.
| No crash ever triggered via AppData fuzzing.
|-
| Mario & Luigi: Paper Jam
| Yes
| No
| 0x00132600
| Starts with the process-name("MILLION"). The rest seems to be bitmasks maybe?
| No crash ever triggered via AppData fuzzing, when viewing "character cards"(just unlocks various cards).
|-
| The Legend of Zelda: Twilight Princess HD
| No
| Yes
| 0x1019C800
| Unknown.
| No crash/hang ever occurred when using amiibo in-game for "Cave of Shadows".
With the amiibo quick-start option at the title-screen, only errors ever occurred(<quick-start data not found> / <quick-start data is for another user>).
|}

= External links =
* [http://wiiubrew.org/wiki/Wii_U_GamePad Wii U Gamepad and Amiibo information on WiiUBrew].

Amiibo

2022-08-31T16:32:13Z

GaryOderNichts: Wii U's ntag.rpl calls this field "Format version"

'''Amiibo''' are [[NFC_Services|NFC]] figures made by Nintendo, used in games in different forms (different in each game). It can be used with the New3DS and the Old3DS with an [[IR_Services|IR]] [[NFC_adapter|peripheral]].

= Tag information =
* Model: [http://www.nxp.com/products/identification_and_security/smart_label_and_tag_ics/ntag/series/NTAG213_215_216.html NTAG215]
* Manufacturer: NXP Semiconductor
* Page size: 4 bytes
* Page count: 135 pages (540 bytes)
* Data pages: 126 pages (504 bytes)

= Page layout =
Excluding the auth-related configuration pages at the end, the structure of the NFC pages is the following:
{| class="wikitable" border="1"
|-
! NFC page
! Total pages
! Raw byte offset in EEPROM
! Total byte size
! Writable
! Description
|-
| 0x0
| 0x3
| 0x0
| 0xC
| style="background: red" | No
| Standard NTAG215: 9-byte serial-number, "internal" u8 value, then the two lock bytes which must match raw binary "0F E0".
|-
| 0x3
| 0x1
| 0xC
| 0x4
| style="background: red" | No
| Standard NTAG215: "Capability Container (CC)". Must match raw binary "F1 10 FF EE".
|-
| 0x4
| 0x1
| 0x10
| 0x4
| style="background: green" | Yes
| Last 3-bytes here are used with the following HMAC where the size is 0x1DF-bytes. The u16 starting at byte1 is used for the first two bytes in the 0x40-byte input buffer for Amiibo [[Process_Services_PXI|crypto]] init. The first byte must be 0xA5. The remaining bytes are initially(before the Amiibo is written to) all-zero. Byte[2](maybe big-endian u16 starting at byte1?) here is incremented each time the Amiibo is written to.
|-
| 0x5
| 0x8
| 0x14
| 0x20
| style="background: green" | Yes
| The system crypts 0x1A0-bytes with some data from here, see below.
|-
| 0xD
| 0x8
| 0x34
| 0x20
| style="background: red" | No
| SHA256-(HMAC?) hash. The first 0x18-bytes of this hash is section3 in the encrypted buffer.
|-
| 0x15
| 0xB
| 0x54
| 0x2C
| style="background: red" | No
| This is plaintext data, see below.
|-
| 0x20
| 0x8
| 0x80
| 0x20
| style="background: green" | Yes
| SHA256-HMAC hash over 0x1DF-bytes: first 3-bytes are from the last 3-bytes of page[4], the rest is over the first 0x1DC-bytes of the plaintext data.
|-
| 0x28
| 0x45
| 0xA0
| 0x114
| style="background: green" | Yes
| This is section1 in the encrypted buffer.
|-
| 0x6D
| 0x15
| 0x1B4
| 0x54
| style="background: green" | Yes
| This is section2 in the encrypted buffer.
|-
| 0x82
| 0x1
| 0x208
| 0x4
| style="background: red" | No
| Standard NTAG215: first 3-bytes are dynamic lock bytes. Must match raw binary "01 00 0F".
|-
| 0x83
| 0x1
| 0x20C
| 0x4
| style="background: red" | No
| Standard NTAG215: CFG0. Must match raw binary "00 00 00 04".
|-
| 0x84
| 0x1
| 0x210
| 0x4
| style="background: red" | No
| Standard NTAG215: CFG1. Must match raw binary "5F 00 00 00".
|}

Specifications can be found on this image, which is a compilation of screenshots made by scanning a Samus amiibo with the Android App "NFC TagInfo":
[[File:Amiibonfctaginfo.png|500px]]

See here regarding the Amiibo [[Process_Services_PXI|encryption]].

= Data structures =

== Structure of the data starting at page 0x15 ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x8
| Amiibo Identification Block
|-
| 0x8
| 0x4
| ?
|-
| 0xC
| 0x20
| Probably a SHA256-(HMAC?) hash.
|}

===Structure of Amiibo Identification Block===
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
! Notes
|-
| 0x0
| 0x2
| Game & Character ID
| First 10 bits are the Game ID and last 6 bits are Character ID.
|-
| 0x2
| 0x1
| Character variant
|
|-
| 0x3
| 0x1
| Amiibo Figure Type
|
|-
| 0x4
| 0x2
| Amiibo Model Number
|
|-
| 0x6
| 0x1
| Amiibo Series
|
|-
| 0x7
| 0x1
| Version
| Always 0x02
|}

== Encrypted data buffer structure ==
{| class="wikitable" border="1"
|-
! Encrypted buffer offset
! Raw byte offset in NFC EEPROM
! NFC page
! Byte size
! Notes
|-
| 0x0
| 0x14
| 0x5
| 0x20
|
|-
| 0x20
| 0xA0
| 0x28
| 0x114
|
|-
| 0x134
| 0x1B4
| 0x6D
| 0x54
|
|-
| 0x188
| 0x34
| 0xD
| 0x18
| This data is included in the crypto buffer, even though this data isn't actually encrypted(this is part of a hash).
|}

== Structure of the plaintext data ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0xB0
| Amiibo settings are stored within here.
|-
| 0xB0
| 0xD8
| AppData, for the user-application specified in the above Amiibo settings. The data stored here is application-specific. The data stored here is normally all big-endian, even when the user-application is only for 3DS systems. Note that this data is initially uninitialized, and at least some of it will stay that way unless an application clears/initializes *all* of it.
|-
| 0x188
| 0x18
| Not used in "decrypted" form, since this isn't encrypted to begin with.
|}

== Structure of Amiibo settings ==
{| class="wikitable" border="1"
|-
! Offset
! Size
! Description
|-
| 0x0
| 0x1
| Flags. The low 4-bits here are copied to the struct used with [[NFC:GetAmiiboSettings]]. The below setup date is only loaded when bit4 and/or bit5 here are set, otherwise value 0 is used instead for the date. Bit4=1 indicates that the Amiibo was setup with [[amiibo Settings]]: [[NFC:GetAmiiboSettings]] will return an all-zero struct when this is not set.
Bit5=1 indicates that the AppData was [[NFC:InitializeWriteAppData|initialized]]. [[NFC:InitializeWriteAppData]] will return an error if this is value 1, when successful that command will then set this bit to value 1.
|-
| 0x1
| 0x1
| Country Code ID, [[Config_Savegame|from]] the system which setup this amiibo. This is copied to the struct used with [[NFC:GetAmiiboSettings]].
|-
| 0x2
| 0x2
| This big-endian u16 counter is incremented each time that the CRC32 at offset 0x8 gets updated by [[NFC:InitializeWriteAppData]], due to that value not matching the calculated one. When this value is already 0xFFFF, this counter won't be updated anymore.
|-
| 0x4
| 0x2
| u16 big-endian date value, see below. This is the date for when the Amiibo was initially setup in [[amiibo Settings]]. This is also written by [[NFC:InitializeWriteAppData]].
|-
| 0x6
| 0x2
| u16 big-endian date value, see below. This is the date for when the Amiibo was last written to.
|-
| 0x8
| 0x4
| Big-endian CRC32 value with initialval=~0, with the 8-byte output from [[Cfg:GenHashConsoleUnique]]. This is written by [[NFC:InitializeWriteAppData]], when the current value doesn't match the calculated one.
|-
| 0xC
| 0x14(10*2)
| UTF-16BE Amiibo nickname.
|-
| 0x20
| 0x60
| Owner [[Mii_Maker|Mii]].
|-
| 0x80
| 0x8
| Big-endian application programID/titleID from the application which [[NFC:InitializeWriteAppData|initialized]] the AppData, zero otherwise. This is only written, not compared with the user application titleID: doing the latter would break games' cross-platform compatibility with 3DS<>Wii U(Super Smash Bros 3DS/Wii U for example).
|-
| 0x88
| 0x2
| u16 big-endian. This value is incremented each time the Amiibo is written to. When this value is already 0xFFFF, this counter won't be updated anymore.
|-
| 0x8A
| 0x4
| Big-endian u32 Amiibo AppID.
|-
| 0x8E
| 0x2
| ?
|-
| 0x90
| 0x20
| Probably a SHA256-HMAC hash.
|}

Format of the big-endian date values:
{| class="wikitable" border="1"
|-
! Bit
! Description
|-
| 0-4
| Day
|-
| 5-8
| Month
|-
| 9-15
| Year, relative to 2000.
|}

= 3DS read/write procedure =
Note this is the procedure used by the console, but isn't the only way of reading them.

== Read procedure ==
* GET_VERSION
* READ, startpage=0x03.
* PWD_AUTH. Key is based on UID.
* FAST_READ: startpage=0x00, endpage=0x3B
* FAST_READ: startpage=0x3C, endpage=0x77
* FAST_READ: startpage=0x78, endpage=0x86

Therefore, *all* pages from the Amiibo NFC tag are read, including the configuration pages at the end.

== Write procedure ==
* GET_VERSION
* READ, startpage=0x03.
* PWD_AUTH. Key is based on UID.
* Multiple WRITE commands for writing to pages 0x04..0x0C. The first byte for page[4] is zero here.
* Multiple WRITE commands for writing to pages 0x20..0x81.
* Use the last 3 commands from the above reading section.
* WRITE: page=0x04, same data as before except first byte is 0xA5 this time.
* FAST_READ: startpage=0x04, endpage=0x04

=Games using Amiibo AppData=
The following is a list of games which actually store game-specific data on Amiibo, not *just* using Amiibo for checking character IDs:
{| class="wikitable" border="1"
|-
! Name
! Available for (New)3DS
! Available for Wii U
! Amiibo AppID
! AppData structure / link to info
! AppData modification for exploitation notes.
|-
| Super Smash Bros
| Yes
| Yes
| 0x10110E00
| [https://github.com/yellows8/smash3ds-tools/wiki/SmashAmiiboAppData]
| No crash ever triggered via AppData fuzzing.
|-
| Mario Party 10
| No
| Yes
| ?
| N/A
| N/A
|-
| Animal Crossing: Happy Home Designer
| Yes
| No
| 0x0014F000
| N/A
| The initial AppData handling doesn't appear to have any vuln(s), going by manual code-RE for update v2.0. Fuzzing wasn't attempted.
|-
| Chibi-Robo!: Zip Lash
| Yes
| No
| 0x00152600
| The entire AppData is read by the game, but only the first 0x10-bytes are actually used.
| No crash ever triggered via AppData fuzzing.
|-
| Mario & Luigi: Paper Jam
| Yes
| No
| 0x00132600
| Starts with the process-name("MILLION"). The rest seems to be bitmasks maybe?
| No crash ever triggered via AppData fuzzing, when viewing "character cards"(just unlocks various cards).
|-
| The Legend of Zelda: Twilight Princess HD
| No
| Yes
| 0x1019C800
| Unknown.
| No crash/hang ever occurred when using amiibo in-game for "Cave of Shadows".
With the amiibo quick-start option at the title-screen, only errors ever occurred(<quick-start data not found> / <quick-start data is for another user>).
|}

= External links =
* [http://wiiubrew.org/wiki/Wii_U_GamePad Wii U Gamepad and Amiibo information on WiiUBrew].