Hacking into the .g3p/b format [HALTED]

[fxdev]

All hacking has been stopped because of recent concerns expressed by the community.

KermMartian writes:

I am one of the Prizm hackers who had been expressing concerns on #cemetech. I've been in various contact with Casio marketing and engineering personnel over the past year or so, and they have made it clear that they're currently turning a blind eye to mature, responsible third-party hacking. Officially, they're supposed to both not support it and potentially disallow it, but that hinges on how we behave. [...]

We do not want to drive Casio into the same cat-and-mouse game the Nspire developers have to work around.

General header format:

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

AAACBDAF90889A8D _xFF_yFF_yFF..FE _a_a_a_a.._b_c_c 00000000_._._d_d _x : file type - .g3a=0xD3; .g3e=0xB6; .g3p/b=0x82; .g3m=0x8A _y : unknown - if (.g3a) then 0xFE else 0xEF .. : check bytes - upper=LSB_of_a+0xBF - lower=LSB_of_a+0x48 _. : CP check bytes - rightmost=if (Casio Provided) then LSB_of_a+0x85 else LSB_of_a+0x17 - leftmost=(checksum of LSW_of_a) + ... -- if (Casio Provided) then (.g3p/b=0x9B; .g3e=0xCF) ... -- else (.g3p/b=0x09; .g3e=0x3D; .g3m=0x11) _a : inverted file size _b : unknown - if (.g3m) then 0x01 else 0x00 - could be related to _d _c : unknown - if (!.g3a) then 0x0000 - seems to be unrelated to _a _d : inverted element count - if (!.g3m) then 0x0000

The .G3P format:

A 32-bit ckecksum seems to be stored at the end of the image data block (starts at 0xD0), but before any footer. The procedure to calculate this checksum is not known. Without disassembling the Prizm's CAPTURE routine, further analysis appears to be a waste of time.

References to zlib inside the OS imply they are using this for data compression. Also, it is not known if the type ID at _o (see below) is required for the decompression part.

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

AAACBDAF90889A8D 82FFEFFFEFFF..FE _a_a_a_a..000000 00000000_._.0000 4350_b_b_b_b_c_c _c_c_c0000000000 _d_d_d_d0000_e_e _f_f_f_f00000000 00000000000000_g 0000000000000000 0000000000000000 00000000000000_h 00000000000000_i 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 _b_b_b_b_j_j_j_j ??_k_l_l_m_m???? ????????_n_n_n_n _o_o???????????? ???????????????? Main header: .. : check bytes (see 'General header format') _. : CP check bytes (see 'General header format') _a : inverted file size Sub header: _b : if "CP" then 0x00010000 else 0x30313030 _c : if "CP" then 0x00 else 0x4C79373535 _d : file_size - 0x20 _e : if "CP" then (0x0001 or 0x0009) else (0x0A09 or 0x0009) _f : file_size - (0xB8 + _g + _i + _h) _g : if _e=0x0001 then 0x00 else 0x8C // length footer 1 _h : if _e=0x0A09 then 0x2C else 0x00 // length footer 3 _i : if _e=0x0A09 then 0x?? else 0x00 // length footer 2 _j : file_size - (0xCC + _g + _i + _h) _k : if CAPTURE then 0x01 else 0x00 _l : image_width _m : image_heigth _n : file_size - (0xD0 + _g + _i + _h) _o : type ID (see 'Sub formats' below)

Sub formats:

"CP" format with _e=0x0001 and _g=0x00
- no footer; Casio Provided (ID: 0x3C1B)

"CP" format with _e=0x0009 and _g=0x8C
- one footer; Casio Provided (ID: 0x3C1B)

"CP0100" format with _e=0x0001 and _g=0x00
- no footer; CAPTURE Format (ID: 0x388D)

"CP0100" format with _e=0x0009 and _g=0x8C
- one footer; Converter Format (ID: 0x789C)

"CP0100" format with _e=0x0A09 and _g=0x8C; _i=0x??; _h=0x2C
- three footers; Casio Provided (ID: 0x3E93)

The .G3B format:

A 32-bit ckecksum should be stored at the end of the image data block (starts at 0xD0), but before any footer.

Code: Select All | Copy To Clipboard

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

AAACBDAF90889A8D 82FFEFFFEFFF..FE _a_a_a_a..000000 00000000_._.0000 4350_b_b_b_b_c_c _c_c_c0000000000 _d_d_d_d0000_e_e 00000000_f_f_f_f 0000000000000000 0000008C00000000 000000000000002C 0000000000000000 000000_z00000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 _b_b_b_b_j_j_j_j _l_l_m_m???????? ????????_n_n_n_n _o_o???????????? ???????????????? Main header: .. : check bytes (see 'General header format') _. : CP check bytes (see 'General header format') _a : inverted file size Sub header: _b : if "CP" then 0x00010000 else 0x30313030 _c : if "CP" then 0x00 else 0x4C79373535 _d : file_size - 0x20 _e : if "CP" then 0x0492 else 0x0092 _f : file_size - (0xB8 + 0x8C + _z + 0x2C) _z : if "CP" then 0x10 else 0x00 // length footer 2 _j : file_size - (0xCC + 0x8C + _z + 0x2C) _l : image_width _m : image_heigth _n : unknown length _o : type ID (see 'Sub formats' below)

Sub formats:

"CP" format with _e=0x0492 and _z=0x10
- three footers; Casio Provided (ID: 0x3C1B)

"CP0100" format with _e=0x0092 and _z=0x00
- two footers; Casio Provided (ID: 0x3C1B)
- two footers; Converter Format (ID: 0x789C)

[sammyMaX]

Why does Casio have two formats? Do they serve different purposes?

[fxdev]

The "CP" format seems to be older. All later tools and files use "CP0100". I did not focus on what is stored inside these footers. If it contains extra security against modifications, then we can just modify the _e flag to ignore this (at least for .g3p files).

[sammyMaX]

I meant, what's the difference between .g3b and g3p files?

[fxdev]

I meant, what's the difference between .g3b and g3p files?

Sorry, I did not expect such a basic question.

.g3p is the Prizm's image format
.g3b is the Prizm's animation format
The latter is only used along with the Picture Plot add-in.

[sammyMaX]

Cool, thanks for the info

[bynary_man]

This is very interesting

[krazylegodrummer56]

And how does this help?

Will you now be able to put modified pics onto the prizm?

[fxdev]

And how does this help?

Will you now be able to put modified pics onto the prizm?

The missing part is the checksum calculation. When we know it, we can (hopefully) create Casio provided images.

[calc84maniac]

Won't that completely nullify the point of them making the CG-10?

[Jonius7]

So this will allow us to change the Prizm Startup screen and system screens?
That sounds really cool, we could completely change what it says, or 'rearrange' pixels for efficiency.

[fxdev]

Won't that completely nullify the point of them making the CG-10?

Yep.

So this will allow us to change the Prizm Startup screen and system screens?

As far as I know, these are simple bitmaps inside the OS. On legacy models, OS patching is not too complicated from within an add-in as you can use flash writing syscalls. But I don't know if the Prizm adds extra security against modifications. Well, the OS checksum is already known.

[JosJuice]

Won't that completely nullify the point of them making the CG-10?

Yes.

So this will allow us to change the Prizm Startup screen and system screens?
That sounds really cool, we could completely change what it says, or 'rearrange' pixels for efficiency.

No. What this will allow us to do is to create our own images to use as backgrounds for graphs and other math purposes that already support the images that are supplied by Casio.

EDIT: Ninja'd by more that an hour. I should use F5 more.

[DJ Omnimaga]

I would definitively like if it was made possible to create CG10 custom images or port CG20 ones to the CG10.

A lot of PRIZM BASIC games do not run on the CG10 because of the different format.

[fxdev]

Anyone skilled in disassembling PC programs like the Casio image converter? Because I'm not...
And Simon doesn't seem to be interested in reverse-engineering the CAPTURE routine.

In the worst case, this could take us another year.