Search Results

GSoC 2015 Mentor Summit wrap-up

The security guard attending the door (before)

The security guard attending the door (before)

I participated at the GSoC mentor summit as part of Openwall’s team during this year’s iteration. The summit took place 6-8 Nov in California, Mountain View at Google and it offers a chance for all GSoC participant orgs to meet up, exchange ideas and contacts, swag, drinks and chocolate and even PGP keys. It is also a good opportunity to talk with the Google peeps assigned with GSoC and suggest new ideas, resolve issues or congratulate their efforts.

Here are a dozen or so ideas that I walked off with from the summit, no particular order:

  1. GSoC is a lot of work, especially from just a handful of people involved with logistics/admin and likely another handful with development of the Melange suite. Be conscious of your non-critical communications and requests of Carol and company, less is better.
  2. Melange, the software behind GSoC platform is Open Source. How about applying the bad blood in regards to it on the source directly? If you’re a student, I think you can apply to Melange org.
  3. The program is here to stay. If anything, it will get bigger and with more money involved. Congrats to Google and shame on all the other big leechers who don’t seed anything back. This has side effects, more people know about it now and spam applications are an issue. Some orgs had dozens if hundreds of spam applications from India this year and most were targeted at the initial 500$ stipend. The only mitigation to this is increased attention to details from mentors and more careful evaluation of students before the program kicks off. If in doubt don’t accept. You’ll waste your and Carol’s time and Google’s bucks and deny another potentially more successful opportunity to another org, student. Yes, many orgs don’t get into GSoC.
  4. The student conflict resolution process, with the IRC meeting and all, is a pain for both Google and orgs, for many reasons such as time zones, speed at which it happens, lack of useful feedback. Automation and improvements to that process were discussed. An interesting proposal was the possibility to see if a student has already been accepted to another org right from Melange before you accept it to yours.
  5. Mid-term student turn over issues like dropping off the radar, throughput drops significantly, loss of interest somewhere half way, reveals commitment to another engagement not agreed upon beforehand, are all very valid reasons for FAILING. Also keep in mind that many (all) students lie before, during and after the program, either malign or benign in nature. If you have doubts, notice lack of interest, respect and time, give one strike, maybe two, then FAIL. GSoC is not a benefactor program doing charity.
  6. Another interesting discussion was the possibility of extending the community bonding period by moving the org application deadline to early as December and thus start with the student application, review and bonding early in the year and have a couple of months at hand for the student to introduce himself, get started on the project, show interest or reveal the opposite. I personally like this suggestion, since it could provide a much wider ground for careful evaluation and acceptance of students, despite increasing the commitment required from mentors and orgs.
  7. Keeping students involved after the program is an issue for all orgs. I think the previous point might help in weeding out students that are only interested in a summer gig, they do some work during the dead months of summer vacation, get paid and wash hands quickly after, very similar to an internship. I think GSoC aims a bit higher than this, but keeping students interested after the program’s end is really hard, it’s usually up to the student and his overlook for the Open Source community and the org he ends up with.
  8. At least 1 member from a total of 119 orgs participated this year, thus a couple hundred heads. Security projects weren’t that many, apart from Openwall, Nmap, The Honeynet Project, that I noticed. I got a chance to meet people from Nmap that I acquainted way back in GSoC 2011 while I was student with Nmap, a nice surprise for me. The orgs roster was diverse, ranging from Wikimedia, gcc, llvm, git to R, Python and *BSDs to CERN, Bioinformatics and Genome research. Very few people had previous knowledge of Openwall, John the Ripper or Nmap, imagine the raised eyebrows when you tell about John the Ripper. Once I’ve learned that lesson, I started using “Password security testing suite” and “Security for Open Systems” to introduce my self and Openwall (mentioning bcrypt efforts yielded a bit). No shame here, such is the state of the industry and by inference the Open Source segment (which is full of hackers), lots of code, systems, technologies, communities and people involved, but little to no attention given to security, a mere afterthought given the scale, economy and speed of the tech and info industry in its entirety. I take it as a reminder though, the minute you step outside the security bubble you find out that the community is not that wide or evenly spread, popular or interesting to much of the IT industry and audience.  I guess that’s why Openwall, Nmap are here in the first place, to at least attempt a swing at the current state of affairs and challenge the modus vivendi. Too much leeway here, I should expand this in a separate post.
  9. Google was really efficient in taking care of any needs for this 2 day summit(food, shelter, directions, transportation). This was an “unconference” where most of the talks were held by participating orgs and only a couple by Carol and the company. I even met some people from Nmap I acquainted with back in 2011 while I was a student contributor. The atmosphere was relaxed, casual, no rush between events, at least for the first day. On the second the majority of attendees had to rush to the Airport by evening and I think that subtracted from the experience and casual atmosphere for the first day. Maybe one extra day would have helped.
  10. It would have been really interesting and a pleasure to have some talks by Google employees, from different departments, on how they use Open Source for good or bad, what works and what doesn’t. This would have provided some badly needed perspective and real world use case scenarios that expand outlook and even possibly motivate the OSS geeks working for the most part in solitude.
  11. Google “owns” Mountain View so badly. Wherever you look there’s Google territory. You won’t see police cars patrolling the city but you will see Google Security black SUVs strolling all over the city.

This is it for now. I’ll follow up with a separate post to jot down some random thoughts regarding Silicon Valley and San Francisco.


Bruce, after the event

Bruce, after the event

Bruce, after the event (close up)

Bruce, after the event (close up)

Tagged with:

Johnny 2.0 (reloaded)


Johnny, the GUI interface for the popular John the Ripper password cracker has received quite some love this past summer in an orchestrated effort to pick it up and drag it beyond the stale 1.0 branch.

Johnny who

Johnny is the cross-platform Open Source GUI frontend for the infamous password security testing suite John the Ripper. It was originally proposed and designed by your’s truly in 2011 as a POC, then version 1.0 basic implementation was achieved by Aleksey Cherepanov as part of GSoC 2012. Nothing much else happened beyond the 1.1 fix release.

Johnny’s original aim is to automate and simplify the password testing/cracking routine across all major desktops with the help of the tremendously versatile and robust John the Ripper suite, as well as add extra functionality on top of it, specific to the desktop and GUI paradigms in contrast to the command line, like improved hash and password handling, multiple attacks and session management, easily define and test complex attack rules, visual feedback and statistics, all of it by building on the immense capabilities and features already offered by both JtR core/proper as well as jumbo flavors.

Johnny 2.0 reloaded

Fast forward to 2015, I finally got some spare time to turn my attention towards Johnny again in order to further the stated goal for Johnny in the previous paragraph. So I devised a fresh plan for developing Johnny further and reconsolidate the original mission. The development plan has turned into reality with the acceptance of Mathieu Laprise as a student coder for Openwall (the org behind JtR and many other cool projects) as part of this year’s GSoC iteration. The tasks in the roadmap were split between me and Mathieu and with help from my co-mentor Aleksey Cherepanov we proceeded to the actual work involved in rebooting Johnny.

Now that the summer has concluded, it’s time to draw a summary of the achievements:

  • Cross platform issues fixed across all latest versions of supported Operating Systems and desktops
  • The UI has been significantly revamped for improved usability, robustness and consistency and looks across latest desktop paradigms
  • Full translation and I18N support added (only French for now, contribute translations to your own language on github)
  • Attack session history and persistence, easier to define new attacks
  • Greater coverage of JtR core and jumbo functionality (fork, jumbo attack modes, hash format detection)
  • Improved input and output options (2john format conversion support, export to CSV)
  • Smarter Passwords table (ability to show hash format, filter, sort, include/exclude from attack)
  • You can now test passwords manually via the Guess button

Overall Johnny is faster, more robust, better looking and much more equipped and forward looking (code and internals wise) than the previous incarnation and resulted in a significant code/ui refactoring of the original codebase (maybe 80% rewrite). All of the goodness described above and more was delivered to users in three releases starting with a major version bump to 2.0 to reinstate the fresh reboot and outlook for the project. The latest release is v2.2 and is considered to be stable and feature packed enough to be called the official GUI for John the Ripper. There are binary packages for Windows and OS X and detailed source build instructions for the other platforms on the wiki page for Johnny, thus I urge you to give it a spin and leave feedback here, on Github (where the project is hosted and tracked) or on the john-users mailing list. As always, contribution of any kind is very appreciated.



Thanks to Mathieu Laprise for his important and dedicated contribution to Johnny as a student coder for GSoC 2015 and we hope to hear back from him from time to time. Big thanks to the entire john-dev community and Aleksey Cherepanov. Also an extended appreciation goes to Google for their continued dedication to support Open Source and contribute big bucks in the process.



Johnny on Ubuntu

Johnny on Ubuntu

Johnny on Gnome 3

Johnny on Gnome 3

Johnny on OS X Yosemite

Johnny on OS X Yosemite

Tagged with:


For the better part of the last half year I’ve been working on a Graphical User Interface for the popular Tarsnap online backup service. The frontend enables desktop users to benefit from the same advantages that the Tarsnap service offers, admittedly only at the command line interface. These benefits include:

  • cost effectiveness;
  • flexibility and control of your backup process;
  • total openness on the client side;

While the Tarsnap service is of immense efficiency and conveniency for server and scripted backups thanks to its Unix utility design, that same characteristic makes it a good choice for wrapping a desktop application with a graphical interface on top so that more users can benefit from truly secure and well designed backups as well as to easily define and use more complex backup routines from a comfortable and lean interface.


Tarsnap Setup Wizard


The application is cross platform, written in C++ with the help of the Qt SDK and is released under the BSD 2 clause license. It has been tested on OS X Yosemite, FreeBSD and most Linux distributions with a wide audience.

In the present state, the application makes it easy to:

  1. Configure Tarsnap on your system via a Setup Wizard;
  2. Make single shot backups from the Backup tab, for quickly putting some important files and directories at rest on Tarsnap;
  3. List, inspect and manage your backup archives from the Archives tab  ;
  4. Define frequent backups you attend to as a job from the Jobs tab; A job has custom backup paths and settings;
  5. Provides useful customizations and help via the Settings and Help tabs;

The current version is 0.5. There’s so much more to be implemented and ground to cover in both usability as well as Tarsnap options breadth and depth coverage. So stay tuned for further releases and announcements to this blog, @shinn0K, @tarsnap or the tarsnap-users mail list.

Project page and source code is available at GitHub:

Head over to this overview Wiki page for extra details regarding the current release. Also read the announcement e-mail on the tarsnap-users mail list.

As explained in the wiki page and the announcement e-mail, there are no binary redistributable packages for now, mainly because there aren’t any for the Tarsnap command line client either. This might change in the future though.

As with any Open Source project, I encourage you to participate via discussion, feedback, code contributions, bug reports, fixes and platform testing. Basically any type of constructive and informative contribution is very much welcomed.

Tagged with:

Blocking ads and trackers using HOSTS

If you’ve stumbled across this post, you’re probably familiar with adblocking extensions such as Adblock and uBlock(seriously recommend the latter for a handful of reasons) and most likely you’re in need of a solution to take back your network and system resources as well as a need for less clutter and more privacy in your daily web ventures, however, this method for blocking ads at the browser level only tends to be quite inefficient and fairly limited. Wouldn’t it be cool to also have ads and trackers blocked at the system level, including but not limited to applications like Skype, uTorrent, IE(seriously?) and other browsers or the many shareware/freeware apps that track your usage via mechanisms like Google Analytics(some use exactly that for tracking).

The solution is fairly simple, we’re going to use a simple hostname based block list to map undesirable domain names to either or In my testing on OS X, I found that works best, that might not be the case on different operating systems. The blocking is done via the ages old hosts(5) unix file, but still very useful mechanism for easy static ip-name mappings at the host level.

The current block list that I use is hosted at I’m not affiliated with that site and don’t know who is providing it, that being said I use git to track and review changes between updates. The list is quite exhaustive, combining lists from several other sources cited in the header. I’d like to see a couple more lists combined like that from several other places(mainly the ones from uBlock would be useful), but you can then add extra lists by modifying the script fairly easily.

Now the script itself, is hosted on Github. Please read the entire script and what I’ve written bellow before running the script on your system.

Before you go on and use the script on your OS X, I really encourage to start using git in your /etc/ directory. The script won’t even work without a git repo in /etc/, unless you know what you’re doing and you’re going to modify it to bypass that. Having a git repo in your etc directory gives you revisioning, rollback, beta-testing, review and scrutiny abilities to whatever you’re doing to your etc. I do this on my workstations, laptops and servers that I manage. The added git overhead on your daily etc routines is insignificant when compared to the benefits you get when you most need them.

The script is smart enough to not break your current system. What it does as part of the first time run initialization is copy your current /etc/hosts to /etc/hosts.d/hosts.1.head. All your existing localhost rules and custom rules will be maintained there. The adblocking rules will go into /etc/hosts.d/hosts.3.adblock. You can add custom mapping rules(for staging servers, local network mappings) to  hosts.2.custom.

Then each time the script updates it will do the following:

  1. Update hosts.3.adblock with the latest rules from upstream;
  2. Concatenate the rules in /etc/hosts.d in the numeric order to your /etc/hosts;
  3. Show you a git diff of the changes and the option to commit those changes or deny to review, undo or commit yourself using git;

The script also has some pfsense blocking rules from and some custom ip blocking enabled in /etc/pf.rules/ This is disabled by default, you can enable it by setting the PFSENSE var to “true” or passing -f as argument. If you know of some other worthy and fresh ad/malware ip lists let me know.

Although my script is OS X only, it’s fairly easy to port it to any other UNIX system(I welcome patches to the main script via Github), having such a solution for the Windows platform would be cool too. Maybe someone reading this can weigh in with their solution or insight? Would it work fair enough, is cygwin the only way for automating this? Nonetheless, stay tuned, since I have a similar router solution(AsusWRT, DD-WRT) coming up soon, that steps up the game a notch and provides blocking for your entire network, though it surely doesn’t deprecate this host level solution (on a laptop for e.g. that is frequently switching networks).

Pros for this setup:

  1. Easy setup and update (when compared to a firewall or a custom dns);
  2. Cross-platform and cross-application solution;
  3. Faster and less intrusive(also no https mitm) than proxy solutions(such as Privoxy);
  4. Easy to temporarily disable: just cp /etc/hosts.d/hosts.1.head /etc/hosts and to restore git checkout /etc/hosts;


  1. On some operating systems hosts files with tens of thousands of rules might slow name resolution up to a certain degree. In my usage with over 50000 rules, OS X and Linux is quite fine in that regard. If you find that such is your case, maybe using a dns server or firewall rules is better for you;
  2. Some blank spaces, containers, divs or unresolved error messages will take the place of the ads themselves in sites and apps that don’t handle failure very well. You can get rid of the browser related blanks at least by using uBlock extension with just the cosmetic rules enabled(in the extension Settings);
  3. Related to the previous one, you might experience some failures in certain web related functionality(fairly limited though). Most of them will be social related or news sites that use ad nag pages before they redirect you to the article content itself. Personally I don’t care about them and as soon as I hit such a road block I close it and move on. The benefit of more resources and network bandwidth for my system as well as the increased privacy and less clutter in general, totally trumps any minor drawback like this;
  4. The script relies on the links(1)(or elinks) tool to parse the html page at and extract only the text. On OS X I use homebrew to install additional tools that I need. If you have a better solid solution that relies only on coreutils or other commonly installed shell utilities let me know;



Tagged with:

How motherboards are assembled

Just a couple videos showing a sneak peak into the steps involved in assembling a motherboard that I find interesting:


Alternative to the finger Unix command

Every once in a while I stumble on this question on yet too many forums and Q&A sites:

Is there an alternative to the finger command?

The simple answer is yes! There is an official replacement for the original finger command and it’s part of the gnu coreutils package, it is called pinky(1) and it’s available on all systems that use the gnu coreutils.

The long answer is, no, there isn’t really a real replacement to the original remote enabled finger protocol along with the fingerd daemon and finger client. While it did make sense and has seen its fair share of usage in the early days of the Internet,  it has been considered obsolete and a security issue for way over a decade now, thus all of the modern Linux distributions and Unix flavors don’t install the service nor the client by default anymore, some don’t even include them in their repositories at all.

So now, most of the replacement tools and commands that one can use instead of finger are going to act on the local machine only and provide logged in user info only for the current host. One such tool is pinky of course and it’s output similar to:

$ pinky
Login Name TTY Idle When Where
shinnok Shinnok pts/0 2013-09-18 07:32
andy        Andy pts/1 2013-09-18 07:32

As you can see the output is pretty similar to the who(1) command(it was actually ported from who.c), nothing special about it. The other traditional alternatives to the finger command include w(1) and users(1).

Tagged with:

Tingling the nerd in you

Infosec and devops can be fun, with the right mindset, so take a step back and appreciate it: