Difference between revisions of "Amiibo"

From 3dbrew
Jump to navigation Jump to search
(30 intermediate revisions by 3 users not shown)
Line 1: Line 1:
 
'''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]].
 
'''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]].
  
−
== Technical specifications ==
+
= Tag information =
−
See also [http://wiiubrew.org/wiki/Wii_U_GamePad here].
+
* 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)
  
−
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":
+
= Page layout =
−
[[File:Amiibonfctaginfo.png|500px]]
+
Excluding the auth-related configuration pages at the end, the structure of the NFC pages is the following:
−
 
 
−
See here regarding the Amiibo [[Process_Services_PXI|encryption]].
 
−
 
 
−
The NFC tag for Amiibo is NTAG215.
 
−
 
 
−
=== AUTH_PWD ===
 
−
The NFC 32bit password for the PWD_AUTH command(for enabling write-access to the encrypted NFC pages / etc), appears to be generated from unknown data that doesn't change when the Amiibo data pages are being updated.
 
−
 
 
−
=== NTAG215 commands ===
 
−
==== Amiibo reading ====
 
−
* GET_VERSION
 
−
* READ, startpage=0x03. The read page data for page[0x3] must match little-endian 0xEEFF10F1.
 
−
* PWD_AUTH
 
−
* 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.
 
−
 
 
−
==== Amiibo writing ====
 
−
* Use the same commands under the above reading section, then use those first 3 commands again.
 
−
* 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
 
−
 
 
−
=== NFC pages ===
 
−
Each page is 4-bytes, there is a total of 0x87/135 pages. Minus the configuration pages at the end, the total is 0x82/130 pages. The following is the structure of the NFC pages:
 
 
{| class="wikitable" border="1"
 
{| class="wikitable" border="1"
 
|-
 
|-
Line 41: Line 16:
 
!  Raw byte offset in EEPROM
 
!  Raw byte offset in EEPROM
 
!  Total byte size
 
!  Total byte size
 +
!  Writable
 
!  Description
 
!  Description
 
|-
 
|-
 
| 0x0
 
| 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
 
| 0x4
−
| 0x10
+
| style="background: red" | No
−
| 0x10
+
| Standard NTAG215: "Capability Container (CC)". Must match raw binary "F1 10 FF EE".
−
| Same as standard NTAG215: 9-byte serial-number, "internal" u8 value, two lock bytes then the "Capability Container (CC)" page.
 
 
|-
 
|-
 
| 0x4
 
| 0x4
Line 53: Line 37:
 
| 0x10
 
| 0x10
 
| 0x4
 
| 0x4
−
| 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 is normally 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.
+
| 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
 
| 0x5
Line 59: Line 44:
 
| 0x14
 
| 0x14
 
| 0x20
 
| 0x20
 +
| style="background: green" | Yes
 
| The system crypts 0x1A0-bytes with some data from here, see below.
 
| The system crypts 0x1A0-bytes with some data from here, see below.
 
|-
 
|-
Line 65: Line 51:
 
| 0x34
 
| 0x34
 
| 0x20
 
| 0x20
−
| SHA256-HMAC hash. The first 0x18-bytes of this hash is section3 in the encrypted buffer.
+
| style="background: red" | No
 +
| SHA256-(HMAC?) hash. The first 0x18-bytes of this hash is section3 in the encrypted buffer.
 
|-
 
|-
 
| 0x15
 
| 0x15
Line 71: Line 58:
 
| 0x54
 
| 0x54
 
| 0x2C
 
| 0x2C
 +
| style="background: red" | No
 
| This is plaintext data, see below.
 
| This is plaintext data, see below.
 
|-
 
|-
Line 77: Line 65:
 
| 0x80
 
| 0x80
 
| 0x20
 
| 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.
 
| 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.
 
|-
 
|-
Line 83: Line 72:
 
| 0xA0
 
| 0xA0
 
| 0x114
 
| 0x114
 +
| style="background: green" | Yes
 
| This is section1 in the encrypted buffer.
 
| This is section1 in the encrypted buffer.
 
|-
 
|-
Line 89: Line 79:
 
| 0x1B4
 
| 0x1B4
 
| 0x54
 
| 0x54
 +
| style="background: green" | Yes
 
| This is section2 in the encrypted buffer.
 
| 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".
 
|}
 
|}
  
−
==== Structure of the data starting at page 0x15 ====
+
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"
 
{| class="wikitable" border="1"
 
|-
 
|-
Line 100: Line 119:
 
|-
 
|-
 
| 0x0
 
| 0x0
−
| 0xC
+
| 0x8
 +
| Amiibo Identification Block
 +
|-
 +
| 0x8
 +
| 0x4
 
| ?
 
| ?
 
|-
 
|-
 
| 0xC
 
| 0xC
 
| 0x20
 
| 0x20
−
| Probably a SHA256-HMAC hash.
+
| 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
 +
| Unknown
 +
| Always 0x02
 
|}
 
|}
  
−
==== Encrypted data buffer structure ====
+
== Encrypted data buffer structure ==
 
{| class="wikitable" border="1"
 
{| class="wikitable" border="1"
 
|-
 
|-
Line 142: Line 204:
 
|}
 
|}
  
−
==== Structure of the plaintext data ====
+
== Structure of the plaintext data ==
 
{| class="wikitable" border="1"
 
{| class="wikitable" border="1"
 
|-
 
|-
Line 155: Line 217:
 
| 0xB0
 
| 0xB0
 
| 0xD8
 
| 0xD8
−
| AppData, for the user-application specified in the above Amiibo settings. The data stored here is application-specific.
+
| 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
 
| 0x188
Line 162: Line 224:
 
|}
 
|}
  
−
==== Structure of Amiibo settings ====
+
== Structure of Amiibo settings ==
 
{| class="wikitable" border="1"
 
{| class="wikitable" border="1"
 
|-
 
|-
Line 172: Line 234:
 
| 0x1
 
| 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.
 
| 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
 
| 0x1
 
| 0x1
−
| Unknown. The low 4-bits here are copied to the struct used with [[NFC:GetAmiiboSettings]].
+
| Country Code ID, [[Config_Savegame|from]] the system which setup this amiibo. This is copied to the struct used with [[NFC:GetAmiiboSettings]].
 
|-
 
|-
 
| 0x2
 
| 0x2
 
| 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
 
| 0x4
 
| 0x2
 
| 0x2
−
| u16 big-endian date value, see below. This is the date for when the Amiibo was initially setup in [[amiibo Settings]].
+
| 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
 
| 0x6
Line 191: Line 254:
 
| 0x8
 
| 0x8
 
| 0x4
 
| 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
 
| 0xC
Line 203: Line 266:
 
| 0x80
 
| 0x80
 
| 0x8
 
| 0x8
−
| Big-endian application programID for the AppData, zero otherwise.
+
| 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
 
| 0x88
 
| 0x2
 
| 0x2
−
| u16 big-endian. This value is incremented each time the Amiibo is written to.
+
| 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
 
| 0x8A
 +
| 0x4
 +
| Big-endian u32 Amiibo AppID.
 +
|-
 +
| 0x8E
 
| 0x2
 
| 0x2
−
| ?
 
−
|-
 
−
| 0x8C
 
−
| 0x4
 
 
| ?
 
| ?
 
|-
 
|-
Line 237: Line 300:
 
| Year, relative to 2000.
 
| 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].

Revision as of 19:08, 14 July 2017

Amiibo are 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 peripheral.

Tag information

  • Model: 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:

NFC page Total pages Raw byte offset in EEPROM Total byte size Writable Description
0x0 0x3 0x0 0xC 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 No Standard NTAG215: "Capability Container (CC)". Must match raw binary "F1 10 FF EE".
0x4 0x1 0x10 0x4 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 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 Yes The system crypts 0x1A0-bytes with some data from here, see below.
0xD 0x8 0x34 0x20 No SHA256-(HMAC?) hash. The first 0x18-bytes of this hash is section3 in the encrypted buffer.
0x15 0xB 0x54 0x2C No This is plaintext data, see below.
0x20 0x8 0x80 0x20 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 Yes This is section1 in the encrypted buffer.
0x6D 0x15 0x1B4 0x54 Yes This is section2 in the encrypted buffer.
0x82 0x1 0x208 0x4 No Standard NTAG215: first 3-bytes are dynamic lock bytes. Must match raw binary "01 00 0F".
0x83 0x1 0x20C 0x4 No Standard NTAG215: CFG0. Must match raw binary "00 00 00 04".
0x84 0x1 0x210 0x4 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": Amiibonfctaginfo.png

See here regarding the Amiibo encryption.

Data structures

Structure of the data starting at page 0x15

Offset Size Description
0x0 0x8 Amiibo Identification Block
0x8 0x4 ?
0xC 0x20 Probably a SHA256-(HMAC?) hash.

Structure of Amiibo Identification Block

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 Unknown Always 0x02

Encrypted data buffer structure

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

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

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 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, 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.
0x80 0x8 Big-endian application programID/titleID from the application which 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:

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:

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 [1] 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

Retrieved from "https://www.3dbrew.org/w/index.php?title=Amiibo&oldid=20167"