[wolfgke]

> Reverse Engineering is a much broader field than simply in the context of software engineering.

I will not disagree. But I am explicitly talking about reverse engineering as in the original article (i.e. mostly software and to a lesser (but not less important) sense electronics).

I do not know enough details about the other segments that you mention to make deep statements about them. But I am pretty confident in my opinion that the kind of skills that you require for them are really different from those that you need for software/electronics reverse engineering. What I want to say with this: The skills that you need for hacking an XBox (as in the article) do hardly ever transfer to any of your examples (bomb squad detectives, Root cause analysis experts, market/competition research, Prototyping, NTSB agent).

[kumarharsh]

I can think of some fields where these kids would be well suited - like employing them to make the XBox Live/PS/Steam gaming networks more secure, or employed by game companies to root out the cheaters (Sea of Thieves being a very recent example of a game infested with too many cheats).

[wolfgke]

> I can think of some fields where these kids would be well suited - like employing them to make the XBox Live/PS/Steam gaming networks more secure

In my opinion/experience, finding loopholes/security bugs in an existing system and designing systems that are unprone to security bugs are two very distinct skills. It is quite imaginable that many people that people who work in the branch become good at both, but being good at one of them does not make you good at the other.

EDIT: The only kind of knowledge that comes spontanously to my mind that transfers well between both areas is having an immense amount of obscure knowledge about weaknesses in lots of protocol designs.

[blackflame7000]

In order to design a really secure system, wouldn't you first have to know what "secure" is? If I am an expert an building impenetrable servers, then I must know how to penetrate servers since I've added patches to block all known attacks. How could I do that without first being a hacker?

See, its a progression not a dichotomy. A hacker possesses only a subset of a truly skilled security programmer. And the security programmer always has home field advantage. As a hacker becomes more seasoned, they learn more and more about the system until they reach the level of the security programmer or the person implementing all the locks and keys

[wolfgke]

> In order to design a really secure system, wouldn't you first have to know what "secure" is?

Indeed. For this one loves to build mathematical models, formulate security properties, make proofs, think deeply about the limits of the formulated models (e.g. tempest attacks, cache timings etc. which might introduce side channels) etc.

Finding exploits is quite a different job: Here you very often have lots of legacy systems which have an architecture that is hard to make secure. To give an example: A parser for a very complicated and ill-specified file format where mistakes can easily lead to catastrophes (for example because the format allows to embed "executable scripts" that are run in a JIT-based virtual machine). So you look for loopholes in an often badly designed or at least complex and thus error-prone system and think about how you can exploit these mistakes in a clever way.

I am very sure that both can be very exciting jobs, but they are in my opinion quite different in nature.

> If I am an expert an building impenetrable servers, then I must know how to penetrate servers since I've added patches to block all known attacks. How could I do that without first being a hacker?

I think the essential difference is that if you are an expert in building impenetrable servers, you simply avoid lots of design decisions that are prone to security problems (to stay in my explanation above: these also typically have the property that they can be specified rather well formally). On the other hand, if you want to penetrate servers, you need creativity to turn "suspicious looking design decisions/oversights" into working exploits.

So being an expert in building impenetrable servers will not make you good in penetrating servers: Knowing what design decisions are hard to keep in control security-wise does not (necessarily) give you the knowledge about how to concretely exploit them. On the other hand: Having a strong creativity for how one can in practice exploit oversights does not (necessarily) make you a good engineer for systems that are hard to exploit.

[blackflame7000]

“On the other hand, if you want to penetrate servers, you need creativity to turn "suspicious looking design decisions/oversights" into working exploits.” - imagine you at 30 trying to beat your 10 year older self for eternity.

The coder oversights wont be there because that seasoned expert once exploited someone else like that and knows where to defend. There is such a thing as 100% secure code. Although instances of it are very small. My point is, you get to be so good at building defenses because youve seen so many offenses and know what to expect and how to counter.

[blackflame7000]

Of course, they do! Reverse engineering is the skill of being able to see how things are put together without having the whole picture. It's having an intuition of where to find the clues to solve the bigger puzzle. From decerning which chip to decode to find the encryption key, to deducing that a broken fan blade is the only item that could strike a window at high enough velocity to shatter it, the skills are the same. A software reverse engineer is good because they possess many of the same traits as other types of reverse engineers. It's just a matter of how they apply their skill.

[wolfgke]

First: I respect your view on this topic.

> Of course, they do! Reverse engineering is the skill of being able to see how things are put together without having the whole picture.

I disagree and have done quite some reverse engineering out of private interest. To me it was mostly about learning and applying an excessive amount of knowledge about obscure trivia that can hardly be applied anywhere else (except perhaps for some really rare embedded developing stuff), such as knowledge about some obscure flags in the linker format, knowledge about aracane details of the call convention and instruction encoding, arcane features of the respective CPU/chipset that probably only OS developers are even aware of, etc.

This is what > 90% of reverse engineering consist of for me: Learning/having/applying an immense knowledge of a giant amount of arcane details that are hardly useful anywhere else.

> It's having an intuition of where to find the clues to solve the bigger puzzle.

I am not aware that I have used a lot of intuition. It is rather a lot about documenting everything well, documenting how each subsystem/function relates to others, ... lots of long, monotonous (but not boring) documentation. The reasons is that if you do not document a lot, you will soon be struck by the immense amount of details. A little bit like how you would document the inner workings of a space ship that landed on earth exhaustively in terms of lots engineering diagrams.