My thoughts. A reduction in the memory footprint of the Metasploit Framework is a definite plus. My understanding is that this change would result in a directory structure with all the modules in a single folder. Downside would be that this could become unwieldy to find particular modules, however the improving search capabilities in the Framework would allay my concerns here.
Rhys 2008/9/26 H D Moore <[EMAIL PROTECTED]> > Hi everyone, > > We (the dev team) have been crunching for a 3.2 release in early October, > one of the things I want to improve is the module loader and caching > systems. The idea is to make the framework much less memory hungry and to > cache all of the fields which are not normally dynamic. So far, the best > new module loader implementation requires a small change to the format of > the Metasploit modules, one which is not backwards compatible. > > Most Metasploit modules have the following syntax: > > --- > module Msf > class Exploit::Remote::Windows::Ftp::SomeOverflow < Exploit::Remote > > def initialize > .. > end > > end > end > --- > > > The module format change would result in this becoming: > > --- > class Metasploit3 < Msf::Exploit::Remote > def initialize > .. > end > > end > --- > > I was able to script up this change to the existing module tree, but > third-party modules would need to be updated to match. This also solves > the problem where modules which dont have a class path matching their > directory structure are not loaded, which in turn makes it easier to add > new third-party modules. > > Thoughts? > > -HD > _______________________________________________ > Framework-Hackers mailing list > Framework-Hackers@spool.metasploit.com > http://spool.metasploit.com/mailman/listinfo/framework-hackers >
_______________________________________________ Framework-Hackers mailing list Framework-Hackers@spool.metasploit.com http://spool.metasploit.com/mailman/listinfo/framework-hackers
