flat assembler
Message board for the users of flat assembler.

Index > Linux > creating shared libraries - how to do make PIC with GOT

Goto page Previous  1, 2
Author
Thread Post new topic Reply to topic
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4624
Location: Argentina
LocoDelAssembly 25 Sep 2006, 20:19
[edit] SOLVED, check below [/edit]
No luck Sad

This is what I tryed:

The sources first...
Code:
; shared-lib.asm
format ELF

section '.text' executable

public getTheMostValuableMessage

getTheMostValuableMessage:
        push    ebx

        call    @f
    @@: pop     ebx
        sub     ebx,rva @b ; @b-rva @b is the GOT address

        lea     eax,[ebx+rva message]
        mov     edx, size-message

        pop     ebx
        ret

message db 'Which is the sense of the life? 42', 10 ;added "10" to get better output (and to make the output visible in some distros)
size:    

Code:
; shared-lib-test
format ELF

section '.text' executable

 public _start
 extrn getTheMostValuableMessage

 _start:
        call    getTheMostValuableMessage

        mov     ecx,eax
        mov     eax,4
        mov     ebx,1
        int     0x80

;       ret produces segmentation fault so I'll use int $80 to exit instead
        mov     eax, 1
        xor     ebx, ebx
        int     $80

    


Now the terminal:
Quote:
root@athlon64:/home/oem/Desktop/test# fasm shared-lib.asm
flat assembler version 1.67.10 (16384 kilobytes memory)
3 passes, 429 bytes.
root@athlon64:/home/oem/Desktop/test# fasm shared-lib-test.asm
flat assembler version 1.67.10 (16384 kilobytes memory)
1 passes, 404 bytes.
root@athlon64:/home/oem/Desktop/test# ld -m elf_i386 -shared -soname shared-lib.so -o shared-lib.so shared-lib.o
root@athlon64:/home/oem/Desktop/test# ld -m elf_i386 -o shared-lib-test shared-lib-test.o shared-lib.so
root@athlon64:/home/oem/Desktop/test# ./shared-lib-test
bash: ./shared-lib-test: No such file or directory
root@athlon64:/home/oem/Desktop/test# ls shared* -l
-rw-r--r-- 1 root root 369 2006-09-25 17:11 shared-lib.asm
-rw-r--r-- 1 root root 429 2006-09-25 17:13 shared-lib.o
-rwxr-xr-x 1 root root 1450 2006-09-25 17:13 shared-lib.so
-rwxr-xr-x 1 root root 1653 2006-09-25 17:15 shared-lib-test <- Here it is!!
-rw-r--r-- 1 root root 182 2006-09-25 17:11 shared-lib-test.asm
-rw-r--r-- 1 root root 404 2006-09-25 17:13 shared-lib-test.o


I don't know what happens here, I also tried copying shared-lib.so to /lib directory and /lib32 directory but same result Sad

Yeah, I know, I must be using a command wrong but what is the correct way then?

Regards

[edit] There is some modifications on the sources [/edit]


Last edited by LocoDelAssembly on 26 Sep 2006, 16:08; edited 1 time in total
Post 25 Sep 2006, 20:19
View user's profile Send private message Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4624
Location: Argentina
LocoDelAssembly 26 Sep 2006, 02:44
Seems that I'll never get it work, 4 hours trying, 4 hours!!!

Even using "-rpath /home/oem/Desktop/test/" doesn't work, throws "bash: ./shared-lib-test: No such file or directory ".

My last attempt was this:
Quote:
root@athlon64:/home/oem/Desktop/test# ld -m elf_i386 -shared -o shared-lib.so shared-lib.o
root@athlon64:/home/oem/Desktop/test# ld -m elf_i386 -rpath /home/oem/Desktop/test/ -o shared-lib-test shared-lib.so shared-lib-test.o


But I'm still geting the "bash: ./shared-lib-test: No such file or directory" message (but the file exists of course).

Here the readelf -a shared-lib-test
[edit] <Removed to improve screen space>[/edit]


PS: Note that if I link statically I can execute shared-lib-test without problems (linking against shared-lib.o instead of shared-lib.so), but it's not shared in that case...

[edit]

Here the definitive sequence to get it work on Ubuntu 64-bit Dapper Drake (6.06.1 LTS)

Quote:
fasm shared-lib.asm
fasm shared-lib-test.asm

ld -m elf_i386 -shared -o shared-lib.so shared-lib.o
ld -m elf_i386 -rpath . -dynamic-linker /lib/ld-linux.so.2 -o shared-lib-test shared-lib-test.o shared-lib.so



Note that this is for testing, you have to follow a diferent procedure in order to install the shared library (check the link that Tomasz posted below).

Regards
[/edit]


Last edited by LocoDelAssembly on 26 Sep 2006, 16:04; edited 1 time in total
Post 26 Sep 2006, 02:44
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8363
Location: Kraków, Poland
Tomasz Grysztar 26 Sep 2006, 07:33
The way you linked it, to execute the program correctly you have to run it like:
Code:
/lib/ld-linux.so.2 --library-path . shared-lib-test    


Or better, link the test program like this:
Code:
ld -dynamic-linker /lib/ld-linux.so.2 -o shared-lib-test shared-lib-test.o shared-lib.so    

and then execute with command:
Code:
LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH ./shared-lib-test    


PS. See http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html for some info.
Post 26 Sep 2006, 07:33
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4624
Location: Argentina
LocoDelAssembly 26 Sep 2006, 16:15


I read it yesterday but seems that I got it wrong...

Using "ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o shared-lib-test shared-lib-test.o shared-lib.so" shared-lib-test works using /lib/shared-lib.so or /lib32/shared-lib.so and using "ld -m elf_i386 -rpath . -dynamic-linker /lib/ld-linux.so.2 -o shared-lib-test shared-lib-test.o shared-lib.so" works with ./shared-lib.so . No need to use LD_LIBRARY_PATH in both cases Very Happy

Thank you a lot!!

PS: I edited my previous posts

[edit] Tested in the 32-bit version, works too [/edit]
Post 26 Sep 2006, 16:15
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8363
Location: Kraków, Poland
Tomasz Grysztar 26 Sep 2006, 18:49
Strange news: I don't know how it was actually working, but I discovered that there was a bug that caused the generated code to be not really PIC. [Maybe ld can make shared library even from non-PIC code, by choosing some random fixed base address for it? That needs investigating.]

I fixed the bug and added the PLT operator at the same time. You use it just like:
Code:
call PLT printf    

to call the external procedure via PLT. You can also do something like:
Code:
extrn 'printf' as _printf
printf = PLT _printf    

and be able the to simply call the "printf" label, while assembler will make this call work through the Procedure Linkage Table.

Well, it appears I have to rewrite the first post with more information how to get this all working. A new thread perhaps?
Post 26 Sep 2006, 18:49
View user's profile Send private message Visit poster's website Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4624
Location: Argentina
LocoDelAssembly 26 Sep 2006, 19:29
aaahh, I forgot to tell something more, using "objdump -D shared-lib-test" I saw that it resolves using the same technique that MASM uses when you call an API (calling a jmp). However the jmp is not a "jmp dword ptr" like MASM but a "jmp rel32".

Do you mean that or I'm still getting it wrong?Razz

[edit] I just found this http://www.iecc.com/linker/linker10.html . Nice explanation [/edit]
Post 26 Sep 2006, 19:29
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8363
Location: Kraków, Poland
Tomasz Grysztar 26 Sep 2006, 20:38
No, it was about relocations in shared-lib.o, not shared-lib-test (and the latter is created by ld and not fasm, anyway).
Post 26 Sep 2006, 20:38
View user's profile Send private message Visit poster's website Reply with quote
FlashBurn



Joined: 06 Jan 2005
Posts: 87
FlashBurn 27 Sep 2006, 06:21
Thanks, I now will have a deeper look into the elf specifications and will see if I will get shared library support for my os working!
Post 27 Sep 2006, 06:21
View user's profile Send private message Reply with quote
pelaillo
Missing in inaction


Joined: 19 Jun 2003
Posts: 878
Location: Colombia
pelaillo 29 Sep 2006, 22:50
Quote:

a bug that caused the generated code to be not really PIC.

Now I understand why a PIC version of my example (posted here) wasn't working. I arrived nowhere and then move the focus away. Maybe is time to fix it. Wink
Post 29 Sep 2006, 22:50
View user's profile Send private message Yahoo Messenger Reply with quote
LocoDelAssembly
Your code has a bug


Joined: 06 May 2005
Posts: 4624
Location: Argentina
LocoDelAssembly 07 Aug 2008, 00:26
Tomasz Grysztar wrote:
Well, it appears I have to rewrite the first post with more information how to get this all working. A new thread perhaps?


Could you? Because:
Code:
format ELF

section '.text' executable

public main
extrn  printf

main:
  push msg
  call PLT printf
  add  esp, 4
  ret

msg db "Hello World", 0xA,0

;----

;flat assembler  version 1.67.28  (16384 kilobytes memory)
;libcdemo.asm [10]:
;  call PLT printf
;error: invalid use of symbol.
    


PS: Note the incorrect version number 1.67.28
Post 07 Aug 2008, 00:26
View user's profile Send private message Reply with quote
Tomasz Grysztar



Joined: 16 Jun 2003
Posts: 8363
Location: Kraków, Poland
Tomasz Grysztar 11 Nov 2008, 13:50
It's going to be fixed finally in 1.67.29.
Post 11 Nov 2008, 13:50
View user's profile Send private message Visit poster's website Reply with quote
reyuki



Joined: 24 Jan 2025
Posts: 8
reyuki 26 Jan 2025, 08:38
is there a PIC example for ELF64?

I tried to create a shared library of this code:
Code:
format ELF64

SYS_write               = 1
STDOUT_FILENO           = 1

section '.text' writeable executable
public print
print:
        mov             eax, SYS_write
        mov             edi, STDOUT_FILENO
        mov             rsi, buff_ptr
        mov             edx, buff_len
        syscall

        ret

buff_ptr db "Lorem ipsum", 0xa
buff_len = $-buff_ptr
    


however, the linker complain it must be "position independent code", and it's first time I heard about it:
Code:
$ ld -shared shared-lib.o 
ld: shared-lib.o: relocation R_X86_64_32S against `.text' can not be used when making a shared object; recompile with -fPIC
ld: failed to set dynamic section sizes: bad value
    


I think the error occurs because the buff_ptr used in the print for some reason is 0x0 instead of its actual address/offset (is this how .o file behave? if I specify it as executable file in the format directive, it doesn't behave like this), and it seems make it PIC will somehow resolve the 0x0 address issue?
Post 26 Jan 2025, 08:38
View user's profile Send private message Send e-mail Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 4120
Location: vpcmpistri
bitRAKE 26 Jan 2025, 08:58
Using "lea rsi, [buff_ptr]" would make the reference RIP-relative, and hence the code would be position independent. Prior the reference was an absolute address - which would require relocation or a fixed address.
Post 26 Jan 2025, 08:58
View user's profile Send private message Visit poster's website Reply with quote
reyuki



Joined: 24 Jan 2025
Posts: 8
reyuki 26 Jan 2025, 09:19
Ah I see, thanks for the explanation!

so, when I instruct fasm to generate executable it will use absolute addressing and thus its reference address is fixed, while I instruct fasm to just generate object file it will leave the reference address to 0x0 to tell the linker that its value need to be relocated for obvious reason.

hopefully I understand it properly.

I'll link some sources that also helped me while I'm confused with this new stuff:
- stackoverflow
- other thread on this forum


Last edited by reyuki on 26 Jan 2025, 09:43; edited 2 times in total
Post 26 Jan 2025, 09:19
View user's profile Send private message Send e-mail Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 20482
Location: In your JS exploiting you and your system
revolution 26 Jan 2025, 09:22
fasm doesn't change the output. If you use lea for a code address in 64-bit mode then fasm uses RIP-relative addressing. This is always the case regardless of the output format chosen.
Post 26 Jan 2025, 09:22
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 4120
Location: vpcmpistri
bitRAKE 26 Jan 2025, 09:23
Your understanding is correct. Although, I believe fasm can also emit relocation information for ELF executables - I haven't looked into it specifically.
Post 26 Jan 2025, 09:23
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  
Goto page Previous  1, 2

< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.

Website powered by rwasa.