As I'm new to binutils, gcc ant others, I have some general questions, anwsers on which I havn't found in manuals.
I'm using C and assembly(nasm syntax) and I need raw binary files on output. First of all, I compile my code to objec file with parameters:
cc -nostartfiles -nostdlib -c -ffreestanding <input file(s)> ;cc or gcc no matter
Then I link all the files using simple script which only puts segments in needed order.
ld -T <script> -o <o.file> <in.file(s)> ;nothing special here
And to get raw binary I use objcopy
objcopy -O binary <o.file> <in.file> ;can't be simplier
All in all, I need binary file only with .text and .data segments in it and 32-bit code.
1.Can i get this way what I want?
2.Are there other ways to do that? (no matter easier or more complicated)
Thank you for help.
I haven't problems compiling Asm code, almost all problems with C code.
Once I came across a ld manual page and /DISCARD/ block was said to exclude everything listed in it from final output.
So I've inserted this block after the .text, .data and .bss blocks
/DISCARD/ :
{
*(.comment)
*(.eh_frame)
*(.note.GNU-stack)
}
As well as this line in the very beginning of my linker script.
OUTPUT_FORMAT("binary")
Therefore, I do not need to use objcopy anymore.
You need to compile the source files using this command
nasm -o bin <SOURCE FILES>
This will produce pure binary output.
Related
I'm attempting to convert an assembly file to C++ for use as a small and easy to insert "trampoline" loader for another library. It is injected into another program at runtime, then loads a library, runs a function inside of it, and frees it. This is simply to avoid needing multiple lengthy calls to WriteProccessMemory, and to allow certain runtime checks if needed.
Originally, I wrote the code in assembly as it gave me a high degree of control over the structure of the file. I ended up with a ~128 byte file structured as followed:
<Relocation Header> // Table of function pointers filled in by the loading code
<Code>
<Static Data>
The size/structure of the header is known at compile-time, also allowing the entry point to be calculated, so there is very little code needed to load this.
The problem is that sharing the structure of the header between my assembler (NASM) and compiler (GCC) is... difficult, hence the rewrite.
I've come up with this series of commands to compile/link the C++ code:
g++ -c -O3 -fpic Loader.cpp
g++ -O3 -shared -nostdlib Loader.o
Running objcopy -O binary -j .text a.exe then gives a binary file only about 95 bytes in size (I manually inserted some padding in the assembly version to make it clear when debugging where "sections" are).
Only one problem (at least for this question), the variable offsets haven't been relocated (obviously). Viewing the binary, I can see lines like mov rcx, QWORD PTR [rip+0x4fc9]. Clearly, this will not be valid in a 95 byte file. Is there a way (preferably using GCC or a program in Binutils) that I can get a stripped binary with correct offsets? The solution doesn't have to be a post-process like objcopy, it can happen during any part of the build proccess.
I'd really like to avoid any unneeded information in the file, it wouldn't necessarily be detrimental, but this is meant to be super lightweight. The file does not need to be directly runnable (the entry-point does not have to be 0).
Also to be clear, I'm not asking for a simple addition/subtraction to all pointers, GCC's generated addresses are spread across memory, they should be up against the code.
Although incomplete and needing some changes, I think I've come up with a functioning solution for now.
I compile as before, but link with a slightly different command: g++ -T lnkscrpt.txt -O3 -nostdlib Loader.o (-shared just makes the linker complain about missing a DllMain).
lnkscrpt.txt is an ld linker script (https://ftp.gnu.org/old-gnu/Manuals/ld-2.9.1/html_node/ld_5.html#SEC5) as follows:
SECTIONS
{
. = 0x00;
.bss : { *(.bss) }
.text : { *(.text) }
.data : { *(.rdata) *(.data) }
/DISCARD/ : {*(*)}
}
This preserves the order I want and discards any other default sections.
Finally I run objcopy -O binary -j .* --set-section-flags .bss=alloc,load,contents a.exe
to copy over the remaining sections to a flat binary. The --set-section-flags option simply insures that the binary contains space allocated for the .bss section.
This results in a 128 byte binary, laid out in the exact same way as my custom assembly version, using correct offsets, and not containing any unneeded data.
I want to add EWR(Execute/Write/Read) memory attribute to the .data section at compile time.
MSVC compiler can do this by simply adding the "/SECTION:.data,EWR" linker option.
But I don't know how to do this in GCC compiler (MinGW).
Please help!
The simplest way I could think of is adding a dummy file to the link with a .data.* section that has the desired flags. That dummy file is easy to produce using assembly:
.section .data.fake, "axw"
(assuming you are on an ELF platrofm, using gas).
Say, the file containing the above is called dummy.s, then you can either assemble it manually, and then add the result to the link
as dummy.s -o dummy.o
gcc <all your normal .o files> dummy.o # or `ld`
Or just pass the assebmly file to the driver:
gcc <all your normal files> dummy.s
Note that the assembler gives a warning:
Warning: setting incorrect section attributes for .data.fake
because of the unusual flags. It does set them as asked though.
Now, let me explain a little what is going on.
All the input .data* sections are merged into the output .data section. See the default linker script (ld --verbose):
.data :
{
*(.data .data.* .gnu.linkonce.d.*)
SORT(CONSTRUCTORS)
}
The flags of the output section are the union of the flags of the input section (I'm pretty sure this behavior is documented in the linker manual). That is how the trick works. The flags for the segment holding the resulting .data are then also computed as the union of the flags of the sections it contains. See the output of readelf -lW to make sure you got the result you expect. I have
...
LOAD 0x002e28 0x0000000000003e28 0x0000000000003e28 0x000200 0x000208 *RWE* 0x1000
...
05 .init_array .fini_array .dynamic .got .got.plt *.data* .bss
I am working on some (very) low level programming but not everything is completely clear to me. I start by creating a .cpp (or .c) file which is run through gcc to create an elf or object file but what is an object file? I get object files when I use the "as" compiler but how are these used and what is the purpose of having an object file when we could have a straight binary?
There is a very clear explanation of this question on the this site. I pasted it down below as well. But I strongly suggest you take a look at the diagram on the website. That will give you a much better high-level understanding of what is going on.
Compiling a source code file in C++ is a four-step process. For example, if you have a C++ source code file named prog1.cpp and you execute the compile command
g++ -Wall -ansi -o prog1 prog1.cpp
the compilation process looks like this:
The C++ preprocessor copies the contents of the included header files into the source code file, generates macro code, and replaces symbolic constants defined using #define with their values.
The expanded source code file produced by the C++ preprocessor is compiled into the assembly language for the platform.
The assembler code generated by the compiler is assembled into the object code for the platform.
The object code file generated by the assembler is linked together with the object code files for any library functions used to produce an executable file.
By using appropriate compiler options, we can stop this process at any stage.
To stop the process after the preprocessor step, you can use the -E option:
g++ -E prog1.cpp
The expanded source code file will be printed on standard output (the screen by default); you can redirect the output to a file if you wish. Note that the expanded source code file is often incredibly large - a 20 line source code file can easily produce an expanded file of 20,000 lines or more, depending on which header files were included.
To stop the process after the compile step, you can use the -S option:
g++ -Wall -ansi -S prog1.cpp
By default, the assembler code for a source file named filename.cpp will be placed in a file named filename.s.
To stop the process after the assembly step, you can use the -c option:
g++ -Wall -ansi -c prog1.cpp
By default, the assembler code for a source file named filename.cpp will be placed in a file named filename.o
I am developing an operating system. I would like to include a small asm program into my main kernel elf that can serve as the first process to load. I am having trouble getting this to work. The program is initcode.s. I using the following Makefile which I modified from the xv6 operating system source for this task:
initcode:
$(AS) $(ASFLAGS) initcode.s -o initcode.o
ld $(LDFLAGS) -N -e start -Ttext 0 -o initcode initcode.o
objcopy --input binary --output elf32-i386 --binary-architecture i386 initcode.out initcode
kernel.elf: $(OBJECTS) initcode
ld -T link.ld -melf_i386 $(OBJECTS) -o kernel.elf initcode
The kernel compiles and links fine. objcopy also creates markers which enable me to find the binary from within the kernel code. However the contents of initcode is trashed. The contents does not resemble what the assembler step produced within initcode.out.
How can I achieve including initcode.s as a separate binary somewhere in my main kernel.elf with some markers generated so I can find it from within my kernel? Any suggestions?
I can think of 2 simple methods. There are certainly more complex methods if you prefer.
Write a small utility to convert the initcode binary to an asm file (or even C file) containing a GAS data section. Then assemble that file and link it with your kernel. Your initcode will than appear as a variable in your kernel.
OR
Simply 'cat' the initcode binary to the end of your kernel elf after the link step. This method will depend on whether your loader is happy to support this.
I know there are some other similar questions about this out there, be it StackOverflow or not. I've researched a lot for this, and still didn't find a single solution.
I'm doing an operative system as a side project. I've been doing all in Assembly, but now I wanna join C code.
To test, I made this assembly code file (called test.asm):
[BITS 32]
GLOBAL _a
SECTION .text
_a:
jmp $
Then I made this C file (called main.c):
extern void a(void);
int main(void)
{
a();
}
To link, I used this file (called make.bat):
"C:\minGW\bin\gcc.exe" -ffreestanding -c -o c.o main.c
nasm -f coff -o asm.o test.asm
"C:\minGW\bin\ld.exe" -Ttext 0x100000 --oformat binary -o out.bin c.o asm.o
pause
I've been researching for ages, and I'm still struggling to find an answer. I hope this won't be flagged as duplicate. I acknowledge about the existence of similar questions, but all have different answers, and none work for me.
Question: What am I doing wrong?
Old MinGW versions had the problem that "ld" was not able to create non-PE files at all.
Maybe current versions have the same problem.
The work-around was creating a PE file with "ld" and then to transform the PE file to binary, HEX or S19 using "objcopy".
--- EDIT ---
Thinking about the question again I see two problems:
As I already said some versions of "ld" have problems creating "binary" output (instead of "PE", "ELF" or whatever format is used).
Instead of:
ld.exe --oformat binary -o file.bin c.o asm.o
You should use the following sequence to create the binary file:
ld.exe -o file.tmp c.o asm.o
objcopy -O binary file.tmp file.bin
This will create an ".exe" file named "binary.tmp"; then "objcopy" will create the raw data from the ".exe" file.
The second problem is the linking itself:
"ld" assumes a ".exe"-like file format - even if the output file is a binary file. This means that ...
... you cannot even be sure if the object code of "main.o" is really placed at the first address of the resulting object code. "ld" would also be allowed to put the code of "a()" before "main()" or even put "internal" code before "a()" and "main()".
... addressing works a bit differently which means that a lot of padding bytes will be created (maybe at the start of the file!) if you do something wrong.
The only possibility I see is to create a "linker script" (sometimes called "linker command file") and to create a special section in the assembler code (because I normally use another assembler than "nasm" I do not know if the syntax here is correct):
[BITS 32]
GLOBAL _a
SECTION .entry
jmp _main
SECTION .text
_a:
jmp $
In the linker script you can specify which sections appear in which order. Specify that ".entry" is the first section of the file so you can be sure it is the first instruction of the file.
In the linker script you may also say that multiple sections (e.g. ".entry", ".text" and ".data") should be combined into a single section. This is useful because sections are normally 0x1000-byte-aligned in PE files! If you do not combine multiple sections into one you'll get a lot of stub bytes between the sections!
Unfortunately I'm not the expert for linker scripts so I cannot help you too much with that.
Using "-Ttext" is also problematic:
In PE files the actual address of a section is calculated as "image base" + "relative address". The "-Ttext" argument will influence the "relative address" only. Because the "relative address" of the first section is typically fixed to 0x1000 in Windows a "-Ttext 0x2000" would do nothing but filling 0x1000 stub bytes at the start of the first section. However you do not influence the start address of ".text" at all - you only fill stub bytes at the start of the ".text" section so that the first useful byte is located at 0x2000. (Maybe some "ld" versions behave differently.)
If you wish that the first section of your file is located at address 0x100000 you should use the equivalent of "-Ttext 0x1000" in the linker script (-Ttext is not used if a linker script is used) and define the "image base" to 0xFF000:
ld.exe -T linkerScript.ld --image-base 0xFF000 -o binary.tmp a.o main.o
The memory address of the ".text" section will be 0xFF000 + 0x1000 = 0x100000.
(And the first byte of the binary file generated by "objcopy" will be the first byte of the first section - representing memory address 0x100000.)