Just leave a comment about experience like this, as I pass by.
during developing Kafka search tool, it have to support many kind of decode formats ( such as Avro + schemaRegistry, protobuf, ConnectJson(json with schema), and so on ).
it recommend a type of deserializer by looking at the leading bytes.
After user select final decision, it is ok if error occurs during first data deserialize,
But many case it’s not occurred error, just pass through with plausibly wrong parsed data.
So my solution was display 10 pre decoded sample to user, and make user select one deserializer by eye.
ConnectJson is reliable, because it has data and schema embedded in every message ( but large ).
In my case using schema-registry, server1 has schema no 10, and server2 has schema no 10 but it’s different.
I make a mistake select wrong server 2, data parsing is progressed but plausibly wrong data
It took me a long time to find and correct some thing wrong.
It's derived from a password. The article is from a cyber investigation company and Cronos is a Russian database, so I guess they got some files leaked from a CIS based threat actor and the password wasn't included.
Yes, as tancop answered, the KOD key is encryption and obfuscation mechanism to secure the CronosPro files. And with enough schema data the correct KOD table can be inferred.
CronosPro is a proprietary format and it is assumed you are using their own software to manipulate it. As it is closed source and not really a software we dare to run on managed devices, exporting data from the Cronos format to CSV through the proprietary software becomes quite a hassle. And this is the reasoning behind the whole reverse engineering.
But of course it was a fun process and very satisfying when the normalizer actually started to work.
I love this new trend of reverse engineering, amplified by AI. Been doing numerous projects like this myself.
Indeed, past a certain skill level it all becomes grunt work. Fun grunt work, but one that AI is also good at.
Just leave a comment about experience like this, as I pass by.
during developing Kafka search tool, it have to support many kind of decode formats ( such as Avro + schemaRegistry, protobuf, ConnectJson(json with schema), and so on ). it recommend a type of deserializer by looking at the leading bytes. After user select final decision, it is ok if error occurs during first data deserialize, But many case it’s not occurred error, just pass through with plausibly wrong parsed data. So my solution was display 10 pre decoded sample to user, and make user select one deserializer by eye.
ConnectJson is reliable, because it has data and schema embedded in every message ( but large ). In my case using schema-registry, server1 has schema no 10, and server2 has schema no 10 but it’s different. I make a mistake select wrong server 2, data parsing is progressed but plausibly wrong data It took me a long time to find and correct some thing wrong.
Where does the KOD key come from? Can it be recovered by reverse engineering CronosPro?
It's derived from a password. The article is from a cyber investigation company and Cronos is a Russian database, so I guess they got some files leaked from a CIS based threat actor and the password wasn't included.
Yes, as tancop answered, the KOD key is encryption and obfuscation mechanism to secure the CronosPro files. And with enough schema data the correct KOD table can be inferred.
the cronospro format sounds painful. did you consider asking the vendor for the spec, or was the reverse engineering half the fun?
CronosPro is a proprietary format and it is assumed you are using their own software to manipulate it. As it is closed source and not really a software we dare to run on managed devices, exporting data from the Cronos format to CSV through the proprietary software becomes quite a hassle. And this is the reasoning behind the whole reverse engineering.
But of course it was a fun process and very satisfying when the normalizer actually started to work.
[flagged]
[flagged]