I am having a core dump which stack is corrupted.
I try to disassemble it and found the following plz help me to anaylyse it ..
(gdb) bt
#0 0x55a63c98 in ?? ()
#1 0x00000000 in ?? ()
(gdb) disassemble 0x55a63c90 0x55a63ca8
Dump of assembler code from 0x55a63c90 to 0x55a63ca8:
0x55a63c90: add %cl,%dh
0x55a63c92: cmpsb %es:(%edi),%ds:(%esi)
0x55a63c93: push %ebp
0x55a63c94: add %al,(%eax)
0x55a63c96: add %al,(%eax)
**0x55a63c98: pusha**
0x55a63c99: lret $0x9
0x55a63c9c: subb $0x56,0xd005598(%ebp)
0x55a63ca3: push %ebp
0x55a63ca4: jo 0x55a63cc5
0x55a63ca6: sahf
0x55a63ca7: push %ebp
End of assembler dump.
(gdb) q
Can this pusha instruction can lead to a core dump ?
No*, all pusha does is push all the general purpose registers to the stack, including the stack pointer! What is causing the core dump is the instruction after the pusha, lret, which is a long return with stack pop. The return address is the most recent value pushed to the stack, which in this case will be whatever was in esi:edi (since they are the last values to be pushed by the pusha instruction), and that's likely to point to somewhere random.
* Unless you run out of stack space.
Absolutely. PUSHA followed by RET is never correct, the return address will be junk. Seeing ADD AL,[EAX] in your disassembly is another dead give away, that's the disassembly for 0.
In other words: you are disassembling data, not code. Your program bombed because it was executing data. The classic way that happens is corrupting a stack frame with a buffer overflow. When the function returns it pops an invalid return address from the corrupted stack and jumps into never never land. Not getting a seg fault is very unlucky.
Hard to debug, the stack trace is junked. You'll need to set a breakpoint at the last known good code address and start single stepping. The last good function you stepped into just before it bombs is typically the trouble maker.
pusha can only lead to a core dump if stack overflow occurs at that point. This instruction pushes all the registers values onto the stack and that could lead to an overflow. However the root of the problem is likely elsewhere - most likely the call stack is too deep at that point and pusha just happens to cause such consequences because it is executed in such conditions.
check if you see aligned disassemble code:
x/i $eip
Also show registers values:
i r
Related
I am trying to learn how to use a debugger and I am having some difficulty getting lldb to work properly. In particular, I was trying to follow along with the code the lldb wikipedia page for starters, and after attempting to run the debugger with lldb run I obtained the following error:
(lldb) target create "./example"
Current executable set to '/Users/me/Desktop/c/old/example' (x86_64).
(lldb) run
Process 69451 launched: '/Users/me/Desktop/c/old/example' (x86_64)
Process 69451 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0xffffff90)
frame #0: 0x00007ff80f9066b2 libsystem_platform.dylib`_platform_strlen + 18
libsystem_platform.dylib`_platform_strlen:
-> 0x7ff80f9066b2 <+18>: pcmpeqb (%rdi), %xmm0
0x7ff80f9066b6 <+22>: pmovmskb %xmm0, %esi
0x7ff80f9066ba <+26>: andq $0xf, %rcx
0x7ff80f9066be <+30>: orq $-0x1, %rax
Target 0: (example) stopped.
(lldb)
I searched around online and I could not seem to find what this was all about. I would try to use gdb instead, but it looks like a bit of a mess to set up on mac with permissions and all. Any thoughts on what this issue is?
That's not a debugger error, lldb is reporting that your program crashed in the _platform_strlen function because of a bad memory access (that's what EXC_BAD_ACCESS means). From the crash message, the address you were trying to access was 0xffffff90.
The frame you stopped in is from a system library, so all the debugger can show you is the disassembly of the function. It is interesting (for people who can read disassembly). (%rdi) means "fetch the memory at the address held in the register rdi. That's an argument passing register, so presumably one of the arguments to strlen was bogus. That makes sense with the crash reason.
The next thing to do is to issue the bt command to see the full stack trace for the crash. Then use the frame select - short alias f - command to choose the last stack frame with your code. Presumably the PC in that frame will be a call to strlen, and your code is passing a bad pointer to strlen. You can use the v <varname> command to see the variable you passed in to verify that.
I'm a student learning computer security. Recently, I learned stack buffer overflow on c.
I understood its concepts and run sample codes written by c.
void main(){
char buf[] = "\xeb\x0b\x31\xc0\xb0\x0b\x31\xd2\x31\xc9\x5b\xcd\x80\xe8\xf0\xff\xff\xff/bin/sh\x0";
int* p;
p = (int*)&p + 2;
*p = (int)buf;
return;
}
Runtime Environment
Architecture: i686
OS: ubuntu 16.04 32bit
Compiler: gcc
Turn off ASLR(sysctl -w kernel.randomize_va_space=0)
Options: gcc -z execstack -mpreferred-stack-boundary=2 -fno-stack-protector
But I confuse what stack is saved and which memories are overlapped.
Above binary code, "\xeb\x0b\x31\xc0\xb0\x0b\x31\xd2\x31\xc9\x5b\xcd\x80\xe8\xf0\xff\xff\xff/bin/sh\x0",
the same assembly code is
.global main
main:
jmp strings
start:
xor %eax, %eax
movb $0xb, %al
xor %edx, %edx
xor %ecx, %ecx
popl %ebx
int $0x80
strings:
call start
.string "/bin/sh"
means execve("/bin/sh", NULL, NULL);.
When buffer overflow occurs, the binaries are overlapped return addresses of main on stack. But, I'm understood to be that the stack stores data s.t local variables, previous frame pointers, and return address.
I think the above binaries are not data, actually instructions. If so, why is this valid? The stack stores instructions and executes one-by-one by popping them? Or I misunderstand something?
And if the stack stores instructions, how do previous stack frame pointers(fp) and return addresses(ra) work?
I learned that previous function's stack frame address is stored in fp and next instruction's address on code area is stored in ra. So, when called function is terminated, sp is popped and then ra does to restore previous function state and run next instruction. Is it correct? Or I misunderstand something?
I want to know really this..
Thank you for your help.
Data are instructions are instructions are instructions.
The stack is memory is memory is memory.
That's just that.
Since the stack is ordinary memory, just like what you get with malloc, only growing downward and used implicitly by some instructions, you can put any data on the stack.
Since instructions are data, it follows that you can put instructions on the stack.
This particular exploitation works by overwriting the return address with a specific value and everything above it with a sequence of instructions.
That's why you need to tell GCC to make the stack executable (the code is on the stack) and not to generate a canary (both of these protections will suffice to prevent the attack) and also you need to tell Linux not to randomize the process address space layout (or the specific, fixed, value used to overwrite the return address won't work).
The fp and ra thing is most likely for a RISC architecture, x86 doesn't have such registers.
The execution flow is redirected when main returns (with ret), that's what ret does.
Look in Intel's manuals how the call/ret pair works and then see it in practice by just stepping into a call with a debugger.
Make sure you understand the calling convention and keep an eye on the stack every time you step.
I am trying to familiarize myself with gdb and had a few questions based upon its format and what it shows:
─── Assembly ────
0x00000000004004ed main+0 push %rbp
0x00000000004004ee main+1 mov %rsp,%rbp
!0x00000000004004f1 main+4 movl $0x539,-0x4(%rbp)
What does the memory address on the left column signify, and why is each instruction a variable-width "between" the next address?
What does the second column mean?
.
─── Registers ───────────────────────
rax 0x00000000004004ed
rbx 0x0000000000000000
rcx 0x0000000000000000
Is the value next to the register its memory location, or the value contained in the registry?
.
─── Stack ───────────────────
[0] from 0x000000000040058c in main+47 at main.c:7
What is this line telling us: does the stack start at memory address 0x000000000040058c, and what does the main+47 refer to?
What does the memory address on the left column signify, and why is
each instruction a variable-width "between" the next address?
x86 machine-code instructions are variable length. So some instructions take a single byte while for example movabs $0x12345678abcdef, %rax takes 10. The hard limit is 15 bytes, but only intentional padding with redundant prefixes can get all the way to 15.
Many other architectures are RISC and have fixed-width instructions.
What does the second column mean?
It tells you the relative address from the symbol main. Note that the actual location in memory is not assigned at compile time.
(Editor's note: this is not a PIE executable so the absolute address actually is set at link time. We can tell because the address is 0x00400... in the low 32 bits of address space, not 0x55555555....)
Is the value next to the register its memory location, or the value
contained in the registry?
Registers are not stored in memory (except in rare architectures); registers don't have addresses and are a separate space from memory. It's also not showing the value pointed to by a register that happens to be holding a valid address.
The value shown is the value in the resister itself. Note that rbx and rcx are both showing 0x0.
What is this line telling us: does the stack start at memory address
0x000000000040058c, and what does the main+47 refer to?
(editor's note: this part is wrong but I'm not sure enough exactly what it is to replace it with something else. But 0x40058c is definitely not a plausible value for RSP. main+47 is a code address somewhere inside main, like always for GDB symbol+number).
This is the location of the stack. Your code is small, so main is only taking space less than 48 addresses. Note that memory is normally allocated in blocks, so the stack would not appear at main+7, or whatever immediately follows the movl instruction.
#daShier's answer is mostly right, but is completely wrong about this part:
What is this line telling us: does the stack start at memory address
0x000000000040058c, and what does the main+47 refer to?
I think this is a qword value on the stack (pointed to by RSP). It's probably main's return address, or maybe just a value that was in RBP when main pushed it.
(But a return address is plausible: main starting at 0x4004ed is not far from 0x40058c).
main + 47 = 0x40051c is a code address inside main, corresponding to C source on line 7 of main.c. (main.c:7). This symbol+number is GDB's way of printing addresses in a human-readable way, relative to the closest symbol above them. i.e. what function they're in. ; I think that's the breakpoint you're stopped at when you copy/pasted this. It's telling you where execution is now. Or was when this snapshot of data on the stack was taken.
I'm not sure how you got GDB to print that Stack dump. It's a slightly different format from info stack or backtrace. TUI mode layout reg or any other layout doesn't include a Stack pane.
But anyway, 0x000000000040058c is most certainly not a stack address; it's in the same 4kiB virtual memory page as main so it's in the .text section. (In fact it's only 0x70 bytes past main + 47). That virtual page will be executable and not writeable.
RSP (stack pointer) values are things like 0x7ffff7fd4100, near the top of the lower 48 bits of virtual address space. (The top of the user-space part of the usable (canonical) part of virtual address space on x86-64).
As I said, main+47 is just a code address inside main. It has nothing to do with 47 or 48 bytes of stack space.
I have an issue where my Cortex-M0 is hard faulting, so I am trying to debug it. I am trying to print the contents of the ARM core registers that were pushed to the stack when the hard fault occurred.
Here is my basic assembly code:
__attribute__((naked)) void HardFaultVector(void) {
asm volatile(
// check LR to see whether the process stack or the main stack was being used at time of exception.
"mov r2, lr\n"
"mov r3, #0x4\n"
"tst r2, r3\n"
"beq _MSP\n"
//process stack was being used.
"_PSP:\n"
"mrs r0, psp\n"
"b _END\n"
//main stack was being used.
"_MSP:\n"
"mrs r0, msp\n"
"b _END\n"
"_END:\n"
"b fault_handler\n"
);
}
The function fault_handler will print the contents of the stack frame that was pushed to either the process stack or the main stack. Here's my question though:
When I print the contents of the stack frame that supposedly has the saved registers, here is what I see:
Stack frame at 0x20000120:
pc = 0xfffffffd; saved pc 0x55555554
called by frame at 0x20000120, caller of frame at 0x20000100
Arglist at unknown address.
Locals at unknown address, Previous frame's sp is 0x20000120
Saved registers:
r0 at 0x20000100, r1 at 0x20000104, r2 at 0x20000108, r3 at 0x2000010c, r12 at 0x20000110, lr at 0x20000114, pc at 0x20000118, xPSR at 0x2000011c
You can see the saved registers, these are the registers that are pushed by the ARM core when a hard fault occurs. You can also see the line pc = 0xfffffffd; which indicates that this is the LR's EXC_RETURN value. The value 0xfffffffd indicates to me that the process stack was being used at the time of the hard fault.
If I print the $psp value, I get the following:
gdb $ p/x $psp
$91 = 0x20000328
If I print the $msp value, I get the following:
gdb $ p/x $msp
$92 = 0x20000100
You can clearly see that the $msp is pointing to the top of the stack where supposedly the saved registers are located. Doesn't this mean that the main stack has the saved registers that the ARM core pushed to the stack?
If I print the memory contents, starting at the $msp address, I get the following:
gdb $ x/8xw 0x20000100
0x20000100 <__process_stack_base__>: 0x55555555 0x55555555 0x55555555 0x55555555
0x20000110 <__process_stack_base__+16>: 0x55555555 0x55555555 0x55555555 0x55555555
It's empty...
Now, if I print the memory contents, starting at the $psp address, I get the following:
gdb $ x/8xw 0x20000328
0x20000328 <__process_stack_base__+552>: 0x20000860 0x00000054 0x00000054 0x20000408
0x20000338 <__process_stack_base__+568>: 0x20000828 0x08001615 0x1ad10800 0x20000000
This looks more accurate. But I thought the saved registers are supposed to indicate where in flash memory they are located? So how does this make sense?
The comments by old_timer under your question are all correct. The registers will be pushed to the active stack on exception entry, whether this is PSP or MSP at the time. By default, all code uses the main stack (MSP), but if you're using anything other than complete bare metal it's likely that whatever kernel you're using has switched Thread mode to using the process stack (PSP).
Most of your investigations suggest that the PSP was in use, with your memory peek around the PSP and MSP being pretty much indisputable. The only bit of evidence you have for it having been the MSP is the results of the fault_handler function, for which you have not posted the source; so my first guess would be that this function is broken in some way.
Do also remember that one common reason for entering the HardFault handler is that another exception handler has caused an exception. This can easily happen in cases of memory corruption. In these cases (assuming Thread mode uses the PSP) the CPU will first enter Handler mode in response to the original exception, pushing r0-r3,r12,lr,pc,psr to the process stack. It will start executing the original exception handler, then fault again, pushing r0-r3,r12,lr,pc,psr to the main stack while entering the HardFault handler. There's often some unravelling to do.
old_timer also mentions using real assembly language, and I agree here too. Even though the ((naked)) attribute should be removing the prologue and epilogue (between them most of the possible 'compilerisms'), your code would simply be far more readable if it was written in bare assembly language. Inline assembly language has its uses, for example if you want to do something very low-level that you can't do from C but you want to avoid a call-return overhead. But when your entire function is written in assembly language, there's no reason to use it.
Suppose you are running a program with interrupts handling enabled on a processor. Instruction Pointer points to zero. How can we get to know the cause that caused the Instruction Pointer to point to 0.
I'm not clear whether is it something related to the location of ISRs? As far as I know in some of the processors, IP=0 means the reset address. But why would a running program goto the address?
What all could be the reasons causing IP to be pointing to 0?
Basically all jmp instructions and ret can jump to 0. Examples:
jnz 0 ;; encoded as relative jump JNZ -(next IP)
jmp 00000000 ;; absolute jump
mov ebx, 0
jmp ebx ;; indirect jump
call 0
mov ecx,0
push ecx
ret ;; jump through stack
In C one can (try to) jump through NULL/uninitialized function pointer, as well as through corrupting stack. Some esoteric tricks would be to insert an exception handler (signal) to point to null, or use longjmp.
In x86 architecture (real mode) pointers to the interrupt handlers start at address 0:0, but one doesn't jump there. Instead the table contains 'segment:offset' pairs to be jumped to indirectly.
Debugging methods include bisecting the code with breakpoints, until the next instruction you run, causes your error. Inspecting stack should tell what was the last function that was executed. Sometimes the stack is still valid to show the complete callback trace.