Re: Lexmark script

[Patrik Karlsson <patrik () cqure net>]

On 23 jan 2010, at 01.32, David Fifield wrote:

> On Wed, Jan 13, 2010 at 08:45:43PM +0100, Patrik Karlsson wrote:
> > > The script looks good, but I want you to see if you can make it work
> > > using the dns library. If the dns library lacks some feature that you
> > > need, it better that we improve it centrally there.
> >
> > I've modified the script to make use of the dns library and reduced
> > the code considerably.
> > It required another small patch to the dns library as the printer did
> > not properly populate the question section of the response. I'm
> > attaching this patch as part of the other patches I did to the dns
> > library for the dns discovery script. 
>
> I committed your dns.lua patch.
Thanks.
> > > Looking at the script, it doesn't seem that the protocol uses multicast
> > > DNS, or is any variant of Bonjour/Rendezvous/Zeroconf/DNS-SD. It looks
> > > to me like a simple proprietary protocol using DNS as a transport. If
> > > that's so, we can name the service hbn3, like we do for some other
> > > protocols that run over another protocol.
> >
> > the script should be naming the service as hbn3 now.
> >
> > > Does the printer have the same service on 5353/udp? If not, then the
> > > script shouldn't run for that port.
> >
> > I've removed the 5353 port support as the printer does not have the
> > same service there.
>
> I'm confused. In the new version of this script, the portrule lets the
> script run when port 9100/udp is open, but then goes on to send a probe
> to 5353/udp. Which port is the service you're querying running on? What
> do you get when you probe port 9100 directly?
>
>       portrule = shortport.portnumber(9100, "udp")
>       local response = try( dns.query( "", { port = 5353, host = host.ip, dtype="PTR", retPkt=true} ) )
>
> Your previous portrule would have allowed the script to run if either
> port was open, and I'm confused about which port was really being
> targeted.
Sorry for the confusion. Now, that I've looked at it closer, it works both against 9100/udp and 5353/udp. I have 
updated the script on my blog to work with both.

> I know I said that the protocol didn't look like DNS-SD, but it's
> strange to run something on port 5353 that's almost but not quite
> DNS-SD. What does dns-service-discovery sa about this device, if
> anything?

The dns-service-discovery script does not work because it contains a query.  The query section must be left empty in 
order to trigger a response.  The service will also trigger a response when it receives the NTP probe which doesn't 
decode as a DNS-SD packet either. I previously tried to make the NTP probe shorter in order to find what triggers the 
response and was able to remove a few bytes from the NTP probe and still receive a response. So, basically your right 
the query doesn't look all that DNS-SD even though what the script is sending is basically DNS-SD with an empty query.

Again, sorry for the confusion.

//Patrik

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

--
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/