Hi everybody,

I think that this technique is good to be used for tripwire-like purposes - imagine to patch gcc, so that it builds your system with a unique digital signature - the need for an additional tripwire-db would disapear.

(You also could "patch" every existing file but including the functionallity in the compiler allows a greater controll, after all the compiler "knows", what it wants to achieve (see the carry-flag problem with ADD/SUB).)

What I have in mind is (for example), that a hash of the prog-name and a secret ( SHA("/usr/bin/gcc;mySecret") ) is embedded in the result and that this "sinature" could be verified later on.

Compiling the hash of the executeable into the executeable itself requires that the "to-be-changed instructions" are left out of the hash, lessening the

security (but not that much, because there is a mutual dependencie of the hash and the code, so changing the

"unhashed" code would also alter the hash).

Jens

[ reply ]

Link to this comment: http://www.securityfocus.com/comments/articles/2623/18620#18620