UNIX libraries' preprocessor for IDA Pro
Red Plait
Published by +Tsehp April 2000
|
We should not wait a favour from Ilfak
(C) myself
|
Requirements
This time we will need some equipment. In the first place, as this
program was designed for UNIX you should have the OS; second, you need
some C-compiler; and lastly GNU binutils package is necessary for
building my tool. I use binutils v.2.9.1 for FreeBSD - it is supplied
together with source codes as a part of this fine operation system; but
you always can get latest version of GNU from the nearest GNU-project mirror
(and also read this
document). Moreover, using the tool requires Flair package
of IDA - one of the few add-ons distributed by Ilfak as freeware (either
because of his own distraction or due to his mistake) - it can be got from
its
native site
(I used v.3.8). I hope that's all.
What does it do ?
What the program was designed by this insane Red
Plait? In short it is a UNIX libraries' preprocessor for creation
.PAT-files,
and its full name is "Red
Plait .PAT creator" (shifting
bold characters left and some imagination gives RPat, or may
be RP@. But this name is not the matter of the program). If
you fall mad after reading the previous sentence, I'll try to illustrate
it as simple as possible.
One of the advantages of IDA Pro is its capability to recognize functions
of standard libraries. It is possible not due to the genius of its
author (as erroneously the most part of users think), but by means of a
special mechanism named FLAIR -- Fast Library Acquisition for Identification
and Recognition (its author is Cristina Cifuentes - some of her works can
be seen here
- but nothing has been said about her in any documentation either to IDA
or to Flair). For this purpose signature files are used (similar
to those which are being used in most of antivirus scanners). The
first step to make a signature file is creation of a so-called pattern
file. These are the files which my tool creates. The matter
is that Flair has preprocessors for COFF and OMF libraries.
Ilfak doesn't want to produce any other ones, may be because there is nobody
who wants to pay him for it. But somebody can create a binary file (for
example Linux) with statically linked C run-time library, which has ELF
format ('-static' linker option). May be in consequence of some thoughtlessness
this time Ilfak has described the .PAT-files format - see pat.txt
document from Flair. (It's quite another matter than the use
of this "documentation" is a bit complicated). And in theory, the
similar tools should have been already created. But inasmuch as no
case of these tools is available (or may it is due to unreasonable high
price - I don't get a Belgian salary), I should make it by my own.
In view of the fact that I am too lazy to begin from the outset (but
I think that laziness is the engine of any progress :-) and to design extractors
for any UNIX format, I have used packet binutils from GNU.
It is able to manipulate dozens files' formats and has very useful utilities
like nm & objdump (by the way some pieces of code were
extracted from the last utility too :o).
I should call your attention to the fact, that it is already the second
version of the tool. The first one was sent with its source codes
to Ilfak just after it had been created (and nothing but disapproval has
arrived in answer). In case he has already sold it to somebody, be
aware of a big error in the program. It put the remains of function
to the output file when it should put them just after the block to be used
to calculate CRC (but Ilfak let me know nothing about this fact).
How does it works ?
It works like all the Flair preprocessors. You run rpat
with name of a library which you guess was statically linked to the file
and the tool generates .PAT-file. The others details were
described in the documentation for Flair.
The tool has some options:
-
-C
Makes demangling for C++ function names.
-
-a
Appends information to output file rather than creates a new one.
-
-g
Includes information not only about functions but all the global objects
from the name table as well. It is very useful with BSDi and old
versions BSD libraries where there is not any difference between variables
and function names and where the compiler puts them all in a common table
and assigns them as exportable (BSF_EXPORT).
-
-o filename
Specifies output file name.
-
-p length
Specifies the minimum function length (by default 32, like as pcf.exe).
-
-r
Doesn't include the list of names that were referred to by the function.
As far as I understand, this list is used neither by Flair nor by
IDA, so you can use this option without any hesitations - the output file would
have smaller length.
-
-v
When this option is set, the tool produces a great many of useful (and
not very) information about every function being processed, e.g. flags,
size. It is helpful to the people who know the processed file format
or to those who want to improve my tool :-).
-
-z
Under this option the tool tries to omit any leading and tail zeroes.
For some reason FreeBSD & SCO wares indicate the function length incorrectly,
with the result that they add zeroes to the end of the function (is it
quite possible that padding in symbol table is not considered ?).
This option was designed for those who like adventures.
How can you build it by yourself
This process is not as trivial as can be expected. The matter is
that UNIX doesn't practice distributing binaries files because there are
many versions of UNIX and they work with different types of processors.
I don't distribute any binary files either and if you want to use this
product of morbid imagination, you should compile it yourself.
But I assure you that I have assembled the tool for the following platforms
and processors:
- FreeBSD 3.1 ( and 3.4 as well) with standard C compiler (gcc 2.7.2.1) and
binutils distributed with source codes of this OS.
- RedHat Linux 5.1 with compiler gcc 2.7.2.3 and binutils 2.9
- RedHat Linux 6.1 with compiler egcs 2.91.66 and binutils 2.9.1
- SCO OpenDesktop 5.0.5 with my own builded compiler gcc 2.7.2.3 and binutils 2.9.1
- SCO UnixWare 7.0 with my own builded compiler gcc 2.8.1 and binutils 2.9.1
- SCO UnixWare 7.1 with egcs 1.1.1 (from SkunkWare) and binutils 2.9.1
- and the tool was not only assembled but it is working (and working quite well
with any OS :-) ! But it is no wonder because I have more than a five-year
experience as software engineer and UNIX system administrator...
Begin with assembling binutils. The process is well described
- configure/make/make install. The only interest point is
that under FreeBSD & others SCO products the configurator makes mistakes
in recognizing some types files for this platform. In such case,
I recommend you to run bfd/configuration with key --enable-targets=all.
This will include in the bfd-library all types of files comprehended
by OS. Here is an example of my version for UnixWare 7.0:
- coff-i386
- coff-a29k-big
- a.out.adobe
- a.out-mips-little
- b.out.big
- b.out.little
- elf32-big
- elf32-bigarc
- elf32-bigmips
- elf32-d10v
- elf32-hppa
- elf32-i386
- elf32-i860
- elf32-little
- elf32-littlearc
- elf32-littlemips
- elf32-m32r
- elf32-mn10200
- elf32-mn10300
- elf32-m68k
- elf32-m88k
- elf32-sparc
- elf32-powerpc
- elf32-powerpcle
- elf32-v850
- ecoff-bigmips
- ecoff-littlemips
- ecoff-biglittlemips
- coff-h8300
- coff-h8500
- a.out-hp300hpux
- a.out-i386
- a.out-i386-bsd
- coff-i386
- a.out-i386-freebsd
- coff-i860
- pe-powerpc
- pe-powerpcle
- pei-powerpc
- pei-powerpcle
- coff-go32
- coff-go32-exe
- a.out-i386-lynx
- coff-i386-lynx
- msdos
- a.out-i386-netbsd
- i386os9k
- pe-i386
- pei-i386
- coff-arm-little
- coff-arm-big
- pe-arm-little
- pe-arm-big
- pei-arm-little
- pei-arm-big
- coff-Intel-big
- coff-Intel-little
- ieee
- coff-m68k
- coff-m68k-un
- a.out-m68k-lynx
- coff-m68k-lynx
- a.out-m68k-netbsd
- coff-m68k-sysv
- coff-m88kbcs
- a.out-m88k-mach3
- a.out-newsos3
- nlm32-i386
- nlm32-sparc
- a.out-ns32k-netbsd
- a.out-pc532-mach
- aixcoff-rs6000
- ppcboot
- coff-sh
- coff-shl
- coff-sh-small
- coff-shl-small
- a.out-sparc-little
- a.out-sparc-linux
- a.out-sparc-lynx
- coff-sparc-lynx
- a.out-sparc-netbsd
- a.out-sunos-big
- a.out-zero-big
- tekhex
- a.out-tic30
- coff-tic30
- a.out-vax-netbsd
- versados
- coff-we32k
- coff-z8k
- srec
- symbolsrec
- tekhex
- binary
- ihex
Is this impressive? The size of libbfd.a is more than 16MB!
Now let's consider that the smoke emitted by your hard disk has already
disappeared and you have prepared binutils for your platform.
But I should let your know that this precompiled packet is not completely
ready for use because I use some object files from binutils subdirectory
besides libbfd.a & libiberty libraries, so don't hurry
to execute make clean. Edit my Makefile - change variable
BFD_ROOT to the subdirectory where binutils is disposed.
And only then execute make.
It should work well. In case if any problem arises... well,
see the next section :-)
Complaints and suggestions
Any complaint and propositions can be sent to the author by e-mail redplait@usa.net.
I will not answer stupid questions like "Where can I get IDA Pro" or "What
is UNIX". But If you'll find any bug, or you have some ideas or think
that I am wrong in some part of my reasoning - I ready to contact you.
There is another modest request, don't send me dozenmegabytes files (especially
uncompressed) as an evidence of anything. And as usual, in
no event will the author be liable to you for any consequences of his program
execution...
And last if you want me to create any loader, plug-in or processor module
for IDA Pro, don't hesitate to contact me...
#include <std_disclaim.h>