[opensuse-kernel] dwarf2json fails with 5.8.0 kernel from Tumbleweed
Hi, 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 > 5.8.0-8-default.json Failed linux processing: could not get DWARF from /usr/lib/debug/boot/ vmlinux-5.8.0-8-default.debug: decoding dwarf section info at offset 0x2705: underflow Just generating the symbol map lloks fine: $ dwarf2json linux --system-map /boot/System.map-5.8.0-8-default > 5.8.0-8- default-syms.json 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? Pete ¹) Already submitted to security:forensics, as well as updates for a couple of related packages: yara, volatility3. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
On 20. 08. 20, 17:58, Hans-Peter Jansen wrote:
Hi,
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 > 5.8.0-8-default.json Failed linux processing: could not get DWARF from /usr/lib/debug/boot/ vmlinux-5.8.0-8-default.debug: decoding dwarf section info at offset 0x2705: underflow
Just generating the symbol map lloks fine: $ dwarf2json linux --system-map /boot/System.map-5.8.0-8-default > 5.8.0-8- default-syms.json
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 regards, -- js suse labs -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
Am Dienstag, 1. September 2020, 10:53:31 CEST schrieb Jiri Slaby:
On 20. 08. 20, 17:58, Hans-Peter Jansen wrote:
Hi,
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
5.8.0-8-default.json Failed linux processing: could not get DWARF from /usr/lib/debug/boot/ vmlinux-5.8.0-8-default.debug: decoding dwarf section info at offset 0x2705: underflow
Just generating the symbol map lloks fine: $ dwarf2json linux --system-map /boot/System.map-5.8.0-8-default > 5.8.0-8- default-syms.json
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... Cheers, Pete [¹] https://github.com/volatilityfoundation/volatility3 [²] https://github.com/volatilityfoundation/volatility [³] https://media.defense.gov/2020/Aug/13/2002476465/-1/-1/0/ CSA_DROVORUB_RUSSIAN_GRU_MALWARE_AUG_2020.PDF -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-kernel+owner@opensuse.org
participants (2)
-
Hans-Peter Jansen -
Jiri Slaby