Engineer vs. Hacker Quandary

Most hackers could eventually become engineers if they chose to do so, but the reverse - training engineers to become hackers - is next to impossible. Is this true?

MADISON, Wis. — There's a popular theory that most hackers could eventually become engineers if they chose to do so, but the reverse -- training engineers to become hackers -- is next to impossible.

Is this true?

Before answering that question, let's examine how exactly hackers are different from engineers. That question (which you might say has already been asked and answered) hit me while talking to Richard Soja, distinguished member of the technical staff at Freescale Semiconductor.

Soja and I were discussing issues concerning cars. I was asking him how the best automotive chip suppliers like Freescale can get a few steps ahead of hackers to identify potential security holes.

Soja quipped: "To protect against attacks, you need to think like attackers."

Obviously. But Soja seems to believe that asking engineers to think like hackers is easier said than done. He explained:

Engineers, by nature, are good at creating positive things and coming up with new ideas. But the idea of destroying their beautiful, brand-new ideas doesn't come naturally to engineers.

Among engineers who can best think like hackers are those who work on testing, he added.

Hmmm. That's interesting.

Still, I'm not totally sold on the premise that hackers and engineers are two different technology types with dissimilar brains.

1. Are hackers and engineers essentially two separate species? I wonder if hackers are born to hack and others are not. If yes, can we define two separate types?

2. One could argue that hackers and engineers are basically alike but display two different mindsets -- depending on the different projects they undertake. If so, how do the mindsets differ?

3. Another argument is that "hackers vs. engineers" merely describes a transitional process in one's career. For example, a budding engineer who doesn't have formal training or a coherent career direction might begin life as a hacker, but then gradually grow up to become an engineer through experiences working in organizations. If true, are we saying that engineers are the butterfly and hackers the caterpillar?

More important, I'm curious:

4. Can you teach engineers to become hackers and think like hackers? The butterfly reverting to caterpillar?

5. If yes, what's the trick?

Searching the issue of hackers vs. engineers, you can find a lot of commentary. Let's consider some of these opinions.

How to get out of the hacker mindset
A student completing his Master's in Computer Science was worried about jettisoning his "hacker mentality" as he starts his career in the "real world." He took part in a forum in shlashdot.org. He wrote:

Since my academic work has focused almost solely on computer science and not software engineering per se, I'm really still a 'hacker,' meaning I take a problem, sketch together a rough solution using the appropriate CS algorithms, and then code something up (using a lot of prints to debug). I do some basic testing and then go with it… Even at my previous job, which was sort of a jack-of-all-trades (sysadmin, security, support, and programming), the testing procedures were not particularly rigorous, and as a result I don't think I'm really mature as an 'engineer.' So my question to the community is: how do you make the transition from hacker (in the positive sense) to a real engineer… How do you get out of the 'hacker' mindset?"

To this earnest question, one person whose username is mcrbids responded thusly:

An "engineer" is somebody who takes the time to understand a problem, and creates something to solve that.

Having done software from scales ranging from "quick shopping cart application" to enterprise scale organizational relationship management software, the only real difference between the two is that with the latter, you create a large number of smaller projects roughly the size of the aforementioned shopping cart application, except that the "users" are often other pieces of the same system. In larger systems, you'll be talking with other
developers who have built or manage the pieces your parts will communicate with. You'll read more documentation, and it will be generally of higher quality than the shopping cart scripts.

Don't *ever* lose the "hacker" mentality - exactly what you described is what software engineering is.

A hacker can come up with solutions, but maybe they can't look back after they've finished and realize how they came up with the solution. They just kinda poke at things until they get something that works…

At some point, you level up and become a developer and a developer understands best practices… and you use those best practices to craft solutions but you don't really understand beneath the best practices, beneath the abstractions.

An engineer is someone who can get things done, craft a solution - they understand the best practices, but they also understand why they're using the best practices… [they] move into an understanding of the platform as a whole.

Thanks, Junko. I love this discussion. In professional engineering, a hack doesn't mean high quality. So maybe it's a pride thing. BTW, to comment on this article, make sure you log in separately because for some reason this article hangs on the log in screen. Hmmm, unless you have a hack to get around that problem, you'll have to use the workaround for now.

First, we need to define which "hacker" you're referring to. Initially it seems like you're talking about someone with malicious intent. Frankly, I see no correlation between engineers and hackers in that sense. The equipment may be similar but it is the mallice that is the differentiating factor.

Toward the middle of the article you're discussing "hackers" in the sense of people who are building things but aren't necessarily fully educated or involved in their career path. This is the one I'd like to focus on. I think many engineers go home at the end of the day and hack. They find a problem and they solve it, and since they're not doing it for work, they aren't following SOP. They're exploring and chasing passions and obsessions, often only for the purpose of doing it. I think engineers can be hackers, and many uneducated hackers can go on to be engineers.

One interesting thing I've seen is when a hacker is obsessed with a specific technology. They learn everything they can about it, sometimes surpassing professionals in their knowledge. However, they have no interest whatsoever in broadening into all the other subjects that one would have to master to become a professional.

Among engineers who can best think like hackers are those who work on testing, he added.

No surprise. A friend who is a test engineer said the fundamental distinction between a developer and a test engineer is that a developer assumes the code will work, while a test engineer assumes the code will fail. Indeed, getting it to fail is what a test engineer does.

"Hackers" in the pejorative sense are behaving like test engineers. The test engineer wants to break the code and discover how and why it broke, so the code can be changed to make that failure impossible. The hacker is looking for failure points where code can be exploited for malicious purposes. The process is similar. The intended end result is very different.

@caleb, there are many ways to define hackers, and clearly, many people have defined it differently.

But my original intention was, as you can see in the first few graphs of my story:

....Soja and I were discussing issues concerning cars. I was asking him how the best automotive chip suppliers like Freescale can get a few steps ahead of hackers to identify potential security holes.

Soja quipped: "To protect against attacks, you need to think like attackers."

My conversation with this Freescale executive really opened my eyes. For example, established automotive chip suppliers -- usually a full of smart engineers -- do need help from hackers. So that they can think ahead, figuring out which security holes that need to patch in designing their next generation automotive MCU, for example.

In that context, I would like to know whetther design engineers at chip companies can morph themselves into hackers to help that cause, or they are really two different types of people and they probably need to hire external "hackers" to do the job...

well put, DMcCunney. So you are saying in their pursuit of "failure points" in a system, test engineers and hackers are working with a similar mindset. It makes sense. Do you think, then, it is customary within an engineering organization to leverage their own test engineers in finding any weakness of a system that can be hacked?

It's all about motif. A Hacker hacks, that is they break the code, to get inside and perform malicious acts. A Test engineer's motivation is to improve the code once the tests show that the code is not fullproof. The only way to get into the mindset of a hacker is think maleciously. Testing the new code of a tested piece of code is much harder. Hence in systems that require close to 100 percent reliability such as space aircrafts redundancy is built in. In security for commercial systems redundancy should also be built in. It is more expensive but might be worth the cost to ensure reliability is met and made harder for hackers to plunder and steal. The current hacker story going around should be analyzed for its flaws. see: http://www.bloomberg.com/news/2013-07-25/5-hackers-charged-in-largest-data-breach-scheme-in-u-s-.html

Do you think, then, it is customary within an engineering organization to leverage their own test engineers in finding any weakness of a system that can be hacked?

I'm not sure it's deliberately done for that purpose, but crafting code harder to hack will be a side-effect of the test process.

The most common hacker exploit is a buffer overflow. Code manipulates data. It expects to get a certain amount of data, in a certain format, and allocates a chunk of memory to hold the data it's manipulating. What happens if it gets more data than expected? What happens to the excess that won't fit in the buffer? In a buffer overflow exploit, that extra data overflows the buffer, and overwrites some other part of memory. The result may allow the hacker to compromise the system,

Checking for things like buffer overflows in code should be part of the test process. The general rules are "never trust your data", and "never assume that your code can handle every possible condition that might arise when it runs."

Most of the publicized exploits I can think of offhand are in legacy code first written before hacking became common. It simply didn't occur to the developers that someone might deliberately try to overflow a buffer with bad intent. In normal operation a buffer overflow wouldn't happen, so there was no provision to guard against it. Most of the Windows Critical Patches addressed precisely those oversights.

I've heard a similar comment about needing to think like a hacker to be able to prevent hacking, during a presentation at the Black Hat conference. I think it reflects the feeling that there is a different mindset (attitude, belief, morality, whatever) involved. On the one hand, you're looking at something to figure out how to make it work correctly as intended. On the other hand you're looking at something to figure out how to make it do something unintended.

But I think we need to be careful in generalizing the term "hacker" too far. I see two different kinds of folks who fall under that term. One is the person who creates a kind of "quick and dirty" solution to a problem and the other is someone who tries to break into a system for malicious purposes.

In order to answer your question, then, you need to be sure of which type of hacker you are talking about. I think that hackers of the first type (problem solvers) can easily act as engineers if they learn and use formal methods, and engineers become hackers by bypassing formality. Some folks may be so ingrained in using formal methods that they need to learn how to let go, but I think any engineer can be a hacker in this sense. One or the other mode might feel more natural to someone, though, so to some extent moving between hacker and engineer is a bit like speaking two languages - your native one and one you learn later in life. The degree of fluency someone has in this second language (or engineering mode) will vary from person to person.

The second type of hacking, though, involves a gap that is a lot harder to bridge. This kind of hacking is filled with ego, greed, and malice and getting into a mindset of seeking to destroy, pervert, or circumvent a design for gain or pride (so that you can predict avenues of attack and block them) is a lot harder for folks to get into when their natural inclination is to build, refine, and perfect. This kind of hacking can also be learned, no doubt, but requires a much greater mental shft.