This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: objcopy and ld: problem embedding string resource in executable


On Mon, Nov 19, 2012 at 12:43 AM, shankarke@gmail.com
<shankarke@gmail.com> wrote:
>
> Is objcopy used in production environments as well. I was just trying to
> find the usecase for this tool in production.
>
> llvm infrastructure does not have objdump today, but I was thinking if its a
> important tool that would be used in production environments.
For me, it helps keep resources with the executable. In my case, it
was some help text written in a text editor rather than placed in
source files with lots of calls to printf/cout. If I did it the
classic *nix way, I believe I would have put the help text in
/usr/share and loaded it if needed. This has caused problems in the
past in some cases (for example,
https://groups.google.com/group/cryptopp-users/msg/7edd5084ac06417e).
For what its worth, this program is cross platform (it has a Makefile
and Visual Studio solution), so embedding the resource was done on
both sides.

If a package system or signature scheme honors semantic
authentication, I think its easier to embed the resource and then sign
rather than signing executables and other select components. I'm not
sure any current package system honors it though (for example, sign
then align an Android APK). I worry about consuming untrusted or
tampered data, but many folks don't care.

I do have some self-checksumming gear, but it only raises the bar for
the attacker. Its useful on systems where signatures are not required.
The routines are for PE/PE+, Elf32/Elf64, and Mach-O. I checksum the
text and data sections (most data since I need to skip a few
variables, such as the signature). I don't want to worry about self
check-summing multiple files. I have a variation I use to attack
software breakpoints (keep the beggars off). In this case, objcopy is
helpful to add the public key to the executable also.

If you do offer the functionality please provide a 'native' flag for
the target architecture (like we use with -march=native). It would
really help clean up the makefile.

# objcopy flags
IS_I386 = $(shell $(UNAME) -m 2>&1 | $(EGREP) -i -c "^i386")
IS_X86_64 = $(shell $(UNAME) -m 2>&1 | $(EGREP) -i -c "^x86_64")

ifneq ($(IS_I386),0)
  OBJCOPY_OUTPUT = elf32-i386
  OBJCOPY_ARCH = i386
endif

ifneq ($(IS_X86_64),0)
  OBJCOPY_OUTPUT = elf64-x86-64
  OBJCOPY_ARCH = i386
endif

help-text.o:
    objcopy --input binary --output $(OBJCOPY_OUTPUT) \
    --binary-architecture $(OBJCOPY_ARCH) help-text.txt \
    help-text.o

Jeff


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]