Given the code attached, and related to this issue 'Global buffer overflow during .text section parsing', I want to know if this code could be modified to only parse the .text section in memory (the executable code) to avoid global buffer overflow with ASAN.
extern char __ehdr_start;
extern char etext;
ElfW(Ehdr) *elfhdr = (ElfW(Ehdr) *) &__ehdr_start;
int i;
for (i = 3; (unsigned long)(&__ehdr_start + elfhdr->e_entry + i) < (unsigned long)(&etext); i = i + 4) {
if ((unsigned char)*(&__ehdr_start + elfhdr->e_entry + i) == 0x01 ) {
if(((unsigned char)*(&__ehdr_start + elfhdr->e_entry + i - 1) == 0x02) && ((unsigned char)*(&__ehdr_start + elfhdr->e_entry + i - 2) == 0x03) && ((unsigned char)*(&__ehdr_start + elfhdr->e_entry + i - 3) == 0x04)) {
....
Parse the .text section of Android application native code without the ASAN crash for Global buffer overflow.
Global buffer overflow during .text segment parsing
In your other question, you were parsing .text
segment. In this question you are attempting to parse .text
section. The titles of your questions are swapped.
Your modified code here doesn't actually parse the .text
section. It starts scanning from (usually) the _start
symbol, and stops when reaching etext
symbol.
There are two assumptions here:
_start
symbol is at the beginning of the .text
section and_start
and etext
is coming from .text
sectionNeither of these assumptions is guaranteed to be true, although usually they are on Linux. I have no idea what a typical Android binary layout is.
You should be able to run nm --numeric-sort a.out
and look at all the symbols between _start
and etext
. If any of them are in the {C,D,G,R,S,V}
set (or same set in lowercase), then the second assumption is violated.
If all symbols are T
, t
, W
or w
, probably something else is going on. But you should be able to tell what's going on since you know which address between _start
and etext
is triggering AddressSanitizer error and which symbol is at that address.