Am Dienstag, 1. September 2020, 10:53:31 CEST schrieb Jiri Slaby:
On 20. 08. 20, 17:58, Hans-Peter Jansen wrote:
slowly approaching volatility3 here.
Now, that I learned to build dwarf2json¹ (home:frispete:Tumbleweed/
dwarf2json), I've tried to actually use it.
$ zyp in kernel-default-debuginfo
$ dwarf2json linux --elf /usr/lib/debug/boot/vmlinux-5.8.0-8-default.debug
processing: could not get DWARF from /usr/lib/debug/boot/
vmlinux-5.8.0-8-default.debug: decoding dwarf section info at offset
Just generating the symbol map lloks fine:
$ dwarf2json linux --system-map /boot/System.map-5.8.0-8-default >
Q is, who/what to blame here? Is it our infrastructure, that generates
DWARF for the kernel in an unusual way, or is it dwarf2json itself?
IMO, it would be incomplete implementation in go's debug/dwarf. Good
luck debugging go ;).
You can check what's at that offset using e.g.
objdump --dwarf=info /usr/lib/debug/boot/vmlinux-5.8.0-8-default.debug
Thanks for the hint, Jiri, will take a look at this, when time allows.
I'm inclined to rewrite the thing in Python3.
What's sad here is the fact, that this issue effectively prevents us from
using the most advanced volatile memory extraction framework for the time
being (the thing, that is used by almost all secret service organizations
around the world for malware attack analysis)¹. Well, to be fair, they still
run the Python2² version³, of course...
To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org