How are Checksums calculated?

[hegyak]

I have been trying to determine how the checksums are calculated. So far, I only know that the the first check for Area 0 (Header) is all the bytes from Offset 00 to Offset 1D. But the other checksums, I don't know how to calculate.

I know most checksums are a CRC16-CCITT with a Polynom of X^16 + X^12 + X^5 + 1 as it's initial value. The source code talks about pulling bytes from various offsets but I can't determine where those offsets are or what bytes are being read to calculate the checksums.

I also know the MD5 hash used for the AES Encryption method uses, the header data of the figure, one byte of something and several bytes that says an ASCII message. But, I don't know how to get that One Byte thing that goes between the Header and the ASCII message. What is that Byte? Where does that come from?

The decryption and checksum methods work. I just want to understand how they work.

[jekarellas]

about Encryption from source - <first 0x20 bytes of sector 0> <1-byte block index> <0x35-byte constant> so One Byte its just number of block what you decrypt :)

So for 24 block it will be- <first 0x20 bytes of sector 0> <24> <0x35-byte constant>

decryption key for each block will be different because number of block changing and Pay attention -

0x20 bytes in hex its 32 bytes in decimal ! same 0x35-byte its 53 bytes in decimal

then you can use source like this to decrypt https://www.hanewin.net/encrypt/aes/aes-test.htm

[hegyak]

So, I would be reading in first 32 Bytes (20 in Hex is 32 in Decimal) from the figure, telling the program what Block I want decrypted, and the 55 Byte (35 in Hex is 53 in Decimal) String. Then from that, generate the MD5 Checksum, and that's my Encryption Key for that Block?

If that's the case, how is a "Block" defined. Is it based on the MiFare Classic Block Format? Or some other partitioning method?

[jekarellas]

Yes, all is correct

Block number is same as in any hex editor (hexadecimal from 00 to 3F ) for blocks like 8,9 you must add 0 before (so it will be 08, 09 )

When you figure out how to do decryption, you will be ready to calculate Checksums, because Checksums need calculate when data is decrypted.

all info about crc in editor source text file

[hegyak]

I successfully decrypted a Block of Data (08) using the First 32 bytes, 08 as the Key and the 53 byte String after I converted those bytes into an MD5 hash. So, that's great so far. I compared my decrypted data, from the webpage you linked me, to the program's output for the same figure that has been decrypted and it's a match.

I also used a hex editor to compare the Decrypted Figure data and the Encrypted Figure data. Some blocks, are not encrypted, it seems. These must be the Data Header blocks?

[jekarellas]

Yes, not all block are encrypted /////Every block from 0x08 onward (with the exception of the access control blocks) is encrypted using a key unique to that block///////

so blocks before 08 not encrypted

Also this - ///There are two main data "areas" where arbitrary data can be written. Each contain a block-sized header: the first data area's header is block 0x08, and the second header is block 0x24 /////

so two encrypted data area 1- blocks 8 -15 2 - blocks 24-31 blocks 16-23 and 32-3F not encrypted (dont used by game )

With some exceptions for Imaginators figures

[hegyak]

I am trying to figure out how Checksum Type 1, Type 2, Type 3 and Type 4. According to the Source code it says, "The type 1 checksum is a checksum of just one block, the data area header (0x08 and 0x24). As it's also stored WITHIN the data area header, a default value must be supplied for the checksum before actually calculating it. That value is 0x0005."

Does the Checksum method do the following for Types 2 and 3. Calculate the checksum value for Type 3, which is,

"Checksum of the next 4 blocks after the type 2 checksum (EXCLUDING the data area header, and the access control blocks), and then 0x0E blocks of zeroes."

Places that Checksum at that Offset 0A for the Data header, then does Type 2 checksum which is.

"A Checksum of the first 4 blocks (EXCLUDING the data area header, and the access control blocks)."

Access control blocks, being the MiFare's Data Control Blocks, correct? Then places that Checksum at Offset 0C on the Data Header then generates a Type 1 Checksum, which is the entire data area header (00 to 0C) with the values for 0E and 0F being 05 and 00 respectively.

[jekarellas]

You must follow step by step with source . I hope you know how calculate crc 0 type. its first step

Then crc type 1 its crc of full one block (block 08 or 24 because two area where info stored) crc itself stored in offsets 0E-0F of blocks 08 and 24

crc type 2 its crc of next 4 block after block 08 (or 24) but EXCLUDING Access control blocks ( 00 00 00 00 00 00 7f 0f 08 69 00 00 00 00 00 00 ) so actualy crc type 2 is crc of 3 block crc type 2 itself stored in block 08 and 24 offsets 0C-0D

crc type 2 is Easiest to calculate

try this 1 - Open any of your skylanders editor dump of figure with working crc in hex editor (Sk editor dump is always decrypted) 2- find values for crc type 2 3-try to calculate it itself and get the same values as in original

when you will be able to correct calculate crc type 2 you will be ready to next step

[hegyak]

I have successfully calculated Checksum Types 0, 1, 2, 3 and 4. And verified they are correct against against the data I dumped.

It should be noted that the Type 4 Checksum notes, I read, were incorrect. You only need four blocks and set the initial Checksum value to be set to 06 01.

You mentioned there are some Encryption changes for the Imaginators figures encryption, what changed?

[jekarellas]

what you mean Type 4 Checksum ? because its not in Skyreader source.

[hegyak]

I found that in another fork. But, I can't seem to find it now.

The Type 4 checksum is in two places. Block 110 and 2D0. The first two bytes, are the checksum value. You will need to read in 64 total bytes while ignoring the Data Access Block. So it's all the bytes from Offset 0x110 to 0x12F along with the bytes from Offset 0x140 to 0x16F The Type 4 checksum and data should be right after the Type 2 and Type 3 Data area.

The Checksum value needs to be set to 06 01 before you check the Checksum for Type 4.

[jekarellas]

hah..) i know different way to calculate it , but result is the same) can you email me? It seems public place its not the best way to discuss on this theme jekarellas@gmail.com

[hegyak]

There is one more checksum (?) I need to calculate. On the Data Area Header Blocks, there's a Checksum like data before the Control Data itself. But, there is nothing that tells me how it's calculated. I think these checksums are recursive like how the Type 1 is done by calculating Types 2 and 3 first.

[jekarellas]

can you get directly blocks and offsets what you talking about?

[hegyak]

These Blocks, 0x030, 0x070, 0x0B0, 0x0F0, 0x130, 0x170, 0x1B0, 0x1F0, 0x230, 0x270, 0x2B0, 0x2F0, 0x330, 0x370, 0x3B0, 0x3F0

All have some kind of Data on them starting at Offset 0x0 for each Access Control block. They go from Offset 0x30 to 0x35 for example.

I dumped a Healing Potion (Adventures) figure. The Type 1, 2 3 and 4 checksums are going to be the same, always. But the data before the Access Control Block data is always different.

[jekarellas]

this is offsets where each key stored. each access control block have 6 byte mifire key (Offset 0x30 to 0x35) each figure have unicue 15 keys based on UID key in 03 block always the same

but Skyreader cant put keys in dump, its always zero in dump.Only portal know keys

What tool do you use for dump if you able to see keys?

[hegyak]

The Key A for MiFare. Right. I forgot about those. That would explain why the Blocks after the Access Control Block are always Zeros. Thank you. That's a big help to me. I have some ideas on further hacking/editing of Skylander Figure Dumps but I need to test them first before I share what I figure out related to Key A behaviors.

To answer your question about how I dumped those Key A's. I used a Proxmark 3. However, I could only dump a Gen 1 (Adventures) Figure. And, one Gen 2 (Giants) Figure. Everything else, has a non-Psudo Random Key A pattern. And Key B is always Zeroed out (I think).

But, that leads to another question, how does the Portal read figures without knowing the Key A?

[jekarellas]

i feel not comfortable to talk about this public .... email me please

[hegyak]

I will Email you. Same Domain as your Email.

[hegyak]

Considering this resolved.