Specify address for a function in Relocatable Code
 

I compiled a program without the main routine in it.
Then I compiled it using : user@user-desktop:~/Dir$ gcc -c blank.c -o blank.o
then I did a relocatable ld on it: user@user-desktop:~/Dir$ ld -r blank.o
Then I took its objdump: user@user-Desktop:~/Dir$ objdump -d blank.o | more

blank.o: file format elf32-i386
Disassembly of section .text:
00000000 <blank>:
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: 83 ec 08 sub $0x8,%esp
6: c7 04 24 00 00 00 00 movl $0x0,(%esp)
d: e8 fc ff ff ff call e <blank+0xe>
12: c9 leave
13: c3 ret

Is there anyway I can make the function start at a specific address, for example <ld -Ttext 08040000 blank.o> would make the "_start" of the binary start at the specified address. Here since I do not have a _start (because I do not have a main() routine) this command fails.

What I am trying to do is Inject this code (well not this code but a different code without any function calls like printf) during run-time into a running process. The reason why I am looking to make the code start at a specific address is that I will be injecting it at that location in the different process. I know all jumps generated by the compiler are relative by default, however, I learnt it the hard way to never trust a compiler. So it might happen that the compiler generates an absolute jump which will cause my application to crash.

Can anyone point me to a sample loader/linker script or compiler command to make the function bytecode start at a particular address? And I guess the ld -r command is a bit redundant.

so you are trying some cracking?

You won't get help here for that. Besides, the linux kernel is a virtual memory system; you won't be able to enforce a specific load location.

No am not trying cracking, lot of things I do sound like cracking, but actually they are not. I think its not really cracking if the program itself decides to inject the code on itself. I know I cant force a specific load location in the physical memory, but I was hoping that I can give the function a specific virtual address to begin.

It is precisely the attitude that is revealed in this statement that will get you no help here.

Ok, not really any intention of mine to argue, but I am doing something perfectly legitimate. Yeah, everyone is going to say, why are you doing it this way. But this is the threat model I am dealing with. However, if the board rules are such that this topic wont be answered, then its all right, this thread can be closed.

Reopen it for a sec - how do you do this "injecting"? I thought one process tampering with anothers memory was forbidden by the chip, that's why "protected" mode..?

And really, how can you crack software for Linux? They are free, except some stuff used by the movie studios.

resetreset - ptrace is the easiest way to inject information into a running program. The memory tampering is user based, any process can access the memory of another process being run as the same user, otherwise debuggers would have a really hard time attaching to running processes. The protected mode is for separating kernel space from user space.

raghu2383 - would it be possible to use a preloaded library? If you aren't trying to replace a function in the program itself that would probably be the easiest route.

No, it is not another process that is injecting code. It is the same process injecting code in itself. Ptrace can be used by another process to inject code into any program on the system. You don't need any admin rights for running ptrace. All debuggers use ptrace. It is very rich and gives lot of handling info. However in my case I cannot use ptrace to inject code on oneself. It will be a weird loop, and even then I would have the same problem that I am currently facing.

There is another way to do it, the concept is quite simple, you read data and write it on yourself. The implementation is a bit complex. But that was not really my problem.

My problem was that I do not want the gcc compiler to produce absolute jump addresses. Normally the compiler produces relative jumps, however the Intel Instruction set has around 8 types of Jumps. 4 of them are relative jumps like jmp 17 bytes, while the other 4 are absolute addresses like jump to <virtual address>. If the compiler produces absolute jumps, then when the process injects new code on itself, everything crashes.

I still havent solved this problem. Looks like gcc -pie -fpie produces relocatable code, but I am not sure if it is guaranteed not to produce absolute jumps. If anyone knows where the documentation for it can be found I will be thankful.

No, I wish it were so :-), however the program, needs to inject code on itself during run time in a pre defined slot which has a bunch of no-ops. And the code contains just one function compiled fresh.

Thanks in Advance.

I think this should be stickied as the hugest possible flaw there can be in an OS.

Hmm. Given the almost unbelievable flaw I've already mentioned, could you look into whether it's possible to get Linux to load a prog at a particular address? :)

Why would you call that a flaw? This capability is at the heart of most of the interprocess communications facilities of Linux. The operative phrase here is that processes can access the memory of other processes being run as the same user. And even then, provision has to be made for that when the program is loaded and the memory is allocated.

raghu2383 - ah well -fPIC might do the trick for you, it should eliminate all absolute jumps, it produces code segments suitable for using with dynamic loading (dlopen ...)

Erm...correct me if I'm wrong, but this sounds a lot like NOP-sled'ing...:scratch:

I havent performed NOP sled in. maybe It is similar. What I did was actually write a function. Write tons of dummy instructions like int a; a= a+1.... etc etc. So well it is not exactly No ops over there, but something similar.