If the shellcode instead references data below the stack
pointer, it is easily possible to overwrite shellcode located in region B.
How do you know if your shellcode has the potential to overwrite itself, and what
steps can you take to avoid this situation? The answer to the first part of this question
depends entirely on how you obtain your shellcode and what level of understanding
you have regarding its behavior. Looking at the Aleph1 shellcode used in Chapters 7 and
8, can you deduce its behavior? All too oftenwe obtain shellcode as nothing more than a
blob of data that we paste into an exploit program as part of a larger buffer. We may in
fact use the same shellcode in the development of many successful exploits before it
inexplicably fails to work as expected one day, causing us to spend many hours in a
debugger before realizing that the shellcode was overwriting itself as described earlier.
This is particularly true whenwe become too reliant on automated shellcode-generation
tools, which often fail to provide a corresponding assembly language listing when spitting
out a newly minted payload for us. What are the possible solutions to this type of
problem?
The first is simply to try to shift the location of your shellcode so that any data written
to the stack does not happen to hit your shellcode.
Pages:
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402