Support for 32-bit PE

[ducphanduyagentp]

Hi there,

Currently the tool is not supporting 32-bit PE. I am not too familiar with the codebase, but is there a simple guideline on how to add support for this? I would be interested in contributing.

Thanks!

[0vercl0k]

Great point!

This shouldn't be hard to add - this is where it should be added: https://github.com/0vercl0k/symbolizer-rs/blob/main/src/pe.rs but I have been working on extracting the logic into a library that I'll use whenever it gets tested a bit more: https://github.com/0vercl0k/addr-symbolizer-rs/blob/fbl_v0.1.0/src/pe.rs#L387 so I'll add it / port your changes there as well; don't worry too much about it :)

You need to read the type of PE file it is and read either ImageOptionalHeader64 or ImageOptionalHeader32 and extract the offsets for the export / debug directory and the rest should just work as is I think.

[0vercl0k]

@ducphanduyagentp I've implemented a dirty PoC in 0vercl0k/addr-symbolizer-rs@a1c2887 - do you mind giving it a shot?

You can try it out by running the below (it'll pull addr-symbolizer-rs & the fix automatically):

$ git clone https://github.com/0vercl0k/symbolizer-rs.git
$ cd symbolizer-rs
$ git checkout fbl_libify
$ cargo run --release

Let me know!

Cheers

[ducphanduyagentp]

Looks like it works well for me 👍

./symbolizer-rs --trace traces/input.txt.trace --symcache sym --crash-dump snapshot_main_x86_1/mem.dmp
main_x86.exe+0x1100
main_x86.exe+0x1000
main_x86.exe+0x1001
main_x86.exe+0x1003
main_x86.exe+0x1004
main_x86.exe+0x1008
main_x86.exe+0x100c
main_x86.exe+0x1011
main_x86.exe+0x1014
main_x86.exe+0x1017
main_x86.exe+0x101b
main_x86.exe+0x101e
main_x86.exe+0x1071
main_x86.exe+0x1073
main_x86.exe+0x1074
✓ Successfully symbolized 15.0 lines across 1.0 files in 0.0s (0% cache hits)

[ducphanduyagentp]

After I tested it with a couple more complex traces, it seems to be skipping modules that are still present in the memory dump. Not sure if this is a dump parser bug or symbolizer bug. I'll send you the dump and trace for this case.

Output:

...
symbolizing address 0xfffff805392041b0..
address 0xfffff805392041b0 doesn't belong to any module
...

Windbg output in mem dump:

32.kd:x86> u 0xfffff805392041b0
nt!SwapContext:
fffff805`392041b0 48              dec     eax
fffff805`392041b1 55              push    ebp
fffff805`392041b2 48              dec     eax
fffff805`392041b3 83ec30          sub     esp,30h
fffff805`392041b6 0f0d4e71        prefetchw [esi+71h]
fffff805`392041ba 884c2428        mov     byte ptr [esp+28h],cl
fffff805`392041be 807e7100        cmp     byte ptr [esi+71h],0
fffff805`392041c2 0f8552060000    jne     3920481a

[0vercl0k]

Thank you! Will investigate this this week and let you know :) Cheers

…

On Thu, Jul 25, 2024 at 12:31 AM Duc Phan ***@***.***> wrote: After I tested it with a couple more complex traces, it seems to be skipping modules that are still present in the memory dump. Not sure if this is a dump parser bug or symbolizer bug. I'll send you the dump and trace for this case. Output: ... symbolizing address 0xfffff805392041b0.. address 0xfffff805392041b0 doesn't belong to any module ... Windbg output in mem dump: 32.kd:x86> u 0xfffff805392041b0 nt!SwapContext: fffff805`392041b0 48 dec eax fffff805`392041b1 55 push ebp fffff805`392041b2 48 dec eax fffff805`392041b3 83ec30 sub esp,30h fffff805`392041b6 0f0d4e71 prefetchw [esi+71h] fffff805`392041ba 884c2428 mov byte ptr [esp+28h],cl fffff805`392041be 807e7100 cmp byte ptr [esi+71h],0 fffff805`392041c2 0f8552060000 jne 3920481a — Reply to this email directly, view it on GitHub <#5 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AALIORM56MVEKCOIXX2ZC4TZOCSUZAVCNFSM6AAAAABLMKUR2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENBZGY2DQOBZGA> . You are receiving this because you commented.Message ID: ***@***.***>

[0vercl0k]

Okay so kdmp-parser can see ntoskrnl.exe:

(base) c:\work\codes\kdmp-parser-rs>cargo run --example parser \Users\over\Downloads\mem.dmp --modules

    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.13s
     Running `target\debug\examples\parser.exe \Users\over\Downloads\mem.dmp --modules`
...
0xfffff80538e00000-0xfffff80539e46000: \SystemRoot\system32\ntoskrnl.exe
...

Will check if something funky happens on the symbolizer side.

Cheers

[0vercl0k]

Actually it seems to work fine; maybe I'm looking at the wrong dump (or maybe you're using symbolizer-rs from the main branch? I've implemented improvements in the libify branch that might explain what you are seeing)?

(base) c:\work\codes\symbolizer-rs>cargo run -- --trace c:\Users\over\Downloads\test-trace.txt --crash-dump \Users\over\Downloads\mem.dmp
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.33s
     Running `target\debug\symbolizer-rs.exe --trace c:\Users\over\Downloads\test-trace.txt --crash-dump \Users\over\Downloads\mem.dmp`
ntoskrnl.exe!SwapContext+0x0
✓ Successfully symbolized 1.0 lines across 1.0 files in 4.0s (0% cache hits, downloaded 8.2mb / 1.0 PDBs)

[ducphanduyagentp]

Hey there,
I tested it again today and it was able to symbolize it just like yours. I was using the correct branch, but wasn't sure what caused the previous output.

Also as discussed, some WoW64 32-bit modules are still missing. I've opened a PR here 0vercl0k/kdmp-parser-rs#8 to address it. You can test it out on the same dump and trace I've sent you.

Thanks!

[0vercl0k]

Beautiful - I'll review this as soon as I can (probably this week-end); thanks again man! Closing this as that part of the work is done 🫡