Home page logo

nmap-dev logo Nmap Development mailing list archives

Re: backorifice-info
From: Gorjan Petrovski <mogi57 () gmail com>
Date: Wed, 20 Apr 2011 04:41:15 +0200


Thanks for the reply, the script is now much more readable :-)
You will find the updated script attached to this mail and comments
below the quoted reply.

I've looked into writing a backorifice-brute script, which would
actually initiate the backorifice-info script by identifying the
service. The thing is that backorifice-brute would not search for the
password to the service, instead it would search for the initial seed.
This is because of the encryption algorithm: First, an initial seed is
generated from the password and every next seed is generated from the
initial seed and has no other correlation to the password. So in order
to break the encryption, only an initial seed is necessary. The set of
values for an initial seed is much smaller than the set of values for
a password. That is why backorifice-brute will search for an inital
seed and pass that to backorifice-info. I've modified backorifice-info
to work with that initial seed if it has a value even though I haven't
written backorifice-brute yet. You could wait until I write
backorifice-brute, or add it now, it will work either way.

Some things:

Add documentation for the script argument.


Is it necessary to bind the socket? Can you just let the OS choose a

Indeed it is NOT necessary to bind the socket. I saw the windows
client always communicate using that port, but the unix client used
whichever port the OS appointed. I have removed that line.

I like the system you have of keeping the commands to be run in a table.
But put the filter functions in the table too, so they don't have be
kept in sync:

       cmds = {
               {cmd_name="PING REPLY", p_type="TYPE_PING", p_code=0x01, arg1="", arg2="",
                         return string.gsub(data," ","")

(Or, define named filter_* functions and refer to them by name in the

I have included them in the table, as you can see from the updated script.

You don't need to have an initialize_globals function. Just make your
globals top-level local variables.

I thought that I would have some processing to do when the script is
initialized in order to set the globals. That is not needed now with
the cmds table reorganization.

I think you can get rid of some redundant information in the commands
table. Instead of this:

       cmds = {{cmd_name="PING REPLY",p_type="TYPE_PING",p_code=0x01,arg1="",arg2=""}, ...}

you might do this:

       TYPES = { PING = 0x01, ... }
       CMDS = {{ p_type = TYPES.PING, arg1 = "", arg2 = "" }, ... }

Then, instead of checking cmd_name == "PING_REPLY", just check p_type ==

I kept these strings in the cmds table so it would be obvious that the
source code for the client was used while writing this script. I
thought that would be beneficial, but it only made the script more
chaotic. Now it's much cleaner.

Instead of using a global "rand" variable to track random number state,
make mrand take a parameter (the current seed), and return the new seed.
Make the seed local to the BOcrypt function. Let BOcrypt do the
(seed >> 16) & 0xff calculation, not mrand.

Done. The function msrand is gone now, initial seed is calculated by
gen_initial_seed() (previously getkey()), every next seed is
calculated by gen_next_seed() (previously mrand()). Why I kept these
cryptic names and globals? -Because they were used in the source code
of the unix client. Unnecessarily. (as above)

How do we handle lines that are too long to be printed into terminal
(longer than 80 chars)?
I cut long lines at about ~75 chars and added a "  ..." at the
beginning of the new line so output looks like this now:

I wouldn't worry about this too much. Just print the long lines, unless
you expect them to wrap three or four times.

I don't think they'll be more than two lines. I've removed the string
split from the previous version of the script. It's normal output now.

Best Regards,
Gorjan Petrovski

Attachment: backorifice-info.nse

Sent through the nmap-dev mailing list
Archived at http://seclists.org/nmap-dev/

  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]