Utility to change "image file identification"?

[H.Becker]

>>>  For the imgid Itanium code, refer to:

http://vouters.dyndns.org/tima/OpenVMS-IA64-Changing_the_image_identitication_of_an_executable.html

   /*

   * The ident string must be no longer than eight characters

   * including the null terminating byte.

   */

No, see previous replies. In case the current string length is >=8 characters, your code creates an invalid - or should I say corrupts the ? - note section.

[Ph Vouters]

Harmut,

I did realize that the linker's IDENTIFICATION option string can be longer than 7 characters not including the

terminating null byte. So I reworked the code. The new code has been tested using binutils' readelf and is available at the same URL. I have set the ID string buffer limit to 80 inside the code. I hope it is large enough.

I have been misled by your imgid run on Alpha.

Philippe

[jreagan]

I still think Philippe's code won't do the right thing if you expand an image ident such that the .note section grows past a page boundary.  If you have to bump other sections down inside the file, you have LOTS of work to do to recompute all the section offsets in the header table.

[Ph Vouters]

John,

Do not think ! Send me an actual VMS image where the code I post does not do the trick and I'll rework upon it. On Itanium, I use both analyze/image and binutils' readelf to control. On Alpha, I only know of analyze/image.

Regards,

Philippe

[Ph Vouters]

John,

As you can read from this binutils's readelf run, the IA64 VMS Linker aligns the .note section on a disk block boundary and the .note length does not exceed a disk block.

$ readelf -a Rudy.EXE
ELF Header:
  Magic:   7f 45 4c 46 02 01 01 0d 02 00 00 00 00 00 00 00
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            VMS - OpenVMS
  ABI Version:                       2
  Type:                              EXEC (Executable file)
  Machine:                           Intel IA-64
  Version:                           0x1
  Entry point address:               0x501c8
  Start of program headers:          72 (bytes into file)
  Start of section headers:          11784 (bytes into file)
  Flags:                             0x1000014, 64-bit, vms_linkages
  Size of this header:               72 (bytes)
  Size of program headers:           56 (bytes)
  Number of program headers:         6
  Size of section headers:           64 (bytes)
  Number of section headers:         9
  Section header string table index: 1

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .shstrtab         STRTAB           0000000000000000  00002c08
       0000000000000056  0000000000000000           0     0     0
  [ 2] .strtab           STRTAB           0000000000000000  00002a08
       0000000000000001  0000000000000000           0     0     0
  [ 3] .debug_line       VMS_TRACE        0000000000000000  00001e00
       000000000000020f  0000000000000000           0     0     1
  [ 4] .trace_abbrev     VMS_TRACE        0000000000000000  00002200
       000000000000001e  0000000000000000           0     0     1
  [ 5] .trace_info       VMS_TRACE        0000000000000000  00002400
       000000000000006c  0000000000000000           0     0     1
  [ 6] .trace_aranges    VMS_TRACE        0000000000000000  00002600
       0000000000000030  0000000000000000           0     0     1
  [ 7] .note             NOTE             0000000000000000  00002800
       0000000000000188  0000000000000000           0     0     0
  [ 8] .dynstr           STRTAB           0000000000000000  00001750
       000000000000000a  0000000000000000   A       0     0     0
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

There are no section groups in this file.

Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000000000 0x0000000000010000 0x0000000000000000
                 0x0000000000000000 0x0000000000001230  RW     10
  LOAD           0x0000000000000200 0x0000000000020000 0x0000000000000000
                 0x0000000000000c90 0x0000000000000c90  R E    10
  LOAD           0x0000000000001000 0x0000000000030000 0x0000000000000000
                 0x00000000000000b0 0x00000000000000b0  R      10
  LOAD           0x0000000000001200 0x0000000000040000 0x0000000000000000
                 0x0000000000000100 0x0000000000000100  R      8
  LOAD           0x0000000000001400 0x0000000000050000 0x0000000000000000
                 0x00000000000001f8 0x00000000000001f8  R      10
  DYNAMIC        0x0000000000001600 0x0000000080000000 0x0000000000000000
                 0x0000000000000668 0x0000000000000668  R      200

 Section to Segment mapping:
  Segment Sections...
   00     
   01     
   02     
   03     
   04     
   05     

Dynamic section at offset 0x1600 contains 21 entries:
  Tag        Type                         Name/Value
 0x0000000060000019 (VMS_IDENT)          0x12c457f1337f3
 0x0000000060000035 (VMS_LINKTIME)       2012-07-14T19:26:47
 0x000000006000004d (VMS_PLTGOT_SEG)     0x4
 0x000000006000004b (VMS_PLTGOT_OFFSET)  0x200000
 0x000000006000002f (VMS_UNWINDSZ)       0x60
 0x0000000060000031 (VMS_UNWIND_CODSEG)  0x1
 0x0000000060000033 (VMS_UNWIND_INFOSEG) 0x3
 0x000000006000003d (VMS_UNWIND_OFFSET)  0x0
 0x000000006000003f (VMS_UNWIND_SEG)     0x3
 0x000000006000004f (VMS_FPMODE)         0x9800000
 0x0000000060000041 (VMS_STRTAB_OFFSET)  0x150
 0x000000000000000a (STRSZ)              10 (bytes)
 0x000000006000001d (VMS_NEEDED_IDENT)   0x2000100000001
 0x0000000000000001 (NEEDED)             Shared library: [DECC$SHR]
 0x0000000060000025 (VMS_FIXUP_NEEDED)   0x0
 0x0000000060000023 (VMS_FIXUP_RELA_CNT) 0x13
 0x0000000060000049 (VMS_FIXUP_RELA_OFF) 0x160
 0x0000000060000015 (VMS_LNKFLAGS)       0x4a0 IMGSTA MAIN TBK_IN_IMG
 0x000000006000001f (VMS_IMG_RELA_CNT)   0x11
 0x0000000060000045 (VMS_IMG_RELA_OFF)   0x3c0
 0x0000000000000000 (NULL)               0xdead

There are no relocations in this file.

There are no unwind sections in this file.

No version information found in this file.

Notes at offset 0x00002800 with length 0x00000188:
  Owner                 Data size       Description
  IPF/VMS              0x00000005       NT_VMS_IMGNAM (image name)
    Image name: RUDY
  IPF/VMS              0x00000005       NT_VMS_GSTNAM (sym table name)
    Global symbol table name: Rudy
  IPF/VMS              0x00000010       NT_VMS_IMGID (image id)
    Image id: 123456789012345
  IPF/VMS              0x00000020       NT_VMS_IMGBID (build id)
  IPF/VMS              0x00000008       NT_VMS_LINKTIME
   Link time: 2012-07-14T19:26:47
  IPF/VMS              0x0000000e       NT_VMS_LINKID (link id)
    Linker id: Linker I02-38
  IPF/VMS              0x00000025       NT_VMS_ORIG_DYN
   Major id: 1,  minor id: 3
   Manip date  : 2012-07-14T19:26:47
   Link flags  : 0x00000000000004a0
   Header flags: 0x01000014
   Image id    : V1.0
  IPF/VMS              0x00000008       NT_VMS_PATCHTIME
   Patch time: 2012-07-14T19:26:47

If you carefully paid attention to the code, this is just 8 + 8 or 16 + 24 bytes I am concerned with (NT_VMS_IMGID above). So, unless I misunderstood it, your remark was purely theoretical. However to satisfy your past (maybe current) developer mind, I did address your remark in an update of the code. Practically speaking, this should have no influence onto the sake of the produced ELF image compared with previously.

Kind regards,

Philippe

[Ph Vouters]

John,

You could only be correct provided the NT_VMS_IMGNAM + NT_VMS_GSTNAM .note subentries are so large that the NT_VMS_IMGID spans over two adjacent disk blocks AND the ELF image is not disk [re]written into a new file.

One can comment onto IMGNAM and GSTNAM physical limits on VMS.

Regards,

Philippe

[H.Becker]

>>> the IA64 VMS Linker aligns the .note section on a disk block boundary

This was already mentioned in this thread. Except for the dynstr, which for VMS images is part of the dynamic segment, all sections are on disk block boundary. Can you post an output of analyze./image? I'm curious to see that there are two other sections not starting at a block boundary.  But what do I expect.

>>> and the .note length does not exceed a disk block.

In your example the length is 0x188, so in the disk block there is space left for 0x78 characters.

In ELF, there are no limits for the size of the note entries, except that the descriptor size here has to fit in 64 bits. If there is a limit for the imgnam, then it is very likely in the linker processing options and/or tparse. An option line has to be longer than 1024, which is the maximum symbol length. I wouldn't expect any specific limit for the NAME= option. Gstnam is derived from a filename. All together it seems possible to fill more than a disk block. Not usual, but possible. And, the linker may change and add some more note entries and/or data to the orig area.

[Ph Vouters]

Harmut and John,

Please do refrein yourself from thinking theoretically. Find me a single non corrupted .EXE which matches your hypothesis. I can't find any which does.

$ @notes_section.com
Number of .EXE scanned

Grand total of 455 directories, 4563 files.
$ type notes_section.com
$ create notes_section.gawk
{
  blocksize = 512;
  if (/^Notes at offset /) {

     match($0,/^Notes at offset (.*) with length (.*):/,a);
     if ((strtonum(a[1])%blocksize != 0) || (strtonum(a[2]) > blocksize)) {
#          print "Alert : Note section not aligned on a block boundary or ...";
#          print "Notes section length greater than a block size";
          exit 44
     }
     else {
          exit 0
     }
  }
}
$ write sys$output "Number of .EXE scanned"
$ dire/grand sys$sysdevice:[*...]*.EXE;
$ context = 10
$ set process/priv=bypass
$ loop:
$ file = f$search("sys$sysdevice:[*...]*.EXE;",context)
$ if file .eqs. "" then exit
$ pipe readelf --note 'file' | gawk -f notes_section.gawk
$ if $STATUS .eq. 44
$ then
$     write sys$output "Look at this ''file' file"
$ endif
$ goto loop
$ logout

[jreagan]

I'll refrain from thinking.  I've done that for years... ask my wife.

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

linktime + imgnam + imgid + linkid + imgbid + gstnam + orig_dyn + patchtime

That should always be under 512 (I didn't actually add the max values, I did some thinking instead)

For .OBJ files, the .note sections can theoreticallly (there's that word again) be much larger than 512.  If the compilers decide to emit source file names, title text, and Pascal's "entity ident consistency check".

[Bob Blunt]

For non-operating system executable images this idea is ducky.  But, from past experience, munging around with the information in these areas for original .EXE files that are part of OpenVMS or it's layered products is generally what could be called A Bad Thing.  There are several utilities that use the information contained within the executable header of O/S images that depend on the data being exactly what DEC/CPQ/HP sent.

Having said that...it is your (or your customer's) system and it can be modified however you wish.  Just please be prepared with a backup of the disk or images if things stop working so you can restore what got clobbered.  It would also be polite to let customer support know if you've made changes of this sort because tools they use will also be effectively neutered.

bob