Last Class

Thanks for going through this topic with me. I think I've been feeling a little funky about the direction of tech and the nature of careers and the elements of a life well-lived.

My goal is to maximally improve the trajectory of your lives with whatever time and topic we've got.

This topic is cool as shit. Hopefully you agree by now.

I'll watch Attack on Titan this summer. You go watch the first few seasons of Game of Thrones.

The age gap between you and my kids is shrinking each year, so the impacts of a digital life on real life becomes more familiar as time goes on.

So you've learned how to PWN an x86 C program.

Is that a useful skill for your career? It's OK, not the best, not the worst.

Some of you will become professional reverse engineers.

Some of you might even work on a team developing a zero-day RCE exploit.

Some of you will work on firmware and hardware design.

Most of you will work in tech of some kind or another, maybe in a SOC, maybe as a dev.

Some of you will go do something completely untechnical.

I'd like to believe that all of you understand how computers work now.

This class is sort of a crash course on how computers work and how they get corrupted.

I often like to look back and highlight all the things we did learn on the last day, just to take stock of the growth.

But maybe my model of how many types of exploits could you analyze and how many types of exploits could you design was good enough for that:

• Ways to overcome address randomization: leaks, read the GOT, use-after-free, printf vuln, ASLR, no-PIE, uncleared freshly malloced recycled data, and brute force tricks
• Ways to write-what-where (or at least out of bounds): exploiting gets/fgets/scanf, printf vuln, tcache-poisoning, house of botcake, poison null byte, non-stack/weird overflows, almost everything in how2heap
• Ways to control RIP: stack smashing / ROP chains, GOT overwrite, exploitable register calls, the __free_hook, exit_funcs, SROP, FSOP, fini_arrays, deconstructors
• Ways to get shell: a win function, shellcode, calling system via GOT, one gadgets, calling from libc, execve

That's roughly between 10,000 and 100,000 dumb ways to die.

Not bad.

As you go about your careers, feel free to drop me DMs and let me know what's going on in your world. Particularly whenever the ideas from this class pop into your consciousness.

Secure Software Design: The Other Versions

So there are other approaches to learning secure software design.

One is to learn the lessons and procedures of the rest of the industry and become an advocate for following generally good advice. Here's what that kind of looks like:

Head to the SEI C Standard. Poke around a bit.

Here I could have stayed on the dev side the whole time, and we could practice looking at writing code that follows these types of rules. Maybe contextualize them with some case studies or something, but to internalize the right way to code low-level products.

There is a high chance that this would be more practical for a corporate coding position.

Given a set of rules like this we could use a "static analysis toolchain" to evaluate source code for violations of these rules.

Checkout ROSECHECKERS the corresponding rules checker.

This is sort of like TypeScript and Linting as general software practices.

These days you can probably get an LLM to make a static analyzer for you based on your preferences.

Why I didn't

I'd get bored.

Also I think that learning rules from on high doesn't foster the intellectual power I want for you.

Like if someone gives you a life rule to follow, like never walk under a ladder. You follow it. They die. You keep spreading the rule. We end up spreading ladder rules to everyone and no one really knows why.

My version of that is to walk under some ladders, get hit in the head, have other people walk under ladders and you hit them in the head. Now you understand when to get worried about ladders, when not to, and more importantly to pay attention to the crazy people on ladders and their hammers rather than the ladder itself.

Call it FIRST PRINCIPLES thinking.

Do I think the CMU students in their version of this class will make more secure code than you? Well maybe. But I expect you to be more likely to discover the next wave of exploits.

How about SDL?

Let's look at the more DevOps version of Secure Software Design:

Look at a NIST Secure Software Development Framework

How about Microsoft's version: SDL

Maybe I'm just never grew up, but I think that these sort of things are dehumanizing. "Let us create procedures and rules for how things are done here." This is thinking from the era of needing factory workers. I say build your people up and hire slowly and carefully. Foster their sense of ownership in those teams. We aren't replaceable parts.

This is purely my preference for how life ought to be lived. So we did hacking.

How about the industry?

Let's poke at the MITRE ATTACK framework.

There are some roles in a large cyber team that are worth knowing about:

• Incident Response
• Threat Intelligence
• Forensics
• Red Team (sneaky)
• Pentesters (sledgehammer)
• Threat Hunting
• Internal Threats
• Risk Assessment
• Compliance
• Employee Training
• Malware Analyst

PWNing Gaps

So you want to be a 1337 h4x0r?

What did I not teach you (probably because I suck at it):

• how2heap has a TON of other exploits
• Other targets
• Kernel PWNing
• ANGR for Awesome REVing
• ARM pwning
• MUSL C
• RUST pwning
• JIT hacking via browsers
• C++ pwning
• Java pwning
• Python pwning

Thanks for a great semester