In the past few days, there's been a discussion on Twitter over what actually constitutes a cybersecurity researcher. It started with folks discussing the state of jailbreaking iOS 10 and from there started to meander around what exactly a cybersecurity researcher does. Let's take a look at this and see if we can come to a more sound description.

So, I see two types of cyber security researchers out there today: folks who do research into cybersecurity academically, and folks who research specific operating systems or applications for exploitable flaws. The former category usually has more letters associated with their names (i.e., Ph.D. or Professor, things like that), but the kinds of things they do is more a matter of focus rather than substance.

So what do cybersecurity researchers do? They spend lots of time studying. Lots.

Finding exploitable flaws in software is hard, and really time-consuming. I wrote a relatively high-level summary of an exploit Luca Todesco (aka qwertyoruiop) published on ghostbin a few months ago. Let's use that as an example.

This particular exploit involved a race condition that needed to be exploited to trigger a double-free condition. Go ahead and look up these terms, I'll wait.

Okay, you're back! Great. Oh, and by the way, a double-free is one of many different ways you can mess with dynamically allocated memory to attack a program. Most engineers can't write an exploitable program with a double-free condition. Imagine trying to find one, in the kernel, that you need to trigger by running a multitude of threads in very specific ways. How do you think he found this one?

Remember what I said about studying? you find this kind of bug by studying the XNU kernel source, disassembling KEXTs, and so on. Every disassembled a real program before? No? Try this:

$ otool -tvV /bin/ls > file
$ cat file

Well, now you have. Easy to follow, no? Imagine doing this over an operating system kernel.

Now, granted, you're not going to do it over the entire kernel, right? You can download the XNU source after all, but it's still not the easiest thing to follow, and some the kernel's functionality is in proprietary kernel extensions Apple provides. And those extensions, once you get your hands on them, need to be reverse engineered.

So back to Luca's exploit. It's pretty complex, and I'm pretty sure he found it by auditing the code. And this exploit is just the exploit itself - nothing's actually done with it. For it to be useful, it needs to be delivered to an iOS device, triggered, and then you need to inject a payload to take control of the device. All the export does is unlock the door; the heavy lifting's still to come.

And this payload, what does it look like? Well, I'm writing another series right now over what you can do after you capture control of a program, and in this series, I'm using shellcode. Shellcode is so named as it was originally written to give the exporting user a shell on the attacked system. It's essentially a chunk of binary instructions formatted to that they'll be executed by the program once you've gained control of the instruction pointer. You develop it by tweaking assembly code until it's doing exactly what you need in very specific ways (i.e., you can't include any null bytes). It's not super easy, as you can imagine.

And guess what, it doesn't work anymore. Hasn't for years.

Today, we use Return-Oriented Programming (ROP) to build payloads (initial ones, at least). On some platforms, you can use these ROP payloads to turn off shellcode defenses, and then you can execute injected code. On others, you can't, and the entire payload must be ROP code. What is ROP code? basically, you find binary sequences in a program you've compromised that are valid machine instructions on the platform you're attacking, and then you point the instruction pointer to those sections of code. That chunk of code (called a gadget) must include a RET instruction so you can maintain control of execution too. You chain these gadgets together into a sequence of instructions that do whatever you want done. These are easier to build today than they used to be, but they're certainly not trivial.

Okay, so far, we've studied the kernel source, both disassembled and original, we've found an exploit, written a few hundred lines to trigger it, then injected an ROP chain into the compromised program. All of this is pretty time consuming. And it requires a huge amount of know-how that you don't get for free. The knowledge is out there, and you pay for it with your time.

So, you want to be a cyber security researcher? Hit the books, hit the internet, and learn. Then apply what you've learned. That's what cyber security researchers do, and so can you. However, there are no shortcuts, so strap in for the long haul.