CTB Magic Numbers

[NickSica]

Hello,

I am the author of this pull request and originally I had the magic number output for CTBv4 files set to 0x12FD0086 but a user was having issues with using the patch on their Mars 3 Pro. Double checking your files(which is the best source for the CTB file format, thank you for your work), I saw that 0x12FD0106 was used for v4 so I changed it. If i manually convert in the tool I get the former number, though. Shitu making a horrible file format and not documenting it aside, I was hoping you can shed some light on this. Thank you!

[sn4k3]

Elegoo Mars 3 uses the CTB encrypted different format than v4 ctb. It magic should be 0x12FD0107 (318570759). Using such magic on a CTBv4 won't work as it require the new encryted format.
You can use my printer profiles on PS to confirm which format and version the printer should use.

[sn4k3]

It matches what we both have.

Not if you using the key and IV from the image above. More specific on 3rd hex. All others match as far I can see.

You're feeding them in as hex bytes to the encryption right?

Yes. See AesCryptBytes

Does the endianness get swapped on them?

No. After get the encrypted bytes they are dump to the file directly.

I'll probably have to look into how C#

C# use standard implementation, using something else in place would be a big failure and bug. Chitubox uses openssl for that.
If you look at the function AesCryptBytes you see how it's constructed, nothing more is made on it, please double check your key and IV, easy to extract from debugger.

[NickSica]

Yeah that's how I know they're the same I checked them from the debugger and they noth matched yours byte for byte the indices and values are the same.

I've been double checking against AesCryptBytes as well. Which is why I'm so lost as to what's going on.

EDIT:
Oh I didn't see the part about the third byte I'll check again when I can open the debugger and compare.

[NickSica]

Ok, my big issue was that I was using UVTools instead of UVtools, that led me to my problems quickly and I managed to get something working! Thank you again. I found a bug in your code when the Signature is at a different location that I'll open a pull request for(it's like 1-2 lines). One last question just for curiosity. When you were figuring out the key and iv did you find it and figure out what string through the XOR encryption with UVtools would give you the correct output string? Using anything other than UVtools doesn't seem to work and I admit my knowledge on ciphers and such is very lacking.

EDIT: Actually it may look like chitubox has the same behavior(expecting the signature to be at the end of the file) since I get an invalid file in chitubox but UVTools loads it fine. So it may not be worth the fix?

[sn4k3]

The key and IV was plain on chitubox, you can or at least were able to extract it easy without any advanced tools.
The xor I'm using is just to hide the plain iv and key from source (not indexable by search or easy to find)

About the fix if you think it's really a bug you can send a PR so I can really see it, but Soo far I never saw signature in other place. New output CTB append 4 bytes on the end that is not the hash that caused problem in UVtools when was introduced

[NickSica]

Sounds good thank you for explaining the thought process behind everything.