Poohl/failed_amiibo_write.txt

## failed_amiibo_write.txt
UPDATE AT THE END, got a semi-successful write.

I missed some setup that seems to be essential, but looks very similar to a standard read on the Switches side.

The response however is completely different
v generic crep ~~~~~~~~~~~~~~~~~~~~~~~vv Command for NFC
                                        vv read and buffer ntag
                                          vv sequence no
                                            vv ack sequence no
                                              vv end of transmission
                                                vv Payload length ~~~~~~~~~~~~~~~~~~~~
                                                    vv lenght of UID
                                                      vv UID ~~~~~~~ usually this is all 0, but when writing it isn't ?
                                                                       vv first difference to read request
0620350031004100a211040000000000000000020600000813d007047667e21f668001010303000000000000000000000000000000000000d3

In response to this the NFC-State goes to Pending Read (0x2), followed by a weird response:
v generic crep ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~vv This is NFC data?
                                                                                                                          vv this is the first message in a chain
                                                                                                                            vv ackseqno
                                                                                                                              vv this is the chain's end. 0 chains?
                                                                                                                                  vv State is Pending read
                                                                                                                                                vv UID length again
                                                                                                                                                  v UID ~~~~~~~~                                                                        vv first difference to normal read response
                                                                                                                                                                                                                                                          v where we would expect Tag data to start
06006f016b015100a1316c8e0000000000005d187604df0fc1009600d67386eeb9f4da0fc2009300598aa1ff2660d90fc10096000bfc0909ee223a0007010008400200000001020007047667e21f668000000000fdb0c0a434c9bf31690030aaef56444b0f602627366d5a281adc697fde0d6cbc010303000000000000f110ffee00...0014

State stays Pending read, after another status report this message is played back again with 2a in the this is NFC field (and updated checksum)

Then NFC goes into state 04, presumably awaiting write. Next thing


The writing itself (Commands from Switch):

v generic crep ~~~~~~~~~~~~~~~~~~~~~~~vv Command for NFC
                                        vv write ntag
                                          vv sequence no
                                              vv More data                                                     vv some kind of checksum
                                                vv Payload length ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                                    vv UUID Length
                                                      v UUID ~~~~~~~vv follows uid in tag     vv word32 idx
                                                                          vv word32 idx, bytec  vv byte count
                                                                                    v~~~~~~~~ lock page to write after success (page 4 / bytes 16-20)
0a20350031004100a21105000000000000000002080100001fd007047667e21f668001000104ffffffffa500010003052083088d73ff35888e
Data:                                                                       ^0xa0~~~              ^0xa4~~~~~~~~~   // 04, 05
                                                                            ^^    ^^ "write lock", all tags with this set to ff are considered invalid
                                                                                                    vv word32 idx
                                                                                                      vv byte count // is this the maximum possible?
0a20350031004100a21106000000000001404002080200001f9e4208775bd8d12925b1896e95c882c9237fda5c0876b2de2820f05caa6db7d8
Data:                                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~    ^0x80~~~   // 20

0a20350031004100a21107000000000000000002080300001f0d4f3a7471c8ccda4011b3596d7cc5c08d3330ee120d62c6c341726af6c74566
Data:                                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

0a20350031004100a21108000000000000000002080400001f8f9f938145ad6aa1f6c2af2919e03d171c4904185702fa9068f085cb4505b4da
Data:                                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

0a20350031004100a21101000000000000000002080500001feff60973335619c7df36518838daddd889c6388e4a671168044b9d282211f0cb
Data:                                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

0a20350031004100a21106000000000001404002080600001f86fed223514adf96ff3f08ee6719155f836ec96b935c38aac0666bfd5f6bcdff
Data:                                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

0a20350031004100a21107000000000000000002080700001fa9d34063fc121bb3cb469d7cdd6efa6230fc1378cf39ae6c3ea809f13a529713
Data:                                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

0a20350031004100a21108000000000000000002080800001f95af91a626f3736e0bb2494626e5324d54f7f992e268b534795dea8e6565764a
Data:                                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

0a20350031004100a21109000000000000000002080900001f76efa5e222ddf2ea869e36aa5caba6da22f361de7458ae9be30c90822624df70
Data:                                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                                                                                        vv word32 idx
                                                                                          vv 0x48 were written, 152 should be?
0a20350031004100a2110a000000000000000002080a00001f78643e692227dba98976061b2956cc00bcddef5c98615527b4c63b6d1ef1d7b8
Data:                                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~    ~~~~~~~~~~~~~~~~~~~~   // just continues

0a20350031004100a2110b000000000000000002080b00001f5310cbaf6340a80e5df15ab43bb963c4fc4c16659623cb5deb5fa7ddddfde8fc
Data:                                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

0a20350031004100a2110c000000000000000002080c00001f4f65afd43cb7077abf4e22f8c27c9058f83f962b4beee3fdcb7e311eba10a241
Data:                                             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

0a20350031004100a2110d000000000000000002080d00001fac6cbb0080694c4491fbabb6db12cd01e2d9aef3e2ce7dc2ef41f869633315cf
Data:                                             ##############################################################  // not in tag

0a20350031004100a2110e000000000001404002080e00001fefa60d3abccd118e4428fe6853bb620564fe3da619ce06706a38c4826a00711e
Data:                                             ##############################################################  // not in tag

                                              vv End of transmission                    vv last byte of payload
0a20350031004100a2110a000000000000000002080f00081408107a2765c8c79be7b3f19b530e8c3775f300000000000000000000000000d3
Data:                                             ####################################                            // not in tag


checksum is crc8 over one of the following regions with corresponding initial value
initial 0x02                          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
initial 0x00                            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
initial 0x38                              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0a20350031004100a2110e000000000001404002080e00001fefa60d3abccd118e4428fe6853bb620564fe3da619ce06706a38c4826a00711e
confidence on these is 15/15 messages


Response to every packet (Note that the write was not successful and got stuck at ack seq no 12):
v generic crep ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~vv message type = NFC status
                                                                                                                          vv seq no = 0 (status reports fit in one response)
                                                                                                                            vv ack seq no = incoming seq no
                                                                                                                                  vv NFC subsystem state = 0x03 (presumably writing)
                                                                                                                                                  vv payload length = 7 (UID length)
                                                                                                                                                    v UID ~~~~~~~~        vv regular checksum
0a006f016b014900a131e58e000000000000d578730c8a0100feccf0660a879411b69401f8fdcaf0dbdbb7fe63209401f5fdc7f0f4f313f7a4232a000500030931030000000101020007047667e21f668000 .. 002c


UPDATE From another write, that was successuful despite the switch thinking otherwise:

(these are all responses to generic looking and identical NFC status requests like the following. Note that these requests were sent all the time after the write requests and not nearly all were answered at all)
0d20350031004100a2110200000000000000000204000008000000000000000000000000000000000000000000000000000000000000000087


When you actually get ack seq no to increase all the way, you get the following:

v generig crep ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~vv message type=NFC status
                                                                                                                          vvvv seq no & ack seq no = 0, this is a single message and previous was sent
                                                                                                                                  vv NFC subsystem state = 0x05!!!! presumably some kind of processing-write
                                                                                                                                                  vv payload is the UID again
0c206f016b014100a131a88e0000000000003868730bb700a5ff6df0d651449ccdafba00a7ff6cf0e9ff2e015a60b700a5ff6df0ff0f1480c7222a000500000931050000000101020007047667e21f66800 .. 001c

then the switch sent a stop polling request:
0d20350031004100a2110000000000000000000202000008000000000000000000000000000000000000000000000000000000000000000050

afterward the UID dissaperad from the message. Is all the missing stuff polling related?
v generig crep ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~vv message type=NFC status
                                                                                                                                    v just zeros from here instead of the payload part
0c206f016b014100a131bd8e0000000000003558730cbe009fff69f076554496d92fbb00a0ff6af093ffc6fece80b900a5ff6df0f7e305fceb3e2a0005000009310500000000 .. 001d

this was sent 3 times, followed by the same thing but with NFC subsystem state 0x00:
                                                                                                                                  vv NFC subsystem state None
0c206f016b014100a131d28e0000000000003668730bbd00aaff6ef0168644cce46fbf00abff72f094ff96015660be00aaff71f00018120118232a0005000009310000 .. 000f

Afterwards the switch read the tag back (and seemingly wasn't happy) but most notably the 0xffffffff written in packet 1 to page 3 (= bytes [12-16[) were almost replaced back to the original 0xa5XXXX00.
The only difference is the XXXX part, which according to https://wiki.gbatemp.net/wiki/Amiibo is a write counter and this matches with what happened, since interpreted as big endian value it increased by one.
	UPDATE AT THE END, got a semi-successful write.

	I missed some setup that seems to be essential, but looks very similar to a standard read on the Switches side.

	The response however is completely different
	v generic crep ~~~~~~~~~~~~~~~~~~~~~~~vv Command for NFC
	vv read and buffer ntag
	vv sequence no
	vv ack sequence no
	vv end of transmission
	vv Payload length ~~~~~~~~~~~~~~~~~~~~
	vv lenght of UID
	vv UID ~~~~~~~ usually this is all 0, but when writing it isn't ?
	vv first difference to read request
	0620350031004100a211040000000000000000020600000813d007047667e21f668001010303000000000000000000000000000000000000d3

	In response to this the NFC-State goes to Pending Read (0x2), followed by a weird response:
	v generic crep ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~vv This is NFC data?
	vv this is the first message in a chain
	vv ackseqno
	vv this is the chain's end. 0 chains?
	vv State is Pending read
	vv UID length again
	v UID ~~~~~~~~ vv first difference to normal read response
	v where we would expect Tag data to start
	06006f016b015100a1316c8e0000000000005d187604df0fc1009600d67386eeb9f4da0fc2009300598aa1ff2660d90fc10096000bfc0909ee223a0007010008400200000001020007047667e21f668000000000fdb0c0a434c9bf31690030aaef56444b0f602627366d5a281adc697fde0d6cbc010303000000000000f110ffee00...0014

	State stays Pending read, after another status report this message is played back again with 2a in the this is NFC field (and updated checksum)

	Then NFC goes into state 04, presumably awaiting write. Next thing


	The writing itself (Commands from Switch):

	v generic crep ~~~~~~~~~~~~~~~~~~~~~~~vv Command for NFC
	vv write ntag
	vv sequence no
	vv More data vv some kind of checksum
	vv Payload length ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	vv UUID Length
	v UUID ~~~~~~~vv follows uid in tag vv word32 idx
	vv word32 idx, bytec vv byte count
	v~~~~~~~~ lock page to write after success (page 4 / bytes 16-20)
	0a20350031004100a21105000000000000000002080100001fd007047667e21f668001000104ffffffffa500010003052083088d73ff35888e
	Data: ^0xa0~~~ ^0xa4~~~~~~~~~ // 04, 05
	^^ ^^ "write lock", all tags with this set to ff are considered invalid
	vv word32 idx
	vv byte count // is this the maximum possible?
	0a20350031004100a21106000000000001404002080200001f9e4208775bd8d12925b1896e95c882c9237fda5c0876b2de2820f05caa6db7d8
	Data: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^0x80~~~ // 20

	0a20350031004100a21107000000000000000002080300001f0d4f3a7471c8ccda4011b3596d7cc5c08d3330ee120d62c6c341726af6c74566
	Data: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

	0a20350031004100a21108000000000000000002080400001f8f9f938145ad6aa1f6c2af2919e03d171c4904185702fa9068f085cb4505b4da
	Data: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

	0a20350031004100a21101000000000000000002080500001feff60973335619c7df36518838daddd889c6388e4a671168044b9d282211f0cb
	Data: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

	0a20350031004100a21106000000000001404002080600001f86fed223514adf96ff3f08ee6719155f836ec96b935c38aac0666bfd5f6bcdff
	Data: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

	0a20350031004100a21107000000000000000002080700001fa9d34063fc121bb3cb469d7cdd6efa6230fc1378cf39ae6c3ea809f13a529713
	Data: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

	0a20350031004100a21108000000000000000002080800001f95af91a626f3736e0bb2494626e5324d54f7f992e268b534795dea8e6565764a
	Data: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

	0a20350031004100a21109000000000000000002080900001f76efa5e222ddf2ea869e36aa5caba6da22f361de7458ae9be30c90822624df70
	Data: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	vv word32 idx
	vv 0x48 were written, 152 should be?
	0a20350031004100a2110a000000000000000002080a00001f78643e692227dba98976061b2956cc00bcddef5c98615527b4c63b6d1ef1d7b8
	Data: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~~~~~~~~~~~~~~~ // just continues

	0a20350031004100a2110b000000000000000002080b00001f5310cbaf6340a80e5df15ab43bb963c4fc4c16659623cb5deb5fa7ddddfde8fc
	Data: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

	0a20350031004100a2110c000000000000000002080c00001f4f65afd43cb7077abf4e22f8c27c9058f83f962b4beee3fdcb7e311eba10a241
	Data: ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

	0a20350031004100a2110d000000000000000002080d00001fac6cbb0080694c4491fbabb6db12cd01e2d9aef3e2ce7dc2ef41f869633315cf
	Data: ############################################################## // not in tag

	0a20350031004100a2110e000000000001404002080e00001fefa60d3abccd118e4428fe6853bb620564fe3da619ce06706a38c4826a00711e
	Data: ############################################################## // not in tag

	vv End of transmission vv last byte of payload
	0a20350031004100a2110a000000000000000002080f00081408107a2765c8c79be7b3f19b530e8c3775f300000000000000000000000000d3
	Data: #################################### // not in tag


	checksum is crc8 over one of the following regions with corresponding initial value
	initial 0x02 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	initial 0x00 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	initial 0x38 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
	0a20350031004100a2110e000000000001404002080e00001fefa60d3abccd118e4428fe6853bb620564fe3da619ce06706a38c4826a00711e
	confidence on these is 15/15 messages


	Response to every packet (Note that the write was not successful and got stuck at ack seq no 12):
	v generic crep ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~vv message type = NFC status
	vv seq no = 0 (status reports fit in one response)
	vv ack seq no = incoming seq no
	vv NFC subsystem state = 0x03 (presumably writing)
	vv payload length = 7 (UID length)
	v UID ~~~~~~~~ vv regular checksum
	0a006f016b014900a131e58e000000000000d578730c8a0100feccf0660a879411b69401f8fdcaf0dbdbb7fe63209401f5fdc7f0f4f313f7a4232a000500030931030000000101020007047667e21f668000 .. 002c


	UPDATE From another write, that was successuful despite the switch thinking otherwise:

	(these are all responses to generic looking and identical NFC status requests like the following. Note that these requests were sent all the time after the write requests and not nearly all were answered at all)
	0d20350031004100a2110200000000000000000204000008000000000000000000000000000000000000000000000000000000000000000087



	When you actually get ack seq no to increase all the way, you get the following:

	v generig crep ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~vv message type=NFC status
	vvvv seq no & ack seq no = 0, this is a single message and previous was sent
	vv NFC subsystem state = 0x05!!!! presumably some kind of processing-write
	vv payload is the UID again
	0c206f016b014100a131a88e0000000000003868730bb700a5ff6df0d651449ccdafba00a7ff6cf0e9ff2e015a60b700a5ff6df0ff0f1480c7222a000500000931050000000101020007047667e21f66800 .. 001c

	then the switch sent a stop polling request:
	0d20350031004100a2110000000000000000000202000008000000000000000000000000000000000000000000000000000000000000000050

	afterward the UID dissaperad from the message. Is all the missing stuff polling related?
	v generig crep ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~vv message type=NFC status
	v just zeros from here instead of the payload part
	0c206f016b014100a131bd8e0000000000003558730cbe009fff69f076554496d92fbb00a0ff6af093ffc6fece80b900a5ff6df0f7e305fceb3e2a0005000009310500000000 .. 001d

	this was sent 3 times, followed by the same thing but with NFC subsystem state 0x00:
	vv NFC subsystem state None
	0c206f016b014100a131d28e0000000000003668730bbd00aaff6ef0168644cce46fbf00abff72f094ff96015660be00aaff71f00018120118232a0005000009310000 .. 000f

	Afterwards the switch read the tag back (and seemingly wasn't happy) but most notably the 0xffffffff written in packet 1 to page 3 (= bytes [12-16[) were almost replaced back to the original 0xa5XXXX00.
	The only difference is the XXXX part, which according to https://wiki.gbatemp.net/wiki/Amiibo is a write counter and this matches with what happened, since interpreted as big endian value it increased by one.