Exploit docs

[jerome.athias at free.fr (Jerome Athias)]

Heya,

M. GAD a ?crit :
> Jerome, you have already done a greate work but why you stopped at MSF v2 :(
>   
Quite simple: lack of time.
> I have looked at ur code at a glance, u have advanced well. However, I
> think it may be simpler to program new functionalities (i.e., databse
> backend, automatic Exploiter) in Ruby.
> This has several advantages because it will allow the reuse of MSF
> libraries and classes and will encourage other metasploiters to be
> involved.
>   
I AGREE.
My problems is (was): lack of time, verfy few time to spend to acquire
good Ruby skills.
>   
> > I thought also to put exploits modules in XML files, what do you think
> > about it? (even if it would be time consumming at start)
> >
> >     
>
> Why do it manually? there exist some tools to export Databases into
> XML and vice versa. For example:
>  "mysqldump --xml --databases your database name -u username -p
> password >test.xml"
>
>  IMHO, what we need is an extension of MSF that is compatible with the
> current implementation and that maximize the reuse of MSF code. This
> may be achieved through the following steps:
> (1) determine the useful information that one can need to characterize
> the module (exploit, payload, etc),
> (2) Code these information directly into the module when creating it
> (as already done with the platform and privilege attributes),
> (3) Design database schema and tables,
> (4) write a program to extract information coded within the module and
> export it to the database,
> (5) Design the exploiter as a plugin of MSF (this is another story but
> I have some clues for doing that)
>
> Now, as the thread is becoming more close to framework-hackers, HDM or
> list moderators can switch it there.
>
> Regards,
> MG
>
>   
I agree, but MSF developpers should agree and give their opinion on this.
>   
> > M. GAD a ?crit :
> >     
> > > In fact consulting references one by one to find out more information
> > > about the exploit is sufficiently tedious. MSF-XB quite facilitate it
> > > but we still need to visit several sites.
> > > There is a closely related issue: selecting appropriate exploits. As
> > > the number of exploits and auxiliary tools increases it will be more
> > > difficult to select an appropriate exploit. Although the current GUI
> > > or the web interface are supporting module selection either by
> > > platform or arch, we need sometimes to make selection based on other
> > > criteria a combination of them. For example, selecting an exploit
> > > based on the privilege that it provides, according to its launching
> > > source, according to the directly involved program (the vulnerable
> > > program) , etc.
> > >
> > > The current implementation of modules has useful information about
> > > modules that represent a good basis for this.
> > > However, we need to:
> > > (1) add more information such as the corresponding CPE entry (Common
> > > Platform Enumeration of MITRE) or the attributes of reasonable attack
> > > classification (I suggest the one attached with this email)
> > > (2) think about importing such information into a backend DB. This
> > > will facilitate the selection process as well as allows establishing a
> > > link with CVE, OSVDB or CPE detailed data easily.
> > >
> > > Best regards,
> > > M GAD
I totally agree.
We need also to add the opcode in the exploit module, because a lot of
sploits modules only have the return adresses, and we have to search
what the opcode is... time consumming....
I add a "reverse research" functionnality in MSF-XB, so if the return
address is found in the MSF-XB's local db, it give you the opcode, and
so, you can then use MSF-XB to search the same opcode/ret address for
the target OS/locale/SP.

Thanks for your feedbacks
Regards & take care

/JA