I've been studying assembly lately and i can't seem to understand how the exceptions work exactly. More specific, i get the message Exception 6 occurred and ignored. Can someone please explain what exactly does this mean? I am using qtspim.
Exceptions may be caused by hardware or software. An exception is like an unscheduled function call that jumps to a new address.
The program may encounter an error condition such as
an undefined instruction. The program then jumps to code in the operating system (OS), which may choose to terminate the program. Other causes of exceptions are division by zero, attempts to read some nonexistent memory, hardware malfunctions, debugger breakpoints, and arithmetic overflow.
The processor records the cause of an exception and the value of the PC
at the time the exception occurs. It then jumps to the exception handler function. The exception handler is code (usually in the OS) that examines the
cause of the exception and responds appropriately, It then returns to the program that
was executing before the exception took place.
In MIPS, the exception handler is always located at 0x80000180. When an exception occurs, the processor always jumps to this instruction address, regardless of the cause.
The MIPS architecture uses a special-purpose register, called the Cause
register, to record the cause of the exception.
MIPS uses another special-purpose register called the Exception
Program Counter (EPC) to store the value of the PC at the time an
exception takes place. The processor returns to the address in EPC after
handling the exception. This is analogous to using $ra to store the old
value of the PC during a jal instruction.
Related
Taken from the Intel 80386 Programmer's Reference Manual, CH9:
Exceptions are classified as faults, traps, or aborts depending on the way
they are reported and whether restart of the instruction that caused the
exception is supported.
Aborts: An abort is an exception that permits neither precise location
of the instruction causing the exception nor restart of the program
that caused the exception. Aborts are used to report severe errors,
such as hardware errors and inconsistent or illegal values in system
tables.
(Emphasis mine)
What does it exactly mean that aborts are exceptions that do not permit precise location of the instruction causing the exception?
There's only 2 "abort" exceptions:
a) Double fault exception. This happens when trying to start one exception caused a second exception; where the instruction pointer (saved by CPU when starting the double fault exception handler) could be from the original instruction, the first exception, the second, something else or nothing. In this case, because the CPU couldn't start the first or second exception handler you can't return from the double fault to the second (or first) exception handler anyway.
b) Machine check exception. This is purely for hardware faults where you probably don't want to assume that memory, or caches, or the CPU actually work. You can't expect "guaranteed behavior" from faulty hardware.
Note 1: Technically, for some causes of machine check, you can return to the precise location of whatever happened to be interrupted by the exception; you just need to be very careful about determining if you can/can't return (and need some way to fix/work-around the hardware problem/s so that returning from the machine check exception handler won't just trigger a second machine check exception).
Note 2: It's perfectly possible for the exceptions preceding a double fault, or machine check, to be caused by something that isn't an instruction at all (e.g. caused by an IRQ). In these cases "the precise location of the instruction causing the exception" would be "the precise location of something that doesn't exist". Intel's words should be interpreted as being conditional (like "an exception that permits neither precise location of the instruction causing the exception if there is one, nor restart of the program that caused the exception if there is one").
I'm trying to identify a bug in a program (32bit) which could probably lead to code execution. So far I debugged the application with ollydbg and ran my exploit code. Then ollydbg gives me an exception.
If I press "Ctrl+F9" nothing seems to be executed of my shellcode
In contrast when the exception occures and I step through the next instructions with "F8" I finally reach my shellcode and it gets executet
If I run the application without ollydbg, my shellcode also doesn't get executed
Why does my shellcode get executed when I step to the next instructions an otherwise not? What's then the normal case when I run my application without a debugger?
Thanks a lot!
When an exception is raised in a thread the system will first check if a debugger is attached.
If a debugger is attached the exception is reported to the debugger (and not to the faulting process or thread). In ollydbg (and most debuggers) you then have the choice to do something with that exception.
The 1st one is to pass that exception to the faulting thread (CTRL+F9) in ollydbg.
The system will look at the EXCEPTION_REGISTRATION_RECORD for the current thread and walks the list of EXCEPTION_REGISTRATION structures (each of these structures has an exception handler) and check if a handler can handle the exception.
If a handler can handle the exception, the stack is unwind (to a certain point) and the thread might continue its life.
If no handler can handle the exception, the final handler is called and the program crashes (the system will then usually display a dialog box informing the user that the process crashed).
This is exactly the same behavior in the case no debugger is attached.
Thus, in your case, passing the exception to the debugger will probably unwind the stack, and the thread will continue its execution after the location of the exception (or simply crash the whole application if the exception couldn't be handled).
The second option - when a debugger is attached - is to not pass the exception to the faulting thread (using one of the step [into | over] / run button). In this case the system will not search for any handler and the thread will either simply rethrow the exception (if it can't pass over it) or continue execution like nothing happened (if the debugger knows how to handle it).
You should check which type (most probably one of: Access violation in read / write ; breakpoint exception) of exception is raised and correct the problem (see at the bottom of the ollydbg window, it will tell you which kind of exception has been raised) if you want to execute your shellcode without problem.
I'm reading about HW\SW interrupts and something isn't clear to me:
When the normal flow is interrupted by an exception ("software interrupt"), the address of the instruction which caused the interrupt is saved, and then the OS gives the exception handler a chance to handle it.
The point I'm not sure about is which instruction is processed after the handler finishes:
If the same "faulty" instruction in run again, it might cause the same exception.
If the next instruction is run, aren't we losing the affect of the previous instruction (which might cause a "normal" exception, such as page fault)?
The instruction that caused the fault is executed again. The idea is that the handler should make appropriate changes so that the instruction will be able to execute properly.
For instance, if an instruction causes a page fault because it tries to access virtual memory that's paged out, the OS will load the page from backing store, update the page table, and then restart the instruction. This time it will succeed because the page is in RAM.
If the handler doesn't fix things, you'll get another interrupt when it's restarted, and the process will repeat.
For some months I've been working on a "home-made" operating system.
Currently, it boots and goes into 32-bit protected mode.
I've loaded the interrupt table, but haven't set up the pagination (yet).
Now while writing my exception routines I've noticed that when an instruction throws an exception, the exception routine is executed, but then the CPU jumps back to the instruction which threw the exception! This does not apply to every exception (for example, a div by zero exception will jump back to the instruction AFTER the division instruction), but let's consider the following general protection exception:
MOV EAX, 0x8
MOV CS, EAX
My routine is simple: it calls a function that displays a red error message.
The result: MOV CS, EAX fails -> My error message is displayed -> CPU jumps back to MOV CS -> infinite loop spamming the error message.
I've talked about this issue with a teacher in operating systems and unix security.
He told me he knows Linux has a way around it, but he doesn't know which one.
The naive solution would be to parse the throwing instruction from within the routine, in order to get the length of that instruction.
That solution is pretty complex, and I feel a bit uncomfortable adding a call to a relatively heavy function in every affected exception routine...
Therefore, I was wondering if the is another way around the problem. Maybe there's a "magic" register that contains a bit that can change this behaviour?
--
Thank you very much in advance for any suggestion/information.
--
EDIT: It seems many people wonder why I want to skip over the problematic instruction and resume normal execution.
I have two reasons for this:
First of all, killing a process would be a possible solution, but not a clean one. That's not how it's done in Linux, for example, where (AFAIK) the kernel sends a signal (I think SIGSEGV) but does not immediately break execution. It makes sense, since the application can block or ignore the signal and resume its own execution. It's a very elegant way to tell the application it did something wrong IMO.
Another reason: what if the kernel itself performs an illegal operation? Could be due to a bug, but could also be due to a kernel extension. As I've stated in a comment: what should I do in that case? Shall I just kill the kernel and display a nice blue screen with a smiley?
That's why I would like to be able to jump over the instruction. "Guessing" the instruction size is obviously not an option, and parsing the instruction seems fairly complex (not that I mind implementing such a routine, but I need to be sure there is no better way).
Different exceptions have different causes. Some exceptions are normal, and the exception only tells the kernel what it needs to do before allowing the software to continue running. Examples of this include a page fault telling the kernel it needs to load data from swap space, an undefined instruction exception telling the kernel it needs to emulate an instruction that the CPU doesn't support, or a debug/breakpoint exception telling the kernel it needs to notify a debugger. For these it's normal for the kernel to fix things up and silently continue.
Some exceptions indicate abnormal conditions (e.g. that the software crashed). The only sane way of handling these types of exceptions is to stop running the software. You may save information (e.g. core dump) or display information (e.g. "blue screen of death") to help with debugging, but in the end the software stops (either the process is terminated, or the kernel goes into a "do nothing until user resets computer" state).
Ignoring abnormal conditions just makes it harder for people to figure out what went wrong. For example, imagine instructions to go to the toilet:
enter bathroom
remove pants
sit
start generating output
Now imagine that step 2 fails because you're wearing shorts (a "can't find pants" exception). Do you want to stop at that point (with a nice easy to understand error message or something), or ignore that step and attempt to figure out what went wrong later on, after all the useful diagnostic information has gone?
If I understand correctly, you want to skip the instruction that caused the exception (e.g. mov cs, eax) and continue executing the program at the next instruction.
Why would you want to do this? Normally, shouldn't the rest of the program depend on the effects of that instruction being successfully executed?
Generally speaking, there are three approaches to exception handling:
Treat the exception as an unrepairable condition and kill the process. For example, division by zero is usually handled this way.
Repair the environment and then execute the instruction again. For example, page faults are sometimes handled this way.
Emulate the instruction using software and skip over it in the instruction stream. For example, complicated arithmetic instructions are sometimes handled this way.
What you're seeing is the characteristic of the General Protection Exception. The Intel System Programming Guide clearly states that (6.15 Exception and Interrupt Reference / Interrupt 13 - General Protection Exception (#GP)) :
Saved Instruction Pointer
The saved contents of CS and EIP registers point to the instruction that generated the
exception.
Therefore, you need to write an exception handler that will skip over that instruction (which would be kind of weird), or just simply kill the offending process with "General Protection Exception at $SAVED_EIP" or a similar message.
I can imagine a few situations in which one would want to respond to a GPF by parsing the failed instruction, emulating its operation, and then returning to the instruction after. The normal pattern would be to set things up so that the instruction, if retried, would succeed, but one might e.g. have some code that expects to access some hardware at addresses 0x000A0000-0x000AFFFF and wish to run it on a machine that lacks such hardware. In such a situation, one might not want to ever bank in "real" memory in that space, since every single access must be trapped and dealt with separately. I'm not sure whether there's any way to handle that without having to decode whatever instruction was trying to access that memory, although I do know that some virtual-PC programs seem to manage it pretty well.
Otherwise, I would suggest that you should have for each thread a jump vector which should be used when the system encounters a GPF. Normally that vector should point to a thread-exit routine, but code which was about to do something "suspicious" with pointers could set it to an error handler that was suitable for that code (the code should unset the vector when laving the region where the error handler would have been appropriate).
I can imagine situations where one might want to emulate an instruction without executing it, and cases where one might want to transfer control to an error-handler routine, but I can't imagine any where one would want to simply skip over an instruction that would have caused a GPF.
what will the program behave when they have two exceptions.
And none of them have been caught yet.
what type of handler will be called .
lets say both the exceptions were of different type.
i apologize if i am not clear but i feel i have made myself clear enough.
thank you!!!
what if the try block throws an exception and try block is exited which destroyes all the automatic variables.Lets say one was an automatic object and its destructor again threw an exception.Now we have two uncaught exception.My question is based on this fact.
thank you!!
It depends entirely on the language. However, in all the languages I know there can't ever be multiple exceptions at the same time (in the same thread). If an exception has been thrown, it travels up the call stack until it's caught, with no code executing during this time. If the exception is not caught, the program crashes before another can be thrown. If it is caught, the exception is no longer "active" and if the handler throws a new exception, the old one is forgotten.
At the CPU level (on x86), there is a situation called a double fault:
On the x86 architecture, a double fault exception occurs if the processor encounters a problem while trying to service a pending interrupt or exception.
However, this kind of "double fault" is a very low level situation and is only of concern to the operating system kernel.
Few languages or frameworks can do a good job of handling an exception that occurs while cleaning up from an earlier exception. Effective handling of such situations would require the cleanup code to know what exception, if any, occurred on the "main line". Conceptually it would not be at all difficult for such information to be provided to cleanup code, but frameworks generally don't provide it.
Otherwise, normal behavior in C++ is to hard-crash the system when an exception occurs during the cleanup from another exception; Java and .NET languages generally abandon any pending exception if a cleanup exception occurs. Newer versions of Java, however, include a feature which (if used) will handles such things much better. In a try-with-resources block, an exception which occurs while cleaning up resources when no other exceptions are pending will be treated normally; if, however, an exception was pending, the pending exception will remain pending but have the new exception added to its list of "suppressed exceptions". It would be nice if there were a way of specifying that a particular finally block should behave the same way, but I don't know of any feature for that.
When Exception is occurred then complier unwind stack(closing current functions and going to back, caller function). If no exception is caught in main than complier called abort function. By this program terminate abnormally.
But during unwinding stack if another exception is occurred(for your case in destructor) than at this time/point without reaching main function, compiler called abort function which terminate program abnormally.
If you know that exception could be occurred in destructor than you must handled in destructor .Means in destructor you should have catch block to catch that exception. By this way second exception generated is to be handled within a destructor and this exception is not out from the destructor and program is to saved from crash due to two exception generated at a time
Complier handle only one exception at a time. If compiler find more than one exception call abort function by which program terminate abnormally.