Homebrew Pyramids QR Code Hacking

[elisherer]

Check out "The" list in the 1st post...(spoiler at the end of the post)

 

[duke_srg]

According to this, the footer is variable length 6-8 bytes. It is a good idea now to guess the checksum algorithm so we can test custom levels with the application, because count records seems to be more weird than expected.

 

[elisherer]

I still suspect the data uses some kind of compression...so until we rule it out I don't think we can understand the checksum. Plus, we can't make more codes
and we don't have files of the same size, so now it's only the guess game... I try from time to time running several algorithms to find out what it is...
I have a suspicion that it's CRC16 because only two bytes (the 4th and 3rd from the end) has distinctly different values, but it's really too early to know...

 

[vashgs]

I still suspect the data uses some kind of compression...so until we rule it out I don't think we can understand the checksum. Plus, we can't make more codes
and we don't have files of the same size, so now it's only the guess game... I try from time to time running several algorithms to find out what it is...
I have a suspicion that it's CRC16 because only two bytes (the 4th and 3rd from the end) has distinctly different values, but it's really too early to know...

Create a few sample QRs modifying a byte at a time, to see when the game rejects the data. You can find the CRC data block this way (although it's probably the entire block with the checksum appended). Try changing one byte and using all of the common CRC16 variations on the data block. Let me know how that goes for you. We can't exactly work our magic on this game when we can't generate levels with intelligent differences.

Try all of the polys from this table, alternating reflections and initials. You know what to do

http://en.wikipedia....andardized_CRCs

P.S. You can do a simple xor check on two data blocks to see whether they're using a CRC algorithm or not. That would be the best place to start.

EDIT: What makes you think CRC16 and not 32? I see 32-bits that are consistently inconsistent at the end of the file. Also, try editing the 2 bytes after the checksum and see if the game accepts the file. Change it to a known working value from one of the other files. I'd assume that the 2 bytes after the checksum aren't part of the data block.

 

[morphius]

0A = Snake

Witnessed in the end of 2-3 and 1-9

 

[vashgs]

Does the game reject this QR? It has an edited last byte, which should be after the checksum and data block.

 

[duke_srg]

This QR is rejected =(
I doubt that any kind of 32-bit CRC was used. 0xA0 and 0x00 bytes are too often in the footer in place of suspected CRC. I'd rather believe there is only 1 tail byte used as a checksum.

 

[vashgs]

This QR is rejected =(
I doubt that any kind of 32-bit CRC was used. 0xA0 and 0x00 bytes are too often in the footer in place of suspected CRC. I'd rather believe there is only 1 tail byte used as a checksum.

The checksum looks to be the 4 bytes prior to the final 2. That is what has been said all along, I believe...

EDIT: After looking into the format a little more, the only option for the checksum seems to be the 2 bytes prior to the final 2, or the last byte itself (as duke_srg suggested). All others don't make sense as a checksum. That being said, the last byte isn't looking so great for a checksum either, only because more times than not the low end is C.

EDIT 2: The data also looks way too consistent/repetitive to be compressed. It's probably a much simpler format than has been discussed thus far.

 

[elisherer]

I have a theory that it uses a "known" huffman tree (known to the game) or it uses some kind of RLE compression as suggested before...

 

[elisherer]

Look at the first post (in the "list") i kindof figured something about the "repeat" flag...it seems to work with most of the stuff i found...
I'll try make a loader soon.

 

[morphius]

can anyone help with software that can do binary>QR and back again?

 

[elisherer]

can anyone help with software that can do binary>QR and back again?

Your wish is my command ..

http://code.google.com/p/pushmoleveleditor/downloads/detail?name=qrtool.rar

 

[morphius]

thx!

 

[morphius]

It is MORE than just a checksum. It must be some sort of CRC or the like. I took 1-2 and swapped 0x07 and 0x08 18->00 00->18 .. the 16bit checksum for both files is still 0EA1 ... but the edited file doesn't work.

 

[duke_srg]

Checksum is the most a common name. CRC, MD5 is a checksum algorithms too. Moreover an addition operator in Galois field is a bitwise XOR which is used in CRC calculations

 

[bailli]

I liked the commands with "repeat last two blocks" better. If you look at 2-1 you'll see
0x12 (player) 0x0D (fire) 0x00 (blank) and 0x90 0x01. 9001 could be interpreteted as
repeat 6 times the last to blocks thous creating the first row except the last blank, but
0x9001 is followed by 0x00.

After that there are some "problems": 0x01 ("carriage return" ?) 0x44 (could be marker to
duplicated later) 0x01 (again?) 0xB0 (full row of sand blocks?!) 0x01 (end of row?)

Here we can speculate again: 0x0B (skull - would be fitting if snake is 0x0A)
0x00 0x00 0x90 0x01 (two blanks and 6 times repeated the two blanks) 0x0B (the other skull)

after that it gets really messy... and we used half the available data and constructed only 3/10 rows...

A interesting question would be if the game accepts levels without the "compression" (or whatever it is).

 

[morphius]

I was thinking that too .. if we could just use a pair for 160 (16x10) places, .... we just need to work out the checksum/crc to test this.

 

[duke_srg]

That won't help us. Pyramids may check the level content aswell, i.e. level must contain exactly 1 start point, exactly 1 exit otherwise drop it.

 

[elisherer]

I liked the commands with "repeat last two blocks" better. If you look at 2-1 you'll see
0x12 (player) 0x0D (fire) 0x00 (blank) and 0x90 0x01. 9001 could be interpreteted as
repeat 6 times the last to blocks thous creating the first row except the last blank, but
0x9001 is followed by 0x00.

After that there are some "problems": 0x01 ("carriage return" ?) 0x44 (could be marker to
duplicated later) 0x01 (again?) 0xB0 (full row of sand blocks?!) 0x01 (end of row?)

Here we can speculate again: 0x0B (skull - would be fitting if snake is 0x0A)
0x00 0x00 0x90 0x01 (two blanks and 6 times repeated the two blanks) 0x0B (the other skull)

after that it gets really messy... and we used half the available data and constructed only 3/10 rows...

A interesting question would be if the game accepts levels without the "compression" (or whatever it is).

Look at p2-5 for example...you can find the sequences 705F 706F A08F all works perfect with my theory.
You might want to say that the negative offset is -(1+byte) meaning that 9001 is repeat sequence from offset -2 until you write 12 bytes.
I'm just saying that defining the tags that way covers the majority of the tags found in the compression.

 

[duke_srg]

Seems to be right guess, but in p1-2 we have 1062 and 105d representing a 4 block sequence copy, but it is unclear how to determine whether it is a copy byte or just a dog block?

And even zero can be a copy command P1-3

0x018: 00 00 15 15 01 01 00 - space - 4*sand - space
0x026: 000F - copy 3 blocs from above (bullet, space, block)
0x029: 00 14 80 00 01 - space-fly-space-fly-space
0x035: 3002 - just bullet (02)