This question already has an answer here:
execve shellcode linux segmentation fault
(1 answer)
Closed 7 years ago.
Any idea why this is causing a segfault? mov byte [esi +9], bl
I went through it line by line using the debugger and they segfault appears after it executes that line.
Which I guess means its trying to access something in memory that its not suppose to.
Here is the whole code:
global _start
section .text
_start:
jmp short call_shellcode
shellcode:
pop esi
xor ebx, ebx
mov byte [esi +9], bl
mov dword [esi +10], esi
mov dword [esi +14], ebx
lea ebx, [esi]
lea ecx, [esi +10]
lea edx, [esi +14]
xor eax, eax
mov al, 0xb
int 0x80
call_shellcode:
call shellcode
message db "/bin/bashABBBBCCCC"
By default the text section is not writeable, and the data section is not executable.
Related
This question already has answers here:
Nasm segmentation fault on RET in _start
(1 answer)
Assembly segmentation fault after making a system call, at the end of my code
(1 answer)
Closed 4 years ago.
Program received signal SIGSEGV, Segmentation fault.
I am using this assembly program:
and for some reason I'm getting a segmentation fault, is it related to the stack? What does this program even supposed to output? somebody told me to run it and see what it does, any ideas?
I thought it would be problematic and made a post about it, but it wasn't a problem, I tried debugging it with GDB and that didn't really help. If you could tell me what it outputs it would probably even be better, that's what I'm really looking for
.code32
.intel_syntax noprefix
.global _start
_start:
mov eax, 0x04
push eax
mov eax, 0x2d
push eax
call asm2
asm2:
push ebp
mov ebp, esp
sub esp, 0x10
mov eax, DWORD PTR [ebp + 0xc] --- seg fault here
mov DWORD PTR [ebp-0x4], eax
mov eax, DWORD PTR[ebp+0x8]
mov DWORD PTR [ebp-0x8], eax
jmp part_b
part_a:
add DWORD PTR [ebp - 0x4], 0x1
add DWORD PTR [ebp + 0x8], 0x64
part_b:
cmp DWORD PTR [ebp+0x8], 0x1d89
jle part_a
mov eax, DWORD PTR [ebp-0x4]
mov esp, ebp
pop ebp
ret
I'm writing a program to print binary string of a hardcoded word. Here is how it looks like currently:
main.asm
section .text
global _start
extern _print_binary_content
_start:
push word [word_to_print] ; pushing word. Can we push just one byte?
call _print_binary_content
mov rax, 60
mov rdi, 0
syscall
section .data
word_to_print: dw 0xAB0F
printer.asm
SYS_BRK_NUM equ 0x0C
BITS_IN_WORD equ 0x10
SYS_WRITE_NUM equ 0x01
STD_OUT_FD equ 0x01
FIRST_BIT_BIT_MASK equ 0x01
ASCII_NUMBER_OFFSET equ 0x30
section .text
global _print_binary_content
_print_binary_content:
pop rbp
xor ecx, ecx ;zeroing rcx
xor ebx, ebx ;zeroing rbx
pop bx ;the word to print the binary content of
;sys_brk for current location
mov rax, SYS_BRK_NUM
mov rdi, 0
syscall
;end sys_brk
mov r12, rax ;save the current brake location
;sys_brk for memory allocation 16 bytes
lea rdi, [rax + BITS_IN_WORD]
mov rax, SYS_BRK_NUM
syscall
;end sys_brk
xor ecx, ecx
mov cl, byte BITS_IN_WORD - 1; used as a counter in the loop below
loop:
mov dx, bx
and dx, FIRST_BIT_BIT_MASK
add dx, ASCII_NUMBER_OFFSET
mov [r12 + rcx], dl
shr bx, 0x01
dec cl
cmp cl, 0
jge loop
mov rsi, r12
mov rax, SYS_WRITE_NUM
mov rdi, STD_OUT_FD
mov rdx, BITS_IN_WORD
syscall
push rbp ; pushing return address back
ret
If I compile link and run this program it works. But the question is about performance and maybe conventions of writing assembly programs. In the file printer.asm I cleaned ecx twice which looks kind of not optimal. Maybe some registers were used not by their purpose (I used intel-manual).
Can you please help me to improve this very simple program?
I'm writing an assembly program that would print even numbers between 0-9 using a loop. I encountered this problem, segmentation fault while running the code. I check other answers on the site but couldn't find an answer that satisfies my issue.
I suspect that the function nwLine might be the source of the problem.
;;this program prints even numbers from 0-8 using loop function
section .text
global _start
cr db 10
_start: ;tell linker entry point
mov ecx, 5
mov eax, '0'
evenLoop:
mov [evnum], eax ;add eax to evnum
mov eax, 4
mov ebx, 1
push ecx
mov ecx, evnum
mov edx, 1
int 80h
call nwLine
mov eax, [evnum]
sub eax, '1'
inc eax
add eax, '2'
pop ecx
loop evenLoop
nwLine: ;function to move pointer to next line
mov eax,4 ; System call number(sys_write)
mov ebx,1 ; File descriptor 1 - standard output
mov ecx, cr
mov edx, 1
int 80h ; Call the kernel
ret
mov eax,1 ;system call number (sys_exit)
int 80h ;call kernel
section .bss
evnum resb 1
if anyone knows how to solve the problem with the nwLine function, please tell me.
section .text
global _start ;must be declared for linker (ld)
_start:
mov eax,5
mov ebx,plname
mov ecx,0x202
mov edx,0700o
int 0x80
mov eax,4
mov ecx,plaintext
mov edx,256
int 0x80
xor eax,eax
inc eax
xor ebx,ebx
int 0x80
section .data
key db '123456passwordqwerty',0x0
keylen equ $ - key ;length of our dear string
plname db 'plname.bin',0x0
plaintext times 256 db 1
first part planned to create a file specified in plname, first time I'd tryed create it into /tmp/plname.bin and after fail, try to create at least into excuting directory.I've also tried create syscall and got the same results.
programm fails on open syscall, after excuting int 0x80 instruction, eax contains -2, programm ends normally, but doesn't create file.
here i got flags and mods
https://sourceware.org/gdb/onlinedocs/gdb/mode_005ft-Values.html#mode_005ft-Values
here is gdb output
Dump of assembler code for function _start:
0x08048080 <+0>: mov $0x8,%eax
0x08048085 <+5>: mov $0x80490c9,%ebx
0x0804808a <+10>: mov $0x700,%ecx
0x0804808f <+15>: int $0x80
0x08048091 <+17>: mov $0x4,%eax
0x08048096 <+22>: mov $0x80490e3,%ecx
0x0804809b <+27>: mov $0x100,%edx
0x080480a0 <+32>: int $0x80
0x080480a2 <+34>: xor %eax,%eax
0x080480a4 <+36>: inc %eax
0x080480a5 <+37>: xor %ebx,%ebx
0x080480a7 <+39>: int $0x80
End of assembler dump.
Breakpoint 1, 0x0804808f in _start ()
(gdb) i r eax
eax 0x5 5
(gdb) stepi
0x08048094 in _start ()
(gdb) i r eax
eax 0x5 5
(gdb) i r eax ebx ecx edx esi edi
eax 0x5 5
ebx 0x80490d1 134516945
ecx 0x202 514
edx 0x1c0 448
esi 0x0 0
edi 0x0 0
(gdb) stepi
0x08048096 in _start ()
(gdb) i r eax ebx ecx edx esi edi
eax 0xfffffffe -2
ebx 0x80490d1 134516945
ecx 0x202 514
edx 0x1c0 448
esi 0x0 0
edi 0x0 0
You used the wrong reference manual. What you linked to is the flags used in the gdb protocol, not the ones used by system calls.
O_CREAT is actually 0100 octal, so you should do mov ecx,0102o.
Also note you have forgotten to move the returned file descriptor from eax to ebx for the sys_write.
Working code:
section .text
global _start ;must be declared for linker (ld)
_start:
mov eax,5
mov ebx,plname
mov ecx,0102o
mov edx,0700o
int 0x80
mov ebx, eax
mov eax,4
mov ecx,plaintext
mov edx,256
int 0x80
xor eax,eax
inc eax
xor ebx,ebx
int 0x80
section .data
key db '123456passwordqwerty',0x0
keylen equ $ - key ;length of our dear string
plname db 'plname.bin',0x0
plaintext times 256 db 1
I'm writing a simple subroutine in FASM to print 32-bit unsigned integers to STDOUT. This is what I came up with:
format elf
public uprint
section ".text" executable
uprint:
push ebx
push ecx
push edx
push esi
mov ebx, 10
mov ecx, buf + 11
xor esi, esi
do:
dec ecx
xor edx, edx
div ebx
add dl, 0x30
mov [ecx], dl
inc esi
test eax, 0
jnz do
mov eax, 4
mov ebx, 1
mov edx, esi
int 0x80
pop esi
pop edx
pop ecx
pop ebx
ret
section ".data" writeable
buf rb 11
Then I wrote another program to test whether the above subroutine works properly:
format elf
extrn uprint
public _start
section ".text" executable
_start:
mov eax, 1337
call uprint
mov eax, 4
mov ebx, 1
mov ecx, newline
mov edx, 1
int 0x80
mov eax, 1
xor ebx, ebx
int 0x80
section ".data"
newline db 0x0A
I compiled both these programs to their corresponding object files and linked them to create the executable.
On executing the program however it only displayed 7 instead of 1337. As it turns out only the last digit of the number is display regardless of the number itself.
This is strange because my uprint subroutine is correct. In fact if I combine both these programs into a single program then it displays 1337 correctly.
What am I doing wrong?
I gain the distinct impression that your LINK operation is building the uprint before the _start and you're in fact entering UPRINT, not at _start as you expect.
I found out my mistake. I'm using test eax, 0 which always sets the zero flag. Hence only the first digit is processed. Intead I need to use either test eax, eax or cmp eax, 0.