Utility to change "image file identification"?

[H.Becker]

The people in the objects and images team in VMS engineering, who did the IA64 linker, did way too much thinking.

They anticipated that manipulated images would cause some problems or confusion for customer support. They thought of two things, an area where the original data was stored including a cell for the manipulation date and a cell for the patch time. SET IMAGE was adjusted to update the manipulation date, whenever it changed the image. The only changes it can make are to the data which are kept in the original data area. And sure, there is a simple command to restore the original image. PATCH/ABSOLUTE was adjusted to update the patch time. That is, with all VMS supplied tools there is a timestamp indicating an image manipulation.

But it is true, everybody can write her/his own tool (a program, a DCL script or whatever) and change any data anywhere in an image - without knowing how to or even thinking of leaving any (other) footprint.

[H.Becker]

>>> Find me a single non corrupted .EXE...

It took some time, because I usually don't have access to an Integrity. I let the linker create one for you:

Number  Type                 Name                              File Address     
File Size         Flags

...

    7.  NOTE                 .note                             0000000000001200
0000000000000218  ------------------------------

I didn't use readef,  but I'm sure you will see that the size of the note section is 0x218.  As I said, it is possible. And if it is possible, it will show up, sooner or later. That's my experience.

[Ph Vouters]

Bob,

Refer to the NT_VMS_ORIG_DYN .notes subsection of the readelf output I posted.  Although the Image identification is changed, the ORIG_DYN .note subsection still shows V1.0. I haven't checked thoroughly but I do not seem to recollect that analyze/image displays such information.

I strongly agree with you : this kind of practice makes software support slightly more complicated and should be best effort avoided. However, when developers do not follow strict Linker's IDENTIFICATION option setting, the code I propose is a mean to address such lack. If I refer to David Lennon original post and need, this addresses the problem he is faced with.

Yours sincerely,

Philippe Vouters (ex-HP French support)

[Dennis Handly]

>In an .EXE, there is an upperbound for .note section size.

>For .OBJ files, the .note sections can theoretically (there's that word again) be much larger than 512.

Gee, you are thinking too small.  ;-)

For HP-UX using the aC++ compiler, the compiler ecom itself has, the HP-UX linker just concatenates the .notes:

41     NOTE 0000000000000000 00000000048d5ba8 000fb590 .note
1,029,520 bytes

[jreagan]

Currently, none of the .note entries in object files are carried over to the executable.  Such things have been suggested in the past for people asking "what source files or compiler versions were used to create my executable".  The answer has always been "you should have saved the linker .MAP file, it tells you almost all of that".  If that would ever changes, then yes, the executable's .note section would be much larger.  It would take up more disk space, but not make the activation that much slower as the .notes would still be in an ELF section, not an ELF segment.