volatility3 icon indicating copy to clipboard operation
volatility3 copied to clipboard

Linux: Replace uses of specific types with the more generic pointer

Open ikelos opened this issue 1 year ago • 2 comments

Attempts to fix #1041 by changing hard coded types into the more general pointer (since the type is usually for a pointer). This is due to LLVM producing a different base type. It doesn't necessarily resolve the situation permanently, but it should alleviate the main situations where it arises.

ikelos avatar May 20 '24 20:05 ikelos

Could someone on #1041 please test this to see if it resolves the issue at hand? The other options available are to hard code our own version of that type, or force dwarf2json to inject it, neither of which seem all that clean...

ikelos avatar May 20 '24 20:05 ikelos

Welp, that didn't work. Looks like I'll need to investigate what went wrong... Seems to be returning no results for linux plugins (but not throw an issue). Should be easy to check the difference between the working version and the patched version.

ikelos avatar May 20 '24 23:05 ikelos

Ok, turns out this doesn't work for a number of reasons. Firstly, it's being done on the physical layer, which still comes out with the right pointer size, but the pointer is then limited to the size of the layer it's in, so it gets cropped. Secondly, the symbol space has been loaded, but the higher layer hasn't been decided yet (because that depends on the init_task, which is what we're trying to make) so there's no way of using it as the native_layer for the pointer.

So now I'm doing a little bit of ugly gymnastics to cast the pointer to bytes (to get the original value) and then read the integer value from it the same way the pointer would, but without the address layer mask. Shouldn't be necessary for the other use because just wants the size, which should match the system's pointer size (not sure if that holds true for 32-bit systems, I'm not sure what long unsigned int is defined as in 32-bit systems). There may still be other places where the core depends on symbols that may not be present in the final symbol table. Some will be in plugins, but I care less about them than the core.

ikelos avatar May 21 '24 22:05 ikelos