> The software analogy I like to use is trying to reflect a change in your source code by modifying the binary directly without recompiling. Not sure about kay

> The software analogy I like to use is trying to reflect a change in your source code by modifying the binary directly without recompiling. Not sure about kayson, but I've done essentially that on a couple occasions (usually to some C++ abomination that refuses to compile away from the authors' build server). It's not that difficult.[0] > Unlike those pirate crackers who sometimes can pull this off, imagine you have no idea what the binary does, and even if you "run" it in simulation (super slowly) everything is gibberish. Realisticly, you usually do have a pretty good idea what the chip does[1], and may have 'extra'/'lost' stock from the previous revision to compare its behaviour against, especially if you're attacking something popular enough to be worth compromising (= probably more than one batch ordered). 0: Most off-the-top-of-head example from my notes file: fix caja(glib) wrong(decimal) unit prefixes: at libglib-2.0.so.0.4105.0:7CFB1 [... more at ...] change 4 bytes in g_format_size_full from: 41 F6 C4 02 test r12b 0x02 # if(flags&G_FORMAT_SIZE_IEC_UNITS) into: 48 83 FB 00 cmp rbx byte(+0x00) # if(size!=0) 1: Presuming 'you' are a intelligence agency, ie the kind of thing that would credibly try such a attack, not a isolated disgruntled fab employee.