Potential lead regarding savefile encoding (Rewritten data remains in the file) about byond-data-docs

[20kdc]

Quite interesting, thank you!

Some key notes:

• The end of the string is known based on the length (the 14 00).
• The savefile analyzer script shows all data to the end of the RAD entry (see https://github.com/20kdc/byond-data-docs/blob/master/formats/RAD.md ) even if there's less data described by the savefile entry stored within it.
• The more interesting point here is that it seems as if at least that BYOND version (appears to be 510) will not split RAD blocks (at least beyond a certain point, but perhaps even at all?), using more space for the entry than is strictly necessary rather than shrinking it.
• While it doesn't have an effect on the file format, as a matter of implementation behaviour knowing what RAD block structures are caused by various insertion/deletion sequences might be useful in studying ways to either prevent and/or cause bloated savefiles.

[20kdc]

Oh, also, if you just want to take an existing savefile of a relatively short length and salvage whatever strings you can out of it, try the xor-jump-9 bruteforcer, it tends to do well enough.

a4/9a
N/A RP fairly well, providing a good enough scenario is given.

[20kdc]

Ah! I found a bug in my savefile analyzer where it would still try to read those invalid RAD blocks. This failed, as could be expected. It's fixed now.

[KirbyDaMaster]

This information is very useful, can you contact me through discord so I can ask a few questions regarding save files? Kirbsuke #0857