how to insert unique ID into binary file that created after compilation?

[pristo]

hello All,
how can i insert unique ID into binary file (that created by compiler)?
(so after compiling i can to identify the src that i use)

thx

[Jordan Abel]

On 2005-11-09, Alan Balmer <al******@att.n et> wrote:

On Wed, 9 Nov 2005 19:36:20 +0000 (UTC), Jordan Abel
<jm****@purdue. edu> wrote:

On 2005-11-08, Gordon Burditt <go***********@ burditt.org> wrote:

There's no guarantee that SEEK_END on a binary file will work.
(Some OS such as CP/M only keep file sizes in sectors, so
there may be unwritten stuff at the end of the last sector in
a binary file, with no way to tell how much of it is unwritten.)
But those will be null bytes. You could always decide "that is part of
the file for purposes of what i'm doing" - just keep in mind that there
also may be extra null bytes after whatever _you_ wrote.

They won't necessarily be null.

C89 4.9.2

A binary stream is an ordered sequence of characters that can
transparently record internal data. Data read in from a binary stream
shall compare equal to the data that were earlier written out to that
stream, under the same implementation. Such a stream may, however, have
an implementation-defined number of null characters appended.

IOW... If the underlying filesystem doesn't zero such "garbage
characters" out, the C implementation is required to on closing the
file.
Even if they are, how do you know they weren't written on purpose, and
part of the data?

You'll have to keep track of that yourself. Anyway, it's
"Implementa tion-defined", not unspecified, so you have to be able to
look it up in the documentation.

[Gordon Burditt]

>> Even if they are, how do you know they weren't written on purpose, and

part of the data?

You'll have to keep track of that yourself. Anyway, it's
"Implementatio n-defined", not unspecified, so you have to be able to
look it up in the documentation.

You can't keep track of that yourself. The idea here was that the
code takes a random executable, having absolutely no idea whatever
of the format of an executable, and appends some stuff to the end
of it to stamp it with some kind of tag, hopefully without destroying
its usefulness as an executable in the process. Since the code has
no idea what the format of an executable is, it has no way to tell
whether trailing 0 bytes are an intentional part of the executable
or not.

A possible consequence of doing this is that some of the global
variables that are supposed to be zeroed on program loading are
now initialized to the contents of the tag. Or the executable
could fail its checksum and the OS would refuse to run it.

Gordon L. Burditt

[Jordan Abel]

On 2005-11-09, Gordon Burditt <go***********@ burditt.org> wrote:

Even if they are, how do you know they weren't written on purpose, and
part of the data?

You'll have to keep track of that yourself. Anyway, it's
"Implementati on-defined", not unspecified, so you have to be able to
look it up in the documentation.

You can't keep track of that yourself. The idea here was that the
code takes a random executable, having absolutely no idea whatever
of the format of an executable, and appends some stuff to the end
of it to stamp it with some kind of tag, hopefully without destroying
its usefulness as an executable in the process. Since the code has
no idea what the format of an executable is, it has no way to tell
whether trailing 0 bytes are an intentional part of the executable
or not.

It doesn't need to. It just has to leave everything it finds intact. I
didn't say it should overwrite the null bytes. I said it should write
beyond it, leaving everything it finds, including the null bytes,
intact.

[Daniel Rudy]

At about the time of 11/8/2005 1:01 PM, Skarmander stated the following:

Otherwise, you'll have to try and outsmart your compiler (this is
generally a bad idea, but it may be the only option). That is, involve
the constant in expressions that are too complicated for the compiler to
detect as going unused or evaluating to a constant. If you find such an expression, it may be a good idea to encapsulate it
in a function, otherwise it'll look very mysterious.

S.

For an embedded solution, that might not be a bad idea. It would throw
those off who are trying to hack the code. But, because the compiler is
compiling for an embedded system, there may not be a way to disable this
because embedded systems only have a few K of program storage at most.
For example, the Atmel ATmega16 has only 8K locations at 16-bits wide.
The processor word side is 16-bits, and it's a RISC.

--
Daniel Rudy

Email address has been base64 encoded to reduce spam
Decode email address using b64decode or uudecode -m

Why geeks like computers: look chat date touch grep make unzip
strip view finger mount fcsk more fcsk yes spray umount sleep

[Chris Torek]

>On 2005-11-09, Gordon Burditt <go***********@ burditt.org> wrote:

... The idea here was that the
code takes a random executable, having absolutely no idea whatever
of the format of an executable, and appends some stuff to the end
of it to stamp it with some kind of tag, hopefully without destroying
its usefulness as an executable in the process. Since the code has
no idea what the format of an executable is, it has no way to tell
whether trailing 0 bytes are an intentional part of the executable
or not.

In article <sl************ *******@random. yi.org>
Jordan Abel <jm****@purdue. edu> wrote:It doesn't need to. It just has to leave everything it finds intact. I
didn't say it should overwrite the null bytes. I said it should write
beyond it, leaving everything it finds, including the null bytes,
intact.

Indeed, you can certainly append data to the file (if it is writeable
in such fashion at all) -- but systems exist in which this will
make the file non-executable. In particular, some systems include
a "cryptographica lly-strong" checksum of the binary in the binary,
and will not excute a binary whose checksum is incorrect. (This
does not guarantee that the binary will *not* run either, even
ignoring the -- tiny, one hopes -- possibility that the checksum
still matches: it depends on whether the checksum covers the entire
binary, or only the parts that are used when executing the binary.)

There are also systems that *will* run the resulting binary, but
on which it will behave incorrectly. In particular, the tail end
of the file will be mapped as data+bss on Unix-like systems that
do virtual memory by mapping correctly-aligned files. The first
few bytes of "bss", which are supposed to be zero, will now be
nonzero and contain the appended data. This may cause some
static-duration variables that must be zero to be nonzero:

#include <stdio.h>
#include <stdlib.h>

int main(void) {
static int mbz; /* must be 0 */

if (mbz != 0)
puts("broken");
return mbz == 0 ? EXIT_SUCCESS : EXIT_FAILURE;
}

(One's chances of hitting "mbz" here are small in some cases, large
in others, depending on any shared library mechanisms. You can
often "improve" the chance by fiddling with linker options.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.