3 ms·
OK, but how is the 32-bit header itself embedded? The header is a good thing for preventing accidental extraction from binaries not treated with steg86, but st
by jaclaz 6y ago
OK, but how is the 32-bit header itself embedded?
The header is a good thing for preventing accidental extraction from binaries not treated with steg86, but still you need to modify 4 bytes (or 4 instructions) to embed this header, so - at least theorically - the possibility of a "collision" or of a false positive seems relatively high to me.
- woodruffw 6y ago> OK, but how is the 32-bit header itself embedded? The header is embedded according to the same rules as the rest of the message: it's treated as a bitstring, and flippable instructions are flipped appropriately to encode it. > the possibility of a "collision" or of a false positive seems relatively high to me. As others have pointed out, compilers (and assemblers) tend to stick to a single selection choice for register-to-register ops. Even in the case where a compiler writer flips between them randomly, their 32 random choices would have to align precisely with the expected header. It's certainly not impossible, but pretty unlikely. It's also completely remediable with a CRC32 or similar field tacked onto the header; I just didn't think the likelihood warranted that for the initial design.
- paraboul 6y ago4 bytes of the encoded header isn't 4 instructions, it's 32 consecutive instructions that each translate to a bit depending on their semantic form. So there is virtually no chance for a compiler to generate a valid sequence randomly.
- jaclaz 6y agoI see, each changed instruction gives a single bit (not byte) of information, my bad.