Excellent response Robin. I know you just helped me with a few ideas and I didn't even ask the question.
Thanks, Frank > On Dec 3, 2013, at 4:58 AM, Robin Wood <[email protected]> wrote: > >> On 30 November 2013 13:43, Glen Roberts <[email protected]> wrote: >> Any recommendations for a Linux tool-writing approach? I am more of a >> scripting guy than a programmer but I want to take it to the next level. >> >> For context, I need to write a few SANS gold papers for the Masters program >> and want to author some Linux tools related to the papers I write (subjects >> to be determined). I’m looking at this as an opportunity to improve my >> intermediate Linux skills while also adding some programming skills. I’m >> thinking of going with straight-up bash and maybe use some Python, Ruby or >> Perl but I would love to get some ideas from some of you experts before >> diving in. It would be great to learn how to make a UI that can run various >> back-end scripts. > > I've got a bit of experience here so hope this helps.... > > There are a few reasons I write tools: > > To automate an existing manual process - Wifi Honey came from a video > that Vivek did on SecurityTube where he talked about setting up a wifi > honeypot but did it all by hand. All I did here was to automate that > process. > > To improve an existing automated process - CeWL is based on a set of > one line bash scripts that I saw on PaulDotCom. I took the idea and > fleshed it out into a larger app. > > New ideas - These are fairly rare but I have had a few, Pat To Pass > and PassPat were both ideas I had for ways to analyse passwords. > > So I'd suggest looking around at what you and your colleagues do and > see if you can find something that can either be automated or > improved. Pick something in an area you are interested in even if you > know nothing about it. Don't pick something in an area just because > other people think it is cool, if you don't enjoy the subject you > won't do a good job on it. > > The tool can be iterative in its releases, the first version may only > have fixed options and do just a single job but then you can flesh it > out in the next few versions. If you think you might do this put a bit > more effort into v1 so that it can be extended, or, make v1 just a > throw away proof of concept so you don't mind when you bin all the > code and just take the ideas into v2. > > For the GUI, I'd pick an existing tool and add a GUI onto that rather > than trying to write a tool and a GUI in one. The second approach will > leave you trying to learn GUI writing stuff on top of the tool and > you'll probably do half a job of both. Pick a tool that has a bunch of > command line options and give people an easy way to select them. If > you went for nmap for example, have macro buttons so with one click > you could do "-PN -p 21,22,80,139,445". That would save a little bit > of effort on the user's part. I like it when the GUI shows what the > command line that they are going to run will be, it means I can use > the GUI to learn how to use the CLI version. > > Hope that helps. > > Robin > > >> Thanks in advance for your help. >> >> >> Glen Roberts, CISSP >> @InternetGeneral >> [email protected] >> >> >> _______________________________________________ >> Pauldotcom mailing list >> [email protected] >> http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom >> Main Web Site: http://pauldotcom.com > _______________________________________________ > Pauldotcom mailing list > [email protected] > http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom > Main Web Site: http://pauldotcom.com _______________________________________________ Pauldotcom mailing list [email protected] http://mail.pauldotcom.com/cgi-bin/mailman/listinfo/pauldotcom Main Web Site: http://pauldotcom.com
