Introducing Encoding Tools

If you are a programmer, pen tester, or reverse engineer, you probably find yourself needing to manipulate data between various representations, such as URL encoding, base64 encoding, etc. There are a lot of web sites and utilities to do this sort of thing interactively, but I’ve never been totally satisfied with any of them.

So… I built my own! Today I am releasing Encoding Tools, an open source, browser-based utility for transforming text and binary strings.

Motivation

There are a few websites out there that do various types of encoding/decoding tasks with domains like urlencode.org or base64decode.org (pretty on the nose!). Most of those sites require a round trip to a server and only handle one codec each. I would rather have one tool that can handle many codecs, especially so that I can chain together multiple transforms, e.g. base64 encode followed by URL encode.

It would also be great if the encoding could be done on my local machine to avoid the latency and privacy concerns of sending everything to a server. There are a few utility programs that can do this sort of work locally. The best one I know of is built into Burp Suite:

Burp Decoder has some drawbacks. For one thing, Burp Suite is a behemoth and I don’t usually want to load the entire application just to base64 decode a string. The Burp Decoder also has some awkward UX, like not showing what the currently applied encoding is or arbitrarily removing some (but not all?) outputs after you edit the input.

Solution

Encoding Tools runs in the browser, so you don’t need to install anything. All transformations are done locally, so there is no network latency and your data does not leave your machine. And I went for broke on a brand new UX that is easier and more flexible.

Let’s take the Burp Decoder scenario from above and run it through Encoding Tools.

This screen capture shows the basics: each transformation is abstracted into a “gadget”, and the user can connect gadgets together to create flexible transformations. The example above shows a chain consisting of input → base64 decode → url decode, but the tool supports any arbitrary tree structure:

These two examples should give you a good idea of what this thing is, so go try it already! The URL is https://encoding.tools.

Tech Stack

This wouldn’t be a real nerd post if I didn’t talk about the tech stack. As I mentioned above, this all runs in the browser. There is no server-side application logic. I loathe JavaScript (and I am several years behind on its latest features) so I wrote Encoding Tools in Dart, which is a language created by Google that transpiles to JavaScript. I’ve been using Dart on work projects for over three years now and I really enjoy it. It’s loosely inspired by Java but has optional static typing and a load of other developer-friendly features and syntactic sugar, and it avoids many of the misfeatures of JavaScript.

Once I locked in on Dart, that made my choice of frameworks pretty simple. Dart’s biggest application framework is AngularDart, which is related to AngularJS and offers very similar concepts and APIs. However, after a few hours of trying to implement my idea in Angular, I realized that Angular’s abstractions (e.g. the component tree) are not a good fit for the Encoding Tools GUI. I researched some other Dart frameworks but couldn’t find anything that I fully trusted, so…

I decided to not use an application framework!

Did the sky just turn black and thunder shake the heavens? Yes I know, we are living in anno domini MMXVIII and there are 2.53e6 web application frameworks in existence, and surely one of those must be suitable for the task at hand and only an insane person would decide to write a non-trivial application without one, right?

Well, since Angular wasn’t going to work and I don’t want to depend on a framework that has just one committer working in his/her free time, that didn’t leave me with many good framework choices. On the other hand, I can leverage Dart’s awesome standard libraries (including a DOM API that is more intuitive and consistent than JavaScript’s) and roll my own low-level abstractions that have exactly the features I need.

If you want to read the source code, it is licensed under GPLv3 and hosted on GitHub.

Since I do not have any server-side application logic, the application is statically hosted on Amazon S3 and distributed through CloudFront (the Amazon CDN). This is the same deployment that I use for this very blog you’re reading right now, so I knew it would work well for this application and—better yet—I didn’t need to learn any new technologies to deploy this sucker. This configuration also keeps my hosting costs low (a few dollars per month) and eliminates the time and energy associated with managing production infrastructure.

Future Plans

At the beginning of 2018 I had some down time at work and so I finally read a book that has been on my reading list for a few years: The Lean Startup by Eric Ries. Like many other computer nerds that discovered this book, it inspired me to rethink how I create software. Now to be clear, Encoding Tools is not a tech startup. It is open source software, I’m doing this for fun, and I am hosting it on my own dime. But I want to use this project as an opportunity to practice lean techniques, which is a very roundabout way of saying that Encoding Tools is in its very, very early stages:

Releasing the software at this point is difficult for me. I know it has bugs. I know it is lacking spit and polish. I wanted to refactor the source code before publishing it. I have at least 30 features I want to add. But if there is one central lesson gleaned from Lean Startup, it is validating ideas before investing too much time and money into them. Sure I have 30 features I want to add, but that might take 300 hours of work and are any of those features actually valuable to anyone else in the world? I would rather focus my time and energy on the features that real users will benefit from, and I need feedback and usage data to make those sorts of decisions.

There are a bunch of feature ideas and bugs on the issue tracker, but before I write more code, I am going to spend time on marketing, interaction metrics, and validating the project’s key assumptions. I am keeping track of my hours (48 total) and my out-of-pocket costs ($29 for a domain name). I will share what I learn as I go through this lean process.

Hit me up on Twitter if you have feedback or follow me for project updates. This blog also has an RSS feed if you want to subscribe to project updates. If you have feature requests or bug reports, please create an issue on GitHub. Thanks for reading!