WIP-Extending extensions-multiple loading hooks - discuss... #378
Conversation
added SHA256 hashing
* dynamic dialog box helper * actually do something with defaults, and update docstr to help. * warning and informational messages too. * bugfixes in QtCore and other imports * cleanup and additions to the README * oops, removed this prematurely. * cleanup example gui extension * Update README.md thanks @williballenthin! Co-authored-by: Willi Ballenthin <willi.ballenthin@gmail.com> Co-authored-by: Willi Ballenthin <willi.ballenthin@gmail.com>
vivisect/extensions/__init__.py
Outdated
| extensions.append(mod) | ||
|
|
||
| except Exception as e: | ||
| logger.warn(traceback.format_exc()) |
There was a problem hiding this comment.
you can use logging.somelevel("....", args, exc_info=True) to render the traceback with the log message
There was a problem hiding this comment.
also, looks like inconsistent reporting: is it vw.vprint or logger.warn on extension errors?
|
|
||
| from os.path import dirname, basename, isfile, join | ||
| parserpaths = glob.glob(join(dirname(__file__), "*.py")) | ||
| __all__ = [ basename(f)[:-3] for f in parserpaths if isfile(f) and not f.endswith('__init__.py')] |
There was a problem hiding this comment.
imho, i dont like this. can we instead do explicit imports and avoid runtime resolution of source code?
| 'arm':'armcall', | ||
| } | ||
|
|
||
| def isParser(bytez): |
There was a problem hiding this comment.
"taste" ?
isParser makes me think that we check the bytez to see if the bytez are a parser, versus can be parsed by a given parser.
There was a problem hiding this comment.
suggestion? i think of how it will be called "module.isParser(bytez)" and it makes sense. but you have a good point as well.
|
oh... after going through the code, i see now that it was first proposed in 2019 and there are multiple merge conflicts that would have to be addressed first. sorry! |
|
thanks @williballenthin ! i appreciate your feedback. this certainly is not ready for merging. @rakuy0 and i were talking about the idea of giving extensions more places to hook in, allowing them to provide new parsers, new architectures, etc... unfortunately, that means some dynamic loading of code, but we'll work with you to minimize the pain. extensions are by nature dynamic code in some fashion. i'm not sure what your constraints are, but i'm interested in a solution that gives the power but doesn't cause you grief. |
I think this is great!
couple thoughts... first, i'd discourage dynamically looking for code based on the file path of some analyzer. recall that viv will often be installed via pypi these days, so the source code gets copied into instead, i'd suggest an architecture in which clients of the library (including vivbin and friends) register plugins they've configured/recognized with the workspace as they create it. for example: vw = vivisect.Workspace()
vw.registerFileFormatPlugin(viv_utils.png.PngFileFormatPlugin)
vw.registerFunctionAnalyzer(viv_utils.flirt.FlirtFunctionAnalyzer)
vw.load(...)
vw.analyze(...)This way, various applications can use different strategies to locate the plugins that are relevant to them. For example, maybe capa looks into (A nice side effect is that there are fewer global variables needed, which is great when working with multiple workspaces/daemons/etc. As is, its currently hard to isolate settings and context.) |
# Conflicts: # vivisect/__init__.py # vivisect/extensions/__init__.py # vivisect/extensions/example_gui_extension.py # vivisect/parsers/__init__.py # vivisect/parsers/blob.py # vivisect/parsers/elf.py # vivisect/parsers/ihex.py # vivisect/parsers/macho.py # vivisect/parsers/pe.py # vivisect/vivbin.py
Co-authored-by: Willi Ballenthin <willi.ballenthin@gmail.com>
Co-authored-by: Willi Ballenthin <willi.ballenthin@gmail.com>
Co-authored-by: Willi Ballenthin <willi.ballenthin@gmail.com>
Co-authored-by: Willi Ballenthin <willi.ballenthin@gmail.com>
Co-authored-by: Willi Ballenthin <willi.ballenthin@gmail.com>
|
hey @williballenthin i was just re-reading your suggestions from 9 months ago (wow, how time flies). thank you, those are valuable suggestions. i may pick this PR back up in the near future, and i'll consider how to leverage your suggestions to make this a positive change. |
|
TODO: make architectures a registerable thing. |
|
@williballenthin oddly enough, this is part of what drove the "loading envi modules" approach for v1.1.0. the ability to load envi modules in a uniform way. |
No description provided.