corelan / mona

Corelan Repository for mona.py
BSD 3-Clause "New" or "Revised" License
1.7k stars 565 forks source link

Raise an exception if the module info cannot be loaded and properly handle the error #3

Closed moshekaplan closed 9 years ago

moshekaplan commented 9 years ago

This pull request is to resolve the error reported in IRC http://i.imgur.com/6iYT9JA.png This issue is caused by dbg.getModule able to return None instead of a module object (windbglib line 899 and immlib.py's getModule on line 1171).

Please ensure that the code runs without issue and that the exceptions are handled in an appropriate fashion before merging.

corelanc0d3r commented 9 years ago

Hi, thanks for the PR.

There are a couple of small issues with modules in mona. In any case, there should not be a case where mona is not able to load the module, so if there is an error, it's a bug in mona. Is there a good way to simulate the issue reported on IRC, so we can check why mona is not able to return a valid module object ?

One of the other changes I need to make is the case where the process has 2 modules with the same name. Right now, the module name is also uses a dictionary key, so this will cause issues. The way windbg fixes this, is by appending the baseaddress to the modulename. (for example: "module1" and "module1_12000000".

moshekaplan commented 9 years ago

In any case, there should not be a case where mona is not able to load the module, so if there is an error, it's a bug in mona.

When an MnModule is created, it uses information from getModule to populate the fields of the instance. The problem is caused by the implementation of getModule in immlib.py and windbglib sometimes returning None, so none of the data is available. Below is the implementation from immlib.py

def getModule(self, name):
    """
        Get Module Information

        @type  name: STRING
        @param name: Name of the module

        @rtype:  Module OBJECT
        @return: A Module object
        """

    #self.getAllModules()

    modulos = debugger.get_all_modules()
    if modulos.has_key(name):
        if not self.Modules.has_key(name):
            # Modules are stable
            m = Module(name, modulos[name][0], modulos[name][1], modulos[name][2])
            mod_dict = self._getmoduleinfo(modulos[name][0])
            m.setModuleExtension(mod_dict)
            #if symbol:
            #    self.getAllSymbols() #_getsymbols()
            #    symbol = 0

            #try:
            #    m.setSymbols( self.Symbols[ mod.lower() ] ) 
            #except KeyError:
            #    pass
            self.Modules[name] = m
            return m
        else:
            return self.Modules[name]

    #if type(name) == type(''):
    #    try:
    #        return self.Modules[ name ]
    #    except KeyError:
    #        return None
    #else:
    #    for mod in self.Modules.keys():
    #        if self.Modules[ mod ].baseaddress == name:
    #            return self.Modules[ mod ]
    return None

Is there a good way to simulate the issue reported on IRC, so we can check why mona is not able to return a valid module object ?

To test this, I'd make a replacement getModule stub that returns None for a specific module name.