ReMASTering Applications by Obfuscating during Compilation

In this post, we discuss the creation of a novel software obfuscation toolkit, MAST, implemented in the LLVM compiler and suitable for denying program understanding to even the most well-resourced adversary. Our implementation is inspired by effective obfuscation techniques used by nation-state malware and techniques discussed in academic literature. MAST enables software developers to protect applications with technology developed for offense.

MAST is a product of Cyber Fast Track, and we would like to thank Mudge and DARPA for funding our work. This project would not have been possible without their support. MAST is now a commercial product offering of Trail of Bits and companies interested in licensing it for their own use should contact info@trailofbits.com.

Background

There are a lot of risks in releasing software these days. Once upon a time, reverse engineering software presented a challenge best solved by experienced and skilled reverse engineers at great expense. It was worthwhile for reasonably well-funded groups to reverse engineer and recreate proprietary technology or for clever but bored people to generate party tricks. Despite the latter type of people causing all kinds of mild internet havoc, reverse engineering wasn’t widely considered a serious threat until relatively recently.

Over time, however, the stakes have risen; criminal entities, corporations, even nation-states have become extremely interested in software vulnerabilities. These entities seek to either defend their own network, applications, users, or to attack someone else’s. Historically, software obfuscation was a concern of the “good guys”, who were interested in protecting their intellectual property. It wasn’t long before malicious entities began obfuscating their own tools to protect captured tools from analysis.

A recent example of successful obfuscation is that used by the authors of the Gauss malware; several days after discovering the malware, Kaspersky Lab, a respected malware analysis lab and antivirus company, posted a public plea for assistance in decrypting a portion of the code. That even a company of professionals had trouble enough to ask for outside help is telling: obfuscation can be very effective. Professional researchers have been unable to deobfuscate Gauss to this day.

Motivation

With all of this in mind, we were inspired by Gauss to create a software protection system that leapfrogs available analysis technology. Could we repurpose techniques from software exploitation and malware obfuscation into a state-of-the-art software protection system? Our team is quite familiar with publicly available tools for assisting in reverse engineering tasks and considered how to significantly reduce their efficacy, if not deny it altogether.

Software developers seek to protect varying classes of information within a program. Our system must account for each with equal levels of protection to satisfy these potential use cases:

  • Algorithms: adversary knowledge of proprietary technology
  • Data: knowledge of proprietary data (the company’s or the user’s)
  • Vulnerabilities: knowledge of vulnerabilities within the program

In order for the software protection system to be useful to developers, it must be:

  • Easy to use: the obfuscation should be transparent to our development process, not alter or interfere with it. No annotations should be necessary, though we may want them in certain cases.
  • Cross-platform: the obfuscation should apply uniformly to all applications and frameworks that we use, including mobile or embedded devices that may run on different processor architectures.
  • Protect against state-of-the-art analysis: our obfuscation should leapfrog available static analysis tools and techniques and require novel research advances to see through.

Finally, we assume an attacker will have access to the static program image; many software applications are going to be directly accessible to a dedicated attacker. For example, an attacker interested in a mobile application, anti-virus signatures, or software patches will have the static program image to study.

Our Approach

We decided to focus primarily on preventing static analysis; in this day and age there are a lot of tools that can be run statically over application binaries to gain information with less work and time required by attackers, and many attackers are proficient in generating their own situation-specific tools. Static tools can often very quickly be run over large amounts of code, without necessitating the attacker having an environment in which to execute the target binary.

We decided on a group of techniques that compose together, comprising opaque predicate insertion, code diffusion, and – because our original scope was iOS applications – mangling of Objective-C symbols. These make the protected application impossible to understand without environmental data, impossible to analyze with current static analysis tools due to alias analysis limitations, and deny the effectiveness of breakpoints, method name retrieval scripts, and other common reversing techniques. In combination, these techniques attack a reverse engineer’s workflow and tools from all sides.

Further, we did all of our obfuscation work inside of a compiler (LLVM) because we wanted our technology to be thoroughly baked into the entire program. LLVM can use knowledge of the program to generate realistic opaque predicates or hide diffused code inside of false paths not taken, forcing a reverse engineer to consult the program’s environment (which might not be available) to resolve which instruction sequences are the correct ones. Obfuscating at the compiler level is more reliable than operating on an existing binary: there is no confusion about code vs. data or missing critical application behavior. Additionally, compiler-level obfuscation is transparent to current and future development tools based on LLVM. For instance, MAST could obfuscate Swift on the day of release — directly from the Xcode IDE.

Symbol Mangling

The first and simplest technique was to hinder quick Objective-C method name retrieval scripts; this is certainly the least interesting of the transforms, but would remove a large amount of human-readable information from an iOS application. Without method or other symbol names present for the proprietary code, it’s more difficult to make sense of the program at a glance.

Opaque Predicate Insertion

The second technique we applied, opaque predicate insertion, is not a new technique. It’s been done before in numerous ways, and capable analysts have developed ways around many of the common implementations. We created a stronger version of predicate insertion by inserting predicates with opaque conditions and alternate branches that look realistic to a script or person skimming the code. Realistic predicates significantly slow down a human analyst, and will also slow down tools that operate on program control flow graphs (CFGs) by ballooning the graph to be much larger than the original. Increased CFG size impacts the size of the program and the execution speed but our testing indicates the impact is smaller or consistent with similar tools.

Code Diffusion

The third technique, code diffusion, is by far the most interesting. We took the ideas of Return-Oriented Programming (ROP) and applied them in a defensive manner.

In a straightforward situation, an attacker exploits a vulnerability in an application and supplies their own code for the target to execute (shellcode). However, since the introduction of non-executable data mitigations like DEP and NX, attackers have had to find ways to execute malicious code without the introduction of anything new. ROP is a technique that makes use of code that is already present in the application. Usually, an attacker would compile a set of short “gadgets” in the existing program text that each perform a simple task, and then link those together, jumping from one to the other, to build up the functionality they require for their exploit — effectively creating a new program by jumping around in the existing program.

We transform application code such that it jumps around in a ROP-like way, scrambling the program’s control flow graph into disparate units. However, unlike ROP, where attackers are limited by the gadgets they can find and their ability to predict their location at runtime, we precisely control the placement of gadgets during compilation. For example, we can store gadgets in the bogus programs inserted during the opaque predicate obfuscation. After applying this technique, reverse engineers will immediately notice that the handy graph is gone from tools like IDA. Further, this transformation will make it impossible to use state-of-the-art static analysis tools, like BAP, and impedes dynamic analysis techniques that rely on concrete execution with a debugger. Code diffusion destroys the semantic value of breakpoints, because a single code snippet may be re-used by many different functions and not used by other instances of the same function.

graph view is useful

Native code before obfuscation with MAST

graph view is useless

Native code after obfuscation with MAST

The figures above demonstrate a very simple function before and after the code diffusion transform, using screenshots from IDA. In the first figure, there is a complete control flow graph; in the second, however, the first basic block no longer jumps directly to either of the following blocks; instead, it must refer at runtime to a data section elsewhere in the application before it knows where to jump in either case. Running this code diffusion transform over an entire application reduces the entire program from a set of connected-graph functions to a much larger set of single-basic-block “functions.”

Code diffusion has a noticeable performance impact on whole-program obfuscation. In our testing, we compared the speed of bzip2 before and after our return-oriented transformation and slowdown was approximately 55% (on x86).

Environmental Keying

MAST does one more thing to make reverse engineering even more difficult — it ties the execution of the code to a specific device, such as a user’s mobile phone. While using device-specific characteristics to bind a binary to a device is not new (it is extensively used in DRM and some malware, such as Gauss), MAST is able to integrate device-checking into each obfuscation layer as it is woven through the application. The intertwining of environmental keying and obfuscation renders the program far more resistant to reverse-engineering than some of the more common approaches to device-binding.

Rather than acquiring any copy of the application, an attacker must also acquire and analyze the execution environment of the target computer as well. The whole environment is typically far more challenging to get ahold of, and has a much larger quantity of code to analyze. Even if the environment is captured and time is taken to reverse engineer application details, the results will not be useful against the same application as running on other hosts because every host runs its own keyed version of the binary.

Conclusions

In summary, MAST is a suite of compile-time transformations that provide easy-to-use, cross-platform, state-of-the-art software obfuscation. It can be used for a number of purposes, such as preventing attackers from reverse engineering security-related software patches; protecting your proprietary technology; protecting data within an application; and protecting your application from vulnerability hunters. While originally scoped for iOS applications, the technologies are applicable to any software that can be compiled with LLVM.

McSema is Officially Open Source!

We are proud to announce that McSema is now open source! McSema is a framework for analyzing and transforming machine-code programs to LLVM bitcode. It supports translation of x86 machine code, including integer, floating point, and SSE instructions. We previously covered some features of McSema in an earlier blog post and in our talk at ReCON 2014.

Our talk at ReCON where we first described McSema

Build instructions and demos are available in the repository and we encourage you to try them on your own. We have created a mailing list, mcsema-dev@googlegroups.com, dedicated to McSema development and usage. Questions about licensing or integrating McSema into your commercial project may be directed to opensource@trailofbits.com.

McSema is permissively licensed under a three-clause BSD license. Some code and utilities we incorporate (e.g. Intel PIN for semantics testing) have their own licenses and need to be downloaded separately.

Finally, we would like to thank DARPA for their sponsorship of McSema development and their continued support. This project would not have been possible without them.

Education Initiative Spotlight: THREADS Call for Papers

A 2-day conference exploring state-of-the-art advances in security automation.

We would like to share the call for papers for THREADS 2014, a research and development conference that is part of NYU-Poly’s Cyber Security Awareness Week (CSAW). Trail of Bits is a founding sponsor of THREADS. The final deadline for submissions is October 6th, but you are encouraged to apply earlier.

This year’s theme for THREADS is scaling security — ensuring that security is an integral and automated part of software development and deployment models. In previous years THREADS served as a discussion forum for major developments in the security industry, like mobile security and Cyber Faster Track.

We need to scale security because every day we trust more about our lives and our society to internetworked information systems. The development of these systems is accelerating in pace and increasing in complexity — it is now common to deploy code multiple times per minute to worldwide production systems. To cope with this increasing complexity, more development and deployment tasks are becoming fully automated.

Security must be a core part of our new technology and fully integrated into an increasingly automated development and deployment model. THREADS will present new research and developments about integrating security into modern software development and operations.

Highlights from CSAW 2012 where the first THREADS conference was held

THREADS 2014: Security Automation

Companies such as Amazon and Netflix deploy code to worldwide production systems several times per minute. Tesla automobiles download software updates over the Internet to provide new functionality. An Internet-connected thermostat is a best-selling home automation gadget.

Traditional models of security are increasingly irrelevant in a rapidly updated world of Internet-connected devices. Gating deployments by manual security assessments would erase the point of agile development and continuous deployment. Endpoint security products can’t target rapidly updated customized embedded platforms like cars and thermostats. The new model of security has to focus on automation, integration, detection and response time.

This year’s THREADS conference will focus on how to automate security. The goal of automating security is to ensure that security is never a roadblock, but a core part of development and operations. The success of automated security is essential to our ever more internetworked society and devices.

DAY 1: RESEARCH

The research portion of THREADS will discuss the latest academic and industrial advances in security automation for the identification of errors in programs and intrusions in networks. This will include dynamic and static analysis, symbolic execution and constraint solving, data flow tracking and fuzz testing, host and network monitoring, and related technologies. This research advances the state of the art in reasoning about applications and systems to discover security vulnerabilities, identify flaws in applications, and formulate effective defenses.

DAY 2: DEVELOPMENT

The development portion of THREADS will discuss strategies to integrate security into your development pipeline: what automated analysis tools are available, how to integrate them with developers, and how to provide feedback to developers that encourages reporting instead of assigning blame. Other sessions will show you how to add security monitoring triggers to existing monitoring infrastructure, and how to tune these triggers to information attackers want to steal. Our focus is on practical examples and lessons learned when automating security.

Join Us!

Join us on November 13-14, 2014 at NYU-Poly (5 Metrotech Center, Brooklyn, NY 11201) for the 3rd annual THREADS Conference. We’re incredibly excited about the lineup this year and will be announcing keynote and first round speakers soon.

About THREADS

THREADS is a conference that focuses on pragmatic security research and new discoveries in network attack and defense. It is part of NYU-Poly’s Cyber Security Awareness Week (CSAW) in Brooklyn, NY. THREADS is chaired by NYU-Poly Hacker in Residence and Trail of Bits CEO Dan Guido and the program committee includes Sergey Bratus (Dartmouth), Julien Vanegue (Bloomberg), John Viega (Silver Sky), Max Caceres (the D. E. Shaw group), Rajendra Umadas (Etsy), Phyllis Frankl (NYU-Poly), Tyler Bohan (NYU-Poly), and Justin Cappos (NYU-Poly).

THREADS aims to present and discuss cutting edge, peer reviewed, industrial and academic research in computer and network security and focuses on advances in attack techniques and methodologies. We want to discuss what vulnerabilities exist and how attackers of today and tomorrow exploit those vulnerabilities.

Education Initiative Spotlight: Build it Break it

Build it Break it is a first-of-its-kind security challenge run by UMD

Build it Break it is a first-of-its-kind security challenge run by UMD

We’re proud to be a sponsor of the first Build it Break it programming contest, run by the University of Maryland (UMD) and supported by one of our own employees and PhD student at the university, Andrew Ruef. Build it Break it is a “flipped CTF” where contestants both implement secure software and identify vulnerabilities in the creations of others. Points are awarded for the secure construction of software and for identifying security flaws.

The build-it, break-it, fix-it contest was conceived as a way to acquire useful scientific evidence, while at the same time engaging the student population and the wider community in a mentality of building security in rather than adding it after the fact. – Michael Hicks

At Trail of Bits, we think Build It Break it is a necessary addition to the suite of available competitions in the security community. There are a wealth of opportunities for students to learn to break software (many of which we support), however, there are relatively few that challenge them to build it right. In this unique contest, there is something for both builders and breakers since it rewards both activities.

It also presents an opportunity for language evangelists to demonstrate the merits of their approach – if their language is “more secure” than others, it should come out on top in the contest and more implementations built with it will remain standing. Contestants can use any programming language or framework to write their software, so by observing the contest, the community gathers empirical evidence about the security or insecurity of available tools.

Any undergraduate or graduate student at a US-based university is eligible to compete for cash prizes in Build it Break it. Though, be warned that Trail of Bits engineers will be on hand to assist as a “break it” team. For more information about the motivations behind this contest, see this blog post and slide deck from Michael Hicks.

Education Initiative Spotlight: CSAW Summer Program for Women

At Trail of Bits we are proud of our roots in academia and research, and we believe it is important to promote cyber security education for students of every academic level. We recently sponsored a High School Capture the Flag (CTF) event, we released a CTF Field Guide, and we are a regular part of Cyber Security Awareness Week (CSAW) at NYU-Poly.

CSAW Summer Program for High School Women

10487588_588177764633699_1497332133553342074_n

Recent graduates of the CSAW Summer Program for High School Women

As part our ongoing collaboration with NYU-Poly, Trail of Bits is proud to be a part of the CSAW Program for High School Women. This program is a unique opportunity for teenage women from the New York City area to learn the fundamentals of computer science and cyber security. Qualifying young women from local high schools participate in two weeks of lecture and hands-on training breaking codes, hacking databases, and unraveling a digital forensics mystery.

“The Introduction to Computer Science and Cyber Security Summer Program aims to introduce young women to computer science in a safe and encouraging learning environment. Exposing young women to female role models and mentors in computer science allows the women to view the field as a viable career option.” – Summer of STEM

The CSAW Program for High School Women is led by Linda Sellie, an Industry Professor of Computer Science and Engineering at NYU-Poly. The complete program covers a variety of topics in computer science, including cryptography, databases, basics of computation, networking, and more. Trail of Bits’ Dan Guido, along with NYU-Poly Computer Science and Engineering Department Head, Nasir Memon, taught an overview of computers and career opportunities in the field of cyber security. Following this course module, students engaged the first level of Matasano’s MicroCorruption challenge to further explore low-level software security issues. Graduates of the program are prepared to compete in other challenges, such as CSAW’s High School Forensics and Capture the Flag competitions this fall.

The first summer program ran from July 7-18 and a second session begins today and will run through August 8th. For more information about the CSAW Summer Program for High School Women, see the press release from the NYU Engineering department.

Trail of Bits Adds Mobile Security Researcher Nicholas DePetrillo to Growing Team

New York, NY (July 15th, 2014)—Veteran computer security researcher Nicholas DePetrillo has joined Trail of Bits, the New York-based security company, as Principal Security Researcher. Trail of Bits Co-founder and CEO Dan Guido announced the hire today. DePetrillo brings the headcount of the firm, which was founded by a team of three in 2012, to 13 employees.

DePetrillo brings more than ten years of security research experience to Trail of Bits, most notably in the area of mobile security. DePetrillo is widely regarded as one of the industry’s foremost experts in the field, attracting considerable attention for his discovery of significant security flaws that impact the privacy of millions of smartphone users and wireless network customers. He has worked on research throughout the entire mobile phone technology stack including cell phone network infrastructure, baseband radio security research and at the application and operating system level.

“Having Nick on our team opens up tremendous new opportunities for us and for the companies we work with,” said Guido. “Mobile security is one of the most important issues our industry is facing, and Nick’s work provides great insight into how mobile attackers think and work, which is key to developing solutions to protect these devices.”

Among DePetrillo’s first projects with Trail of Bits is the development of secure mobile technologies for use in next-generation smartphones.

Prior to joining Trail of Bits, DePetrillo was an independent consultant specializing in mobile security research services. He was also a Senior Security Researcher at Harris Corporation, focusing on mobile and wireless platforms. DePetrillo is a frequent lecturer, and has presented his work at BlackHat and other security conferences around the world.

About Trail of Bits
Founded in 2012, Trail of Bits enables enterprises to make better strategic security decisions with its world-class experience in security research, red teaming and incident response. The Trail of Bits management team is comprised of some of the most recognized researchers in the security industry, renowned for their expertise in reverse engineering, novel exploit techniques and mobile security. Trail of Bits has collaborated extensively with DARPA on the agency’s acclaimed Cyber Fast Track, Cyber Grand Challenge and Cyber Stakes programs. In 2014, the company launched its first enterprise product, Javelin, which simulates attacks to help companies measure and refine their security posture.

Learn more at www.trailofbits.com.

A Preview of McSema

On June 28th Artem Dinaburg and Andrew Ruef will be speaking at REcon 2014 about a project named McSema. McSema is a framework for translating x86 binaries into LLVM bitcode. This translation is the opposite of what happens inside a compiler. A compiler translates LLVM bitcode to x86 machine code. McSema translates x86 machine code into LLVM bitcode.

Why would we do such a crazy thing?

Because we wanted to analyze existing binary applications, and reasoning about LLVM bitcode is much easier than reasoning about x86 instructions. Not only is it easier to reason about LLVM bitcode, but it is easier to manipulate and re-target bitcode to a different architecture. There are many program analysis tools (e.g. KLEE, PAGAI, LLBMC) written to work on LLVM bitcode that can now be used on existing applications. Additionally it becomes much simpler to transform applications in complex ways while maintaining original application functionality.

McSema brings the world of LLVM program analysis and manipulation tools to binary executables. There are other x86 to LLVM bitcode translators, but McSema has several advantages:

  • McSema separates control flow recovery from translation, permitting the use of custom control flow recovery front-ends.
  • McSema supports FPU instructions.
  • McSema is open source and licensed under a permissive license.
  • McSema is documented, works, and will be available soon after our REcon talk.

This blog post will be a preview of McSema and will examine the challenges of translating a simple function that uses floating point arithmetic from x86 instructions to LLVM bitcode. The function we will translate is called timespi. It it takes one argument, k and returns the value of k * PI. Source code for timespi is below.

long double timespi(long double k) {
    long double pi = 3.14159265358979323846;
    return k*pi;
}

When compiled with Microsoft Visual Studio 2010, the assembly looks like the IDA Pro screenshot below.

IDA_TimesPi_Original

This is what the original timespi function looks like in IDA.

After translating to LLVM bitcode with McSema and then re-emitting the bitcode as an x86 binary, the assembly looks much different.

IDA_TimesPi_Lifted

How timespi looks after translation to LLVM and re-emission back as an x86 binary. The new code is considerably larger. Below, we explain why.

You may be saying to yourself: “Wow, that much code bloat for such a small function? What are these guys doing?”

We specifically wanted to use this example because it shows floating point support — functionality that is unique to McSema, and because it showcases difficulties inherent in x86 to LLVM bitcode translation.

Translation Background

McSema models x86 instructions as operations on a register context. That is, there is a register context structure that contains all registers and flags and an instruction semantics are expressed as modifications of structure members. This concept is easiest to understand with a simplified pseudocode example. An operation such as ADD EAX, EBX would be translated to context[EAX] += context[EBX].

Translation Difficulties

Now let’s examine why a small function like timespi presents serious translation challenges.

The value of PI is read from the data section.

Control flow recovery must detect that the first FLD instruction references data and correctly identify the data size. McSema separates control flow recovery from translation, and hence can leverage IDA’s excellent CFG recovery via an IDAPython script.

The translation needs to support x86 FPU registers, FPU flags, and control bits.

The FPU registers aren’t like integer registers. Integer registers (EAX, ECX, EBX, etc.) are named and independent. Instructions referencing EAX will always refer to the same place in a register context.

FPU registers are a stack of 8 data registers (ST(0) through ST(7)), indexed by the TOP flag. Instructions referencing ST(i) actually refer to st_registers[(TOP + i) % 8] in a register context.

figure_8_2

This is Figure 8-2 from the Intel IA-32 Software Development Manual. It very nicely depicts the FPU data registers and how they are implicitly referenced via the TOP flag.

Integer registers are defined solely by register contents. FPU registers are partially defined by register contents and partially by the FPU tag word. The FPU tag word is a bitmap that defines whether the contents of a floating point register are:

  • Valid (that is, a normal floating point value)
  • The value zero
  • A special value such as NaN or Infinity
  • Empty (the register is unused)

To determine the value of an FPU register, one must consult both the FPU tag word and the register contents.

The translation needs to support at least the FLDFSTP, and FMUL instructions.

The actual instruction operation such as loads, stores, and multiplication is fairly straightforward to support. The difficult part is implementing FPU execution semantics.

For instance, the FPU stores state about FPU instructions, like:

  • Last Instruction Pointer: the location of the last executed FPU instruction
  • Last Data Pointer: the address of the latest memory operand to an FPU instruction
  • Opcode: The opcode of the last executed FPU instruction

Some of these concepts are easier to translate to LLVM bitcode than others. Storing the address of the last memory operand translates very well: if the translated instruction references memory, store the memory address in the last data pointer field of the register context. Other concepts simply don’t translate. As an example, what does the “last instruction pointer” mean when a single FPU instruction is translated into multiple LLVM operations?

Self-referencing state isn’t the end of translation difficulties. FPU flags like the precision control and rounding control flags affect instruction operation. The precision control flag affects arithmetic operation, not the precision of stored registers. So one can load a double extended precision values in ST(0) and ST(1) via FLD, but FMUL may store a single precision result in ST(0).

Translation Steps

Now that we’ve explored the difficulties of translation, let’s look at the steps needed to translate just the core of timespi, the FMUL instruction. The IA-32 Software Development Manual manual defines this instance of FMUL as “Multiply ST(0) by m64fp and store result in ST(0).” Below are just some of the steps required to translate FMUL to LLVM bitcode.

  • Check the FPU tag word for ST(0), make sure its not empty.
  • Read the TOP flag.
  • Read the value from st_registers[TOP]. Unless the FPU tag word said the value is zero, in which case just read a zero.
  • Load the value pointed to by m64fp.
  • Do the multiplication.
  • Check the precision control flag. Adjust the result precision of the result as needed.
  • Write the adjusted result into st_registers[TOP].
  • Update the FPU tag word for ST(0) to match the result. Maybe we multiplied by zero?
  • Update FPU status flags in the register context. For FMUL, this is just the C1 flag.
  • Update the last FPU opcode field
  • Did our instruction reference data? Sure did! Update the last FPU data field to m64fp.
  • Skip updating the last FPU instruction field since it doesn’t really map to LLVM bitcode… for now

Thats a lot of work for a single instruction, and the list isn’t even complete. In addition to the work of translating raw instructions, there are additional steps that must be taken on function entry and exit points, for external calls and for functions that have their address taken. Those additional details will be covered during the REcon talk.

Conclusion

Translating floating point operations is a tricky, difficult business. Seemingly simple floating point instructions hide numerous operations and translate to a large amount of LLVM bitcode. The translated code is large because McSema exposes the hidden complexity of floating point operations. Considering that there have been no attempts to optimize instruction translation, we think the current output is pretty good.

For a more detailed look at McSema, attend Artem and Andrew’s talk at REcon and keep following the Trail of Bits blog for more announcements.

EDIT: McSema is now open-source. See our announcement for more information.

We’ve Moved!

Trail of Bits headquarters has moved! Located in the heart of the financial district, our new office features a unique design, cool modern decor, and an open layout that makes us feel right at home.

With fast internet, well-appointed conference rooms, and comfortable work stations, we feel that this is a great place to grow our business.

We are also loving our new commute options. We have easy access to several main subway lines, and for those of us who bike, there is indoor bicycle storage and a Citibike located right outside our building. Oh yeah, there’s also this view:

We’re hiring and we encourage you to apply if you’re interested in joining us!

Dear DARPA: Challenge Accepted.

CGC_Stacked_ColoronBlack

We are proud to have one of the only seven accepted funded-track proposals to DARPA’s Cyber Grand Challenge.

Computer security experts from academia, industry and the larger security community have organized themselves into more than 30 teams to compete in DARPA’s Cyber Grand Challenge —- a first-of-its-kind tournament designed to speed the development of automated security systems able to defend against cyberattacks as fast as they are launched. DARPA also announced today that it has reached an agreement to hold the 2016 Cyber Grand Challenge final competition in conjunction with DEF CON, one of the largest computer security conferences in the world.

More info from DARPA:

Press coverage:

Our participation in this program aligns with our development of Javelin, an automated system for simulating attacks against enterprise networks. We have assembled a world-class team of experts in software security, capture the flag, and program analysis to compete in this challenge. As much as we wish the other teams luck in this competition, Trail of Bits is playing to win. Game on!

Trail of Bits Releases Capture the Flag Field Guide

Free Online Coursework Allows Students, Professionals to Build Essential Offensive Security Skills

New York, NY (May 20, 2014)–Security researchers at Trail of Bits today introduced the CTF Field Guide (Capture the Flag), a freely available, self-guided online course designed to help university and high school students hone the skills needed to succeed in the fast-paced, offensive competitions known as Capture the Flag.

Capture the Flag events consist of many small challenges that require participants to exercise skills across the spectrum of computer security, from exploit creation and vulnerability discovery to forensics. Participation in such games is widely viewed as a critical step in building computer security expertise, especially for high school and college students considering a career in the field.

Despite the value of CTF events, few high schools and colleges have the resources to mentor students interested in computer security, and often the expertise needed to create and train CTF teams is lacking. The CTF Field Guide will help students build the skills to compete and succeed in these competitions, supplementing their existing coursework in computer security and providing motivated students with the structure and guidance to form their own CTF teams.

The CTF Field Guide is based on course content created by Dan Guido, co-founder and CEO of Trail of Bits and Hacker in Residence at NYU Polytechnic School of Engineering, one of the first universities to offer a cybersecurity program.

Guido is among the few instructors in the country to teach offensive security tactics, and his Penetration Testing and Vulnerability Analysis course is a mainstay of the cybersecurity programs at NYU Engineering. The CTF Field Guide combines elements of Guido’s classes, along with material Trail of Bits developed in collaboration with the Defense Advanced Research Projects Agency (DARPA) to train military academy students and reference material from leading security researchers around the world.

“Capture the Flag events can test and improve almost every skill that computer security professionals rely on, but one of the most valuable is mastering offensive maneuvers—-learning to think like attackers,” said Guido. “We created the CTF Field Guide to allow anyone interested in boosting their skills, from high school students to working professionals, to benefit from some of the best teaching in the world, free of charge and at their own pace.”

The CTF Field Guide is housed on GitHub, which allows users to contribute to and improve the course material over time. It is also available as a downloadable GitBook that can be viewed as a pdf or ebook. While courses on similar topics have been previously offered online, the CTF Field Guide is the first to be freely available and to allow ongoing collaboration and updates based on real-world attack trends.

Participation in CTF competitions has skyrocketed in recent years. Some of the largest events—DEF CON’s CTF and the NYU Engineering CSAW CTF among them—attract tens of thousands of entrants, and many events now include challenges specifically tailored for young student teams.

Trail of Bits is a sponsor of the High School CTF (HSCTF), the first CTF event designed for high school students by their peers which included more than 1000 competitors. Guido believes there’s no better time to launch the CTF Field Guide. “Students who competed in these recent games—or who plan to do so in the future—can start the course right now and there’s no question they’ll be better prepared to succeed next year.”

About Trail of Bits

Founded in 2012, Trail of Bits enables enterprises to make better strategic security decisions with its world-class experience in security research, red teaming and incident response. The Trail of Bits management team is comprised of some of the most recognized researchers in the security industry, renowned for their expertise in reverse engineering, novel exploit techniques and mobile security. Trail of Bits has collaborated extensively with DARPA on the agency’s acclaimed Cyber Fast Track, Cyber Grand Challenge and Cyber Stakes programs. In 2014, the company launched its first enterprise product, Javelin, which simulates attacks to help companies measure and refine their security posture.

Learn more at www.trailofbits.com

Follow

Get every new post delivered to your Inbox.

Join 3,629 other followers