Skylander Dump Files
Zareen Zapata
We use a specific file format (FFF, Flipper File Format, .nfc for NFC files), to which you need to convert your proxmark dumps to use. This was done intentionally to make the files human-readable as well as easy for our weak CPU to parse, and proxmark3 files do not fit into those criteria.
Hi! I used the script to dump the json from proxmark3 to nfc and when i use FZ say a text " can not parse file " and I used the script python3 script -i archive_dump.json -o archive.nfc , but dont work , any idea?? thanks
Given the amount of different versions of Skylanders games that exist, alongside the large number of figures and figure types released, I quickly realized that I needed to limit the scope of this project to something that I could actually manage.
All the data in this paper will be limited to the Wii version of all Skylanders games, meaning that both the normal version of Skylanders: Superchargers, any version of Skylanders: Imaginators, mobile-exclusive games, and any alternative game for the 3DS will not be discussed and that this research, specifically the parts related to portal communication, might not apply.
Nearly every Skylander game shipped with a new portal, which all have some slight differences. The Traptanium Portal, released alongside Skylanders: Trap Team has all the functions any other portal has and can be used on any game for a console with a USB port. Although commands have been verified on other portals where possible, most of the research was done on a Traptanium Portal.
The first challenge I encountered when researching the portal was how to actually read the information being sent between the portal and the game/console. My first idea was to use a USB logic analyzer to read the data being sent, but these are either wildly expensive or require me to modify my portal in some way. With these methods out of the way, I started looking for different options. This is when I remembered that Dolphin exists. Dolphin is the leading emulator for the Nintendo Wii and allows USB-passthrough, meaning that I could extract the game files from my own discs to be used within Dolphin. This allowed me to play the Skylanders games on my PC without a need for the console itself.
After getting Skylanders running I had to figure out a way to read the data being sent. Luckily, this was easily done using Wireshark and an extension called USBPCap. Wireshark is a program designed to capture and analyze data being sent over the network and USBPCap extends its capabilities to reading the communication to and from specific USB devices. With this, I could freely read all data being sent to and from the portal alongside some other useful information like timing. To make this process easier, I built a Wireshark dissector which I will discuss later.
If you have ever used a keyboard or mouse, you have used the same type of device as the Skylanders portal. They all use a USB standard called HID (Human Interface Device). This specification describes how to send and receive packets of data, often containing human input.
Looking at the descriptors, we can see that every portal has 2 endpoints. The direction of endpoint 0 is IN and the direction of endpoint 1 is OUT. These directions are not from the perspective of the device but from the perspective of the host. In this case, that would be my PC or, when the device is being used on a console, the console. Both endpoints use the interrupt transfer type.
There is a third endpoint that is not reported by any descriptor. Every USB device is required to have a default endpoint. The purpose of this endpoint is to retrieve descriptor data, configure the device, and perform operations specific to this device. Transfers to this endpoint are called control transfers.
The games and portals communicate with each other with what I call commands, 32 byte-long packets of data which all share some common elements. The first byte in every command dictates which command it is. This byte encodes a capital ASCII character. This first byte will from now on be referred to as the command character. Most commands can be given a name where the command character is the first character of the name.
As previously mentioned, every command is 32 bytes long. Most of this space goes unused since no command is 32 bytes long. When generating the data for a command, all bytes of the 32-byte long buffer are set to 0x00. When emulating either a portal or a console, a buffer with just the length of the data can be sent, but padding the buffer to 32 bytes is recommended for the most accurate emulation.
As can be seen, there are two distinct lines around the 0.02-0.03 seconds. The median of all my data points gave me 0.020003 seconds or about 20 milliseconds. This means that the portal tries checking for incoming commands, or sending a Status response, 50 times per second, although this can vary quite a bit. The lowest time between responses was 0.000993 seconds, or 0.993 milliseconds, whilst the highest time between responses was 1.539001 seconds or 1539 milliseconds.
Although it is recommended that any device aiming to emulate a Skylanders portal adheres to the timing of 50 Hertz, all the games are fully capable of handling packets sent at a higher rate or even a slightly lower rate.
One of the first commands sent by the game is the Activate command. This command is used to activate the portal and many of its features. This command should be used before any other commands with the exception of the Ready command. Although some commands will still work, others like the Query and Write command will not.
When the portal is activated, it will periodically send out Status responses even when no Status request has been sent. If the portal has not been activated, or if it has been deactivated again, Status responses will still be sent when requested. If a Deactivate request is received by a portal, all LEDs will turn off. They can be turned on again by their respective commands.
The Activate request is very simple. It is the command character followed by a boolean dictating whether to turn the portal on or off. For this boolean, and every other boolean in the communication protocol, 0x01 is true and 0x00 is false.
The response mirrors the first two bytes of the request followed by the constant bytes 0xFF and 0x77. The function of these constants is unknown.The Color commandOne of the easiest commands, but one whose effects are also the most easily visible. Except for the portal that accompanies Skylanders: Superchargers, every portal has one or more LEDs which are used to illuminate the base of the portal. By default, these LEDs cycle through a range of colors. Using this command, the color can be set to a specific color.
This command is one of a few which only go one way. After receiving this command, any portal containing LEDs will set its colors. No response is sent, regardless of whether the portal has LEDs or not.
Alongside Skylanders: Trap Team, a new portal was released called the Traptanium Portal. Alongside a lot of other cool features like a speaker and a slot for a trap figurine, the portal features a ring that lights up from two sides instead of having a single LED in the base. These LEDs can be controlled separately. This is what the J command is for.
The first argument after the command character is the side to light up. When orienting the portal so that the speaker faces towards you, an argument of 0x00 means left, and an argument of 0x02 means right. For a while, I assumed 0x01 would set both sides to the same color, but this turned out to be a mistake in my implementation of this command in my program.
Another new feature of the J command is the ability to fade between colors. The Color command immediately switches an LED to the designated color, whereas the J command can fade between the current and the desired color. This is what the last two bytes are for. These bytes, stored as a little-endian u16, represent how long the fade should last in milliseconds.
Unlike the Color command, the J command does require a response. This is because of the timing of the fades. The game needs to know when a command was received so it can calculate when to send the next command. The response is the command character without any additional data.
After the side, the command deviates based on which side was provided. If either left or right was specified, the next 3 bytes form an RGB color, just like in the Color and J commands. However, if the trap slot was specified, only one extra byte is provided, the brightness. The LED in the trap slot will only ever output the color white. The only thing that can be changed is the brightness.
Unlike the J command, the Light command does not have any extra arguments after the color or brightness. Both the changes to the LEDs in the base and the LED in the trap slot will happen instantaneously. This also means that the command does not need a response from the portal.
Another caveat with this command, and something that made this command incredibly difficult to reverse engineer at first, is that the light will only be on if there is currently a figure being read by the trap slot, be that a trap inserted into it or a normal figure right on top of it. If this is not the case, or if one is removed, the light will immediately turn off. The state is still stored and the light will turn on with the right brightness once the trap slot starts reading a figure again.
The Music command is somewhat similar to the Activate command in the sense that it activates and deactivates the speakers. This means that the structure for the request is also the same, that being the command character followed by either a 0x00 or 0x01 depending on whether the speakers need to be turned on or off.
The Music command is weird in that it does require a response, but it does not need to be instantaneous. After having sent a few activation commands, the game starts sending music data. Meanwhile, the game will keep sending more Music requests. This means that, until the portal sends a response, the game is unable to send any other commands and therefore will cease to function properly.
4a15465005