SEARCH
0-9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
Prev | Current Page 844 | Next

Shon Harris, Allen Harper, Chris Eagle, and Jonathan Ness

"Gray Hat Hacking, Second Edition"

Key things to think about when considering binary patching
include
??? Does the patch cause the length of a function (in bytes) to change?
??? Does the patch require functions not previously called by the program?
Any change that affects the size of the program will be difficult to accommodate and
require very careful thought. Ideally, holes (or as Halvar Flake terms them, ???caves???) in
which to place new instructions can be found in a binary??™s virtual address space. Holes
can exist where program sections are not contiguous in memory, or where a compiler or
linker elects to pad section sizes up to specific boundaries. In other cases, you may be
able to take advantage of holes that arise because of alignment issues. For example, if a
particular compiler insists on aligning functions on double-word (8-byte) boundaries,
then each function may be followed by as many as 7 bytes of padding. This padding,
where available, can be used to embed additional instructions or as room to grow existing
functions. With a thorough understanding of an executable file??™s headers, it is sometimes
possible to take advantage of the difference between an executable??™s file layout
and its eventual memory layout. To reduce an executable??™s disk footprint, padding bytes
that may be present at runtime are often not stored in the disk image of the executable.


Pages:
832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856