Encrypted bb graph decode error

[yyc12345]

When a script contain a encrypted bb graph, decoder will throw a assert error.
It seems that this app don't process correctly for the encrypted bb graph header.
It need to take some research of bb store struct to fix this bug.

for reproducing this issue, you can create a script containing encrypted bb on your own, save as encrypted script NMO file and use this app to decode it.

[instr3]

It is not actually encrypted, I believe. I think it is something similar to --script hidden--.

Just need to look into the format of the BG block.

[tomysshadow]

The precise issue, which I am trying to investigate, seems to be that BBDecoder works for files saved with Virtools Dev 2.1 (even if it is used in Virtools Dev 3.5,) however files saved in Virtools Dev 3.0+ cause an assert message.

BBDecoder=>Error(Line 76: assert failed: 0x10 == ClaimInt(p, "fixed_var1"))

I decided to investigate myself. Usually, there is a buffer acquired from the CKStateChunk interface, representing a CKBehavior object. The buffer starts with a ClassID, then there are two chunks:

• one starting 0x00000010, the interface data - this is the main one we care about
• another starting 0x00000020, the "tail" data - some lengths, then mostly 0xFFFFFFFF repeated from what I've observed

However, in files saved with Virtools Dev 3.0+, the entire 0x00000010 chunk is missing. Instead, immediately following the ClassID is the 0x00000020 chunk, then the tail data, and then nothing else. The interface data is not present in the buffer given by the CKStateChunk, therefore the interface data must live in a different object and not CKBehavior. This is pretty detrimental to the purposes of restoring the schematic view of course, because it might not even be represented in a similar format wherever it does end up :(

I tried with several NMOs created in 3.0, 3.5, and 4.0 but the only ones BBDecoder would open are 2.1 version files.

What's interesting though is I can't seem to figure out where the interface data comes from, even in working files. Obviously it must come from the NMO and I know they are Zlib compressed, so I tried decompressing a working, 2.1 file with offzip - but I can't find matching interface data to the one in the buffer. Knowing how it's represented in the raw file might help with determining if there's still enough data to generate a new interface in 3.0+ or if it's represented too differently to parse. After all, it is possible the interface data is still there but stripped out by CKStateChunk before we receive it. More testing could easily be done here, I can try creating my own scripts to see how it affects the output.

Note: the issue doesn't occur with files upgraded from 2.1 to 3.0+. Only files created in 3.0+ originally.

[yyc12345]

the issue doesn't occur with files upgraded from 2.1 to 3.0+. Only files created in 3.0+ originally.

Thanks for your research, I never notice this before.

The interface data is not present in the buffer given by the CKStateChunk.

I have read your investigation. I definitely believe that the interface data properties are still lay in CKStateChunk. Something was hidden by Virtools implementation. Maybe only the reverse work can reveal it.

Knowing how it's represented in the raw file might help with determining if there's still enough data to generate a new interface in 3.0+ or if it's represented too differently to parse.

The reverse work for Virtools engine is on the way. doyaGu, who comes from our Ballance community have great progress on this. He has revealed the entire format of Virtools file, including CKStateChunk. Contacting him may help your futher investigation.

Btw, we are perhaps not urge to fix this problem because this is not the focus of this project. This project is served for Ballance, a Virtools 2.1 game. However, any PRs are welcomed especially when you have resolve this issue.