You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We are using protobuf now, it will keep the protocol in binary, it can almost restore the protocol, I noticed that FastBinaryEncoding also has this problem, I hope not to keep any related strings with the protocol declaration
The field names remain in the source code, and as long as you are familiar with fbe, you can still infer the message structure through reverse engineering
Ok, as I understand you want to have 'transparent' fields that are present in objects/clases, but not serializable/deserializable and not output in logger/std::streams. Am I right?
When deserialzed this fields are skip and contain default or prev value.
No, serialization/deserialization is still supported, you can check flatbuffers or capnproto (they generate source code that doesn't keep any strings), just to protect data don't want any message interface strings to be preserved in source code. Because once retained it can be easily reverse engineered, which is especially important in our game, where we want to hide the message structure
Activity
chronoxor commentedon Jun 27, 2022
You can annotate field as

[Hidden]:And its output will be

***:romanholidaypancakes commentedon Jun 28, 2022
The field names remain in the source code, and as long as you are familiar with fbe, you can still infer the message structure through reverse engineering
chronoxor commentedon Jun 30, 2022
Ok, as I understand you want to have 'transparent' fields that are present in objects/clases, but not serializable/deserializable and not output in logger/std::streams. Am I right?
When deserialzed this fields are skip and contain default or prev value.
Something like

[NonSerialized]attribute in .NET:romanholidaypancakes commentedon Jul 1, 2022
No, serialization/deserialization is still supported, you can check flatbuffers or capnproto (they generate source code that doesn't keep any strings), just to protect data don't want any message interface strings to be preserved in source code. Because once retained it can be easily reverse engineered, which is especially important in our game, where we want to hide the message structure