Re: backorifice-info

[Toni Ruottu <toni.ruottu () iki fi>]

Are you planning to try all seed values? Would it make sense to
generate a table that has one password for each seed value, so you
could return that password to the user when you find the correct seed?

On Wed, Apr 20, 2011 at 5:41 AM, Gorjan Petrovski <mogi57 () gmail com> wrote:
> 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
>
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://seclists.org/nmap-dev/
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/