These days it's hard to conceive of life without the internet. We have come a long way since the early days of the internet as a hobbyist's retreat full of text bulletin boards and personal "web logs". People now rely on the internet to pay bills, shop for necessities and even earn an income. The world is at your fingertips... if you can use a mouse... and see the screen... and hear the audio.

For many many people this is not as simple as it sounds. One in four adults in the United States has a disability. This means that a huge number of Americans are limited in the way they can interact with a computer, and might use it differently than your average user.

The good news is that humans are clever and adaptible and we have created all kinds of fantastic assistive technology tools like screen readers, pointing implements and voice control that help make the digital world accessible to everyone. And they usually work great out of the box as long as the websites they visit follow a few simple best practices.

You don't have to be a screen reader master or have a team of professional accessibility testers to improve the accessibility of your website. Here are five easy steps you can take to make your website accessible without needing to be an accessibility expert:

1. Add alt text to your images

What happens when a non-sighted user encounters an image on a website?

If the content is a news article, the image might be a picture illustrating the scene. If its a how to listicle, it might be a diagram illustrating a particularly complicated step.

Screen readers aren't smart enough to be able to describe a picture on their own, so they rely on the information that the webpage gives them about that image. For example, if our webpage is displaying an article about penguins and we want to show an image of the penguin we're talking about, but we only include the bare image tag on the page, such as

<img src="847227.jpg" />  

all the screen reader user will hear is:

"image. eight four seven two two seven dot jpg."

This means the screen reader user is missing out on some of the information the page has to offer.

The good news is this issue is extremely easy to correct. Introducing the humble alt tag!

<img src="847227.jpg" alt="A penguin standing on a beach" />  

With the simple addition of this tag, the screen reader will switch from reading out the meaningless image file name, to reading:

"image. A penguin standing on a beach."

With this one line addition, screen reader users now have all the same information that visual readers do.

Adding alt tags to your images helps sighted users too! We've all had the experience of being in a place with such bad cell service that the images on the webpage we're trying to load time out. Alt text to the rescue! Most browsers will display alt text if they're unable to load the image, so users with bad cell signal can still get all the information the page has to offer, even if they're not able to download the images.

This kind of outcome - a design that's intended to help disabled users helps non-disabled users as well - is known as the "curb cut effect".

A curb cut is a depression in the sidewalk curb that leads down to the street. Curb cuts were designed to make public streets accessible to wheelchair users, but today everyone benefits. Curb cuts are useful to moms with strollers, delivery drivers, people with temporary injuries and anyone who has ever walked down the street with their eyes locked on their phone.

Many web accessibility fixes are curb cuts for regular users. We'll see many more examples in this article.

2. Fix your low contrast fonts

In the early and mid 2010's, lots of websites underwent redesigns to make them more aesthetically beautiful and "web 2.0":

Light font weights and delicate low-contrast accent colors were all the rage. The instinct was understandable - the web was shifting from a smaller, technical minded audience to a more general audience who businesses who businesses knew they could draw in with more attractive experiences.

Aesthetics are important but they aren't the ultimate goal of design. The most beautiful website is useless if the user can't read and interpret its content. And often poor readability doesn't get noticed during the design process. We developers and designers don't read the text the same way a visitor might.

Humans have done a lot of scientific research on what makes text on a background readable vs. not readable, and the W3C has actually published a document called Web Content Accessibility Guidelines (WCAG) 2.1 that covers successful contrast guidelines. They boil readable text down into a single mathematical formula: the contrast ratio.

The contrast ratio explains the difference between the lightest color brightness and the darkest color brightness in a given range. It’s the relative luminance of each color. This article is meant to be purely practical, so I'm not going to go into the details of the math here, but you can read this great CSS Tricks article for more information.

What we care about here is that the minimum acceptable ratio for readablility is 4.5:1 for most body text and 3:1 for larger text.

If your eyes just glazed over, don't worry. There are automated tools that can do this for you. The simplest way to look up the ratio between two colors is with the WebAIM contrast checker: https://webaim.org/resources/contrastchecker/

For the working web developer, I suggest the WCAG Contrast Checker extension for Chrome and Firefox.

It will automatically analyze your entire webpage for contrast problems and suggest fixes.

Just like alt text, better contrast is a curb cut. More readable color schemes mean less strain on the eyes, and more readable websites for users who might be trying to read your website on their phone while they're outside in bright sunlight.

3. Make clickable elements keyboard-friendly

Are the only interactive elements on your website <a>, <button> and <video> tags? Great, you're done! You can go onto the next section, because HTML5 handles keyboard accessibility by default.

If you've ever put an onClick on a <div> tag, however, read on...

There are a lot of reasons why someone would choose to use a keyboard rather than a mouse to interact with your website. The most obvious case is that non-sighted users can't see where the cursor is, but many people have physical limitations that make mouse precision difficult or impossible. Many more people are perfectly capable of using a mouse, but can't or don't want to for a variety of reasons. Maybe their mouse is just broken and they're trying to use your ecommerce website to buy a new one!

The simplest way for a keyboard user to navigate through a website is with the tab key. Pressing tab will shift the browser focus to the next interactive element on the page. Once the focus is on the element the user is interested in, they can hit the enter or space key to interact. You've probably seen this before when you accidentally bumped tab and one of the links on the page reacted by looking like this:

As I mentioned at the beginning of the section, this works by default for HTML5 elements that are meant to be interactive. The problem is that websites do a lot more nowadays than present text and links.

Go to your website right now and hit the tab key. Is the element you expect highlighted? Keep pressing tab until you cycle through the entire page. Did every element you know is clickable get highlighted? If not, that means that your keyboard-only users are unable to interact with all parts of your website.

The good news is that for most simple websites, the solution is elementary: USE. SEMANTIC. TAGS.

Replace

<div>Play video</div>  

with

<button>Play video</button>  

Things the user clicks to make something on the page are buttons, so call them buttons in your HTML.

Replace

<div onclick="window.location = 'https://new.url'">Click here to go</div>  

with

<a href="https://new.url">Click here to go</a>  

Things the user clicks to navigate from the current page to another page are links, so call them links in your HTML.

"BUT ZACH!" you say, "I'm maintaing a legacy widget that renders a grid of clickable images and if I change them to buttons the 10,000 lines of spaghetti CSS I inherited break the whole page due to a browser bug!"

Ok. I get it. I'm also a working web developer. You should always try to use semantic HTML tags wherever possible, but if you can't for whatever reason, at least put tabindex on interactive elements so keyboard users can get to them.

4. Add accessibility audit tools to your build

No one can be an expert in everything. While I always encourage web developers to understand accessibility basic, I also understand that there's an infinite amount of interesting things to learn about computers, and its unrealistic to expect everyone to be an expert in every topic.

But, as with everything else in computing, you don't have to be an expert to benefit from the learnings of other programmers and computer scientists. You can approach it in the most programmer way possible: automate it!

There are a huge variety of excellent accessibility testing tools out there, and its almost guaranteed you can find one to fit your workflow.

I suggest that every software project have two levels of automated accessibility testing: a static code analyzer and an end-to-end system tester.

Static Code Analysis

Are you working with a modern JavaScript framework and using ESLint? Great, you're one npm install away from automated a11y code auditing. There are ESLint accessibility audit plugins for JSX and Vue.

There's a ton of great accessibility linting tools out there, here's a few I found in a 5 minute search:

• AriaLinter
• AccessLint
• Stylelint A11y

Look around and be creative. If you don't see one for your specific use case, consider writing a plugin for your linter and putting it out there!

End to End System Tester

Only so many issues can be caught by statically reading code, so its also important to have a tool that loads your website in a browser and audits the actual page for issues.

I strongly suggest Axe. Its a fantastic accessibility testing toolkit that is already built into a lot of existing integration test solutions.

There's a Cypress integration, a Lighthouse integration, a Ghostjs integration and even a Py Selenium integration. Here's the full list of integrations, I can pretty much guarantee that at least one of these will work for your use case.

I use the Cypress integration and love it.

It gives you a clear printout of what went wrong, with a rule name ("heading-order in the screenshot) that's easily searchible, so you can look up what the fix is without being an accessibility expert.

5. Learn the basics of assistive technologies and empathize with your users

“The more you watch users carefully and listen to them articulate their intentions, motivations, and thought processes, the more you realize that their individual reactions to Web pages are based on so many variables that attempts to describe users in terms of one-dimensional likes and dislikes are futile and counter-productive. Good design, on the other hand, takes this complexity into account.”

― Steve Krug, Don't Make Me Think: A Common Sense Approach to Web Usability

We're all in this industry because we love using the web so much we wanted to be a part of shaping the experience. Apply that enthusiasm on behalf of your users. Ask them questions and listen to what they say. Seek diverse perspectives. Try interacting with your sites the way they do.

I have spent the past year gaining fluency in Apple's VoiceOver and it has been an exciting and humbling experience. I'm now able to articulate accessibility pain points in design discussions because I myself have felt those pain points. I know what frustrates screen reader users the most beacuse I've felt those very frustrations.

The internet is also full of passionate assistive technology users sharing their experiences with technology. Listen and reach out!

Here's one of the talks that got me excited about accessibility in the beginning. Hopefully it inspires you as well.

As a beginner developer working on pet projects at home, it's easy to argue that once code goes through the compiler, it's all the same. Right?

The flaw in this argument is that it assumes that all software developers do is write new code. The reality is that we actually spend much more time reading and modifying existing code than writing new code.

For this reason, code cleanliness and readability are paramount to project success. More important than your framework choice, test coverage percentage or project management solution, is the cleanliness and readability of your code.

The seminal MIT textbook Structure and Interpretation of Computer Programs sums it up perfectly:

Programs must be written for people to read, and only incidentally for machines to execute

Clean code matters to project success because starting a project quickly is rarely the problem; it's finishing quickly that's hard. As the cyclomatic complexity of your app increases, it becomes more and more difficult to add new features and diagnose bugs. It also becomes harder for programmers who are not specialists to make meaningful contributions to your project. Bad code compounds these issues. If you can't read the code, how can you understand what it's doing?

For this reason, the most important book I have ever read as a programmer is Clean Code by Robert C. Martin. Everyone who writes code should read this book.

I could write a second book just pointing out all the great parts of the first book. But for now, I'd like to reflect on my favorite five quotes from the first five chapters. I hope these quotes will inspire you to push yourself and your team towards better, more maintainable code.

Chapter 1 - Clean Code

"You know you are working on clean code when each routine you read turns out to be pretty much what you expected."

– Ward Cunningham (inventor of Wiki)

If I had to pick a favorite quote from the book, this would be it. Clean code does what you'd expect it to do. In many ways, every other sentence in the book is just an attempt to clarify this concept.

But how can you know what the reader expects your code to do? Grab a friend and do a code review.

Take note of what makes sense to them right away, and what makes them say "WTF". If you get a lot of "WTFs", your code is not clean. Let's look at some more quotes from the book to identify common causes of "WTF".

Chapter 2 - Naming

"Programmers must avoid leaving false clues that obscure the meaning of code... Do not refer to a grouping of accounts as an accountList unless it's actually a List. The word means something specific to programmers. If a container holding the accounts is not actually a List, it may lead to false conclusions. So accountGroup or bunchOfAccounts or just plain accounts would be better."

Most programmers know to stay away from poor variable names like one or two character names (e.g. a1) or undescriptive placeholders (e.g. mystring). But an overly descriptive name can be just as bad or worse. If you call a variable thingHashMap and a year later your team decides to model "things" as a tree map instead, all of a sudden the variable name isn't just useless, its actually harmful.

Choose names that describe what the content does, not what it is.

Chapter 3 - Functions

"Functions should do one thing. They should do it well. They should do it only."

Take a look at this example Spring MVC controller method:

@RequestMapping(value = {"/"})
public ModelAndView execute() {  
  ModelAndView mav = new ModelAndView();
  URL url = new URL("http://example.com");
  HttpURLConnection con = (HttpURLConnection) 
  url.openConnection();
  con.setRequestMethod("GET");
  con.setRequestProperty("Content-Type", "application/json");
  BufferedReader in = new BufferedReader(
  new InputStreamReader(con.getInputStream()));
  String inputLine;
  StringBuffer content = new StringBuffer();
  while ((inputLine = in.readLine()) != null) {
    content.append(inputLine);
  }
  con.disconnect()
  mav.add("content", content);
  return mav;

If you take 20 or so seconds, you can parse through this code block to understand the basic control flow:

• Instantiate a ModelAndView object
• Get content from example.com and put it into the ModelAndView object
• Return the ModelAndView object

But when reading the code, there are all kinds of other details that distract from that main purpose, e.g.

• Modeling the URL as a Java object
• Casting the connection to the right type
• Setting request method and headers
• Setting up a BufferedReader to parse the response

etc etc.

A reader can understand the control flow once they figure out which lines are details and which lines are important, but that takes unnecessary effort, and someone who isn't well versed in Java might get bogged down trying to understand what's happening here.

Now consider this refactored version, which accomplishes the same thing:

@RequestMapping(value = {"/"})
public ModelAndView execute() {  
  ModelAndView mav = new ModelAndView();
  mav.add("content", getExampleContent());
  return mav;
}

Even though this refactored version looks radically different, it still accomplishes the same control flow:

• Instantiate a ModelAndView object
• Get content from example.com and put it into the ModelAndView object
• Return the ModelAndView object

The difference is that it only explicitly describes the important parts. The name of the method getExampleContent() tells the reader what is happening without bogging them down with the details. If they need to know how it works under the hood, they can jump to that method definition.

A well written main method should read like a story. Just like each of the methods it executes, it should do one thing, do it well, and do it only: execute the right methods in the right order.

Chapter 4 - Comments

"When you find yourself in a position where you need to write a comment, think it through and see whether there isn't some way to turn the tables and express yourself in code."

Comments seem like a great way to make code more readable, but they can be dangerous as well. Why is this? Uncle Bob explains it best:

Because they lie. Not always, and not intentionally, but too often. The older a comment is, and the farther away it is from the code it describes, the more likely it is to be just plain wrong. The reason is simple. Programmers can't realistically maintain them."

My rule of thumb is as follows:

A comment is helpful if it describes what the code is used for. A comment is harmful if it describes how the code works.

Do write comments that describe what your class represents, what problems it solves, etc. Do not write comments explaining the control flow of your code. Comments that explain "how" your code works are an indication that your code isn't clean.

If you need to explain why you've defined a variable or what a for loop is doing, write a named function instead. Document your code with your code.

Chapter 5 - Formatting

"Code formatting is important. It is too important to ignore and it is too important to treat religiously. Code formatting is about communication, and communication is the professional developer's first order of business."

When different blocks of code in the same project look different, it causes the reader to wonder whether the differences are functional or stylistic. This is bad, because it increases cognitive overhead.

Imagine a legacy Javascript project with single quotes in one file and double quotes in another. When reading through that project for the first time, it’s natural to wonder whether the double quotes are there for a reason, or if one programmer just preferred them.

Your reader should never have to ask this question, because it unnecessarily increases the overhead required to understand the project. If you're constantly forced to manually separate style differences from functionality in your brain, you're wasting energy on making a distinction that should have been made by the author.

As an author, don't make your reader work any harder than they already have to. It doesn't really matter what your style rules are - just pick some and be consistent. The best way to do so is by codifying them into linter rules and enforcing them at build time.

I hope these tips have inspired you to push yourself and your team towards better, more maintainable code. If you haven't yet read Clean Code by Robert C. Martin, you should pick up the book as soon as possible. It made me a better programmer, and it can make you a better programmer too.

Jeff Atwood once famously proclaimed "we are typists first, programmers second". While I think software development is a little more complicated than that, this quote brings up an important point: efficiency in software development hinges on the tooling we choose.

For the longest time I used Bash as my UNIX shell. It got the job done. I would occasionally feel frustrated by a repetitive command or a missing feature, but there was usually an alias or script I could apply like a bandaid to minimize the pain enough to keep going. I even switched to iTerm several years back to improve my terminal emulator GUI. I worked with Bash for long enough that I managed to amass a pretty fancy .bash_profile config. If you're curious about my config, you can check it out for yourself.

But I'm not here to help you optimize Bash. I'm here to tell you there's a better way.

Why ZSH is better than Bash

After a few years working in the software industry, I kept noticing that the shells of senior programmers often looked much different than mine did.

Whereas my shell looked something like this:

Theirs tended to look more like this:

I had heard talk of alternative shells like ZSH before, but I always assumed that the difference was purely aesthetic. It wasn't until I started working for a company whose cloud machines all came pre-configured with ZSH that I realized what I was missing.

ZSH provides a huge number of improvements over other shells and I could write an entire post just comparing and contrasting the benefits and drawbacks. Instead, I'll provide you with this excellent slide deck about the benefits of ZSH over Bash:

Getting Started on Mac OS X

First let's cover the basics of getting ZSH set up on your Mac. The good news is that you probably already have ZSH on your system.

1. Install ZSH

Let's get started by running which zsh in whatever shell you're currently using. If you have the executable on your system, which should output /bin/zsh or something similar.

If which instead outputs zsh not found, you can install zsh easily with Homebrew. Just run brew install zsh.

I also strongly recommend using iTerm2 as your terminal emulator app on Mac OS X. You can download it here.

2. Set ZSH as your default shell

The actual process for changing your default shell from Bash to ZSH is extremely easy. Just run chsh -s /bin/zsh.

Note that you'll need to supply the correct path your ZSH binary which you can get with the which zsh command we used earlier. Click here for more information on the chsh command.

That's it! Close and reopen your terminal. You're now using ZSH!

3. Install a ZSH configuration manager

In the old days, configuring ZSH manually took a lot of time and effort. Thankfully, ZSH has a large and devoted user community which has produced a few tools to help with writing and sharing ZSH configurations.

The two big players are Oh My ZSH and Prezto.

tl;dr Oh My ZSH has a larger community, but Prezto performs better with a large number of modules installed.

I use Oh My ZSH since it has a wider variety of themes and plugins. Its also the most "standard" of all options, which means a larger community and better support. If you hit a wall early with Oh My ZSH, feel free to try out alternatives.

Installing Oh My ZSH is pretty easy. You can find CURL and WGET instructions here.

Run the command of your choice and that's it. One and done.

4. Choose a theme

Setting a custom theme with Oh My ZSH is simple. Oh My ZSH comes bundled with a bunch of themes by default. You can find a list with screenshots on their wiki. If you want to see the files on your local filesystem, they live in ~/.oh-my-zsh/themes.

Once you've picked a theme, open the file ~/.zshrc in the text editor of your choice. Towards the top of the file you should see a value ZSH_THEME. Change the value of the string to the name of the theme, save the file, and then run source ~/.zshrc to pick up the changes.

Check out the Oh My ZSH README for info on how to install custom themes.

5. Add plugins

Oh My ZSH's best feature is its ability to manage custom ZSH plugins. Setting up a list of custom plugins works just like changing themes. Open ~/.zshrc in a text editor and look for a line that looks something like plugins=(git). Check out the comment two lines up for an example of how to add to this list.

Just like with themes, you can browse bundled plugins in a list on the Oh My ZSH wiki, or you can browse the files locally at ~/.oh-my-zsh/plugins. Custom plugins can also be installed. Check out the Oh My ZSH README for more info.

I'm a relative newbie which makes me a bad resource, but here's a list of the plugins I'm currently using:

• colorize
• colored-man-pages
• command-not-found
• cp
• extract
• git
• npm
• web-search

6. Customize your experience

Now that you've got ZSH and Oh My ZSH set up, the possibilities for customization are nearly endless. You can add custom themes and plugins, write your own custom aliases or configure advanced auto-completion for the tools you use most commonly. A couple good places to get started are zsh-lovers, the ZSH man page and the Oh My ZSH community page.

As a VIM lover, one addition I personally made was to add a command mode to my shell so that I could use VIM keybindings to navigate around the text of my commands. You can do this with bindkey -v.

Bonus shot of my terminal (PII grayed out):

Peking University went on holiday last month in observance of Chinese New Year. As such, I knew I would be logging quite a few extra programming hours over the course of February. While I don’t mind working part-time from the comfort of my apartment’s bedroom, I actually kind of hate working from home full time. There are benefits of course: fewer interruptions, more comfortable and configurable workspace and no commute. Nevertheless, I start to go a little crazy when I spend over 16 hours a day in the same 10′ x 10′ space.

I started looking for coworking spaces in Beijing right away. Despite whatever misconceptions most Westerners might have about China’s backwardness, Beijing actually has a thriving tech sector who’s physical heart lies just south of Peking University campus in a neighborhood called Zhong Guan Cun (中关村). Quite a few tech giants call Zhong Guan Cun home, including SINA Corp, Microsoft China, Tencent, Youku, Tudou and Qunar.

What really makes Zhong Guan Cun interesting, however, is it’s thriving start-up scene. There are actually hundreds of start-ups that call Beijing home. The concentrated nature of both established and start-up tech companies has recently earned Zhong Guan Cun the title “China’s Silicon Valley”. The industry boom has lead to a massive influx of coworking spaces and incubators designed to produce the next Weibo or WeChat. Most of these spaces follow the traditional business model, requiring either invitation or a hefty monthly fee or both. Recently, however, a new class of coworking spaces has arrived in Zhong Guan Cun. These places may call themselves “cafes”, but they offer much more than just coffee.

Meet Beijing's Garage Cafe

Garage Cafe (车库咖啡馆）can be difficult to find as a non-local. Its nestled in an alley called “Innoway” near the northwest corner of Zhong Guan Cun. According to one of the area’s natives, this alleyway used to be one of the largest book-seller streets in all of Beijing. Its only appropriate, therefore, that as the knowledge economy transitioned from paper to digital media, this information hub made the transition from literati bazaar to start-up haven.

The cafe itself sits on the second floor of an otherwise innocuous looking building. I walked around in circles and had to ask a few people on the street before I finally figured it out. Upon entering the building, it can almost feel like you’ve walked into a private apartment building rather than into one of the most important spots in the Chinese start-up scene:

Nevertheless, once you head up the back stairs and through the door, you’re greeted by a massive space humming with energy and excitement.

The floor space of the cafe measures to 800 square meters, and has seating for about 150 people. The decor is sleek and industrial; minimalist black furniture, exposed fixtures and extension cords hanging down from the ceiling. Unlike most cafes, which seem to despise laptop users, Garage Cafe’s message is clear: grab a seat, plug in and get coding. Every table has a charging station with enough plugs for laptops, cell phones and even external monitors. The internet is also quite fast, which is a rarity at Chinese cafes. They even go so far as to provide monitors for people to plug into while they work.

Garage Cafe boasts a pretty solid library of programming books in both English and Chinese. No matter where you sit in the cafe, you can catch wisps of conversation about product optimization, unit testing, market share, etc. As a foreigner who speaks Chinese, I already had several job offers after just my first visit to the cafe. People go to Garage to network, brainstorm and build. There’s also a huge bulletin board of job listings that can be great to check out if you’re looking for a position in a Beijing start-up.

Keep in mind that Garage Cafe is much more “Chinese” than most cafes in Beijing. The staff most definitely does not speak English, and in the 20 or so times I have visited so far, I have only ever seen one other non-Han patron. Nevertheless, if you can speak Chinese and are looking for an awesome space to get some work done or network with like-minded programmers, Garage Cafe is a great option. The coffee isn’t half bad either, at least by Chinese standards.

In case you want to check it out for yourself, here is the address of Garage Cafe in English and Chinese:

Haidian District,
Zhongguancun, Haidian Qiao,
Dong Nan Haidian Tu Shu Cheng Bu Xing Jie

北京市海淀区中关村海淀桥东南海淀图书城步行街 (鑫鼎宾馆2层) – 车库咖啡

You can also find the cafe on Weibo here.

A note to the reader: For explanation on how to set up the lab environment see the "Introduction" section of the post.

If you're looking for a specific phase:

• Here is Phase 1
• Here is Phase 2
• Here is Phase 3
• Here is Phase 4
• Here is Phase 5

This phase is definitely the trickiest out of all of the other bomb lab phases. Prepare for data structures…

This phase is a doosey. Let’s go through everything step by step to figure out what we need to do.

First things first, our friend <read_six_numbers> from Phase 2 is back again. So, our input should be six integers. That one is a gimmie.

Next, we’ve got some loops happening. Firstly, <phase_6+47> is making sure that each number in our password is less than six. Now we have two criteria for our password. It needs to be six integers separated by spaces, and each integer needs to be less than or equal to six.

The final constraint on our input occurs in the nested loops between <phase_6+57> and <phase_6+104>. We have a loop with iterators %ebx and %edi. Essentially what happens is that we compare each number with every other number, and we only jump <explode_bomb> on line <phase_6+89> if the comparisons are not equal. In other words, all six of our integers need to be distinct.

Let’s summarize what we know so far about our input for this phase:

• six integers separated by spaces
• each integer should be less than or equal to 6
• no integer should be the same as any other integer

Now that we have a better idea of what our input should look like, let’s use the test string 1 2 3 4 5 6 and head on down towards the <explode_bomb> call at <phase_6+225> to see if we can find out more.

Here is the conditional statement by itself. First, the contents of %esi + 8 get moved into %edx. Subsequently, %esi itself gets moved into %eax. Then, %eax gets compared to %edx. If the value of %edx (which is %esi + 0x8) is less than the value at %eax (which is %esi) then the bomb explodes.

So, what are these values we’re comparing anyway? Let’s take a look:

When we take a look at the contents of %esi and %esi + 0x8, we get a couple of structures called <node1> and <node2>. Each node has three elements. The second element here obviously corresponds to the node number itself: 1 for <node1>, 2 for <node2>, etc. The third element of the node looks like a pointer. As we check out the contents of %esi + 0x8, and then ((%esi + 0x8) + 0x8), and so on, we see that these pointers are decreasing 0x8 at a time. Given that the first column of values seem to be arbitrary, this is starting to look like a common data structure: a (singly) linked list. Column one is the value of the node, column two is the node’s position in the list, and column threee is the pointer to the next node in the list.

So now we know, when we compare %edx and %eax at <phase_6+221>, what we’re actually doing is comparing the value of the current linked list node to the value of the next node in the list. If the next node’s value isn’t lower than the present node’s value, the bomb explodes. In other words, we need to put the nodes in order from largest value to smallest value. How do we do this? With our input.

Here’s a table of the values for reference:

And here they are in order from largest to smallest:

So there you go. That’s the answer right there.

Phase 6 complete! We did it!

Wrap Up

I hope you had fun working through the six levels of the bomb lab with me. I certainly enjoyed it. There’s nothing like quite like some crunchy reverse engineering goodness to get your brain in gear again. For the record, I do know there is a secret phase. While I solved it correctly for my class, I am not going to go through the steps here. If you reallllly need a tutorial, you can find one pretty easily with the search engine of your choice.

Thanks for reading, and I hope you found this tutorial helpful.

A note to the reader: For explanation on how to set up the lab environment see the "Introduction" section of the post.

If you're looking for a specific phase:

• Here is Phase 1
• Here is Phase 2
• Here is Phase 3
• Here is Phase 4
• Here is Phase 6

Ok, let’s get right to it and dig into the <phase_5> code:

So, what have we got here? First things first, we can see from the call to <string_length> at <phase_5+23> and subsequent jump equal statement our string should be six characters long.

Next, as we scan through each operation, we see that a register is being incremented at <phase_5+57>, followed by a jump-less-than statement right afterwards that takes us back up to <phase_5+43>. Remember this structure from Phase 2? A loop is occurring. And, as you can see at <phase_5+58> structure, the loop iterates 6 times. Given that our string is 6 characters long, it makes sense to assume that the function is iterating over each character in the loop and presumably doing something to them.

Finally, we can see down at the bottom of the function that <strings_not_equal> is being called after the contents of %eax and the fixed address 0x804980b have been pushed onto the stack. This looks just like phase 1. The code is comparing the string (presumably our input) stored in %eax to a fixed string stored at 0x804980b.

So, what do we know about phase 5 so far?

• our input has to be a string of 6 characters
• the function accepts this 6 character string and loops over each character in it
• the result of the loop is compared to a fixed string, and if they’re equal, the bomb doesn’t explode

As a next step, let’s input the test string “abcdef” and take a look at what the loop does to it. Then, we can take a look at the fixed value we’re supposed to match and go from there:

Woah. “srveaw” is pretty far off from “abcdef”. On the bright side, at least now we know that our string should come out of the loop as “giants”. Given this info, it looks as though the loop is implementing a cypher. From here, we have two ways to solve this phase, a dumb way and a smart way. The dumb way is to simply input all characters from a-z into the cypher and create a mapping table. From this mapping table, we can figure out the un-cyphered version of “giants”. This works just fine, and I invite you to try it.

The smart way of solving this phase is by actually figuring out the cypher. Once we understand how it works, we can reverse engineer “giants” into its pre-cypher form without having to waste time doing trial and error.

I don’t want to go through either solution all the way here, since the first one is a no-brainer and the second one is a little complicated. In order to solve the cypher, take a look at %esi and you’ll find an array of characters stored there, where each character has an index. Essentially what is happening is, each character from our string is ANDed with 0xf, and the result is used to get the character with the corresponding index from the array. If you solve the phase this way, you’ll actually notice that there is more than one correct solution.

Either way, eventually you’ll find that the pre-cyphered version of “giants” is actually “opekmq”.

On to the last phase!

A note to the reader: For explanation on how to set up the lab environment see the "Introduction" section of the post.

If you're looking for a specific phase:

• Here is Phase 1
• Here is Phase 2
• Here is Phase 3
• Here is Phase 5
• Here is Phase 6

Phase 4

In my opinion, this is where things start to get tricky. In this phase, it is not enough to simply understand the assembly. Some pattern-recognition will be required. As usual, let's start by taking a look at the code for this phase's function to see if we can find a vector through which to understand what's happening. I'm going to do so by running gdb with a test string and using disas:

On line <phase_4+16>, the <phase_4> function is pushing a fixed value stored at memory address 0x8049808 onto the stack right before a call to scanf is made. As we have learned from the past phases, fixed values are almost always important. Lo and behold, when we dump the contents of the memory address we get “%d”, which tells us that the answer to this phase should be a single integer

The second important feature of this code occurs on line <phase_4+53>. Our input value, which is stored in %eax, is getting input into this other function called <func4>. Right now <func4> is a black box, so we will need to dig into it using si to figure out what it is doing to our integer

The last thing we need to consider is that, after <func4> gets called and returns our potentially altered input back to %eax, %eax then gets compared to the hex value 37, which in decimal is 55. This means that, whatever our input is to begin with, it needs to be turned into 55 by <func4>.

So, now that we know what is generally happening in <phase_4>, let’s dig into <func4> to figure out what we need to input in order to generate 55.

Ok, before we do anything else, let’s recognize that this function is calling itself, which makes it recursive. All recursive functions have a “base case”, which terminates the loop, and then a series of instructions to follow in order to continue the loop if the base case is not met.

Let’s first identify our base case. It should occur early in the function as a conditional check. In <func4>, our base case occurs at <func4+11>. The function compares its input to 1. If the input is less than or equal to 1, it jumps down to <func4+48>, where the return value is set to one. Finally, it returns this value.

Now that we understand that the base case occurs when input=1, let’s identify what happens when the base case is not met. The first thing to note is that the function calls itself twice, once at <func4+23> and once at <func4+37>. The first time it calls itself, it feeds the new function call its input-1. Similarly, the second time it calls itself, it feeds the new function call its input-2. Once the two recursivelly called functions return, it sums their return values at <func4+42> and returns the result.

Here’s what the corresponding C code would look like:

int test(int n) {  
  if (n<2)
    return n;
  else
    return test(n-1) + test(n-2);
}

Now comes the part where we have to do some abstracted, big-picture thinking. We’ve got recursion, we’ve got a pattern, and we’ve got a function where F(x) = F(x-1) + F(x-2). What famous pattern fits these three parameters? The Fibbonaci sequence!

We should note that <func4> does not exactly return the Fibonacci number of the input. <func4> returns 1 if the input is 1 or less. For example, if our input is x=2, <func4> will return 1 for both x-1 = 1 and x-2 = 0.

So, now that we know all this stuff, how do we solve the stage? Remember that, in order to avoid the bomb blowing itself up, whatever gets spit out has to equal hex 37, which is 55 in decimal. Keeping in mind that func4(0) = func(1) = 1, func4(2) = 2, we will actually need to input the Fibonacci number for 55 with 1 subtracted from it. I find that taking a look at a table of the sequence makes this a little less confusing:

As we can see in the table above, the Fibonacci number for 55 is 10. So given our logic, 10-1= 9, so 9 should be the solution for the fourth phase.

Rock and roll.

A note to the reader: For explanation on how to set up the lab environment see the "Introduction" section of the post.

If you're looking for a specific phase:

• Here is Phase 1
• Here is Phase 2
• Here is Phase 4
• Here is Phase 5
• Here is Phase 6

By now you know the drill. Off to our objdump file!

Woah. There are a lot of conditionals here. Maybe you’re an IA32 warrior who can take one look at this code and immediately tell what is going on, but for the rest of us, an iterative approach might work better here.

The first interesting thing we see here is the call to scanf which occurs at memory address 8048bb7 in my objdump output file. There are two values that are pushed onto the stack right before scanf is called. After the call to scanf is made, the two pushed values are compared, and the bomb explodes if they’re not equal. Let’s use gdb to figure out what they are.

As usual, we will set a breakpoint at our phase, phase_3, and then run the bomb using answers.txt as an argument. After that, we can input a test string and when our breakpoint hits, we can use the gdb command x/s [memory-address] to print whatever string we find at that memory address:

From this we see that our test string is stored in register %eax, while the format being asked for follows the format %d %c %d. In case your C is rusty:

From this, we know that our input will have to be an int, followed by a char, followed by an int again. This is a good first step. Let’s update our test input to 1 a 2 and run our bomb through gdb again.

When we do this, you’ll notice that after passing the format check, the next call to <explode_bomb> gets passed over as well. We could dig into why 1 is correct as the first integer, but let’s take the freebie and use our time to continue on.

Once we arrive at the next test, we see that the value $0xd6 is being compared to the value stored at -0x4(%ebp).

As you should certainly know, d6 in hexidecimal is equal to 214 in decimal. When we check the value stored in -0x4(%ebp), it should be apparent that the program has jumped past our char input for now (its using a case statement for all of you A+ students), and is checking our second integer here. Since the jump statement to miss the next <explode_bomb> call requires equality, this means that our second integer must be 214.

Finally we come to our character. This one is just as simple as the last:

From the move statement on line <+240> its clear that our char is stored at -0x5(%ebp) and the value to compare against is coming from %bl. When we print out the value to be compared against, we get a hexidecimal value of 62, which in decimal is 98:

In other words, our character should be a lowercase ‘b’. Lo and behold, when we put our three answers together:

Looks like the bomb squad is in town!

A note to the reader: For explanation on how to set up the lab environment see the "Introduction" section of the post.

If you're looking for a specific phase:

• Here is Phase 1
• Here is Phase 3
• Here is Phase 4
• Here is Phase 5
• Here is Phase 6

Ok, now things get a lot more interesting a lot more quickly. Let’s get started the same way we did last time, by looking at our objdump file for clues:

The first thing to notice here is that <phase_2> is calling a function by the name of <read_six_numbers>. If we really wanted to be pedantic, we could go take a look at this function, but for the sake of brevity in this already very long tutorial, I’m going to go ahead and tell you that it looks to make sure the stdin input has six integers in it, each separated by a space. So there’s our first big clue: our answer takes the format a b c d e f where a-f are integers.

Now that we know roughly what our input should look like, let’s fire up gdb and do a little reverse engineering to figure out which six integers we should be inputting.

Sidenote: Typing in every passphrase every time we run the bomb gets really annoying really quickly. The bomb is written in such a way that it accepts a text file as an input. You can add your passphrases to this text file, separating each by a newline, and pass it to the bomb binary as an argument to avoid typing everything out every time you run the program. That’s what I’ll be doing from now on. See the lab handout for more information.

Now that we’re stopped at our breakpoint, let’s run disas to take a look at the assembly code and see if we can’t figure out exactly what’s going on. The output will look something like this:

Assuming you know assembly language basics (if you don’t, stop now and study up), a few things should jump out at you right away. Before anything else happens, a number is getting compared to 1, and the bomb is going off this number isn’t also 1. This means that the first integer in our secret phrase is undoubtedly 1.

The second thing to note is that the function is looping over its input. After %eax is compared to (%esi, %ebx, 4) at <+54>, %ebx gets incremented and, as long as its less than 5, the function jumps back to above the comparison so that it can do it again. This means that our input integers will probably be a pattern of some sort, where <+46> is where the math that increments the pattern happens. Let’s use until to jump down to the comparison and see if we can’t suss out what our second input number should be:

Once we’ve arrived at the comparison statement, we can use the i r command to see the contents of our registers. %eax, which is the register to which our value is being compared, is equal to 2. Therefore, the second integer in our passphrase should be 2.

The simplest way to solve this level completely is by continuing to step through the code, seeing what %eax is equal to after each iteration. Next you’ll find 6, then 24, then 120 followed by 720. If you’re really smart, however, you’ll notice that the assembly code is actually implementing the following algorithm:

v[0] = 1  
v[i] = (i+i) * v[i-1]  

Either way, the second passphrase ends up being 1 2 6 24 120 720.

On to the next challenge!