Implement a handle manager about dumpulator HOT 5 CLOSED

Just had another look, saw you renamed the member to handles already, thanks!

For __find_free_handle I guess you could just implement it without reusing handles to keep things simple. Another approach would be to keep a free list and only increase the handle count when there is nothing available in the free list. This is O(1).

For the get function I think you have to & ~3 (or similar) because some lower bits of the handle value are ignored (don't have a reference right now, but I can test later).

The storage of a dict I think is fine to start with, but eventually I suspect it could turn into a mess. An alternative would be to have a typed API, something like:

from typing import Any, Type, TypeVar

class FileHandle:
	def __init__(self, path):
		self.path = path
		
	def __str__(self):
	    return f"{type(self).__name__}(path: {self.path})"
		
class SpecialFileHandle(FileHandle):
	def __init__(self, path, special):
		super().__init__(path)
		self.special = special
		
fh = FileHandle('c:/blah.txt')
sfh = SpecialFileHandle('c:/foo.txt', 1337)

handles = {0x1C: fh, 0x2C: sfh}

# HandleManager
def _get_internal(handle_value: int) -> Any:
    return handles.get(handle_value & ~3, None)

T = TypeVar('T')

def get(handle_value: int, handle_type: Type[T]) -> T:
    data = _get_internal(handle_value)
    if data is None:
        return None
    if handle_type is not None and not isinstance(data, handle_type):
        raise TypeError(f"Expected {handle_type.__name__} got {type(data).__name__}")
    return data

# OK
print(get(0x1C, FileHandle))
print(get(0x1D, FileHandle))

# OK
print(get(0x2C, FileHandle))

# Type error
print(get(0x1C, SpecialFileHandle))

This would allow for full flexibility. Optionally there could be a HandleData base class that stores metadata like creation time, call stack (python and/or native) and tracing if desired.

from dumpulator.

First pass at this. Relatively straight forward implementation.

Decided going for an open ended approach allowing the handle object be dynamic to allow minimal code and reuse of the same object with a dictionary, still not 100% sold on this idea but does save a lot of code.

The other way to approach it would be a more strict object type with a defined strict layout.

Handle manager class:
https://github.com/oopsmishap/dumpulator/blob/handle-manager/src/dumpulator/handles.py

Example of the usage:
https://github.com/oopsmishap/dumpulator/blob/handle-manager/src/dumpulator/ntsyscalls.py#L821

Test cases:
https://github.com/oopsmishap/dumpulator/blob/handle-manager/tests/handletest.py

Let me know what you think.

from dumpulator.

Thanks, I’ll take a more detailed look later. First impressions are good though and I think allowing arbitrary data to be stored is a good idea.

The first thing I noticed is the name “hm”, perhaps it should be “handles” to make the code a bit more readable.

I guess there should also be some generic properties stores but I’ll look at it later.

from dumpulator.

__find_free_handle idea with the free handle list is a good one and easy to implement.

The get function, you are right with the lower bits, windows not only ignores them but raises an exception.

if ( (handle & 3) != 0 )
    ExRaiseDatatypeMisalignment();

For the data storage I completely agree, I was unsure about a dictionary for the same reasons you stated.

Also doing some testing, it seems like keeping a reference count isn't needed for handle duplication as this is automatically handled by adding a new reference to the object under a new handle value, once all references from the dictionary are cleared the object is cleared.

from dumpulator.

I guess an exception could be used to generically handle this in syscalls? I think I confused the behavior with process IDs...

from dumpulator.