search

panda-re / panda

Platform for Architecture-Neutral Dynamic Analysis
https://panda.re
Other
2.47k stars 478 forks source link

Windows osi: program name resolution broken on current dev tree #1274

Open hanetzer opened 1 year ago

hanetzer commented 1 year ago

pulling up an old project, and it seems that asidstory (and others, but I've not yet documented them) is busted on windows targets (win7x32 vm).

Working hash: 8cc9363146bba49dbb70dc14d430f8f92c1ab768

   Count   Pid              Name/tid      Asid     First          Last
     845   400   [csrss.exe  / 460]4  6a8b6000    823962  ->  29758109
     837  1276  [explorer.exe  / 128  639a2000   2227204  ->  29758209
     124     4       [System  / 192]    185000    860055  ->  28006314
     111     0          [Idle  / 0]5    185000    811150  ->  18290571
      86     0          [Idle  / 0]2    185000     26149  ->    811091
      56   400    [csrss.exe  / 460]  6a8b6000     26289  ->   2885016
      41   988  [svchost.exe  / 1124  65d1c000    862521  ->  28204202

Broken hash: 97c0ed956b999958a333f960d85fae7e65f81c04

   Count   Pid              Name/tid      Asid     First          Last
     619     0        [Idle  / 1120]    185000    134885  ->  29758185
     167     0          [Idle  / 0]2    185000     26189  ->  28671794
     110     0        [Idle  / 464]3    185000   2410036  ->  25992571
      74     0        [Idle  / 464]4    185000   2767725  ->  24555166
      35     0       [Idle  / 464]14    185000   6346333  ->  25272503
      35     0        [Idle  / 464]6    185000   3363721  ->  25012477

The latter never shows the process names, and I suspect this is the reason why my attempt to use the trace module in single-executable mode failed (produced no output), as it cannot figure out the name of my target.exe

hanetzer commented 1 year ago

And nvm. I'm dumb, the issue was on my end, but for the sake of future googlers: I specified -os windows-32-7sp1 to get the bad reading on the latter hash; using -os windows-32-7sp0 does work, but I'm not sure where the difference arises, as the wintrospection plugin uses 0x185000 for the system_asid_lookup for both settings. Leaving open because something's probably wrong here even if that wrongness can be fixed by a user flag.