loadimm [-Vv] [-e] [-x] [-a] [ <-n new_value | -i inc_value> ] <constant> <executable> ...
As-is, this utility will probably only be of use under Solaris on a 32-bit
SPARC machine because (a) the ``elfprint'' utility it uses is based on the
source found in Solaris'
elf(3E) man page, (b) ``elfprint''
libelf(4) to link, and (c) it invokes
adb(1), expecting it work exactly like Solaris'
The options and arguments are:
adb(1)will be invoked in write mode (i.e.
adb -w) and will modify the
executable(s).(mnemonic: invoke 'a'db)
-iis used). This value can be specified in decimal or hex (with ``0x'' prefix).
sethi %hi(val), %r17 or %r17, %lo(val), %r17
or like this:
sethi %hi(val), %r17 and %r17, %lo(val), %r17
So, if we can determine the file offset and size of the text segment within
the executable, it is a simple matter of programming to modify those
instructions to load a different value. This is useful in executables for
which one doesn't have the source code but would like to change some hard-
coded ``magic numbers'' within the executable. For instance, one can change
a hard-coded TCP port number to which a given executable
This utility works by:
elf(3E)man page. It acts like the ``elfprint'' command demonstrated there, but also prints the file offset, size, and address of each segment. (Invoke this utility with the
-eoption to generate the ``elfprint'' source, then make and install that executable in the PATH.)
dis(1)assemble/decompilethe executables which would be prohibitively time consuming. strtoul was *very* useful here.)
adb(1)to patch those instruction pairs within the executable. (If the
-aoption is not specified, it just shows you the
adb(1)commands that would perform the change.)
-a!, instead just do, for example:
$ loadimm 0xd00d my_executable
and then invoke
adb manually. As you invoke the ``suggested''
command, carefully consider the context in which the target instructions
(which are displayed with the
adb commands) occur before issuing the
?W adb instructions (which actually perform the modifications.) Of course,
always save a backup of your executable and the file systems containing the
files/databases on which it operates in the event that something goes
Also, if you modify an executable authored by someone else (which is presumably what you're doing since you don't have source code), *don't* report a bug that has only been observed in the modified executable. (Once the executable has been modified - essentially all warranties/ guarantees are void.) Go back to the original, and reproduce the bug there before calling for support.
Before doing an update, it would be a good idea to scan your executable to be sure it doesn't already contain other references to your new constant's value, so that you can be sure that, in the future, it would be possible to locate the modified instructions in case you want to undo what's been done.
First, if you haven't already done so, build the ``elfprint'' utility (Note
that this utility differs slightly from the ``elfprint'' that is shown in
elf(3E) man page):
$ loadimm -e > elfprint.c $ chmod +x elfprint.c $ ./elfprint.c # yes, actually execute the source file (as a shell script)! gcc -o ./elfprint ./elfprint.c -lelf $ # if necessary, install "elfprint" so that it is in your PATH
Check that a ``load immediate 0xbabe'' instruction doesn't already exist in the executable:
$ loadimm -v 0xbabe my_executable
If no occurences are found, do the modification:
$ loadimm -n 0xbabe 0xd00d my_executable
If ever necessary, revert to original:
$ loadimm -n 0xd00d 0xbabe my_executable