.PHZ support

[Hambot3D]

HI, will the program support the .PHZ file extension.
I have a Phrozen sonic mini and it uses that extension.

[riggiding]

I'd love to implement (also looking to get a sonic mini) but cannot find any hints on the format.
Does anyone have an idea where to find documentation? @bonosoft @X3msnake ?

It seems that .zip is also supported (based on nanodlp) - that might be a route to go, @Hambot3D can you confirm?

[X3msnake]

No hints on the format. ask César in the group chat, he has been investigating and his first idea is that the format is similar to CBDDLP but was unconfirmed. The sonic mini board uses a chinese FPGA with integrated MIPI and a STM32 somewhat similar to the CBD-TECH boards, except CBD uses a altera cyclone 1 FPGA and it needs 2 toshiba external processors for MIPI riggiding <notifications@github.com> escreveu no dia terça, 3/03/2020 à(s) 20:00:

…

I'd love to implement (also looking to get a sonic mini) but cannot find any hints on the format. Does anyone have an idea where to find documentation? @bonosoft <https://github.com/bonosoft> @X3msnake <https://github.com/X3msnake> ? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#63?email_source=notifications&email_token=ACUR56QDINNM3PH5A6APUUDRFVOW5A5CNFSM4LAORYC2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENU53VY#issuecomment-594140631>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUR56UYK6MQHLQT2BXZ2O3RFVOW5ANCNFSM4LAORYCQ> .

-- Com os melhores cumprimentos, Vinicius Silva

[johanneslumpe]

@riggiding I tried for a few days now to get the specs from Phrozen directly via their FB support but either people are unwilling to help or do not understand the request. I tried figuring out how the format is compressed but neither file nor strings got me any useful hints. I do have a Sonic Mini as well but haven't yet had time to figure out if it supports zip files.

[X3msnake]

the file format is similar to the Photon/CBDDLP and most of the header strings are the same.
You must however decifer how the images are encoded @Cex123 was investigating it but i don't know if he found any other things besides that

[X3msnake]

@johanneslumpe any news on this?

[johanneslumpe]

@X3msnake indeed! Sadly not good news. I reached out to Phrozen and was told that their own file format is just a zip file. When asking about Chitubox I was told that they had no info on that version of the phz format. So I reached out to Chitubox directly and was told that the format is closed source and contains “NDA sources”, which really seems unlikely for a file format that is essentially some bytes concatenated with a zip of images. Regardless, they didn’t offer up any format specs.

So I’m wondering if we should try to use your plugin to intercept the output and try to get chitu to slice to a zip instead? Then we could add support for that to the validator.

[X3msnake]

i wonder how protected is the chitubox binary. it can open the sliced phz file and show it as voxels so it has the structure to both compile and decompile the files...

with the amount of file formats it is supporting it might be interesting to check for vulnerabilities and see if we can get at least some sort of hints on what is happening in the file

the ui looks very similar to the Chitubox printers like the photon classic and i think it use monochrome images for the AA like the cbddlp/photon

[johanneslumpe]

@X3msnake I have not really done anything like this before, but I'd be interested to dive into it. Do you have some pointers as to how to get started here?

[X3msnake]

This is how a PHZ file looks in BinViz

[X3msnake]

this is what Master @Cex123 has maneged to gathered about the file format, but he is stuck at the compression format since we do not know what type of image format it is using, therefore it is hard to reverse the compression it is using

Chitubox_Files.docx

[johanneslumpe]

According to Phrozen their format uses "sliced PNG files in ZIP format". That's what I was told via email. So I'm wondering if the images in this format actually a zip file embedded in this phz format. If not, then it should use normal PNG files.

[X3msnake]

According to Phrozen their format uses "sliced PNG files in ZIP format"

Well that is true for their flagship line of printers, but those printers also use a version of NanoDLP and a raspberry pi as hardware.

Pretty sure this printer was made by another company like i think i mentioned before there is a printer out there from a russian company that came sometime before the sonic that has the same board footprint.

This is probably just rebranded by Phrozen since this printer use a board and firmware more similar to the CBD-TECH boards, so much that i think @Cex123 said he can probably support the Photonsters firmware UI mods hack tools

That said it is a good thing to check, but i think if it had a embedded zip one would be able to unzip it with 7Zip and we can't

[X3msnake]

https://github.com/cbiffle/catibo/blob/master/doc/phz.adoc

:toc:

= PHZ file format

This document describes the file layout and record format for the phz
filetype used by the Phrozen Sonic Mini 3D printer.

== Relationship with ctb

The phz format is closely related to the ctb format, which I have
previously described. Please study that format first. This document will focus
on the deviations.

== Unified header format

phz contains an evolved version of the file header from ctb/cbddlp. Some
of the oddities and historical details have been cleaned up, and the information
has been collapsed into a single record.

The fields play exactly the same roles as in ctb, just rearranged. As such,
I'm not going to discuss them in detail beyond their layout.

The newly unified file header record is 0xD8 / 216 bytes in length, with several
areas zeroed, either encoding yet-unobserved features, or reserved for
expansion.

[cols="1,6,6,6,3,3"]
.File header layout
|===
|
| x0
| x4
| x8
2+| xC

|0x
|magic
|version
|layer_height_mm
2+|exposure_s

|1x
|bot_exposure_s
|bot_layer_count
|resolution.x
2+|resolution.y

|2x
|large_preview_offset
|layer_table_offset
|layer_table_count
2+|small_preview_offset

|3x
|print_time_s
|projection
|level_set_count
|pwm_level
|bot_pwm_level

|4x
2+|zero
|overall_height_mm
2+|printer_out_mm.x

|5x
|printer_out_mm.y
|printer_out_mm.z
|encryption_key
2+|bot_light_off_time_s

|6x
|light_off_time_s
|bot_layer_count_again
|zero
2+|bot_lift_dist_mm

|7x
|bot_lift_speed_mmpm
|lift_dist_mm
|lift_speed_mmpm
2+|retract_speed_mmpm

|8x
|resin_volume_ml
|resin_mass_g
|resin_cost
2+|zero

|9x
|machine_type_offset
|machine_type_len
3+|zero

|Ax
5+|zero

|Bx
|encryption_mode
|mysterious_id
|antialias_level
2+|software_version

|Cx
5+|zero

|Dx
2+|zero
3+|(start of next record)

|===

NOTE: encryption_mode seems to be reliably set to 0x1c for the Phrozen Sonic
Mini. Changing it makes files unreadable.

The encoding of the preview images and layer table are identical to those in
ctb.

== Layer data encoding

Layers are encoded as 7bpp images using yet another RLE scheme. This scheme,
which is called RLE7a in the Catibo sources because it's our second 7-bit
scheme, works as follows:

• A byte with MSB set represents a pixel in bits 6:0.
• A byte with MSB clear represents a repeat count for the last generated
  pixel.

Thus, 0x80 encodes a single zero pixel, and 0x80 0x7f encodes 128 zero
pixels.

Quirks observed in the wild:

• The repeat count generated by proprietary software never exceeds 0x7d, so
  you can recognize this encoding by looking for long runs of 0x7d. It's not
  clear whether 0x7e/0x7f are somehow reserved, or if this is an off-by-one
  error in the encoder, but Catibo currently mimics this behavior.

• Unlike the other RLE schemes, the encoder for "7a" takes care to terminate
  runs at each half scanline -- so for a 1080-pixel wide scanline, it will
  generate two runs of 540, neither of which overlaps the ends of the lines.
  It's not clear whether this behavior is necessary, but Catibo currently
  mimics it. (If someone with access to an actual Phrozen Sonic Mini could try
  it and report back, I'd appreciate it. It inflates file sizes by 10+%.)

== Layer data encryption

Like ctb, the phz format encrypts layer data for some goddamn reason. Which
is why I took a look at the format, despite not having a compatible printer.

Fortunately for owners of the Sonic Mini, the encryption is straightforward.
It's another 32-bit block XOR cipher. See the ctb doc for details and ranting.

I'm referring to this cipher as the "9f Cipher," named after the initial byte of
files that use it.

Here's the concise version, showing just which parameters vary. The keystream
X[n] is produced by:

....
c = (key % 0x4324) * 0x34a3_2231
X[0] = (iv ^ 0x3fad_2212) * (key % 0x4324) * 0x4910_913d
X[n + 1] = X[n] + c
....

(Where + and * are addition and multiplication mod 2^32^, respectively, and
% is unsigned remainder.)

Each block of data is simply XOR'd with the keystream, as in ctb.

A key of 0 causes the desktop software to accept unencrypted files. This may or
may not have been deliberate: there is a class of weak keys for this cipher that
includes any number that is 0 mod 0x4324; all these keys result in a zero
keystream, disabling encryption.

(However, note that ctb seems to have deliberately skipped encryption or keys
of 0, so it might be deliberate here too.)

TIP: The proprietary desktop software does not appear to check for these weak
keys when selecting its output keys, so it produces unencrypted output with a
probability of 5.818e-5.

== Analysis

I kept commentary to a minimum in the cbddlp doc, but this is the third
variation on the file format I've analyzed, and I have thoughts.

On the new unified header format: This is a great improvement. It really
cleans things up.

On the new RLE scheme: In practice, layer images will tend to include long
runs of fully empty and fully solid pixels. In cases like that, this scheme
achieves strictly worse compression than RLE7. Using catibo-convert to
recompress a sample phz file as ctb produces an output file 0.1x the size. I
have to assume that the RLE scheme was dictated by whatever image processor
Phrozen used to drive their display -- otherwise I can't imagine why this would
be chosen over their previous RLE7 scheme.

On the new cipher: Don't get me started.

[johanneslumpe]

@X3msnake we could just use catibo-convert to convert from .phz to .cbddlp, make changes and then convert it back ;)

[X3msnake]

cbddlp uses monochrome multiple images to emulate AA. ctb uses real greyscale. so that is not a good option

[johanneslumpe]

ah good point. It would only work for non-AA files.

[sauyon]

Now that the file format is known, how much work is it to translate that to something that the validator can process?

(How long might it take me?)

[X3msnake]

as a work around for now just output the file fixed and use UV3DP to convert the file. Sauyon Lee <notifications@github.com> escreveu no dia sábado, 9/05/2020 à(s) 09:47:

…

Now that the file format is known, how much work is it to translate that to something that the validator can process? (How long might it take me?) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#63 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUR56SPBYFSKASFN4QCKBTRQUKBHANCNFSM4LAORYCQ> .

-- Com os melhores cumprimentos, Vinicius Silva

[X3msnake]

PHOTON FILE VIEWER IS NO LONGER MANTAINED OR DEVELOPED!

Use UVTools by Master Photonster Tiago Conceição instead