Corrupting Amiibo BIN Files

So, remember when I posted my research compilation thread, and explained the layout of the NFC chips used in amiibo?

Well, part of the findings others had was that one could write total garbage to anything but the header/ID/validation regions of data.

So what'll happen to Luigi if I shove a BIN file of his through a corruptor program?

Basically, I'll be garbling up the amiibo's data willy-nilly to see what, if anything, happens.

Out of 540 bytes, the only bytes not kosher to mess with are the first four, though I have a hunch that I'll be best off messing with the Writeable pages first instead of garbling everything.

But just as an initial test, what'll happen to poor Luigi if I just blast the BIN file with memory corruption?

---

First, I'll be using a series of "Linear Blaster" functions courtesy of the Chain Chomp corruptor program. This injects noise into the file with a 'blast radius' centered around a target memory offset. In other words, the data is more strongly corrupted at the specified point, and then it tapers off away from there.

I'll be chucking three of these into the main memory regions of the amiibo, where I'd guessed that experience data was stored:

1 at offset 100, 256 bytes from the start of my corruption range, which is itself 64 bytes after the start of the file for the sake of omitting critical data. This blast will corrupt 80 bytes on either side of that address, which means the 'front' half of it will be truncated by the limiting parameters I set. Each of those bytes will be set to FF (256), then gradually averaged down closer to their original values the further they are from offset 100.

The second blast is at A0, 160 bytes from the start, to deliberately create a secondary blast within the first. This is where the openly writeable data can be found, so I'm targeting that with a much narrower blast of only 10 bytes, setting the values to 1.

The third blast targets address 1F1, 436 bytes from the start, with a radius of 42 bytes in either direction, once again setting those bytes to FF (256) and averaging down to their originals.

---

Alright, I've loaded the completely messed-up Luigi BIN file back onto the amiibo! Let's see what happens...

IT'S EPM

Welcome back, man!

It probably shouldn't be surprising I've been scarce. Having approached amiibo like puzzles, I lost interest after obtaining the solution.

But sadly, this experiment was a total failure. Even much smaller-scale adjustments to the corruption attempts would lead to powersaves failing to upload the amiibo. Because, in retrospect this should have been obvious, the checksums and validation codes were all failed, and they check nearly all of the amiibo's data. The only ranges they don't check are completely irrelevant.

I read that you can corrupt an amiibo by loading up a Smash mod (that changes the way characters move/attack/etc) and training it in that the entire way, and then trying to load it back up in normal Smash. Someone reported this happening on a 3DS though, not sure if it'd work the same on a Wii U.

That wouldn't necessarily be a data corruption, but it would certainly yield screwy results. It does beg the question, though... what would be the STRANGEST way to train an amiibo?

Train them in something like Silly Melee (if such a mod existed for smash 4). Silly Melee CPU Tournament