In the second case, eip itself has been corrupted for some reason. Let??™s take a quick look
at each of these cases.
In the case that eip appears to point to valid program code, the instruction immediately
preceding the one pointed to by eip is most often to blame for the crash.
NOTE For the purposes of debugging it should be remembered that eip is
always pointing at the next instruction to be executed. Thus, at the time of the
crash, the instruction referenced by eip has not yet been executed and we
assume that the previous instruction was to blame for the crash.
Analysis of this instruction and any registers used can give the first clues regarding the
nature of the crash. Again, it will often be the case that we find a register pointing to an
unexpected location from which the program attempted to read or write. It will be
Chapter 18: From Vulnerability to Exploit
461
PART IV
Gray Hat Hacking: The Ethical Hacker??™s Handbook
462
useful to note whether the offending register contains user-supplied values, as we can
then assume that we can control the location of the read or write by properly crafting the
user input. If there is no obvious relationship between the contents of any registers and
the input that we have provided, the next step is to determine the execution path that led
to the crash.
Pages:
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807