flat assembler
Message board for the users of flat assembler.

Index > Linux > ELF Segmentation - Fasm produce wrong settings

Author
Thread Post new topic Reply to topic
bugmaker



Joined: 27 Jan 2022
Posts: 3
bugmaker
Hi. While using Evan's debugger, I see when having a extra segment the whole file is included in the the extra segment's memory, this should not be.
The reason must be that the program-header is not set up properly by fasm.

So I made the ELF part from scratch.
This is how the extra segment could be set up

Code:
dd 1                 ;p_type - load
dd 6                 ;p_flags - read + write
dq 0                 ;p_offset
dq 0x401000   ;p_vaddr - virtual address
dq 0                 ;p_paddr
dq 0                 ;p_filesize
dq memsize     ;p_memsize
dq 0x1000       ;p_align
    


Last edited by bugmaker on 28 Jan 2022, 10:30; edited 1 time in total
Post 27 Jan 2022, 23:18
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 18441
Location: In your JS exploiting you and your system
revolution
Please show your source code that produces the wrong output.
Post 28 Jan 2022, 01:28
View user's profile Send private message Visit poster's website Reply with quote
bugmaker



Joined: 27 Jan 2022
Posts: 3
bugmaker
The second segment will be in memory region 401000-402000. But do contain the file.
So the mov content of al will go to address 0x4010c4 in this example.
While I made the ELF from scratch with the content of second programheader as described in the post, nothing would be loaded in that memory region, data: would be at address 0x401000
Code:
use64
format ELF64 executable 3
entry main

segment readable executable
main:
        mov al,0xff
        mov [dataseg],al

        xor     rdi,rdi
        mov     rax,60
        syscall

segment readable writeable
dataseg:
        rb 1
    


Last edited by bugmaker on 28 Jan 2022, 12:38; edited 2 times in total
Post 28 Jan 2022, 10:15
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 18441
Location: In your JS exploiting you and your system
revolution
If you use rb 1 then there is no data to put into the output file. It is an empty segment of only uninitialised data.

If you change the last line to db 0xff then data is put into the output file.
Post 28 Jan 2022, 11:08
View user's profile Send private message Visit poster's website Reply with quote
bugmaker



Joined: 27 Jan 2022
Posts: 3
bugmaker
I do not really know what i'm talking about btw.
But there is some odd ways data is loaded into memory.

In the code below, everything is loaded as part of read + execute segment 0x400000 - 0x402000, what's in the second segment is included as well, as part of it.
Then there's the second segment, where only part of the 0xff are shown, then all the 0x88.

So what i'm getting at is what is the point of loading the same data twice, what is going on?

Code:
use64
format ELF64 executable 3
entry main

segment readable executable
main:
        mov al,0xff
        mov [dataseg],al

        xor     rdi,rdi
        mov     rax,60
        syscall

        db 0x1000 dup 0xff


segment readable writeable
dataseg:
db 0x1000 dup 0x88
    
Post 28 Jan 2022, 12:36
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 18441
Location: In your JS exploiting you and your system
revolution
The loader used by your OS might make shortcuts when laying out the code into memory. It isn't required to zero out undefined memory locations so the data could be anything.

The only guarantee you have is that the addresses that have defined location in the file will be correctly initialised into the memory. Other memory locations are undefined and may contain any values. This does not break the loader contract.
Post 28 Jan 2022, 12:55
View user's profile Send private message Visit poster's website Reply with quote
FlierMate



Joined: 21 Jan 2021
Posts: 208
FlierMate
bugmaker wrote:

So the mov content of al will go to address 0x4010c4 in this example.
While I made the ELF from scratch..... data: would be at address 0x401000


I run your example and a "readelf -a" produces:

Code:
Program Headers:
  Type           Offset             VirtAddr           PhysAddr
                 FileSiz            MemSiz              Flags  Align
  LOAD           0x0000000000000000 0x0000000000400000 0x0000000000400000
                 0x00000000000000c4 0x00000000000000c4  R E    0x1000
  LOAD           0x00000000000000c4 0x00000000004010c4 0x00000000004010c4
                 0x0000000000000000 0x0000000000000001  RW     0x1000
    


Can notice the VirtAddr and PhysAddr of second segment starts at 0x4010c4 (c4 = 196 bytes, the size of entire program), whereas your custom program header fixed the VirtAddr at 0x401000.

Is this your finding?
Post 28 Jan 2022, 15:24
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:  


< 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-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.