Name | Last modified | Size | Description | |
---|---|---|---|---|
Parent Directory | - | |||
loadimm | 2000-03-03 16:26 | 15K | ||
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''
requires libelf(4)
to link, and (c) it invokes
adb(1),
expecting it work exactly like Solaris'
adb(1)
command.
The options and arguments are:
adb(1).
If -n
or -i
is specified, adb(1)
will be invoked in write mode (i.e. adb -w
) and will modify the executable(s).
(mnemonic: invoke 'a'db)
-n
or
-i
is used). This value can be specified in decimal or hex (with ``0x''
prefix).
-n
or -i
is used).
sethi %hi(val), %r17 or %r17, %lo(val), %r17
or like this:
sethi %hi(val), %r17 add %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
bind(2)s
and listen(2)s.
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 -e
option to generate the ``elfprint'' source, then make and install that
executable in the PATH.)
dis(1)assemble/decompile
the executables which
would be prohibitively time consuming. strtoul was *very* useful here.)
adb(1)
to patch those instruction pairs
within the executable. (If the -a
option is not specified, it just shows you the adb(1)
commands
that would perform the change.)
-i
or -n
with -a
!, instead just do, for example:
$ loadimm 0xd00d my_executable
and then invoke adb
manually. As you invoke the ``suggested'' adb
command, carefully consider the context in which the target instructions
(which are displayed with the ?i
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
terribly wrong.
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
the Solaris 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