On Sat, 2010-02-27 at 16:21 +0530, Chandrashekhar B wrote:
> Hello,
>
Hi :)
> What others apart from DCERPC/SMB do you think are inadequate? It'll be
> useful information to list them all somewhere.
Some of the protocols I dealt with: NFS and SUN-RPC, netbios is
scattered all over the plugin repository (maybe a netbt.inc?).
> Nice idea! I agree that the current facility available through smb_nt.inc is
> inadequate to write some of the SMB and RPC checks. We had discussed this
> during last DevCon and the idea that emerged was to integrate low level
> Samba functions into OpenVAS space.
I lack the experience to weight the pro and cons when it comes to
integration into NASL vs implementation in NASL. I presume you don't
want NASL to gain too much weight unnecesary, on the other hand
reinventing the wheel is not always the best approach. My only ground in
this matter is the approach that other scripting languages take.
> If you think it is possible to write .inc based on Impacket or MSRPC
> implementation of Nmap, it would be the way to go.
I am aware of the fact that NASL lacks certain capabilities, such as OO
paradigm, various high level data types. Sure that this kind of
extensions to NASL would mean a great deal to NASL developers to make
state of the art scripts. But lets do the best with what we've got, and
if the time comes for NASL to evolve in such a way, c00l.
Answer to your question...definitely!
To that point, I wish to state that there is a need for introducing
certain design guidelines, patterns for "inc" development. The purpose
of which is, of course, better code quality and speed up of plugin
production. Let me demonstrate my thoughts with a brief example:
Consider the SMB protocol...First I would implement a smb-packet.inc. In
this inc you could find "build_" and "dissect_" methods for easy SMB
packet crafting (like in Perl::Net). This "-packet.inc"s would represent
a ground for protocol operations implementation, also if making some
exploit on that particular level the creation of vuln packet would be
easy and nice. The next step is to implement the actual protocol in a
"smb.inc". As said before, this inc would include("smb-packet.inc") and
would heavily rely on that particular inc. Here you could find protocol
specific methods which provide a adequate abstraction level for the
programmer/user.
This is just a rough outline. Also we should consider naming
conventions, which data types to use etc..
I've looked how other languages do it, and sure they have an advantage
(OOP), but I don't see why we can't make NASL even better. :)
Your opinions?
Thanks,
Dražen.
--
Laboratory for Systems and Signals
Department of Electronic Systems and Information Processing
Faculty of Electrical Engineering and Computing
University of Zagreb
_______________________________________________
Openvas-plugins mailing list
[email protected]
http://lists.wald.intevation.org/mailman/listinfo/openvas-plugins
