"Kristofer T. Karas" <[EMAIL PROTECTED]> writes: > I still like the algorithm I had posted in response thereto: > You have as optional parameters to recv() "min", "max" and "expr".
I thought about it but it is not good... I don't think that something that exits as soon as we match a determined string (or even regex) would be very useful, because if we don't speak the right protocol, we will wait until the timeout for an answer that will never come. The problem is rather to exit quickly if we don't understand the output. So the greatest way to implement it would be to give a regex that *must* be matched. This would cover most cases. i.e., as soon as we are sure that the regex cannot be matched, we exit. Examples: if the regex is something like '^a.*b', we can exit on the first character if it is not 'a'. But if it is '^.*abc', we exit as soon as we find 'abc' (this cover your example) Implementation: 1. The regex must be "compiled" once, for obvious performance reason 2. We must be able to determine if the output hasn't any chance any more to match the regex (the classical Unix regexp doesn't do that, AFAIK) And use is probably not easy too. But all this is nothing (I can read my good old books on machine & language theory and design some nice algorithm, or hack the existing regex library. This will remind me of the good old time when I was young and my brain faster than now :) The biggest problem is not in those technical details. I wonder how many protocols can fit this model... Very few, I'm afraid. Take HTTP: it just doesn't work. You must parse the Content-length header and read that many bytes. This cannot be expressed as a regular expression. The headers can be expressed as a regex, but this does not help much. If you connect to some server that spit out a few chars, or just say *nothing*, you'll wait forever for the end of line. And here is the worst problem: *many* services say nothing if you do not speak the right protocol. I thought of something else: split Services/unknown into Services/mute (those which does not answer anything to the "GET" request from find_service) and Services/talkative But even this may not help much, as probably 99% of the unknown services will fall into Services/mute :-( I think that we have to try. As soon as Renaud opens a unstable "devel" branch, we'll be able to commit much infamous & dirty code to the CVS repository :-] -- mailto:arboi@;bigfoot.com GPG Public keys: http://michel.arboi.free.fr/pubkey.txt http://michel.arboi.free.fr/ http://arboi.da.ru/ FAQNOPI de fr.comp.securite : http://faqnopi.da.ru/ - [EMAIL PROTECTED]: general discussions about Nessus. * To unsubscribe, send a mail to [EMAIL PROTECTED] with "unsubscribe nessus" in the body.
