For my hw assignment I am trying to exploit into an overflow c file. I cannot edit the original file, and I also cannot recompile it.
I have gotten as far as to return to my intended address. However after it executed the code for a while I get this:
0xffffcc38 pop %eax
0xffffcc39 push %eax
0xffffcc3a pop %ecx
→ 0xffffcc3b xor 0x30(%ebp), %eax
0xffffcc3e xor %eax, 0x30(%ebp)
0xffffcc41 xor %esi, 0x30(%ebp)
0xffffcc44 xor 0x30(%ebp), %esi
0xffffcc47 pop %ax
0xffffcc49 push $0x68736538
0xffffcc3b in ?? ()
gef➤
Program terminated with signal SIGSEGV, Segmentation fault.
The program no longer exists.
It was executing fine from 0xfffcc30->0xffffcc3a but suddenly stopped at 0xffffcc3b. Can I know why this could have happened?
Can I know why this could have happened?
If this instruction produced a SIGSEGV:
0xffffcc3b xor 0x30(%ebp), %eax
then it's a safe bet that $EBP + 0x30 points to inaccessible memory.
Most likely you "stepped" on $EBP earlier in your exploit.
Related
I have a __kernel_vsyscall error in a function that gives the correct output but the program can never get past it and gives a __kernel_vsyscall error.
C functions:
void f1(int* input, int* output, int nbElements);
Assembler function (GAS). I can't post the whole thing since it's for an assignment and I don't want someone to copy it.
f1:
push %ebp
mov %esp, %ebp
movl $0, %ecx
movl $0, %ebx
jmp for_loop1
for_loop1:
cmpl %ecx, 16(%ebp)
jb end
movl $0, %ebx
jmp for_loop2
for_loop2:
/*move input elements to output elements*/
cmpl %ecx, %ebx
jmp incr_2
incr_2:
addl $1, %ebx
cmpl %ebx, 16(%ebp)
jb incr_1
jmp for_loop2
incr_1:
addl $1, %ecx
jmp for_loop1
end:
addl $8, %esp
leave
ret
Error when the program terminated :
malloc(): invalid size (unsorted)
Aborted (core dumped)
Error when debugging with gdb with the coredump file :
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./program_name...
[New LWP 2634]
warning: Loadable section ".note.gnu.property" outside of ELF segments
Core was generated by `./program_name'.
Program terminated with signal SIGABRT, Aborted.
#0 0xf7f35ac9 in __kernel_vsyscall ()
I've tried looking at what is at address 0xf7f35ac9 and it returned -402652697, or another random value.
Local variables are at adresses around 0xff83b1fc, the values stored in the pointers are at adresses around 0x80cab30, the functions declared previously are at adresses around 0x8049fc4, and the stack has values around 0xffaddedc, so I have no idea where this is.
Thanks
I was able to fix the problem by changing
cmpl %ecx, 16(%ebp)
jb end
to
cmpl 16(%ebp), %ecx
jge end
same as with all the other comparisons. Looked around online and apparently the difference between jb/ja and jl/jg is that jb/ja is for unsigned comparison while jl/jg is for signed comparison, but I'm still not sure why this causes this error.
I'm really new on LLDB. I'm trying to figure out why my C application sometimes breaks on a segmentation fault.
I've compiled my application with -g and started lldb pointing to the binary. So I ran the app with "run" code and when it crashes, LLDB shows me the message:
* thread #1: tid = 0x8817, 0x00007fffae0feb52 libsystem_c.dylib`strlen + 18, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
frame #0: 0x00007fffae0feb52 libsystem_c.dylib`strlen + 18
libsystem_c.dylib`strlen:
-> 0x7fffae0feb52 <+18>: pcmpeqb (%rdi), %xmm0
0x7fffae0feb56 <+22>: pmovmskb %xmm0, %esi
0x7fffae0feb5a <+26>: andq $0xf, %rcx
0x7fffae0feb5e <+30>: orq $-0x1, %rax
I saw a "tutorial" where the person did the same thing as me, but for him LLDB showed his C source code and pointed the line where it crashed. For me I can only see this hex with assembly that I cannot trace.
What am I doing wrong?
Thank you guys.
EDIT:
Forgot to say that my app is only printing c* chars on terminal each second. Sometimes it take a few minutes to crash, sometimes it crashes after hours.
I'm doing a class in assembly that is called from a class in C. The C class sends 2 integers as parameters but that's not relevant cause I'm getting a segmentation fault error that I don't seem to quite understand why.
Here's the relevant part of the assembly class:
.global testingclass
testingclass:
pushl %ebp
movl %esp, %ebp
subl $4, %esp #reserves space for local variable
movl 8(%ebp), %ebx #first argument of the function to %ebx
movl 12(%ebp), %ecx #second argument of the function to %ecx
function:
movl $0, %eax ----------------< segmentation fault
movl 0x0000FFFF, %eax
and %bx, %ax
movw %ax, -4(%ebp)
...
I signed the line that gives me the segmentation fault error when debugging. I really don't know how can a simple move command trigger a segmentation fault, but hope you can help me.
This is the debugger console output:
...
11 movl 12(%ebp), %ecx #second argument of the function to %ecx
(gdb) n
function() at asm.s:16
16 movl 0x0000FFFF, %eax
(gdb) n
Program received signal SIGSEGV, Segmentation fault.
function() at asm.s:16
16 movl 0x0000FFFF, %eax
the seg fault occurred at this instruction:
movl 0x0000FFFF, %eax
Not at this instruction:
movl $0, %eax
The reason for the seg fault is reading from address (64k-1)
The program can only read/write addresses that are available to the user space.
Since the OS is first, after the interrupt vectors, the code tried to read an address within the OS code. The OS code is not part of the user space.
While I'm debugging a segmentation fault in x86-Linux, I've ran into this problem:
Here goes the seg-fault message from the GDB
0xe2a5a99f in my_function (pSt=pSt#entry=0xe1d09000, version=43)
Here goes the faulting assembly:
0xe2a5a994 <my_function> push %ebp
0xe2a5a995 <my_function+1> push %edi
0xe2a5a996 <my_function+2> push %esi
0xe2a5a997 <my_function+3> push %ebx
0xe2a5a998 <my_function+4> lea -0x100b0c(%esp),%esp
0xe2a5a99f <my_function+11> call 0xe29966cb <__x86.get_pc_thunk.bx>
0xe2a5a9a4 <my_function+16> add $0x9542c,%ebx
As you can see above, the faulting line is "call get_pc_thunk" which is just getting the pc value.
And, I checked the memory at 0xe29966cb is valid and accessible with the following command:
(gdb) x/10i 0xe29966cb
0xe29966cb <__x86.get_pc_thunk.bx>: nop
0xe29966cc <__x86.get_pc_thunk.bx+1>: nop
0xe29966cd <__x86.get_pc_thunk.bx+2>: nop
0xe29966ce <__x86.get_pc_thunk.bx+3>: nop
0xe29966cf <__x86.get_pc_thunk.bx+4>: nop
0xe29966d0 <__x86.get_pc_thunk.bx+5>: nop
0xe29966d1 <__x86.get_pc_thunk.bx+6>: nop
0xe29966d2 <__x86.get_pc_thunk.bx+7>: nop
0xe29966d3 <__x86.get_pc_thunk.bx+8>: mov (%esp),%ebx
0xe29966d6 <__x86.get_pc_thunk.bx+11>: ret
Which looks perfectly fine.
But Strangely, if I use "si" to step into the "get_pc_thunk" function, it seg-faults without even entering the first nop.
Any help would be appreciated.
A crash on CALL (or PUSH, of MOV (%esp)) instruction almost always is due to stack overflow.
Check your program for infinite (or just very deep) recursion.
Also, this:
0xe2a5a998 <my_function+4> lea -0x100b0c(%esp),%esp
means that my_function is allocating slightly over 1MB of local variables for the current stack frame. And now you know why that may not be a good idea.
I have to work with x86 for a homework assignment. I keep getting this segfault for an atoi call, but I'm not sure why it's occurring. This is the code:
addl $4, %eax
movl (%eax), %eax
movl %eax, (%esp)
call atoi
Where $eax right before the "call atoi" equals "11". To prove it, this is what I get in gdb right before the call.
x/s $eax
0xffffd658: "11"
I guess my big question is what should be held in register $eax before the "call atoi" and what would $eax have to hold for the program to then segfault in the "call atoi"?
EDIT: Someone asked for the registers.
(gdb) x/s $eax
0xffffd658: "11"
(gdb) n
Program received signal SIGSEGV, Segmentation fault.
0x2aaaaaa3 in ?? ()
(gdb) inf r
eax 0x0 0
ecx 0x2aaaaaab 715827883
edx 0x0 0
ebx 0x2c3ff4 2899956
esp 0xffffd458 0xffffd458
ebp 0x80484ef 0x80484ef
esi 0x0 0
edi 0x0 0
eip 0x2aaaaaa3 0x2aaaaaa3
eflags 0x10287 [ CF PF SF IF RF ]
cs 0x23 35
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x63 99
(gdb)
It depends on whether your atoi function expects the pointer in %eax or on the stack. You seem to be undecided about that, given the code segment:
movl %eax, (%esp)
call atoi
If that's supposed to be pushing the address on to the stack, you either need to really push it (which modifies the stack pointer correctly) or modify the stack pointer yourself (such as with sub %esp, 4 or something).
The x86 stack pointer points to the last pushed entry so that push will first decrement the stack pointer then store the value at the new pointer. That means movl %eax (%esp) is going to corrupt the last pushed entry on the stack rather than place a new value on the stack.
Most people let the CPU handle the stacking of data rather than trying to do it manually, so you're probably looking for:
push %eax
However, if instead atoi expects its argument in %eax rather than on the stack, why would you write it to the stack? That's still going to corrupt whatever was there.
So, the first thing I would do would be choose either (for a pushed value):
addl $4, %eax
movl (%eax), %eax
push %eax
call atoi
or (for using %eax), just:
addl $4, %eax
movl (%eax), %eax
call atoi