Re: LDAP library and scripts

[Patrik Karlsson <patrik () cqure net>]

On 2 feb 2010, at 18.10, David Fifield wrote:

> On Tue, Feb 02, 2010 at 09:56:51AM -0700, David Fifield wrote:
> > On Tue, Feb 02, 2010 at 04:22:08PM +0100, Patrik Karlsson wrote:
> > > I was hoping to do a clean split between asn1, ldap and snmp.
> > > Unfortunately the solution I chose sucks as once the libraries start
> > > registering their encoders, they do it, as you pointed out, in a
> > > global table. This wouldn't be an enormous problem IF there was NO
> > > overlap.
> > >
> > > But I wanted to split the ldap and snmp decoding/encoding into
> > > ldap.lua and snmp.lua and keep only the basic encoding in asn1.lua
> > > instead of mixing them together in the table decoder in asn1.lua. In
> > > order to achieve this, in the current design, they both need to
> > > register a decoder for the same tag. This is also the case for eg. the
> > > snmp library that encodes booleans as asn null values.
> > >
> > > So while the idea might have been OK to start with, the result
> > > obviously isn't, so we're kind of back to square 1 where I'll be
> > > needing to duplicate a lot of code from snmp.lua into ldap.lua in
> > > order to get it working.
> >
> > I still think making a clean split is a good design. There are other
> > ways to do it without mutating global state. For example, the encoding
> > functions could take an additional argument that is a table of custom
> > encoding functions. Or, you could instantiate individual encoder
> > objects, and each one of them could have its own table of custom
> > encoders. snmp would create one encoder, and ldap would create another.
>
> Another idea is that you don't need one all-powerful asn1.encode
> function. You could provide only lower-level functions, like
> asn1.encodeInt, asn1.encodeBoolean, asn1.encodeSequenceOf, and have
> snmp and ldap use those. Other libraries would contain any
> application-specific encoders that they need. (Of course what I'm saying
> about encoders applies equally to decoders.)
>
> David Fifield

I've re-worked the ASN1 library a bit in order to get rid of that nasty design flaw with the global state. I kind of 
like the "one all-powerful asn1.encode function" approach so I've kept it that way. 

The new design splits encoding and decoding into two separate classes inside the asn1 library. Any library or script 
that needs to do ASN1 encoding or decoding can instantiate an encoder or decoder and the register any custom decoders 
or encoders for that instance only. Sequence tags are no longer handled as decoders and therefore need to be registered 
using the registerSeqTag function. So registering a sequence tag (31) and a decoder (13) would look like this: 

tagDecoder = {}
tagDecoder["13"] = function( self, encStr, elen, pos )
        return bin.unpack("A" .. elen, encStr, pos)
end

local decoder = asn1.ASN1Decoder:new()
decoder:registerTagDecoders(tagDecoder)
decoder:registerSeqTag("31")

Decoding is done as usual (or almost): decoder:decode( data, pos )

I've tested the code using three small test scripts that run in a loop register overlapping decoders and decoding a 
fixed sequence of bytes. This would result in chaos with the previous design error but seems to work alright now. I've 
also tried to run my 2 ldap scripts and 6 snmp scripts in one go against a single server. This does also seem to work 
alright. But it's obvious that it needs further testing and review.

I'm attaching the ASN1 library and the other two making use of it (ldap and snmp).

Attachment: snmp.lua
Description:

Attachment: asn1.lua
Description:

Attachment: ldap.lua
Description:

//Patrik
--
Patrik Karlsson
http://www.cqure.net




_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/