objcopy and ld: problem embedding string resource in executable

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

objcopy and ld: problem embedding string resource in executable

Jeffrey Walton-3
Hi All,

I'm having a problem with objcopy and embedding a string resource in
an executable.

$ cat makefile
...
OBJS = $(SRCS:.cpp=.o) help-text.o
...
help-text.o:
        objcopy --input binary help-text.txt help-text.o

$ make
...
/usr/bin/ld:help-text.o: file format not recognized; treating as linker script
/usr/bin/ld:help-text.o:2: syntax error
collect2: ld returned 1 exit status

I know I'm not using all arguments that objcopy needs
(http://www.linuxjournal.com/content/embedding-file-executable-aka-hello-world-version-5967).
The following are missing: --output elf32-i386 --binary-architecture
i386 (or elf32-x86_64 andx86_64). I did this because I want objcopy to
use the native format (either x86 or x64). I guess I was wrong in
hoping objcopy would deduce proper flags.

Any ideas how I can get objcopy to use sane values for --output and
--binary-architecture? Is the a 'native' flag, such a -march=native?

Jeff
Reply | Threaded
Open this post in threaded view
|

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

shankarke@gmail.com
Hi Jeff,

Is objcopy used in production environments as well. I was just trying to find the usecase for this tool in production.

llvm infrastructure doesnot have objdump today, but I was thinking if its a important tool that would be used in production environments.

Thanks

Shankar Easwaran
Reply | Threaded
Open this post in threaded view
|

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

Andrew Pinski-3
On Sun, Nov 18, 2012 at 9:43 PM, [hidden email]
<[hidden email]> wrote:
> Hi Jeff,
>
> Is objcopy used in production environments as well. I was just trying to
> find the usecase for this tool in production.

Simple use case, when you need a static linked binary that you don't
have a loader for.  Think bootloaders.

Thanks,
Andrew Pinski

>
> llvm infrastructure doesnot have objdump today, but I was thinking if its a
> important tool that would be used in production environments.
>
> Thanks
>
> Shankar Easwaran
>
>
>
> --
> View this message in context: http://sourceware-org.1504.n7.nabble.com/objcopy-and-ld-problem-embedding-string-resource-in-executable-tp213472p213514.html
> Sent from the Sourceware - binutils list mailing list archive at Nabble.com.
Reply | Threaded
Open this post in threaded view
|

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

Jeffrey Walton-3
In reply to this post by shankarke@gmail.com
On Mon, Nov 19, 2012 at 12:43 AM, [hidden email]
<[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

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

Cary Coutant-2
> 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.

Have you considered using the assembler's .incbin directive? This is a
convenient way to embed a file verbatim into an object file, and you
don't need to figure out what the output format is. You can also
define start and end symbols to make it easier to find the data in the
running program.

-cary