Future plans for Inguma development

All right.  After the revelations two days ago about Inguma visiting us from the grave, the next thing is to make a bucket list of what needs to be done.  In a somewhat-ordered list of most to least important, this is what I'd like to accomplish:

1. Port Inguma to GTK+3 + GObject:
• Inguma is written in PyGTK + GTK+2, which has ceased development several years ago.  GObject is the new introspection from the GTK+ project which allows to allow the usage of language bindings for any library using it without having to rewrite things when the library changes.
• This should help us keep an easier install procedure for MacOS and Windows.
2. Port Inguma code to Python 3:
• While we were not looking, the world has finally moved to Python 3 and things like xdot.py are actually now GTK+3 and Python 3.  This is dependent on third-party code living in the tree or external dependencies that are only in Python 2.
3. Remove years-old cruft from the tree:
• Inguma has accumulated a fair amount of old code (pyew, krash, fuzz, scapy, pyshellcodelib, etc.) that it's either plain old and outdated or that has been getting updates in all this time.  Spring cleaning it is!
4. Remove Bokken from Inguma:
• Sadly, Bokken is not usable now with radare having evolved on its own for a few years now.  We will need to revisit that at a later stage.
5. Hide funtionality until it's battle-tested:
• In the open source world, there's always a debate about whether you should release early and often with incomplete functionality, or shipping only features that work well in a variety of environments and that are not going to crush those testers with very high hopes.
• Given that our development time is limited, I prefer to stay with a product that shows only stable features, and instead of removing lots of code that could potentially need to be added later, for now just hide everything else behind a config or runtime flag so we don't confuse new users with broken stuff everywhere.
6. Make documentation great again:
• We lost the wiki, but even if I'm able to recover it, I'm not sure if a wiki is the best way of keeping documentation updated.  I'm thinking about generating it automatically for specific versions so it's easier to change and upload.
7. Make modules...modular:
• The list of actions that you can make with a graph is very limited and hardcoded in lib/ui/target_dialog.py and lib/ui/graphMenu.py (if I'm not mistaken).  In order to make Inguma a proper open-source intelligence client, the list of transforms (borrowing a term from Maltego) has to be extensible and modular, and move away from the actual node-as-IP paradigm.
8. Ignore (or delete) the text-only Inguma client:
• For those of you who don't know it, Inguma started as a text-only application until Hugo built the UI in PyGTK.  Having to maintain both is beyond my expectations at this moment, so if you use it and it goes and eats your grandmother, don't come whining.  Take this as my one and only warning.
9. Fix the terminals code:
• It's broken (or it will be) when anything of the above happens.  It was already brittle and it doesn't like to be disturbed, but it's not a priority to really fix it.

All the above said, I would like to release a couple of versions in technology-preview mode just to make sure that anyone who wants to test it has a good starting point.

Inguma is back, and due team update

As we are approaching Halloween (in the United States, at least) I find quite amusing to announce at this time of the year that Inguma is back from the dead, one more time.

If you like to know the nitty-gritty details about what happened and where we are going, keep reading.  Otherwise:

TL;DR: The Inguma code is now in Github, and we are pivoting it to become a general purpose OSINT tool.

Still here?  Oh, my, you seem to be of the masochistic type.  Let me add some history bits about the project as well.

So...

• The development team (literally these two dummies writing the blog) is still alive.  No doubt on that.
• We lost the server that hosted inguma.eu, bokken.re and the rest of the domains, the Mercurial repository, the wikis and everything else.  We are still in control of DNS and everything but it will take the undersigned (i.e. Ender) some time to come up with a web server, mail server and the rest.
• Hugo and I have been very far from each other, and not exactly with a lot of time in our hands.  Life changes made things more difficult.  Bokken, the only piece of the project that was still moving forward, became obsolete (more on this later).
• I was not working as a security professional when I started helping with the project.  Since then, many things have changed and I have been working as such for the last 6 years.  Needless to say, I see the world in a different way now.
• Inguma was a project that Hugo inherited from hacker extraordinaire Joxean Koret, which was console-only, and which Hugo converted into a dual console-PyGTK application. Bokken, a UI around the reversing framework Radare, was then started around 2011 in the same fashion (a PyGTK application) using the radare Python bindings due to radare being console-only.  We saw the potential to merge it with Inguma in some way, and Bokken became the reversing engine in Inguma apart from being an standalone application.
• Somewhere in 2015 the Radare team expressed that they would like to use Qt and Hugo remade Bokken in a matter of weeks in C++ and Qt as a new project called iaito.  Some time later, the Radare team decided to stop using it and they adopted it into their Github repos as Cutter.
• At the same time, Inguma hadn't seen a commit since 2012.  We were very focused on making Bokken a success, and working in a codebase that was as disorganized (due to its long, organic growth) as Inguma was a barrier.  I wanted to add an HTTP server, proper modules, unit tests, move it to GTK+3, and many other things, but ended up putting only half of the work needed for every one of those things.  A true love-hate relationship.
• At the same time, Hugo had started using Inguma as the base for several personal modified versions with airplane modules for his talks about airplane security (after all, he's a recognized world expert on that field).  He was using it mostly as a pen-testing framework and was reasonably happy with it.
• So fast forward, and we then lost the server with everything.

And then, several weeks ago, I started to look for free software replacement for Maltego, the Open Source Intelligence program.  And do you know what?

There's none.

I thought of using my experience with Inguma and Bokken to write something simple in GTK+3.  After a couple of tries, I dug into my hard drives and I found my Inguma checkouts.  I realized that I had pretty much everything I needed: a modern UI, most of the heavy work that an interface needs, and a graph engine based on Graphviz.  I could just reuse some of the parts.

Long story short, I talked to Hugo and, while he seemed a bit reluctant at first, I managed to get him excited about reviving Inguma and converting it into something... different.

So that’s it. I’m dropping a lot of the old cruft in Inguma that has been outdated since 2012 or before, bringing it up to speed regarding modern codebases, removing (for now) some of the exploiting/terminals/reconnaissance UI, and adding a lot of features to be able to work as a OSINT manager.

See you out there.  It’s going to be great.