Persistence Labs is Shutting Down

(tl;dr: See the title =) Development costs are exceeding revenue. If you own a licence to SemTrax, firstly thanks for your support, and secondly you should have already received an email plus a full refund. If not, get in contact! I'll be returning to writing on my personal blog.)

Most people that have worked as reverse engineers and security researchers for a while have a long list of tasks for which they would like better tool support. In late 2012 I decided to make a dent in my list and started Persistence Labs. Seeking external funding was not an appealing route for various reasons, so initially I used consulting and training to fund development of tools for personal use, as well as developing software for private clients. This model worked well, provided the opportunity to teach and meet a lot of great people while also providing plenty of time for research and tool development. 

While I enjoy consulting and training, what gets me up in the morning is analysis, engineering and learning. With that in mind, in early 2014 I decided to bring on board another couple of engineers and start turning towards building a product-focused company. Over the course of a year we prototyped, tested and eventually released SemTrax. The commercial goals for SemTrax were straightforward: to fund its own development, and ideally to fund R&D on alternate projects. Anyone familiar with the reverse engineering tools market will tell you this was always going to be a difficult objective to achieve (and possibly a naive one ;)). That said, sales were initially strong and SemTrax covered its own development expenses during the first couple of months (while the official release of SemTrax was in June we made it available to subscribers to our mailing list in February, and it turns out that constituted a fairly large proportion of our customers).

That's the good news. The bad news is that unfortunately for the past few months SemTrax sales have tapered off. The problems that SemTrax addresses are non-trivial to solve and expensive in terms of developer time. There's an easy-to-calculate number of sales we need to hit per month in order to progress and we're not hitting that, nor does it appear likely that we will any time soon. While I considered reverting to the role of full-time consulting and training in order to fund development, this would have a detrimental effect on the product side of the company. Fulfilling all of these roles myself is a reasonable strategy when the software being produced is for a low number of private clients, or for myself. For a public, commercial product though I believe customers have an expectation of quality and focus that is unlikely to come from having a project lead spread thin. 

So, with the writing on the wall I have decided to refund all of our existing customers of SemTrax and to close down Persistence Labs. It's been fun, we've built useful technology, I've learned a lot, but now it's time for something new. I've yet to decide what will become of SemTrax; I would like to find some way to put it in the hands of anyone who wants it, but I'm not a huge fan of the "throw it over the wall" model of open-sourcing. Once I've figured that out I'll post an update on my personal blog.

In conclusion, thanks to all of our customers for their support, to Gabriel (the other primary contributor to SemTrax) and to the various friends who have provided advice and assistance over the past 3 years. Onwards!

Dynamic Taint Analysis in your Debugger! (SemTrax is now available)

Good news everyone! I'm very happy to announce that SemTrax is now available*. For all the details see semtrax.io, but in short: SemTrax adds dynamic taint analysis to your debugger, and by doing so it can make things like crash analysis, bug hunting, reverse engineering and plain old debugging, much easier. Built on our custom program analysis technology and integrated with the IDA static analysis platform, SemTrax can greatly increase your productivity when analysing complex software.

Over at semtrax.io there are a number of resources which should give you a feel for what SemTrax is capable of, including:

If you'd like to purchase a licence for SemTrax then check out semtrax.io/buy for licence options and pricing information. We're offering 15% off the listed prices for this version as a "Thanks!" to our early customers.  

One thing not addressed in the above is "What's next for SemTrax?". On that topic: one of our highest priorities is naturally x64 support, which should make it into the next release. We're also planning to overhaul the instrumentation process used to gather data for SemTrax to analyse, with the aim of decreasing the performance overhead on the target application. GDB support (as an alternative to IDA's debugger) is also on our to-do list. Of course we're always open to feature suggestions so if there's anything you'd like to see in SemTrax then drop us a mail!  

- Sean (@seanhn)

For the past 3 months, SemTrax has been available to our mailing list subscribers and I'd like to thank those early customers for their support. Prior to this we spent several months in beta testing and I'd also like to thank everyone that participated in that. Without both groups SemTrax would not have been possible.

Introducing SemTrax: A tool for semantics-aware, runtime dataflow tracking & visualisation on binary software

At Persistence Labs our goal is pretty straightforward: to make great tools motivated by real problems. One such problem, pervasive in software analysis, is dataflow tracking and visualisation. For the past year we've been working hard on exactly that and I'm pleased to introduce what will be our first product: SemTrax. As the title says, SemTrax is a semantics-aware, runtime, dataflow tracking and visualisation tool, designed to answer two fundamental questions:

  • Given a data source, what operations and sinks can it influence?
  • Given a data sink, what sources and operations contributed to it?

These questions are key in many tasks across debugging, vulnerability auditing, reverse engineering and exploit development. For example, tasks we've used SemTrax to help with include triaging memory corruption, tracking down dangling pointers, and attack surface identification. 

We'll have more details early next year, but for now if you'd like to see SemTrax in action check out the following video! In the meantime you can sign up to our mailing list if you'd like to keep up to date. Also, to participate in our forthcoming early access program contact products@persistencelabs.com for pricing information. 

Here's a screenshot for good measure. What you're looking at is SemTrax responding to a user request for information on how the current value of the zero flag was calculated, at a JZ instruction (the SemTrax UI is on the left monitor, with IDA on the right, in case that isn't obvious!).


Hiring: Graduate/Junior Software Engineer in Program Analysis

Update: Applications for this position are now closed. However, we will be hiring again in the next few months. Thanks for your interest!

Want to work on fun problems? Like building things that help break things? Well, if you're a recent graduate, or junior developer then read on!

The role is a mix of engineering and research focused around assisting with RE and vulnerability discovery. Remote work is fine and you'll get to spend 20% of your time on whatever you want (ideally with a tangential relationship to the company's focus!). The full details can be found here (now removed) (i.e. perks, salary, requirements, how to apply, what the interview process is and that sort of thing) , but in summary:

Position

Software Engineer in Program Analysis, suitable for a recent graduate or junior developer

Role

We're looking for a motivated engineer who's passionate about building great tools for program analysis. You'll be one of our first employees and the role will primarily consist of building better systems for assisting with reverse engineering, bug finding and exploit development. Understanding each of these activities is crucial for building better tools, so you'll also spend some of your time doing hands-on work in each area. 

As well as developing your existing skills, you'll also get plenty of opportunities to learn new things. In particular, you'll get to spend 20% of your time working on side projects of your choosing, and have a budget for any required learning materials.

Location

Remote. The only requirement is that your working day overlap for about 4 hours with 9-5 GMT. Some travel will likely be required, but it won't be more than a few weeks a year.

- Sean (@seanhn)

Announcing our First (and only!) Public Training of the Year: The Nordic Security Conference, August 26th - 28th

Despite saying it was highly unlikely we'd do a public training this year, the promise of eating colourful seabirds has won me over! I'm happy to announce that "Advanced Tool Development with SMT Solvers" will be hosted at NSC from the 26th to the 28th of August. This is going to be the only public course we teach this year, so if you're interested in understanding and extending the tech & research behind modern program analysis tools you should sign up while you can!

As this is something of a once-off, we've also decided to offer a discount of ~10% over our usual fee to all attendees of NSC. So, for $3000, you get two awesome things 1) Great program analysis training and 2) an environment where it isn't frowned upon to bury a fish for 12 weeks before consumption. What more could you want? Sign up now or contact us with any questions.

ooking forward to seeing you there!

- Sean (@seanhn)

Trainings: If you're interested in organising one in 2013, book soon!

I'm pleased to say our trainings have been popular so far, so popular in fact that they're essentially booked out until September! That's the first update: if you're interested in organising a class in 2013 then it's probably better to do it sooner rather than later as the number of slots remaining are quite limited.

pdate #2 is that we've made some improvements and changes to the tool development class. Two points are worth mentioning. First, we've decided to focus the class more on symbolic methods (SAT/SMT solvers, symbolic execution, whitebox fuzzing etc) at the expense of abstract interpretation (AI) and dataflow (DFA) analysis. These areas are more practically interesting in my opinion, and the current state of the art shows more promise for the types of tasks we're interested in. We've removed the material on AI and DFA for now, which allows us to change the class to be 3 days in length instead of 4.  It also allows us to add new material on intermediate languages, as well as a bunch of new exercises across all topics. 

The current metrics for that class are something like 500+ slides and 40+ exercises! It's intense, but I guess going from propositional logic to the state of the art in symbolic program analysis techniques in 3 days is probably going to be that way =)

- Sean (@seanhn)

Our 2013 Training Prospectus is Online

I'm happy to announce that in 2013 we'll be offering three different classes. You can get a high level overview here, and a detailed syllabus by sending a mail to services@persistencelabs.com*. In summary, they are:

  • C & C++ Auditing for Professionals: Strategy, Tactics & Techniques (5 days)
  • Binary Auditing for Professionals: Strategy, Tactics & Techniques (5 days)
  • SMT Solvers, Static Analysis, and Advanced Tool Development (4 days)

I'm looking forward to teaching them all, but out of the three I'm most excited about the last. I think it's a fairly unique class and should give students a solid introduction the more useful research topics in program analysis, as well as hands-on experience in developing implementations of the various algorithms covered. We'll also spend time discussing some of the larger problems that still exist when trying to integrate this research into tools for RE and bug finding. 

The other two are also designed to take a slightly different approach to teaching code auditing. Instead of just focusing on enumerating bug categories, the content includes quite a bit of material on actually organising yourself during an audit, prioritising target components for review, and developing good habits to ensure reliable and repeatable results. 

On the less interesting side of things, i.e. administrative details, we're currently only offering the classes to private organisations and government clients. If you'd like to enquire about booking a class, or to receive a more detailed syllabus, send a mail to services@persistencelabs.com. That said, we are considering putting on an open class in either the UK or the US at some point next year. If you're interested, send a mail to the same address mentioning which class(es) you'd be interested in taking, and which country. If the various moons align, we will probably hold that class during the summer of next year.

- Sean (@seanhn)

* As mentioned above, we're currently only offering the classes to private organisations and government clients. 

Augmenting Vulnerability Analysis of Binary Code (ACSAC '12)

One of the problems typically encountered when presented with a new binary to audit is where to focus attention. In a large piece of software the obvious approach of starting at an input point and auditing forwards often doesn't cut it.  It's quite easy to end up in pages of boilerplate code and non-interesting libraries. A common workaround is to do some quick instrumentation to gather coverage information across non-interesting runs of the program, and then do the same across interesting ones. With some straighforward analysis you can extract an idea of where the code you care about is, where the utility functions are, and what is potentially boilerplate. While easy to implement and work with, this approach is rather coarse. For one, you still have no idea which input data influence which calculations, or which of those calculations are actually interesting. Fortunately, with a bit more effort we can solve this problem. 

 

At ACSAC this week a paper by Agustin Gianni and I will be published under the above title. Our goal was to develop a system that could quickly identify the attack surface of an application and prioritise regions of code for manual analysis. As a further constraint, the system had to have runtimes that would make its usage acceptable in a typical auditing workflow.

The paper describes a system for performing taint analysis on binary programs using dynamic instrumentation and a stripped down specification for the data-movement properties of each instruction. The system generates alerts when the data-flow information matches particular patterns, e.g. an attacker controlled argument to malloc, and the results are automatically pulled into IDA for prioritisation and manual analysis. When auditing the highlighted code regions the data-flow information is also made available, making it easier to reason about control-flow and data influenced by attacker input. In the evaluation, we used the tool on quite a few different binaries and found it made for a good way to start an audit and find some nice bugs.

You can find the paper here, and the abstract is as follows:

Discovering and understanding security vulnerabilities in complex, binary code can be a difficult and time consuming problem. While there has been notable progress in the development of automatic solutions for vulnerability detection, manual analysis remains a necessary component of any binary auditing task. In this paper we present an approach based on run time data tracking that works to narrow down the attack surface of an application and prioritize code regions for manual analysis. By supporting arbitrary data sources and sinks we can track the spread of direct and indirect attacker influence throughout a program. Alerts are generated once this influence reaches potentially sensitive code and the results are post-processed, prioritized, and integrated into common reverse engineering tools. The data recorded is used to inform the decisions of users, rather than replace them. By avoiding the processing required for semantic analysis and automated reasoning our approach is sufficiently fast to integrate into the normal work flow of manual vulnerability detection. 

- Sean (@seanhn)