Homebrew Pyramids QR Code Hacking

[elisherer]

I dont understand what you did there...but the files "detonator.png, spike.png and money.png" are files that I made. (cut from the game's screenshots)
all the files in icons are files that i made and not files that I extracted from somewhere...The qr codes definently don't contain icons..

 

[morphius]

elisherer , are we sure the decoder is getting all the data? those seems like pretty high level QRcodes(v21-v27) for such a small amount of data.

 

[duke_srg]

A few suggestions:
1. zero bytes are more frequent than others
2. bytes with high bit set are less frequent
3. data is not ciphered, otherwise it will be random scattered (although it still can be xored by a constant)
4. data is compressed, most probably RLE-like . Notice that p2-1 has a number of blocks but is only 53 bytes long.
5. start positions of moving objects can differ from the screenshot of the original distributed image with QR
6. assuming all of the above, notice a repeated sequence of strings 4-8 in p7-1c and a sequences at offset 0x0026 and 0x0037

P.S. and yes, this is all the data QR contain, it can be checked by generating a QR from a binary file and scannin it in Piramids itself. Believe me it works well for data obtained from ZXing decoder.

 

[morphius]

observation of skulls:

There seem to be only 2 types. Horizontal or Vertical. Horizontal ALWAYS start going to the right. Vertical ALWAYS start going up. From there they are "dumb machines" they just go till they hit something ...then turn around.

 

[morphius]

observation of dogs:

There may be no need to set direction.There seem to be two types only. Horizontal and Vertical. They just shoot in the opposite direction to the block they are next to. They are ALWAYS next to a block or border (no free standing)

 

[elisherer]

I don't understand enough on qr codes but I'm pretty sure that if ZXing gives us a byte array as a result then this is what's inside.
The QR, as i understand, have a lot of checksums and the bigger the qr is, the better accuracy of the data.
The actual qr data's header has the length of the data so if all the binaries has the same header then it's gotta be correct.

 

[elisherer]

@[member='duke_srg'], I remember you from http://gbatemp.net/topic/312112-pyramids-custom-qr-levels/page__st__15 nice to have you on board

 

[duke_srg]

I don't understand enough on qr codes but I'm pretty sure that if ZXing gives us a byte array as a result then this is what's inside.
The QR, as i understand, have a lot of checksums and the bigger the qr is, the better accuracy of the data.
The actual qr data's header has the length of the data so if all the binaries has the same header then it's gotta be correct.

I've already checked a regenerated versions of a first dozen of QRs in Pyramids a while ago. There is nothing to worry about with ZXing, we just need to break a binary.

upd; yep. I'm here. Thanx for PLE, I just had no time on holidays to help with =(

 

[morphius]

Observation on rock doors:

Only one type. Initially all rocks fall then roll to the left. second drop....they fall then roll to the right. etc etc.
although you have them listed as different. They seem to all be the same and they shape is figured by there placement(perspective)

 

[morphius]

Observation on snakes:

only one type. Always start out facing to the right, then turn to face the player wherever he might be.

 

[morphius]

Observation on spike balls:

Seem to be only one type. Always spin clockwise and initially move to the right.

 

[morphius]

From all those enemy observations, there seems no need to set orientation in the QR.
Enemy Types:

1 : Horizontal Skulls
2 : Vertical Skulls
3 : Horizontal Dogs
4 : Vertical Dogs
5 : Rock Door
6 : Snakes
7 : Spike balls
8 : Flies

 

[morphius]

Background Observation:

There are three distinct backgrounds in these particular levels. So there must be a bit/byte to set that.
1-x have a zoomed out pyramid (same as 1-x Levels in game)
2-x have a zoomed in pyramid with fountain (same as 2-x Levels in game)
7-x have a tomb with mummy walking around (assumed the same as 7-x levels in game ...didn't get that far)

**update** I found the hex
0x06 seems to control the background.

00 = Level 1 BG
01 = Level 2 BG
02 = Level 3 BG
03 = ??
04 = Level 7 BG (maybe never got that far in the game...its the one with the mummy walking around)

on a side note compare the BG in the screen shot to the actual import on:
1-7
1-8(assumed)
1-9
2-4
2-5
2-6
2-7
2-8

They are different but correspond to the hex

 

[elisherer]

Great find Morphius...this is going to the first post..!!

 

[elisherer]

Some statistics over all the bin files:

EDIT: some how I missed the first row:
Dec: 0 Hex: 0x00 Count: 167 Percent: 17.96%



Uploaded with ImageShack.us

 

[morphius]

judging by the top left tile and looking at 0x07
and the last few tiles ..and the hex before the timer byte.

00 = Blank
18 = Rock Door
30 = Detonator
12 = Player
05 = Block
13 = Door
02 = Bullet
0D = Fire
06 = Bird Stone
21 = Wings
33 = Pillar
09 = Amulet
19 = Coins
07 = Fourblocks
11 = Vertical Dog
23-24-25-26 = All four pieces of large block

That gives us /some/ insight, both in tile calls and tile placement

 

[morphius]

looking at p7-1b the above post sort of helps with the file structure.

Knowing the first 2 tiles are door(13) and fire(0D)
and the last 2 tiles are detonator(30) and player(12)

we can now see the map data and other info.

The data seems to go from left to right ..top to bottom. where there is a single tile the number is displayed , multiple tiles in a row seems to have some sort of length array after them.

 

[celcodioc]

looking at p7-1b the above post sort of helps with the file structure.

Knowing the first 2 tiles are door(13) and fire(0D)
and the last 2 tiles are detonator(30) and player(12)

we can now see the map data and other info.

The data seems to go from left to right ..top to bottom. where there is a single tile the number is displayed , multiple tiles in a row seems to have some sort of length array after them.

After a very quick look at p1-2.bin that seems to be true...

The first bytes of the file: 18 00 21 21 00 04 18 5C

0x18 = The block in the top left corner... reminds me of donut lifts from Super Mario World... (I don't have this game, is this what you called rock doors? )
0x00 = Empty
0x21 = Banana
0x21 = Banana
0x00 = Empty
0x04 = Repeat flag for the empty tile?
0x18 = Another "donut lift"
0x5C = Repeat flag for the "donut lift"? After these bytes, there is no other 0x18 byte even though there are 6 "donut lifts" in the level...

I don't see how they would separate the repeat flags from the actual blocks though, but this was just a quick look after all.

The repeat flags in p1-7b.bin do actually make sense, but not in this file.



EDIT: Typo

 

[morphius]

I've noticed that for most levels ... first few tiles line up....then it all falls to shit, then comes back together at the end...not too sure whats going on.

look at the last tiles of 1-2

06 bird stone
06 bird stone
05 regular stone

 

[elisherer]

It might be mipmaped...don't worry i'll check it out when i'll get home...I'm at work now..