-
Alessandro Di Federico authored
We used to ignore the `.gnu.hash` section, however it turns out to be fundamental in case the ELF we're working on *defines* one or more symbols. This has not been a problem so far since we usually work with the main executable only, which, usually, doesn't define any dynamic symbol. However, for example, `ls` "defines" a `getoptind` symbol (more accurately, it clones it from libc). To handle this situation, we replace the `.gnu.hash` with a minimal `.hash` section. Basically, the `.hash` section should contain an hash table. However, currently, we just create an hash table with a single entry, which immediately triggers scanning the chain of entries colliding in the (only) entry.
Alessandro Di Federico authoredWe used to ignore the `.gnu.hash` section, however it turns out to be fundamental in case the ELF we're working on *defines* one or more symbols. This has not been a problem so far since we usually work with the main executable only, which, usually, doesn't define any dynamic symbol. However, for example, `ls` "defines" a `getoptind` symbol (more accurately, it clones it from libc). To handle this situation, we replace the `.gnu.hash` with a minimal `.hash` section. Basically, the `.hash` section should contain an hash table. However, currently, we just create an hash table with a single entry, which immediately triggers scanning the chain of entries colliding in the (only) entry.
Loading