Kirby Air Riders IDs & Amiibo v3

[Brickleberry19]

Can only be scanned when both parts together and when you swap the wehicle, the IDs stays the same
Like:
Kirby & Warp Star = 1F00000004C41E03
Kirby & Winged Star = 1F00000004C41E03

Bandana Waddle Dee & Winged Star = 1F03010004C91E03
Bandana Waddle Dee & Warp Star = 1F03010004C91E03

0x1f00000004c41e03": {
"name": "Kirby & Warp Star",
"release": {
"au": "2025-11-20",
"eu": "2025-11-20",
"jp": "2025-11-20",
"na": "2025-11-20"
}
},

icon_1f000000-04c41e03.png
https://amiibo.life/amiibo/kirby-air-riders/kirby-warp-star

0x1f03010004c91e03": {
"name": "Bandana Waddle Dee & Winged Star",
"release": {
"au": "2025-11-20",
"eu": "2025-11-20",
"jp": "2025-11-20",
"na": "2025-11-20"
}
},

icon_1f030100-04c91e03.png
https://amiibo.life/amiibo/kirby-air-riders/bandana-waddle-dee-winged-star

[cheatfreak47]

It's also important to note that these new amiibo appear to be on a new tag format that isn't understood properly yet.
The tag seems to be an ISO14443-3A- so I'm not even 100% sure there a way to populate the API with accurate data from these quite yet.

Some additional research might be needed to understand how these new amiibo work.

[cheatfreak47]

Images from Ske on discord (in the Flashiibo discord)

It looks like based on Ske's research into it, the figure itself contains the re-writable tag, and the machine acts as the antenna.
The machine figures also SEEM to contain a static SRAM area that is read separately with a different command when they are scanned in-game.

Some known SRAM dumps (truncated without the crc16) [apparently these are NOT figure agnostic, we probably need to collect a bunch of dumps of these to learn about what the data in these means.]

Warp Star SRAM
02 00 7f cb 95 65 61 af d1 ce 1c 96 b0 03 98 00 be 00 01 50 42 34 57 31 37 20 01 01 02

Wing Star SRAM
02 00 93 ad d8 1d 37 05 1a a3 53 84 1e 0b 44 00 9f 00 07 50 42 34 57 31 37 20 01 01 04

The amiibo seem to use a new key which would likely require a Switch 2 softmod in order to obtain public knowledge of, meaning Smash-style editing is not currently possible.

These new amiibo are v3 amiibo (hence the IDs above ending in 03 instead of 02)

This is the current state of research at the moment. Big thanks to Ske for doing a hack-down of these things and experimenting with them to figure out how they work.

[cheatfreak47]

On that note, the IDs provided by @Brickleberry19 are correct- however, the labels should probably be vehicle agnostic, because the IDs are read only from the character figure, especially if we plan to do anything with the SRAM stuff. So probably just "Kirby" and "Bandana Waddle Dee" for those.

As for what to do about the new SRAM stuff with vehicles, uh. Discussion and additional research needs done I suppose. Ske said he'll post a writeup here later about what he knows, so, that's helpful.

[xSke]

Hi, Ske from Discord here :)

The tags are NTAG I²C Plus 2K.

The data format is very similar to standard Amiibo, with the exception of:

• There are 64 bytes of seemingly random data between pages 0x20 and 0x30 (bytes 0x80-0xA0).
  • This seems unused for now? If I change it to all-zeros or something and emulate a bin, it loads fine. Possibly used in some key derivation for game-specific data though?
• The encrypted section that previously started at 0x80 (HMAC at 0x80, data at 0xA0) is shifted accordingly (now, HMAC at 0xA0, data at 0xE0). That data now spans to page 0x92 (ie. same size).
• Kirby Air Riders makes use of the extended data sizes, and writes its own data to at least pages 0x9A through 0xA1, and pages 0x11A through 0x131. This is encrypted in a way I haven't figured out yet; probably requires keys from a modded Switch 2.
• The config sections are now pages 0xE2 through 0xE6 - see the memory map on Table 5 on page 17 in the datasheet from NXP.

There's also the new SRAM buffer on pages 0xF0 through 0xFF that seems to be a way for the Amiibo to interface with external hardware going forward.

To interact with it, the Switch (including the stock amiibo applet!) does this:

• FAST_WRITE to page 0xF0-0xFF with a single 0x01 byte, all-zeros, and ending with a CRC-16/MCRF4XX, ie.

01 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 a4 03

• Polls page 0xED (also through a one-page fast read), the second half of the session registers, and checks NS_RED (byte 2) until SRAM_RF_READY (bit 3) is set - presumably this lets something else in the hardware read/write from that buffer
• FAST_READs page 0xF0-0xFF to get the resulting data - in the case of my Warp Star, it's:

02 00 7f cb
95 65 61 af
d1 ce 1c 96
b0 03 98 00
be 00 01 50
42 34 57 31
37 20 01 01
02 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 18 fd

As far as I can tell, there's no way to write to the "other" chip, and the data returned by the SRAM request is the same every time for the same amiibo.

However it seems device-specific - I asked /u/NewAmiiboMod to dump both their Warp Star and Winged Star. Their Winged Star dump is the one @cheatfreak47 posted above (that I put in Discord), and their Warp Star dump is different from mine (02 00 4c 98 0f 69 6f cf 51 28 f8 9e d4 b5 ab 00 9c 00 01 50 42 34 57 31 37 20 01 01 02).

It also seems authenticated in some way (beyond just the CRC-16 on transport); if I swap out known-valid SRAM chunks and emulate, they read fine as what they're supposed to (so we can trivially turn a Warp Star into a Winged Star, etc). But flipping any bit in the first 26 bytes (up to and including the 20, but not the 01 01 02/04) gives a read error. There's not really enough data for a proper HMAC, so it might just be a checksum of some other kind. Changing any data beyond that seems to do nothing (you can fill the padding with FFs and it reads fine) as long as you fix the CRC-16.

The decryption keys for the standard Amiibo sections are the same as normal, by the way. If you cut out the new 64-byte random data buffer from the middle, it'll encrypt and decrypt fine with eg. pyamiibo. Whatever Kirby's doing seems separate, and its data is somehow split between the regular appdata chunks and the new chunks. I don't want to drop an entire bin here for obvious reasons, but here are the metadata sections from my dump:

page 00: 04 0d 89 32
page 01: ab 1f 90 00
page 02: 44 00 0f e0
page 03: f1 10 ff ee
page 04: a5 00 02 00
...
page 15: 1f 03 01 00
page 16: 04 c9 1e 03
page 17: aa bb cc dd
page 18: cd 93 6f 66
page 19: 08 cf fb af
page 1a: f9 af a2 72
page 1b: bc 97 22 6b
page 1c: 32 d7 09 bb
page 1d: ad 57 3d 53
page 1e: f8 93 18 66
page 1f: 46 3d 4c b9
...
page e2: 01 00 ff 00
page e3: 00 00 00 04
page e4: 07 00 00 00
page e5: 00 00 00 00
page e6: 00 00 00 00
...
page ec: 41 00 f8 48
page ed: 08 01 29 00

It should be possible to make a "dumb" NFC dump if you ignore the FAST_WRITE to 0xF0:0xFF and put the output data in the bin as-is (the Switch only reads it after the request write), and hardcode page 0xED to what's in the above dump (with 0x29 in the third byte) to make it immediately read the response (otherwise it's going to be polling forever).

I've already looked through the Switch 1 NFC sysmodule, and it does have handling for skipping the extra data chunks and reading standard Amiibo data from the right offsets, which is how they're backwards compatible - but I haven't found any code for handling the SRAM data or any extra chunks. The Switch 1 doesn't request them at all.

[cheatfreak47]

@AbandonedCart Any input on the file layout possibility and/or supporting dumping these via Tagmo? I believe the Flashiibo Pro device will get support for these amiibo too, once an established tool is out there for making dumps of these new amiibo.

Initially I thought the best layout would be to make single files that append the vehicle SRAM to the NFC binary, but after some careful deliberation, I think It would be best to dump these as two files, one for rider, one for vehicle, so the swap functionality is possible to emulate without needing to do file editing mumbo jumbo.

[AbandonedCart]

I intended to keep them separate. Seems easy enough to flag them in the app by the version and the vehicles are a separate item in the package.

[AbandonedCart]

Looks like a third is coming soon

[cheatfreak47]

Yep, I actually already preordered it myself (I plan to collect all the Air Riders amiibo, as I absolutely LOVE Kirby Air Ride lol)
And two more (King Dedede & Tank Star and Chef Kawasaki & Hop Star) are also already announced for probably a few months after Meta Knight too.

[Brickleberry19]

[AbandonedCart]

The more I think about it, the approach i'll likely have to take is that a character is selected, which then requires selecting the vehicle, which is then written to the new card format. To change characters, it would require a separate card. I can't see there being an option like laying cards on top of each other that would actually function.