Let's add file name, file SHA256, and arbitrary text message/description to qrxfil QRs, inside the first payload chunk.
It isn't wise to add these inside the chunk header, because this has overhead on eveyr chunk, filename + message would be arbitrary sized, and these aren't useful on each chunk, just once.
So this has to go in the payload, I propose in the very first chunk's payload. This means after scanning the first chunk, we know not just how many chunks to expect, but what the file is, and why it's exfiltrated (message/description).
Question:
- How to distinguish the fields (content-length numbers? delimitors?)
- How to keep message size as static as possible, to make easy to (de)serialize.
Example chunk with proposal (using ; delimitor)
001OF006mycoolfile.tar.gz;1a3f466c84f0efdb38b7e807cbe3428aa5d4acb681a1871da2718901a6e25081;Version 1.0 of the coolfile tarball;base64payloadhere
Let's add file name, file SHA256, and arbitrary text message/description to qrxfil QRs, inside the first payload chunk.
It isn't wise to add these inside the chunk header, because this has overhead on eveyr chunk, filename + message would be arbitrary sized, and these aren't useful on each chunk, just once.
So this has to go in the payload, I propose in the very first chunk's payload. This means after scanning the first chunk, we know not just how many chunks to expect, but what the file is, and why it's exfiltrated (message/description).
Question:
Example chunk with proposal (using
;delimitor)