First, my pet peeve; re: "a hacker is someone who breaks into computer systems stealing information and doing other malicious stuff." That defines a criminal. A hacker may or may not be a criminal, as a doctor, lawyer or anyone may or may not be a criminal, but that definition is of a criminal.
Now to the questions at hand: "can engineers become hackers and hackers become engineers?"
I believe they can. In my mind, the mindset, thought processes and level of creativity are similar. Engineering, however, is supposed to follow a disciplined and calculated process, while hacking tend to take a more "I'm pretty sure" approach.
Most engineers I've met can skip the process and work on intuition if need be. I suspect it's a little more difficult for a hacker to move to engineering simply because It's almost always more difficult to transition from low discipline to high discipline.
In other words, I think the hacker mindset is already in most engineers. It just needs to be let loose. Corporate structure is more likely to be an inhibitor than is the engineering mindset.
For a long time, there have been engineering disciplines that requierd thinking like an attacker. Consider the fields of cryptography, signal jamming and anti-jamming systems and the general subject of electronic countermeasures.
Exactly. When the whole world of embedded systems becomes more vulnerable to potentials of external attacks (as more and more systems are designed to get connected to the internet), isn't it about time to have a special cource at an engineering school -- focused on "jpw to think like an attacker"?
If we can teach engineering, we should also be able to teach the art of hacking...
Anyone rememeber Larry Lange? He was the first EE Times reporter to focus on covering Internet stuff. He interviewed Marc Andreessen in our offices before anyone understood what Netscape was doing.
Larry used to love the Black Hat event. He pointed out there are white and black hat hackers working for good and evil purposes.
Since then it has become clear to me there are grey areas too.
Add this to the mix: Hackathons are events where engineers design stuff. In this context hacking means quickly creating prototypes to test ideas out, bypassing what can be a slow design process at large established companies.
IMHO there is little that's differentiating hackers, crackers and engineers: the supposition of maliciousness does not necessarily apply only to one of the categories. (There's also the term of the "malicious engineer".)
On the other hand, one thing is common to all of them: to be superior, you have to apply analysis, a systematical approach, sometimes patience. Besides the 'brute force attack' all these methods describe engineers as well as the 'hackers'.
To be honest, from time to time I HAVE to hack something: to access information necessary but denied to me by to lack of documentation, cooperation, incompentence or sheer ignorance.
My one comment is that in the course of my studies I had to take class entitled "engineering ethics". I do not think hackers have taken this class. Having said that - yes you need to know your enemies better than you know your friends. In some sense ethics is a cultural issue and can be interpreted based on the culture you come from. Not making any judgements here - just an observation.
This is one of the most interesting article I have come across in EEtimes recently. thanks for posting it Junko.
I think Engg and hackers are same species with same mindset just different vision. I have seen engineer act like hackers. In one of a startup I do see when engineers were competing for resources and sys admin was weak they started to hack system to get thier job ahead in competition. I see tasks are like glass half full. Engg focus on half full part and hackers focus on half empty part. Engg try to get more water to fill it and hackers focus only on empty side of glass. I think they can be interchanged. The only thing is engg tend to worry about legal Vs illegal aspect where hacker tend to ignore that part, infact they love being in illegal zone. If we make everything legal then every engg can act like hacker, given bth are asked to do same task.
There are so many different definitions of "hacker" that IMO it's important to indicate which one you're using. There are seven definitions at Wiktionary, four of them technological. Wikipedia has three definitions, which I'll repeat here:
The first definition includes both "white hat" hackers like Robert Redford in Sneakers (1992) and "black hat" hackers AKA "crackers". There's also the pejorative "hacker", meaning someone do does things haphazardly, like a "hack writer", or a programmer who hacks away at code until it works with a few test cases instead of doing a careful design.
So call me a "hacker" if you like, but please don't ever call me a "hacker" :-)
Good questions, Junko, and I think Susan is right that there are many shades of meaning to the word (like the difference between analysis and blog in journalism). But most of the hackers I know studied electrical engineering in school, work as engineers, and call themselves hackers. If we're talking about cyber criminals or other malicious people, let's call them what they are. And if a self-educated hacker gains enough knowledge to do some interesting things in code, is that not -- at some level -- engineering?
Do you have to have a degree in engineering to be an "engineer?" And must you lack such a degree to be a "hacker?" What do others think about that...?
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.