Nmap Development mailing list archives
Re: backorifice-info
From: Gorjan Petrovski <mogi57 () gmail com>
Date: Wed, 20 Apr 2011 04:41:15 +0200
Hello, 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.try(socket:bind(nil,1025))Is it necessary to bind the socket? Can you just let the OS choose a port?
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="", filter=function(data) return string.gsub(data," ","") end }, ... } (Or, define named filter_* functions and refer to them by name in the table.)
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 == TYPES.PING.
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
Description:
_______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- backorifice-info Gorjan Petrovski (Apr 11)
- Re: backorifice-info David Fifield (Apr 18)
- Re: backorifice-info Gorjan Petrovski (Apr 19)
- Re: backorifice-info David Fifield (Apr 20)
- Re: backorifice-info Gorjan Petrovski (Apr 20)
- Message not available
- Message not available
- Re: backorifice-info Gorjan Petrovski (Apr 25)
- Re: backorifice-info Gorjan Petrovski (Apr 19)
- Message not available
- Message not available
- Message not available
- Message not available
- Re: backorifice-info Gorjan Petrovski (Apr 25)
- Re: backorifice-info Patrick Donnelly (Apr 25)
- Re: backorifice-info David Fifield (Apr 18)
- Re: backorifice-info Toni Ruottu (Apr 20)
- Re: backorifice-info Gorjan Petrovski (Apr 20)
- Re: backorifice-info Toni Ruottu (Apr 20)
- Re: backorifice-info Gorjan Petrovski (Apr 20)