[Dwarf-Discuss] security implications of DWARF info
Robinson, Paul T (JCTL-NonStop)
paul.t.robinson at hp.com
Wed Nov 24 09:15:58 PST 2010
>I'm assuming that there's more information that function addresses.
>Type information, for example, or mappings to source code lines.
DWARF includes names of all named entities in the object, as well
as directory and file names of the source files and the mapping
table correlating instructions with source locations. Names that
identify typed entities will also describe those types. Names
that identify entities with associated data storage will also
describe those storage locations. Names that identify entities
with associated instructions (functions, thunks, etc) will also
describe those code locations.
>Such information could aid reverse engineers.
The point of DWARF is to provide information that will help you
understand the execution of the code. Whether you are the one
developing the code or reverse-engineering the code, the information
is the same.
I am not familiar with dSYM files either, but in ELF object files,
even if you strip out all the DWARF there will still be the ELF
symbol table. If you are looking at a DLL the ELF symbol table
cannot avoid listing the names of all exported entrypoints; and
typically it would have all entrypoints and static/global data names.
That symbol table is sufficient for presenting a symbolic traceback
of the call chain at the point of an abend, and if that's all you
need, then stripping the DWARF completely sounds like what you want.
Whether you can obfuscate the object-file's symbol table is a
separate question for some other mailing list.
More information about the Dwarf-Discuss