[FINISHED] A popular toy, Disney Infinity

iceman · 2015-04-10 13:29:52

[edit]update info[/edit]

DI 1.0, 2.0, 3.0

----------------------------------------------------------------------------------
DI uses Mifare Mini 0.3K, same diversified key for all sectors.

sim and sniff is one way of getting key. use Nested to get a dumpkeys-file.
or use didump.lua with key.

Keygen_algo is unknown.
DATA encryption is known.

pm3 --> hf 14a re
ATQA : 00 44
 UID : 04 29 81 ea 1f 31 80
 SAK : 09 [2]
MANUFACTURER : NXP Semiconductors Germany
TYPE : NXP MIFARE Mini 0.3k
proprietary non iso14443-4 card found, RATS not supported
Answers to chinese magic backdoor commands: NO

Last edited by iceman (2016-02-10 11:00:08)

asper · 2015-04-10 15:07:39

Can you test a sniff key decoding attack and see if it works?

iceman · 2015-04-10 15:49:17

well, I bought a figurine, not a complete game/portal/figures starter pack

I read somewhere it was Ultralight, but its not.

UID 7bytes, the tag doesn't respond at all to "hf mf mifare", nor does the default keys work.
I'm guessing that sniff a key is the viable option here.

iceman · 2015-04-13 13:07:24

Sometimes the stuff that comes into the mailbox is amazing.

I just learnt that the whole encryption / decryption / checksums for this one is mapped and known.

As a sidenote,
I'm guessing that the version 1 is Mifare Mini based, and version2.0 is Mifare Ultralight-C based of the tokens.
That means my magic UL-C tags will come in handy pretty soon! *everything is awesome*

Total amount of data on a token is 64bytes, with a bunch of checksums included.

Last edited by iceman (2015-04-13 13:42:30)

asper · 2015-04-13 13:40:01

Great finding !!

iceman · 2015-04-13 13:44:13

What a jewel, Asper!

and if it is as you say, that the portal is the same for all platforms, I might as well just buy a starter pack and start sniffing some traffic..

asper · 2015-04-13 14:03:30

The only different portal seems to be the xbox portal (different vid/pid).

Last edited by asper (2015-04-13 14:21:38)

iceman · 2015-04-22 21:28:35

I got my hands on a starterpack. The "base" (reader) is not recoqnised by the game on PC. @asper, do you know something?!
It is identified by win8.1 as a "Disney Infinity reader" when I plug it in.

"USB device vid:0E6F pid 0129"

asper · 2015-04-22 21:50:22

It is a Logic3 device [VID:0E6F], it should work for what forum users say.
Try to contact the producer here: http://www.logic3.com

asper · 2015-04-22 21:58:22

Another very interesting link:
http://www.disneyinfinityfans.com/viewtopic.php?f=9&t=11200

asper · 2015-04-22 22:04:07

And this (i think he is the same guy): http://m.youtube.com/watch?v=2MIiIDQaAZo

iceman · 2015-04-26 16:11:44

After very good help, I managed to get a base (Disneys portal) to work with a PC.
From there I managed to sniff the trafic.
and was able to run the attacs against it and get the keyA.
the nested command tells a story of a single key... One key to rule a tag.

So what we know today.
: Mifare Mini
: one key for all blocks.
: decrypting/encrypting data is already known

Next step: Figuring out the key-gen-algo.
---- Should be a UID based diversification.
---- Same approach as the other toy-tokens will be used (sim UID, collect, crack, analys relation KEY <-> UID )

pm3 --> hf 14a re
ATQA : 00 44
 UID : 04 xx xx xx xx xx 80
 SAK : 09 [2]
MANUFACTURER : NXP Semiconductors Germany
TYPE : NXP MIFARE Mini 0.3k
proprietary non iso14443-4 card found, RATS not supported
Answers to chinese magic backdoor commands: NO

pm3 --> hf mf nested 0 4 A 6dd747e86975
Testing known keys. Sector count=5
nested...
Time in nested: 1.825 (inf sec per key)

-----------------------------------------------
Iterations count: 0

|---|----------------|---|----------------|---|
|sec|key A           |res|key B           |res|
|---|----------------|---|----------------|---|
|000|  6dd747e86975  | 1 |  6dd747e86975  | 1 |
|001|  6dd747e86975  | 1 |  6dd747e86975  | 1 |
|002|  6dd747e86975  | 1 |  6dd747e86975  | 1 |
|003|  6dd747e86975  | 1 |  6dd747e86975  | 1 |
|004|  6dd747e86975  | 1 |  6dd747e86975  | 1 |
|---|----------------|---|----------------|---|

pm3 --> hf mf rdbl 0 a 6dd747e86975
--block no:0, key type:A, key:6d d7 47 e8 69 75
#db# READ BLOCK FINISHED
isOk:01 data:04 xx xx xx xx xx 80 89 44 00 c2 00 00 00 00 00

pm3 --> hf mf rdsc 0 a 6dd747e86975
--sector no:0 key type:A key:6d d7 47 e8 69 75

Last edited by iceman (2015-04-26 16:12:29)

iceman · 2015-05-06 09:10:36

I found out that the sim-command, needs to have some checks commented out for the "x" crack option to work, despite the updated prng.

Now I only need to write a script (batch?) to run the "power-portal-do-a-read" in a loop, and a lua script that fakes UID and gathers the output from the sim command (and run the mfkey32) to collect the keyA.

both somehow I got stuck on fixing ultralight cmds.. dang...

iceman · 2015-05-26 16:08:06

I added the SHA1 from polar ssl package now to the client in my fork, and made it accessable from LUA.

I can now start with writing a dump lua script for a disney token.

iceman · 2015-05-26 21:35:12

brand new token,

Sector 0,
Block 1, 2 read only, accessbytes: 17878E

all other sectors, all block open, accessbytes 778788

So, what so special with block 1 and 2..

decrypted data:

s#| b# | data
0 | 0 |  nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn
0 | 1 |  000F42430D0A14000001D11F5D738517
0 | 2 |  00000000000000000000000000000000
0 | 3 |  6dd747e8697517878E006dd747e86975

1 | 0 |  00000000000000000000000000000000
1 | 1 |  00000000000000000000000000000000
1 | 2 |  00000000000000000000000000000000
1 | 3 |  6dd747e86975778788006dd747e86975

2 | 0 |  00000000000000000000000000000000
2 | 1 |  00000000000000000000000000000000
2 | 2 |  00000000000000000000000000000000
2 | 3 |  6dd747e86975778788006dd747e86975

3 | 0 |  00000000000000000000000000000000
3 | 1 |  00000000000000000000000000000000
3 | 2 |  00000000000000000000000000000000
3 | 3 |  6dd747e86975778788006dd747e86975

4 | 0 |  00000000000000000000000000000000
4 | 1 |  00000000000000000000000000000000
4 | 2 |  00000000000000000000000000000000
4 | 3 |  6dd747e86975778788006dd747e86975

Last edited by iceman (2015-06-13 22:36:10)

iceman · 2015-05-27 11:46:23

[edit]

The game only uses 4*16 bytes, total 64bytes of the tokens capacity 320bytes. And part of that data is used for checksums.
data part is 64-16 = 52bytes.

It reads it:

Sector# Block
-----------------
S0  B1
S1  B0
S2  B0
S3  B0

Checksums:
on every used block, there is a 4 byte checksum in the end.

S0-B1  00112233445566778899AABB [CCDDEEFF]

Last edited by iceman (2015-05-27 17:45:03)

iceman · 2015-06-16 10:30:05

I wonder if the "hf mf sim" can be used. It has had some issues if I remember correct. I need test it.

securitoys · 2015-10-04 13:14:46

Hi! Okay. I couldn't get `hf mf sim x` to work at all, but following up on http://www.proxmark.org/forum/viewtopic.php?id=2451, I got `hf 14a sim x` working.

With it, I've successfully sniffed keys from 20 figures across all three generations of the game, and spot-checked their validity with `hf mf chk` and `didump`.

Would the list of UIDs + keys A and/or the full dumps be of value to you? I can send them to you, if so.

I'm going to pick up a few more as soon as the shops open to see if I can verify where the figure model type is encoded.

One other thing. While `hf 14a sim` will reliably fake out the reader enough to get a key, the game won't always recognize the simulated figure as valid. `hf mf eload 0` and then `hf mf sim n 0 i` or `hf 14a sim t 6` both seem to just lock up the game's ability to sense figures, and I have to exit to the main menu. Thoughts?

iceman · 2015-10-04 17:33:11

The "Hf mf sim" command has its problems and I never really got it to work very well. There should be an old issue on GitHub about it.

That list would be very nice to have. You can upload it somewhere, or mail me.

If you want to "genuinly" sim a whole tag, you need to load a correct and encrypted dump, I think when I was at it another user @Marshmellow did a fix for the "hf mf eload" in one branch "ntag/sim" of his fork.

I just added his changes to my fork, not sure if Im gonna push it yet..

bettse · 2015-10-04 21:24:10

securitoys wrote:

I'm going to pick up a few more as soon as the shops open to see if I can verify where the figure model type is encoded.

sector 0, block 1, offset 0, length 4, An unsigned integer. The values are the same as printed on the bottom of the models, which are also enumerated here: http://disneyinfinity.wikia.com/wiki/Disney_Infinity/Model_Numbers

two caveats:
* The endianness is inverted from that of the common desktop machine, I think its big endian on the token. I can never keep them straight.
* Block 1 is encrypted. There are publicly available tools to handle that, feel free to email me (bettse@fastmail.fm) for specifics.

securitoys · 2015-10-05 05:20:22

Ah, yes, okay, that's what I'm seeing on these duplicate figures I picked up. The older documentation I have suggested block 0 had it in the same place, which didn't make sense to me, unless it was part of the UID, leaving only the last three bytes as the "real" UID, or block 0 was encrypted, and the visible UID was "fake".

Is block 0 not encrypted?

Here are the UIDs, keys A, and raw block 0 for the 32 opened figures I have: http://pastebin.com/hmK8K8vj

I also took some time to generate some fake UIDs, record the key generated for them by the portal, and included those. Oddly, the portal wouldn't talk to any simulated token if the first four bytes of the UID were 00000000.

I notice everything after the UID in block 0 is the same. If you assume that all figures have the same data after the UID in block 0, then I suppose it's possible the key generation algorithm could "decrypt" block 0 and use that as a starting point, as well. I generated the "decrypted" block 0 for all those records here: http://pastebin.com/hwCXJv0Z

Hope this helps.

bettse · 2015-10-05 05:49:25

block 0 isn't encrypted. Its often referred to as the manufacture block, so I think there maybe requirements that it be clear.[1]

[1] https://learn.adafruit.com/adafruit-pn532-rfid-nfc/mifare

Manufacturer Block (Sector 0, Block 0)
Sector 0 is special since it contains the Manufacturer Block. This block contains the manufacturer data, and is read-only. It should be avoided unless you know what you are doing.

iceman · 2015-10-05 09:57:04

Great work @Securitoys! That list will be helpful indeed.

iceman · 2015-10-06 12:52:11

@securitoys
Could you collect the following sequences of fake uid and their key?

10 00 00 00 00 00 00 01 00 00 00 00 00 00 .... 00 00 00 00 00 00 10 00 00 00 00 00 00 01
20 00 00 00 00 00 00 02 00 00 00 00 00 00 .... 00 00 00 00 00 00 20 00 00 00 00 00 00 02
40 00 00 00 00 00 00 04 00 00 00 00 00 00 .... 00 00 00 00 00 00 40 00 00 00 00 00 00 04
80 00 00 00 00 00 00 08 00 00 00 00 00 00 .... 00 00 00 00 00 00 80 00 00 00 00 00 00 08

the above uids should be seens as:
10 00 00 00 00 00 00 01 00 00 00 00 00 00
01 00 00 00 00 00 00 00 10 00 00 00 00 00
00 10 00 00 00 00 00 00 01 00 00 00 00 00
00 01 00 00 00 00 00 00 00 10 00 00 00 00
...
00 00 00 00 00 00 10 00 00 00 00 00 00 01

securitoys · 2015-10-07 08:54:25

securitoys wrote:

Oddly, the portal wouldn't talk to any simulated token if the first four bytes of the UID were 00000000.

Later, I realized this didn't make any sense, and that it probably meant I screwed up my hacks to cmdhf14a.c to force it to always send 7-byte UIDs. And, lo, I had. This means that a few of the generated fakeuid keys A in those pastebins are wrong. Sorry!

I think I understood your request correctly. I double-checked all the previous keys, and all of these new keys should be correct. http://pastebin.com/Hw58EbxT

iceman · 2015-10-07 09:03:57

Prefect! and Thank you so much,

I got the request from another user, I realized now when I look at the UID table it looks like crap. BUT you understood it correct.

Do you think you can do the:
9-F series aswell?

90 00 00 00 00 00 00
A0 00 00 00 00 00 00
..
F0 00 00 00 00 00 00

securitoys · 2015-10-08 10:31:41

http://pastebin.com/gKN2DUaU

iceman · 2015-10-08 12:28:53

Perfect!

iceman · 2015-10-08 12:45:13

@securitoys,... is it you Vitorio on github?

securitoys · 2015-10-08 14:30:26

Yeah. So much for keeping these accounts separate.

iceman · 2015-10-08 14:33:04

Sorry, I can edit my post if you want to be anon.

how about you email me?

junglipar · 2016-01-02 17:06:53

Has the UID->PWD algorithm been figured out? If not, has anyone attempted to dump/analyze the firmware of a DI base?

iceman · 2016-01-02 18:38:12

nop, not figured out.
and if you manage to dump the firmware send me a email.

junglipar · 2016-01-02 19:55:39

I do not have a DI base so I will first need to buy one of those starter packs. The base appears to use a STM32F072C8T6 (internal photos -> https://fccid.io/document.php?id=2285838). I really hope they did not enable the read out protection or disable the debug interface.

junglipar · 2016-01-06 17:26:01

Today I bought a DI 2.0 starter pack, cracked open the base (no screws) and traced the STM32 JTAG pins.

http://s12.postimg.org/63pbk7lhp/di_base_jtag.jpg

The ST-Link V2 clone I have only does SWIM/SWD so I ordered a different clone which can do JTAG. I should receive it in 2-4 weeks.

In the meantime, would someone be so kind to sniff the passwords for following UIDs so that I can backup my tags?

04 23 A6 DA 2A 2B 81
04 E6 CF 7A 23 2B 80
04 9C B9 CA 0B 3A 80
04 96 BB 9A 11 3A 80
04 05 8B E2 AE 37 81
04 74 B4 9A 3D 35 80

iceman · 2016-01-06 17:48:29

Nice, but you'll need to sniff the passwords yourself using the PM3. You need to have both the toytoken and a DI portal to be able to get it to work

[edit] I wonder if I can sim your id's and get the key.. I'll give it a try.

Last edited by iceman (2016-01-06 17:54:49)

anon1 · 2016-01-12 19:19:06

Hello, new to here, but I am interested in your project.

I've disassembled a base, and hooked up jtag, but without success.
The chip in my base seems different from the one that junglipar mentions.
The one in mine is a STM32F102C6

https://imgur.com/a/0IN6F

http://i.imgur.com/69vRT8j.jpg

I did manage to ID the chip, and connect, but it seems the chip is read protected.
When tying to dump the flash you get an error that the target is still running.

After trying a few different things, I tried "unprotect chip" but I guess that erases the flash too as now I've got a dead base... but it does connect and read from jtag ok now lol.

I also tried extracting the wii iso DI image, and found a gateway.lua file, tried luadec on it but not much luck their either.

I also dropped the gamerel.consumer.wii.rel file into IDA using the wii rel loader plugin.

Found a couple of strings in there which look interesting.

[== Undefined ==]
.data4:80EADDB8                                         # "Loop,C8"
.data4:80EADDBC                 .long aSetledcolor01F   # "SetLedColor,01,FF,80,00"
.data4:80EADDC0                 .long aDelay0a          # "Delay,0A"
.data4:80EADDC4                 .long aFadeledcolor01   # "FadeLedColor,01,1A,C8,FF,00,00"
.data4:80EADDC8                 .long aDelay0a          # "Delay,0A"
.data4:80EADDCC                 .long aSetledcolor010   # "SetLedColor,01,00,00,00"
.data4:80EADDD0                 .long aFlashledcolor0   # "FlashLedColor,01,05,03,C8,00,00,FF"
.data4:80EADDD4                 .long aDelay0a          # "Delay,0A"
.data4:80EADDD8                 .long aEndloop          # "EndLoop"
.data4:80EADDDC                 .long aEndscript        # "EndScript"

also some strings such as
GatewayMaxChallengeMisses
GatewayMaxChallengeFailures
GatewayChallengeTimeout
GatewaySeedTimeout
GatewayTagListTimeoutTime
GatewayHardwareFailure

bettse · 2016-01-12 20:42:10

yeah, the base's USB protocol includes a challenge/response, that's the seed/challenge you're seeing.

Neuromancer · 2016-01-16 16:42:57

At 80F10448 there is a vftable from a class that connects down to "/dev/usb/hid".

.data5:80F10448 CGateway1__vftbl_Gateway_18E8:.long 0
.data5:80F1044C .long 0
.data5:80F10450 _CGateway1__GatewayRead:.long CGateway1__GatewayRead
.data5:80F10454 _CGateway1__GatewayWrite:.long CGateway1__GatewayWrite
.data5:80F10458 .long nullsub_118
.data5:80F1045C .long CGateway1__fn14
.data5:80F10460 _CGateway1__isHardwareReady:.long CGateway1__isHardwareReady
.data5:80F10464 _CGateway1__setHardwareReadyState:.long CGateway1__setHardwareReadyState
.data5:80F10468 _CGateway1__clearHardwareReadyState:.long CGateway1__clearHardwareReadyState
.data5:80F1046C _CGateway1__CloseHID:.long CGateway1__CloseHID
.data5:80F10470 _CGateway1__GatewayDetect:.long CGateway1__GatewayDetect
.data5:80F10474 _CGateway1__setStateGatewayDisconnected:.long CGateway1__setStateGatewayDisconnected
.data5:80F10478 _CGateway1__setHardwareReadyState_1:.long CGateway1__setHardwareReadyState_1
.data5:80F1047C _CGateway1__clearGatewayValues:.long CGateway1__clearGatewayValues
.data5:80F10480 .long CGateway1__fn38

Function GatewayDetect is a good start to investigate the code. Calls to main.dol are mostly asynchronous. for the HID functions a callback and a context is almost everywhere passed.

..
.text1:8045F670 exp_OpenHIDDeviceAsync: # [in] r3 = contextDeviceHID
.text1:8045F670 48 00 10 30 b OpenHIDDeviceAsync # [in] r4 = callback
.text1:8045F670 # [in] r5 = contextCallback

Regards

iceman · 2016-01-19 10:52:30

The DI tokens would be vuln against the new "hardnested" attack, but it isn't. The reason? Well, hardnested depends on a known key to perform and the DI Token uses the same unknown key for all sectors. Reader/tag attack like sniffing is the only way still. Until someone gets a firmware dump and finds the keygen-algo.

belette · 2016-01-20 18:39:02

the base are the same betwen DI v1 DI v2 and v3 maybe old/first v1 base 1.0 chip is NOT read protected ?

iceman · 2016-01-20 19:27:11

If someone has the old DI v1.0 portal wouldn't mind testing your idea, that would be great

belette · 2016-01-21 09:17:30

or 3ds portal ?

securitoys · 2016-01-21 19:34:22

@junglipar

0423a6da2a2b81,163acc20fae3
0474b49a3d3580,f855e15c36a4
04058be2ae3781,cc87f69f58cf
04e6cf7a232b80,6f2cc0c5dc2c
049cb9ca0b3a80,755ebf25d52e
0496bb9a113a80,207c403a0a91

anon1 · 2016-01-22 01:04:18

I don't think you are going to get a firmware dump easily.
I did a little more digging after getting another couple of bases to play with.

The ST32 device is mode 1 protected. This means that you can't just read out the flash. Mode 2 = permanently locked with Jtag disabled.

I did fine that Jtag works, and you can dump the devices ram.
You can also execute your own code on the device (in ram) I tried to read out some flash via that method, but after I read the datasheet it seems that when you connect via jtag, the internal flash gets disabled

Here are a couple of ram dumps (no figures had been placed on the base).

http://www84.zippyshare.com/v/EkJ7HDES/file.html

There may be some interesting data besides the serial number and copyright message in there.
Not sure if any of the figures keys get shoved into ram when you place them on the base too.

I checked the other bases I just got, and they all use the STM32F102C6 part.

Neuromancer · 2016-01-22 08:13:28

Thanks for sharing! The RAM dump suggests this CPU to store data in little endian format. This is consistent with the reference manual. 02D0-030C seem to be pointers to the embedded flash memory. This is consistent with the ref manual as well.

The mentioned area is potentially used as system stack.

You mentioned, that jtag disables access to the flash memory. So a question is: when you disconnect jtag, does the chip reset .. or does it continue to execute code? The later variant would open an attack vector via the system stack.

Neuromancer

belette · 2016-01-22 10:55:00

portal does he work in standalone ? if i power 5v on portal and put a tag on portal can i sniff pwd? or if i sim incremental fake uid can i sniff pwd?

belette · 2016-01-22 16:09:54

can we dump on mifare 1k uid or need 0.3k ?

iceman · 2016-01-22 16:23:13

di portal needs to be told to do something over the USB.
if so, then you can sim/sniff..

belette · 2016-01-22 17:00:26

ok, i just order second hand d.i v2 and v3, i can try dump each for compare or create character list (like sky...)

Proxmark3 community

Announcement

#1 2015-04-10 13:29:52

[FINISHED] A popular toy, Disney Infinity

#2 2015-04-10 15:07:39

Re: [FINISHED] A popular toy, Disney Infinity

#3 2015-04-10 15:49:17

Re: [FINISHED] A popular toy, Disney Infinity

#4 2015-04-13 13:07:24

Re: [FINISHED] A popular toy, Disney Infinity

#5 2015-04-13 13:40:01

Re: [FINISHED] A popular toy, Disney Infinity

#6 2015-04-13 13:44:13

Re: [FINISHED] A popular toy, Disney Infinity

#7 2015-04-13 14:03:30

Re: [FINISHED] A popular toy, Disney Infinity

#8 2015-04-22 21:28:35

Re: [FINISHED] A popular toy, Disney Infinity

#9 2015-04-22 21:50:22

Re: [FINISHED] A popular toy, Disney Infinity

#10 2015-04-22 21:58:22

Re: [FINISHED] A popular toy, Disney Infinity

#11 2015-04-22 22:04:07

Re: [FINISHED] A popular toy, Disney Infinity

#12 2015-04-26 16:11:44

Re: [FINISHED] A popular toy, Disney Infinity

#13 2015-05-06 09:10:36

Re: [FINISHED] A popular toy, Disney Infinity

#14 2015-05-26 16:08:06

Re: [FINISHED] A popular toy, Disney Infinity

#15 2015-05-26 21:35:12

Re: [FINISHED] A popular toy, Disney Infinity

#16 2015-05-27 11:46:23

Re: [FINISHED] A popular toy, Disney Infinity

#17 2015-06-16 10:30:05

Re: [FINISHED] A popular toy, Disney Infinity

#18 2015-10-04 13:14:46

Re: [FINISHED] A popular toy, Disney Infinity

#19 2015-10-04 17:33:11

Re: [FINISHED] A popular toy, Disney Infinity

#20 2015-10-04 21:24:10

Re: [FINISHED] A popular toy, Disney Infinity

#21 2015-10-05 05:20:22

Re: [FINISHED] A popular toy, Disney Infinity

#22 2015-10-05 05:49:25

Re: [FINISHED] A popular toy, Disney Infinity

#23 2015-10-05 09:57:04

Re: [FINISHED] A popular toy, Disney Infinity

#24 2015-10-06 12:52:11

Re: [FINISHED] A popular toy, Disney Infinity

#25 2015-10-07 08:54:25

Re: [FINISHED] A popular toy, Disney Infinity

#26 2015-10-07 09:03:57

Re: [FINISHED] A popular toy, Disney Infinity

#27 2015-10-08 10:31:41

Re: [FINISHED] A popular toy, Disney Infinity

#28 2015-10-08 12:28:53

Re: [FINISHED] A popular toy, Disney Infinity

#29 2015-10-08 12:45:13

Re: [FINISHED] A popular toy, Disney Infinity

#30 2015-10-08 14:30:26

Re: [FINISHED] A popular toy, Disney Infinity

#31 2015-10-08 14:33:04

Re: [FINISHED] A popular toy, Disney Infinity

#32 2016-01-02 17:06:53

Re: [FINISHED] A popular toy, Disney Infinity

#33 2016-01-02 18:38:12

Re: [FINISHED] A popular toy, Disney Infinity

#34 2016-01-02 19:55:39

Re: [FINISHED] A popular toy, Disney Infinity

#35 2016-01-06 17:26:01

Re: [FINISHED] A popular toy, Disney Infinity

#36 2016-01-06 17:48:29

Re: [FINISHED] A popular toy, Disney Infinity

#37 2016-01-12 19:19:06

Re: [FINISHED] A popular toy, Disney Infinity

#38 2016-01-12 20:42:10

Re: [FINISHED] A popular toy, Disney Infinity

#39 2016-01-16 16:42:57

Re: [FINISHED] A popular toy, Disney Infinity