search

volatilityfoundation / dwarf2json

convert ELF/DWARF symbol and type information into vol3's intermediate JSON
Other
104 stars 28 forks source link

Feature request: /proc/kallsyms support #21

Closed gcmoreira closed 3 years ago

gcmoreira commented 4 years ago

When available, it would be great to take advantage of /proc/kallsyms to replace system.map and get the real addresses. Also, it could be useful for ASLR and to speed up the profile/ISF detection process, get the banner, etc. Rekall ( see here ) implements that for similar purposes.

ilch1 commented 4 years ago

Thanks for the suggestion.

From the symbol producer side (dwarf2json), the suggested feature could be implemented. However, I do not know how well it will work with volatility3. The ISF file generated using kallsyms could be specific to the state of the machine (that boot) and would not be usable more broadly on memory images that have a matching kernel but have a different state (e.g., ASLR value).

What do you think @atcuno ?

atcuno commented 4 years ago

@ilch1 is correct about kallsyms containing the slide whereas System.map contains the base (non-slid) values. This makes System.map usable across all memory samples from a particular kernel build whereas kallsyms is boot specific.

A couple other thoughts:

1) Rekall is using /proc/kallsyms for live analysis (https://github.com/google/rekall/blob/ca6ee6bf6065f0431ff8c6f3b2cd06a2d9cec6ab/rekall-core/rekall/plugins/guess_profile.py#L461). Volatility 3's main use case is against static memory samples, not against live systems, so we do not expect nor can we rely on /proc/kallsyms for symbol assistance.

2) By default (https://cateee.net/lkddb/web-lkddb/KALLSYMS.html), kallsyms will only contain non-exported symbols. A second config option (https://cateee.net/lkddb/web-lkddb/KALLSYMS_ALL.html) must be enabled for all symbols to be exposed. In practice, we have seen this second option disabled on many distro kernels, which then removes variables needed by core Volatility plugins. If kallsyms were used for a symbol table json instead of System.map, and the second option was not enabled, then there would then be analysis failures. We have also (although rarely) seen KALLSYMS disabled entirely on systems.

3) When running live, Rekall has the advantage of being able to verify the profile/symbol table quickly as it can already do address translation inside the kernel address space. To accomplish this on a memory sample though relies on having the physical offset of the kernel DTB value (CR3 register on Intel systems), which is something we don't have when given nearly all common memory sample formats (raw, lime, etc.). We also have to account for when the kernel has been both physically and virtually shifted in order to properly find variables in the virtual address space (https://cateee.net/lkddb/web-lkddb/RANDOMIZE_BASE.html). This is also something that kernel modules on the live system do not have to account for.

Thank you for bringing this issue up as we should document this before the official / full release of Volatility 3. I will leave the ticket open a few days in case you have any questions or comments.

ilch1 commented 3 years ago

@gcmoreira, I'm going to close this issue. Please reopen if you have any additional questions or comments.